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