Subject: Reminder: Re: [rfc2462bis issues 275/337] DAD issues

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 02 Jun 2004 17:04:50 +0900

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

Subject: Re: [rfc2462bis issues 275/337] DAD issues
From: JINMEI Tatuya / 神明達哉<[email-masked]>
To: [email-masked]
Date: Fri, 28 May 2004 20:56:52 +0900
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>

>>>>> On Fri, 28 May 2004 20:24:31 +0900, 
>>>>> JINMEI Tatuya <[email-masked]> 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-masked]

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------