I've not seen direct comments on the proposed text (I've seen a
side discussion regarding this topic, so I know at least a few people
have been aware of the proposal).
I've already edited my local copy of rfc2462bis based on the proposal,
which will soon be submitted (probably within a week). It would be
very helpful if anyone who has a problem with the proposed text could
speak up at this timing.
Thanks,
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--- Begin Message ---
>>>>> On Fri, 28 May 2004 20:24:31 +0900,
>>>>> JINMEI Tatuya <[EMAIL PROTECTED]> said:
> I'd now like to resume the discussion on another set of outstanding
> issues for rfc2462bis: DAD related ones.
> Based on the past discussion, I'd like to propose the following basic
> approach:
> - basically, strongly recommend to perform DAD all unicast addresses
> (use much stronger recommendation than in the current RFC2462)
> - use consideration not to "invalidate" existing implementations
> that use the "DIID-like" optimization
> - (for issue 337) require to add a random delay before sending DAD
> NS if the address being checked is configured by a multicasted RA
(snip)
> I'll soon post specific proposed text in a separate message.
And the proposed text is attached below. Comments/suggestions/etc are
welcome, of course, and as usual.
For issue 275, revise the beginning of Section 5.4 as follows:
Duplicate Address Detection is performed on unicast addresses prior
to assigning them to an interface whose DupAddrDetectTransmits
variable is greater than zero. Duplicate Address Detection MUST take
place on all unicast addresses, regardless of whether they are
obtained through stateful, stateless or manual configuration, with
the exception of the following cases:
- Duplicate Address Detection MUST NOT be performed on anycast
addresses.
- Each individual unicast address SHOULD be tested for uniqueness.
However, there are implementations deployed that only performs
Duplicate Address Detection for the link-local address and skips
the test for the global address using the same interface
identifier as that of the link-local address. Whereas this
document does not invalidate such implementations, this kind of
"optimization" is NOT RECOMMENDED, and new implementations MUST
NOT do that optimization. This optimization came from the
assumption that all of an interface's addresses are generated
from the same identifier. However, the assumption does actually
not stand; new types of addresses have been introduced where the
interface identifiers are not necessarily the same for all
unicast addresses on a single interface [SEND-CGA, RFC3041].
Requiring to perform Duplicate Address Detection for all unicast
addresses will make the algorithm robust for the current and
future such special interface identifiers.
For issue 337, add the following paragraph between the third and
fourth paragraphs of Section 5.4.2:
Even if the Neighbor Solicitation is not going to be the first
message to be sent from an interface after interface
(re)initialization, the node SHOULD delay joining the solicited-node
multicast address by a random delay between 0 and
MAX_RTR_SOLICITATION_DELAY if the address being checked is configured
by a router advertisement message sent to a multicast address. The
delay will avoid similar congestion when multiple nodes are going to
configure addresses by a same single multicast router advertisement.
Note: I used "SHOULD" instead of "should" for the random delay, since
I believe we should use an RFC2119 keyword in this context. If this
makes sense, we'll also need to use "SHOULD" in the previous paragraph.
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--- End Message ---
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
