Subject: [rfc2462bis issues 275/337] DAD issues

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 28 May 2004 20:24:31 +0900

Hello,

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

(see the long thread starting at the following message
http://www1.ietf.org/mail-archive/web/ipv6/current/msg01723.html
for the "past discussion)

A bit more detailed rationale is as follows:

First of all, my understanding of repeated discussions on DAD
optimization / DAD vs DIID / etc, in this wg is that the consensus (or
at least majority) has always been preferring DAD for all unicast
addresses.  I don't see no new significant news to reverse the past
result.  So, in the above proposal, I basically honor the past
consensus (or the preference of the majority).

Moreover, an important assumption on which the DIID-like optimization
depends does not necessarily hold: the assumption that all of an
interface's addresses are generated from the same identifier (and thus
it should be enough to check the uniqueness of the link-local address
only).  In fact, RFC3041 temporary addresses or SEND CGA addresses
break the assumption.  We've seen this could cause undetected
duplication when there are nodes that implement the DIID-like
optimization:
http://www1.ietf.org/mail-archive/web/ipv6/current/msg01842.html

As I pointed out in this (sub)thread, actual duplication should rarely
occur and this particular case happens to be a non issue in a
practical sense.  However, now that the basic assumption doesn't hold,
I believe it should be safer to require to perform DAD for all unicast
addresses, in order to prepare for the current and future such special
interface identifiers (like SEND CGA or RFC3041 IDs).

Meanwhile, we'll need to deal with a new issue pointed out in the
latest discussion that DAD NSs for addresses configured by a
multicasted RA can collide (issue 337).  But I think this should be a
separate issue from whether we should strongly recommend DAD for all
addresses or should allow omitting DAD by the DIID-like optimization.
In fact, there is a class of addresses that can be created by a
multicasted RA and always require DAD (e.g., a "bis" version of
RFC3041 requires to perform DAD for all temporary addresses).  Thus,
we'll need to deal with this issue anyway even if we "mandated" the
DIID-like optimization for EUI-64 based global addresses.

The easiest way to realize the strong recommendation of performing DAD
for all addresses is simply saying "MUST".  However, this might be
overkilling, considering there are implementations that support the
DIID-like optimization and we basically do not want to
break/invalidate existing implementations in the rfc2462bis work.  So
we need some kind of wording compromise here.

I'll soon post specific proposed text in a separate message.

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

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 28 May 2004 20:56:52 +0900

>>>>> On Fri, 28 May 2004 20:24:31 +0900, 
>>>>> JINMEI Tatuya <[email-masked]> said:

>     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

---

From: "Gerrit van Niekerk" <[email-masked]>
Date: Fri, 28 May 2004 15:16:42 +0200

I am a bit new to this list and could not pick up the specific thread for issue 
337, but it looks to me like the sending of the NS should be delayed and not 
the joining of the solicited-node multicast address.

>    configure addresses by a same single multicast router advertisement.

===============================================
Gerrit van Niekerk
GP van Niekerk Ondernemings BK
Roosstraat 211, Meyerspark, 0184, South Africa
Tel: +27(12)8036501 Fax: +27(12)8034131
Email: [email-masked], [email-masked]
Web: http://www.gpvno.co.za
===============================================

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 28 May 2004 22:23:38 +0900

>>>>> On Fri, 28 May 2004 15:16:42 +0200, 
>>>>> "Gerrit van Niekerk" <[email-masked]> said:

> the joining of the solicited-node multicast address.

No, saying "joining the multicast address" instead of "sending NS" is
intentional and important.  Actually, this is the result of solving a
separate issue for rfc2462bis.  draft-ietf-ipv6-rfc2462bis-00.txt
explains the rationale in Section 5.4.2:

   If the Neighbor Solicitation is 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 as specified in RFC
   2461 [5]. This serves to alleviate congestion when many nodes start
   up on the link at the same time, such as after a power failure, and
   may help to avoid race conditions when more than one node is trying
   to solicit for the same address at the same time.

   Note that the delay for joining the multicast address implicitly
   means delaying transmission of the corresponding MLD report message
   [9]. Since RFC 2710 [9] does not request a random delay to avoid race
   conditions, just delaying Neighbor Solicitation would cause
   congestion by the MLD report messages. The congestion would then
   prevent MLD-snooping switches from working correctly, and, as a
   result, prevent Duplicate Address Detection from working. The
   requirement to include the delay for the MLD report in this case
   avoids this scenario.

   In order to improve the robustness of the Duplicate Address Detection
   algorithm, an interface MUST receive and process datagrams sent to
   the all-nodes multicast address or solicited-node multicast address
   of the tentative address while the delaying period. This does not
   necessarily conflict with the requirement that joining the multicast
   group be delayed. In fact, in some cases it is possible for a node to
   start listening to the group during the delay period before MLD
   report transmission. It should be noted, however, that in some
   link-layer environments, particularly with MLD-snooping switches, no
   multicast reception will be available until the MLD report is sent.

					JINMEI, Tatuya

---

From: Markku Savela <[email-masked]>
Date: Fri, 28 May 2004 17:10:30 +0300

> From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=

>    result, prevent Duplicate Address Detection from working.

Just a refresh of my opinion on this (so that people don't forget):

  Sending MLD reports on link local multicast groups is silly, and
  SHOULD NOT be required.

It is not nice to require modifications and warts to perfectly working
RFC due to layer breaking entities like MLD-snooping
switches. Especially, when exactly the same information would be
available to them from the DAD NS. Join for "solicited node multicast
group" has exactly the same information as DAD NS.

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Sat, 29 May 2004 07:21:53 +0900 (JST)

> group" has exactly the same information as DAD NS.

	i understand your logic, but disagree.  what you are saying is
	"we can make MLD-and-NS-snooping switch and require no MLD for NS".
	MLD-and-NS-snooping switch is also a layer breaking entity.

itojun

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Mon, 31 May 2004 15:03:47 +0900

>>>>> On Sat, 29 May 2004 07:21:53 +0900 (JST), 
>>>>> [email-masked] (Jun-ichiro itojun Hagino) said:

> 	MLD-and-NS-snooping switch is also a layer breaking entity.

I second this opinion.

Whether or not we like the layer breaking entities, the problem is
real (or likely to happen).  So at least we need to describe the issue
somewhere.

Perhaps rfc2462bis may not be the best place for this, but I cannot
find a better place right now.  For now, I'd like to make the new
revision ship with the proposed wording.

					JINMEI, Tatuya