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?

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to