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