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 PROTECTED] Sent: Friday, April 21, 2006 7:15 AM To: JINMEI Tatuya / ???? Cc: ipv6@ietf.org Subject: Re: why is NA to DAD NS sent to all-nodes address? JINMEI Tatuya / ???? wrote: > 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? 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 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------