Just so everyone's on the same page, although this draft originally targets v6ops, it is going to be looked at in 6man (per the 6man chairs). That's a discussion you may want to have in 6man.
On Oct 11, 2011, at 11:39 AM, Hemant Singh (shemant) wrote: > 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: v6ops-boun...@ietf.org [mailto:v6ops-boun...@ietf.org] On Behalf Of > Lorenzo Colitti > Sent: Monday, August 29, 2011 6:15 AM > To: Erik Kline > Cc: v6...@ietf.org; draft-asati-v6ops-dad-loopb...@tools.ietf.org > Subject: Re: [v6ops] new draft: draft-asati-v6ops-dad-loopback > > On Mon, Aug 29, 2011 at 18:54, Erik Kline <e...@google.com> 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? > _______________________________________________ > v6ops mailing list > v6...@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops
-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
