At Thu, 22 Apr 2010 17:22:26 +0200, Jean-Michel Combes <jeanmichel.com...@gmail.com> wrote:
> 5.4.3. Receiving Neighbor Solicitation Messages > > [snip] > > If the source address of the Neighbor Solicitation is the unspecified > address, the solicitation is from a node performing Duplicate Address > Detection. If the solicitation is from another node, the tentative > address is a duplicate and should not be used (by either node). > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > But I must admit I don't see how the another node would be aware of > the tentative address is a duplicate. > Indeed, as the first node has to stop DAD after the another node's NS > message reception, this first node should not send new NS messages > with the same tentative address and so the another node should > validate this address ... I suspect the intended scenario was that nodes A and B simultaneously start DAD and send out their NSes (probably after some random delays) almost at the same time so that both nodes see the other NSes while still performing DAD: 1. node A starts DAD, waiting some random period 2. node B starts DAD, waiting some random period 3. node A sends out a DAD NS, waiting 1sec 4. node B sends out a DAD NS (before receiving and handling A's NS), waiting 1sec 5. node B receives A's NS, detect duplicate 6. node A receives B's NS, detect duplicate Of course, this could also go like this: 1. node A starts DAD, waiting some random period 2. node B starts DAD, waiting some random period 3. node A sends out a DAD NS, waiting 1sec 4. node B receives A's NS, detect duplicate (before the waiting period expires, so there's no NS from B) In this case, yes, A will keep using the address. Remember, DAD is not a 100% reliable protocol, and in some cases it can result in a suboptimal state. But in this specific case, the result is not as bad as the case where two or more nodes keep using a duplicate address (e.g., due to DAD NSes being dropped); at least one of the conflicting nodes can detect the duplicate. --- JINMEI, Tatuya Internet Systems Consortium, Inc. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
