Hi Lorenzo,
Sorry about the delayed response (and thanks to Hemant for pointing this
out). Pls see inline,
> A couple of points that the draft doesn't explain:
>
> - Why can't the node simply retry DAD without the nonce option?
The node could simply do so, however, it wouldn't be able to
differentiate between the looped message and spoofed message.
Nonce usage significantly eliminates the possibility of a remote node
sending the spoofed message, and causing the node to think that circuit
being looped when it is not really.
> - How does the nonce option guarantee that the address is unique? Just
> probabilistically, because the nonce would have to collide?
Nonce doesn't guarantee anything by itself, IMO.
> - Why only send the nonce on the second (and subsequent?) messages?
Why not
> simply send out all NSes with nonces all the time?
This is a good Q. The reason is that the Nonce usage requires the node
to create and maintain the state for some time (t). It is useful when
there is a loop, so the rationale was to first detect the _possibility_
of loop after the 1st receipt and confirm it with Nonce so as to keep
IPv6 enabled.
Of course, the possibility of the remote node reflecting the same Nonce
value in the spoofed message certainly exists, though it is remote.
The full-proof way to solve this is SeND, needless to say.
> - What state is the address in while the timer is ticking?
UP (or UP/Looped).
> 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?
None of the proposals (including this one) stop the multicast packets
from coming back. Simplest thing is to drop them, based on the Nonce
value.
Cheers,
Rajiv
> -----Original Message-----
>
> 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
--------------------------------------------------------------------
