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

From: <[email-masked]>
Date: Fri, 26 Aug 2011 06:55:00 -0700 (PDT)

A new draft has been posted, at http://tools.ietf.org/html/draft-asati-v6ops-dad-loopback. Please take a look at it and comment.

---

From: Erik Kline <[email-masked]>
Date: Mon, 29 Aug 2011 18:54:59 +0900

+1 to section 3.2, generally.

On 26 August 2011 22:55,  <[email-masked]> wrote:
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 29 Aug 2011 19:15:22 +0900

> +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?