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

神明達哉 <jinmei@wide.ad.jp> Tue, 18 March 2014 15:39 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 C07B51A0404 for <ipv6@ietfa.amsl.com>; Tue, 18 Mar 2014 08:39:24 -0700 (PDT)
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 kfwOC2oHfCKo for <ipv6@ietfa.amsl.com>; Tue, 18 Mar 2014 08:39:23 -0700 (PDT)
Received: from mail-vc0-x231.google.com (mail-vc0-x231.google.com [IPv6:2607:f8b0:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 135C61A041B for <ipv6@ietf.org>; Tue, 18 Mar 2014 08:39:21 -0700 (PDT)
Received: by mail-vc0-f177.google.com with SMTP id if17so7384822vcb.36 for <ipv6@ietf.org>; Tue, 18 Mar 2014 08:39:13 -0700 (PDT)
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=3yGZZ4ZrGW8QbUu00uXhayTv9knOH5aJAu6xZquBU0M=; b=w2v4tnwmYoUTo5adP938IwPKDwqJjIvkxFRTe0HftuRvCwmHjGJPkmPcKwnLQDSH9W bTBDF8LYQaCylZD2xDpBYjGTNK6ZS4ZKO6JQE7lvv/JiVZ17XcFhO5rBWBR2Z/1/Bha1 85GqY7rle21J88ABw75O/EtFLu7P/YLaCYdqrHLCUopZPPL5KvnfV/P7R9sCJFST/FyE qAQU+EkYrBrJOjfC8nfafzxXB+WF/r1zEyRSDoS+PczOxRrwomxatUXn0Ba0bYvK8FbT HvN7FryATLSe/N+Jyy7lB+qRWL5sj2C7Lrc6+VPHbzp7elD5ap0OU8GKrl2Ps0IwlwMk gUPA==
MIME-Version: 1.0
X-Received: by 10.58.221.102 with SMTP id qd6mr800129vec.47.1395157153516; Tue, 18 Mar 2014 08:39:13 -0700 (PDT)
Sender: jinmei.tatuya@gmail.com
Received: by 10.220.173.133 with HTTP; Tue, 18 Mar 2014 08:39:13 -0700 (PDT)
In-Reply-To: <5318ADFB.5070807@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> <CAJE_bqcDR624UnAni63LiNEjBWYnQo_76qqxjObiHLLAE2ccig@mail.gmail.com> <5318ADFB.5070807@acm.org>
Date: Tue, 18 Mar 2014 08:39:13 -0700
X-Google-Sender-Auth: KbgkIU-CgT4I84VQCFvIQPBXgPQ
Message-ID: <CAJE_bqcJVRCjrdWzkDuca6Nxic3X1EbLPqcATETNBifGGxaDGw@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/tSyroY3pEbZQIDHIY4zkQrMh6Yg
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: Tue, 18 Mar 2014 15:39:25 -0000

At Thu, 06 Mar 2014 17:18:51 +0000,
Erik Nordmark <nordmark@acm.org> wrote:

> >> 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.
>
> Any mechanism (be it ARO or DHCPv6) which allows a node to register
> something depends on a unique way to identify the registrants (the nodes).
[...]
> The second issue is how the host can communicate (with the
> routers/relays to do ARO/DHCPv6) if at L2 they do not have a unique
> link-layer address. They need to be able to receive response packets.
> That is hard in general. FWIW in 4861/62 that was solved by the DAD
> response (when a duplicate) being multicast at L2.

Right, so what I wanted to say in the original context was:
- the original DAD can detect MAC address duplicates thanks to the use
  of multicasting
- efficient-nd cannot do that as long as its main purpose is to avoid
  multicasting in the first place

Or in other words, "avoiding multicast" and "performing DAD" cannot
completely be achieved at the same time in efficient-nd.  And hence,
the following:

> >> 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).
> Yes, it makes sense to clarify that.

--
JINMEI, Tatuya