Hi, Sorry for late response.
Since NS(DAD) traverse the same link, couldn't we just use src MAC of the received NS(DAD) to identify if the NS is the one sent by the interface earlier? Am I missing something? THanks, washam 2011/10/11, Hemant Singh (shemant) <[email protected]>: > Lorenzo, > > > > I realized that the looping back of ND messages, especially during DAD > is an issue that needs to be solved at a fundamental level in ND DAD. > Thus I and Wes Beebee came up with a new document for 6man that has no > need to sending probes and then also raising questions such as the ones > you raised as in what is the state of the address while the timer is > ticking. You were on the right track with some of your statement > below. There was some fun integrating with SEND and also some other > subtle issues. I think our document can be referenced as an automated > means in the draft-asati-v6ops-dad-loopback. See > > > > http://www.ietf.org/id/draft-hsingh-6man-enhanced-dad-00.txt > > > > Hemant > > > > > > From: [email protected] [mailto:[email protected]] On Behalf > Of Lorenzo Colitti > Sent: Monday, August 29, 2011 6:15 AM > To: Erik Kline > Cc: [email protected]; [email protected] > Subject: Re: [v6ops] new draft: draft-asati-v6ops-dad-loopback > > > > On Mon, Aug 29, 2011 at 18:54, Erik Kline <[email protected]> wrote: > > +1 to section 3.2, generally. > > > > This is definitely a useful problem to solve. I have personally had to > work around this situation more than once, sometimes by disabling DAD > completely on routers. > > > > A couple of points that the draft doesn't explain: > > - Why can't the node simply retry DAD without the nonce option? > > - How does the nonce option guarantee that the address is unique? Just > probabilistically, because the nonce would have to collide? > > - Why only send the nonce on the second (and subsequent?) messages? Why > not simply send out all NSes with nonces all the time? > > - What state is the address in while the timer is ticking? > > > > Also: in some cases this happens when buggy drivers (typically wifi > drivers) loop back the node's own multicast packets. This is a violation > of 802.11, but nobody notices since it doesn't affect IPv4. With your > proposed scheme, DAD would succeed, but the node would be continuously > receiving its own multicast packets. What happens in such situations? > > -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
