Subject: [v6ops] Fwd: I-D Action: draft-yourtchenko-chown-rupik-v6ops-dad-3x-00.txt

From: Tim Chown <[email-masked]>
Date: Fri, 4 Jul 2014 17:24:33 +0100

Hi,

Just a quick note to explain this short draft.  If there is interest we’d be happy to present for 5-10 mins in Toronto.

We had a strange issue with ND management tools on our vendor’s wireless LAN controller, and as a result it was sending three copies of certain ND messages in very quick succession. On Mac OS X, this was triggered a positive DAD event, which meant OS X would deprecate the tentative address, and IPv6 would be disabled.

Certain other OSes continued to configure the interface successfully though, not considering the messages a DAD event. Which led to a confusing situation for the administrator to debug.

There’s probably a couple of resulting issues here:

1) There is different behaviour in response to triplicates of certain ND messages on different OSes. Is the preferred behaviour what the RFC says? We should certainly try to make the behaviour more predictable (even if the underlying cause is not a common one).

2) Is there a new DAD attack here beyond the classic “No, I already have that address, you can’t have it” one?  You could sniff for ND messages and generate duplicates to prevent (at least an OS X device) from configuring IPv6 successfully.  The rapid duplicates might not be looked for by existing tools that look for the classic DAD attack in action.

Tim

Begin forwarded message:

> From: [email-masked]
> Subject: I-D Action: draft-yourtchenko-chown-rupik-v6ops-dad-3x-00.txt
> Date: 4 July 2014 14:17:07 BST
> To: [email-masked]
> Reply-To: [email-masked]
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
>        Title           : DAD And Packet Triplication
>        Authors         : Andrew Yourtchenko
>                          Tim Chown
>                          Seb Rupik
> 	Filename        : draft-yourtchenko-chown-rupik-v6ops-dad-3x-00.txt
> 	Pages           : 4
> 	Date            : 2014-07-04
> 
> Abstract:
>   This draft captures the observation of IPv6 Duplicate Address
>   Detection behavior in the case of excessive packet replication (3x),
>   the latter caused by by a misbehaving device in the network.  Also it
>   compares the operation of IPv6 vs. IPv4 as a result.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-yourtchenko-chown-rupik-v6ops-dad-3x/
> 
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-yourtchenko-chown-rupik-v6ops-dad-3x-00

---

From: 神明達哉 <[email-masked]>
Date: Fri, 18 Jul 2014 10:49:20 -0700

At Fri, 4 Jul 2014 17:24:33 +0100,

> 1) There is different behaviour in response to triplicates of certain ND messages on different OSes. Is the preferred behaviour what the RFC says? We should certainly try to make the behaviour more…

To the extent of the usefulness of the DAD itself in general, I
believe what the RFC says is the preferred behavior.  The condition of
"when two nodes run Duplicate Address Detection simultaneously and
transmit solicitations at roughly the same time" will be rare, but I
can see it happen in practice (e.g. when multiple boxes that have
duplicate addresses reboot simultaneously after a power cycle).  So it
would be better to keep the ability to detect this case.

It seems the MacOS behavior is completely valid, and since the
description of RFC 4862 on this point is pretty clear, I don't
understand why (some) other implementations didn't behave that way.
I'd suspect it's some kind of bug, but it could still be a "feature",
since there's some flexibility about the expectation on the number of
received NSes:

   -  If the actual number of Neighbor Solicitations received exceeds
      the number expected based on the loopback semantics (e.g., the

So, if it's not a bug, those implementations presumably have some
interesting interpretation of the expectation.

In any case, it's already known that the loopback detection is not
reliable.  I think this particular variant of the problem should also
be addressed with draft-ietf-6man-enhanced-dad.  If and when it's
widely implemented, this specific problem will also be resolved.

BTW, on the draft: this clause wasn't really clear to me:

   because the replication happened on the
   very last point - at the network-client attachment.  So, the only

in particular, it wasn't clear what "at the network-client attachment"
means.  The description in your email is much clearer, so if you
revise the draft I suggest making it a bit more concrete so the
meaning will be clearer.

--
JINMEI, Tatuya