Subject: why is NA to DAD NS sent to all-nodes address?

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 20 Apr 2006 22:01:09 +0900

I encountered one quick question when I reread the spec...the neighbor
discovery specification (1970, 2461, and 2461bis) specifies the
responding NA to an NS for DAD (identified by the source address being
::) must be sent to all-nodes multicast address:

   If the source of the solicitation is the unspecified address, the
   node MUST set the Solicited flag to zero and multicast the
   advertisement to the all-nodes address.
(section 7.2.4 of 2461bis-05)

Does anyone know why this must be sent to the all-nodes address?  I
mean, why can't this be a solicited-node multicast address for the
target address?  Since the sender of the NS joins both the group
addresses according to the DAD specification, it seems to me that
either one should work fine.  Is there any special reason for the
address selection, or is this just an arbitrary choice?

					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: Erik Nordmark <[email-masked]>
Date: Thu, 20 Apr 2006 16:14:45 -0700

> address selection, or is this just an arbitrary choice?

The reason as I recall it was that when the IPv6 address is based on an 
EUI-64, a duplicate IPv6 address is an indication of a duplicate L2 
address. When the L2 address is a duplicate then sending the response to 
the *unicast* L2 address doesn't work.

We might not have thought of using the solicited-node multicast address 
as an optimization at the time, but settled for the all-nodes.
(We're not likely to see a lot of these packets after all.)

AFAICT using the solicited-node MC address should work as well.

    Erik

---

From: zou rong <[email-masked]>
Date: Fri, 21 Apr 2006 09:18:38 +0800

I think using all-node multicast address is better than using
solicited-node multicast address in the DAD, because in some kinds of
implement, for example, the hardware chipset or NP process program will
filter some kind of multicast packet if they are not be said have join
the multicast group. So, in the DAD scenario, when the address is still
in state "template", the implement maybe not open the right for chipset
or NP to let the "template address" solicited-node multicast packet in,
the NA packet maybe discard by the equipment, DAD process will be fail
to detect the duplicate address.

Lawrence

-----Original Message-----
From: Erik Nordmark [mailto:[email-masked]] 
Sent: Friday, April 21, 2006 7:15 AM
To: JINMEI Tatuya / ????
Cc: [email-masked]
Subject: Re: why is NA to DAD NS sent to all-nodes address?

    Erik

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 21 Apr 2006 15:56:33 -0700

> to detect the duplicate address.

But while the address is in tentative state, the host has to be able to 
receive a DAD NS sent by somebody else, and that NS is sent to the 
solicited-node multicast address.
The specification is pretty clear that the solicited-node multicast 
address must be joined before sending the DAD NS.

Note that the above is currently only needed to deal with the case when 
two host do DAD for the same IPv6 address at the same time (during the 
same 1 second interval).

    Erik

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 28 Apr 2006 16:36:11 +0900

Thanks for the prompt response, and sorry for my slow response.

>>>>> On Thu, 20 Apr 2006 16:14:45 -0700, 
>>>>> Erik Nordmark <[email-masked]> said:

> the *unicast* L2 address doesn't work.

That makes sense, of course, but as you said it doesn't answer the
question of why the NA's destination address cannot be the
solicited-node multicast address.

> AFAICT using the solicited-node MC address should work as well.

Okay, thanks.  (I agree it doesn't matter much due to the very limited
possibility of having such packets).

					JINMEI, Tatuya