ietf
[Top] [All Lists]

RE: Review of draft-ietf-dna-simple

2010-08-19 17:01:57
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:rdroms(_dot_)ietf(_at_)gmail(_dot_)com] 
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:

   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:

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. of [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?
 
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf


_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>