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