Subject: Review of draft-ietf-dna-simple

From: "Bernard Aboba" <[email-masked]>
Date: Wed, 18 Aug 2010 15:19:06 -0700

Overall, I think the document the document looks good.  Some comments:

Section 2.4

   The host uses a combination of unicast
   Neighbor Solicitations (NSs), multicast Router Solicitations (RSs)
   and DHCPv6 message exchanges in order to determine whether previously
   encountered routers are present on the link, and if they are not,
   acquire the new configuration information.

[BA] Since DHCPv6 operation isn't affected, it might be more accurate to say
the following: 

   The host uses a combination of unicast
   Neighbor Solicitations (NSs) and multicast Router Solicitations (RSs)
   in order to determine whether previously
   encountered routers are present on the link, in which case an
   existing configuration can be reused.  If previously encountered
   routers are not present then either IPv6 Stateless Address
Autoconfiguration
   and/or DHCPv6 is used for configuration.  

Section 5.3

   o  Sending of neighbor discovery and/or DHCPv6 probes

[BA] When Simple DNA is used, neighbor discovery probes are always sent, and
DHCPv6 operation is not affected.  So I'd change this to:

.         Sending of neighbor discovery probes.

5.7.2.  Receiving Router Advertisements

   On reception of a Router Advertisement the host MUST go through the
   SDAT and mark all the addresses associated with the router (both
   SLAAC and DHCPv6 acquired) as inoperable.  The host MUST then process
   the Router Advertisement as specified in Section 6.3.4
<http://tools.ietf.org/html/draft-ietf-dna-simple-16#section-6.3.4> . of
[RFC4861 <http://tools.ietf.org/html/rfc4861> ].
 
[BA] I don't understand why the first sentence is necessary in the case
where
the addresses have already been confirmed via Neighbor probes. 
 
Section 5.11
 
   If a response is received to any unicast Neighbor Solicitation or
   Router Solicitation message, pending retransmissions MUST be
   canceled.
 
[BA] Why should receipt of a response to a Neighbor Solicitation cancel
pending retransmissions of a Router Solicitation?

---

From: Ralph Droms <[email-masked]>
Date: Thu, 19 Aug 2010 17:50:04 -0400

Bernard - this text is, in my opinion, intended to sync the internal data structures if the RA advertises different prefixes than the last time the host was attached to this link:

   On reception of a Router Advertisement the host MUST go through the
   SDAT and mark all the addresses associated with the router (both
   SLAAC and DHCPv6 acquired) as inoperable.

- Ralph

On Aug 18, 2010, at 6:19 PM 8/18/10, Bernard Aboba wrote:

> [BA] Since DHCPv6 operation isn’t affected, it might be more accurate to say the following:
>  
>    routers are not present then either IPv6 Stateless Address Autoconfiguration
> [BA] When Simple DNA is used, neighbor discovery probes are always sent, and DHCPv6 operation is not affected.  So I’d change this to:
>  
> ·         Sending of neighbor discovery probes.
>  
>  
>    the Router Advertisement as specified in Section 6.3.4. of [RFC4861].
>  
> [BA] I don’t understand why the first sentence is necessary in the case where
> [BA] Why should receipt of a response to a Neighbor Solicitation cancel pending retransmissions of a Router Solicitation?
>  
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

---

From: "Bernard Aboba" <[email-masked]>
Date: Thu, 19 Aug 2010 15:00:38 -0700

In that scenario, it makes sense to me. 

However, if the RA advertises the same prefixes would there be a reason to
mark all addresses as inoperable? 

-----Original Message-----
From: Ralph Droms [mailto:[email-masked]] 
Sent: Thursday, August 19, 2010 2:50 PM
To: Bernard Aboba
Cc: IETF Discussion
Subject: Re: Review of draft-ietf-dna-simple

Bernard - this text is, in my opinion, intended to sync the internal data
structures if the RA advertises different prefixes than the last time the
host was attached to this link:

- Ralph

On Aug 18, 2010, at 6:19 PM 8/18/10, Bernard Aboba wrote:

> [BA] Since DHCPv6 operation isn't affected, it might be more accurate to
Autoconfiguration
> [BA] When Simple DNA is used, neighbor discovery probes are always sent,
and DHCPv6 operation is not affected.  So I'd change this to:
> [BA] I don't understand why the first sentence is necessary in the 
> case where the addresses have already been confirmed via Neighbor probes.
>  
> Section 5.11
>

---

From: Ralph Droms <[email-masked]>
Date: Thu, 19 Aug 2010 18:01:57 -0400

I am OK with publication of the document if Bernard's comments are addressed.

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Thu, 19 Aug 2010 18:02:59 -0400

I think the issue is trying to describe the behavior from an implementation rather than functional perspective.  The goal is to ensure that only those addresses derived from prefixes in the RA are marked as operable.

- Ralph

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 19 Aug 2010 18:03:14 -0400

Hi Bernard,

> mark all addresses as inoperable? 

The reason I changed it to do it this way was to simplify RA processing. 
Now, the RA gets processed based on standard RFC4861/RFC4862 processing. 
In the earlier versions of the draft I was comparing the prefixes in the 
RA to those in the SDAT and selectively marking the absent prefixes as 
inoperable. Ralph suggested this simplification and it made perfect 
sense to do so.

Thanks
Suresh