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

Erik Nordmark <> Thu, 06 March 2014 17:19 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 958D21A029E for <>; Thu, 6 Mar 2014 09:19:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.935
X-Spam-Status: No, score=-0.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IOTxJxf2vnbH for <>; Thu, 6 Mar 2014 09:19:01 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 7FFC71A0290 for <>; Thu, 6 Mar 2014 09:19:01 -0800 (PST)
Received: from [] ( []) (authenticated bits=0) by (8.14.4/8.14.4) with ESMTP id s26HIpov021222 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 6 Mar 2014 09:18:52 -0800
Message-ID: <>
Date: Thu, 06 Mar 2014 17:18:51 +0000
From: Erik Nordmark <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: 神明達哉 <>, Erik Nordmark <>
Subject: Re: New Version Notification for draft-chakrabarti-nordmark-6man-efficient-nd-05.txt
References: <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Sonic-ID: C;jOUVY1Ol4xGap7RWCY+HFQ== M;TnmSY1Ol4xGap7RWCY+HFQ==
Cc: IETF IPv6 <>
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 06 Mar 2014 17:19:02 -0000

On 3/3/14 5:57 PM, 神明達哉 wrote:
> At Mon, 03 Mar 2014 15:01:55 +0000,
> Erik Nordmark <> 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.

sorry for being slow in responding.

>> 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).
For example, with DHCPv6 you can use a DUID which is MAC address plus 
Since two hosts with the same MAC address are likely to have picked a 
different timestamp, the DHCPv6 server can tell them apart (ditto for 
efficient-nd-05 using ARO - identical mechanism).

However, if there is no such unique identifier (except the MAC address 
itself) then they can't be told apart.

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.

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