Re: [v6ops] new draft: draft-asati-v6ops-dad-loopback

[Washam Fan <[e-mail]>]

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) <[e-mail]>:
> 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: [e-mail] [mailto:[e-mail]] On Behalf
> Of Lorenzo Colitti
> Sent: Monday, August 29, 2011 6:15 AM
> To: Erik Kline
> Cc: [e-mail]; [e-mail]
> Subject: Re: [v6ops] new draft: draft-asati-v6ops-dad-loopback
>
>
>
> On Mon, Aug 29, 2011 at 18:54, Erik Kline <[e-mail]> 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?
>
>