Re: New Version Notification for draft-chakrabarti-nordmark-6man-efficient-nd-05.txt

神明達哉 <jinmei@wide.ad.jp> Mon, 03 March 2014 17:58 UTC

Return-Path: <jinmei.tatuya@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 141F71A0177 for <ipv6@ietfa.amsl.com>; Mon, 3 Mar 2014 09:58:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.922
X-Spam-Level: *
X-Spam-Status: No, score=1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R_pgdNdZmdqh for <ipv6@ietfa.amsl.com>; Mon, 3 Mar 2014 09:58:15 -0800 (PST)
Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 5EDAE1A02D7 for <ipv6@ietf.org>; Mon, 3 Mar 2014 09:58:14 -0800 (PST)
Received: by mail-we0-f176.google.com with SMTP id x48so3644954wes.35 for <ipv6@ietf.org>; Mon, 03 Mar 2014 09:58:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=mWcFxuUiDRyVxeYbqcCMnp76EMH7EIdHZqk8GsGKclk=; b=i2eaPrcCwSIyerySjFBvR2lkBJ9TjxCSSTKDn0sK7Xa7SEqoLMUgR54RpyHgl35p07 90M1mq3JZDdganRZmbHolzvBvvR3fzYN0Jl2Hb4sUDEwkHX4eMf+p88RkgP1fLNUwQsz yqf1YvS0lBMy7jppsK/BebGy9SHx+fKmco10qIj6wN9wn/CVWjW4MugTcje/AM5Lp7S9 X3G4Pfdk9nkPJEmlRgS4629QNrGjdwZi90xIWOxgPpB9S6KLMznz68me8w3cLLDaSZMy x2OlKMXVwt/N1akk45QADui12zyKCrqC2jhDoVLwL4yT1FQEjtF0f0xvIBbEarf8ep2m y2+A==
MIME-Version: 1.0
X-Received: by 10.194.200.40 with SMTP id jp8mr11681789wjc.51.1393869475606; Mon, 03 Mar 2014 09:57:55 -0800 (PST)
Sender: jinmei.tatuya@gmail.com
Received: by 10.194.120.167 with HTTP; Mon, 3 Mar 2014 09:57:55 -0800 (PST)
In-Reply-To: <53149963.10900@acm.org>
References: <20140214235734.2509.63069.idtracker@ietfa.amsl.com> <52FF115C.30001@acm.org> <CAJE_bqdOiO2zyCvxsO4sEW+9ZMb0DoOyscNWP1=jedrBbbBkEA@mail.gmail.com> <530FA94B.3050802@acm.org> <CAJE_bqdF2-nH7GaC+j6PnRagDC0jDj0c0me6MOC6AsHNvDaedQ@mail.gmail.com> <5311DA0F.5070106@sonic.net> <CAJE_bqe+db_ojg_3hMkHOo2LCK7cuWmjMa=RgzF5UnWo2q7znQ@mail.gmail.com> <53149963.10900@acm.org>
Date: Mon, 03 Mar 2014 17:57:55 +0000
X-Google-Sender-Auth: il2_3jPCDlRZD7gEn1dLlUw-JsQ
Message-ID: <CAJE_bqcDR624UnAni63LiNEjBWYnQo_76qqxjObiHLLAE2ccig@mail.gmail.com>
Subject: Re: New Version Notification for draft-chakrabarti-nordmark-6man-efficient-nd-05.txt
From: 神明達哉 <jinmei@wide.ad.jp>
To: Erik Nordmark <nordmark@acm.org>
Content-Type: text/plain; charset="ISO-8859-1"
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/u_3kgxW7Mw1DmXZ4DUvGFNKvlYM
Cc: IETF IPv6 <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Mar 2014 17:58:17 -0000

At Mon, 03 Mar 2014 15:01:55 +0000,
Erik Nordmark <nordmark@acm.org> wrote:

> >> To have a unicast RA prior to having registered the link-local address,
> >> the router needs to use the SLLA option in the RS - this would be the
> >> same mechanism as in the draft for sending errors to NS/AROs.
> > What if the link-local address is a duplicate and that's because the
> > link-layer address is a duplicate?  If the unicast RA is supposed to
> > include an ARO whose status field is 1 and be sent to the (duplicate)
> > link-local address, it's not guaranteed the RA is delivered to the
> > node that sent the RS.
> We can not detect and handle duplicate MAC addresses using DAD in general.
>
> Even back when we first defined DAD we knew it could handle MAC address
> duplicates for Ethernet (assuming certain device driver behavior), but
> probably not on FDDI and Token Ring (due to how the ring maintenance
> worked).
>
> More recent work like dad-proxy assumes that the MAC addresses  are not
> duplicate, and the loopback case needs special care even when MAC
> addresses are unique.
>
> Using explicit registrations doesn't really change that. The
> registration needs some unique id (be it an EUI-64 or DCHP DUID) that is
> unique to tell apart a duplicate and a registration refresh. If your MAC
> address is not unique then your EUI-64 (or MAC address based DUID) is
> likely to also not be unique.

I'm not sure if I follow your logic.  Probably as you noted above
yourself, the original DAD took into account handling MAC address
duplicates, even if it may not always work.  On the other hand,
efficient-nd can never handle MAC address duplicates.  Since
efficient-nd seems to cover more general (even if not all) networks,
claiming it eliminates the need for multicast in specific cases
including DAD, I think it's important to clarify what it trades for it
(which is, in this case, the inability of handling MAC duplicates).

--
JINMEI, Tatuya