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 On Aug 19, 2010, at 6:00 PM 8/19/10, Bernard Aboba wrote: > 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.ietf@xxxxxxxxx] > 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@xxxxxxxx >> https://www.ietf.org/mailman/listinfo/ietf > > _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf