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

神明達哉 <jinmei@wide.ad.jp> Fri, 18 July 2014 17:49 UTC

MIME-Version: 1.0
Sender: jinmei.tatuya@gmail.com
In-Reply-To: <EMEW3|a426ada81ef77e9eafb70a4999db5fd6q63HOW03tjc|ecs.soton.ac.uk|2A140777-ACCF-4995-B70E-7E88741EF570@ecs.soton.ac.uk>
References: <20140704131707.3952.10822.idtracker@ietfa.amsl.com> <2A140777-ACCF-4995-B70E-7E88741EF570@ecs.soton.ac.uk> <EMEW3|a426ada81ef77e9eafb70a4999db5fd6q63HOW03tjc|ecs.soton.ac.uk|2A140777-ACCF-4995-B70E-7E88741EF570@ecs.soton.ac.uk>
Date: Fri, 18 Jul 2014 10:49:20 -0700
Message-ID: <CAJE_bqcVJ=yXrgDC2Fye3vjJTWNZ9Vdm6saXUK5an1wvVGHrUQ@mail.gmail.com>
From: 神明達哉 <jinmei@wide.ad.jp>
To: Tim Chown <tjc@ecs.soton.ac.uk>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/JR14shYBfAr1nl2U2YSqnf7OQmI
Cc: v6ops WG <v6ops@ietf.org>
Subject: Re: [v6ops] Fwd: I-D Action: draft-yourtchenko-chown-rupik-v6ops-dad-3x-00.txt
Precedence: list

At Fri, 4 Jul 2014 17:24:33 +0100,
Tim Chown <tjc@ecs.soton.ac.uk> wrote:

> 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).

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

[v6ops] Fwd: I-D Action: draft-yourtchenko-chown-… Tim Chown
Re: [v6ops] Fwd: I-D Action: draft-yourtchenko-ch… 神明達哉