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(_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