Hi, 2010/4/22 JINMEI Tatuya / 神明達哉 <jin...@isc.org>: > 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.
OK. I see now. Thanks a lot for the clarification! Best regards. JMC. > > --- > JINMEI, Tatuya > Internet Systems Consortium, Inc. > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
