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

Erik Nordmark <nordmark@sonic.net> Wed, 19 March 2014 19:22 UTC

Return-Path: <nordmark@sonic.net>
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 10C471A07F1 for <ipv6@ietfa.amsl.com>; Wed, 19 Mar 2014 12:22:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.147
X-Spam-Level:
X-Spam-Status: No, score=-2.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547] autolearn=ham
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 lHVzu2ibNuZL for <ipv6@ietfa.amsl.com>; Wed, 19 Mar 2014 12:22:40 -0700 (PDT)
Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) by ietfa.amsl.com (Postfix) with ESMTP id A05091A07B9 for <ipv6@ietf.org>; Wed, 19 Mar 2014 12:22:40 -0700 (PDT)
Received: from [172.22.209.194] ([162.210.130.3]) (authenticated bits=0) by c.mail.sonic.net (8.14.4/8.14.4) with ESMTP id s2JJMSYK014042 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 19 Mar 2014 12:22:29 -0700
Message-ID: <5329EE77.9010506@sonic.net>
Date: Wed, 19 Mar 2014 12:22:31 -0700
From: Erik Nordmark <nordmark@sonic.net>
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: 神明達哉 <jinmei@wide.ad.jp>, Erik Nordmark <nordmark@acm.org>
Subject: Re: New Version Notification for draft-chakrabarti-nordmark-6man-efficient-nd-05.txt
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> <CAJE_bqcJVRCjrdWzkDuca6Nxic3X1EbLPqcATETNBifGGxaDGw@mail.gmail.com>
In-Reply-To: <CAJE_bqcJVRCjrdWzkDuca6Nxic3X1EbLPqcATETNBifGGxaDGw@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Sonic-ID: C;UpKiz5uv4xG7PrRWCY+HFQ== M;fEW7z5uv4xG7PrRWCY+HFQ==
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/zC6icV8pCpPYNBAzW5yRDCEQrfI
X-Mailman-Approved-At: Thu, 20 Mar 2014 07:35:00 -0700
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: Wed, 19 Mar 2014 19:22:43 -0000

On 3/18/14 8:39 AM, 神明達哉 wrote:
>
> 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
With a caveat or two. This only works on link-layers where the L2 will 
be functioning where there are duplicate MAC addresses (the duplicate 
MAC address can't prevent the link/interface from coming up at L2). And 
the link-layer must not filter out received L2 frames just because the 
MAC header contains your own MAC address, while the link-layer must not 
loop back a copy of the multicast frames you send.

> - 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.
I don't know if I'd call it "performing DAD" since what we are talking 
about is "performing MAD - Mac Address Duplicate Detection".

I don't think the multicast is the fundamental architectural.

There are two issues:
1. Being able to tell the difference between a host moving and redoing 
DAD from a different location (e.g., on a different switch port), and 
another host trying to use the same MAC address and IPv6 address.

2. If a duplicate is detected, how does the system deliver that 
notification to one (or both) of the parties which have the same MAC 
address.

In 4861/62 the link-layer constraints in my caveat above handle #1. In 
general one can't rely on the MAC address to tell them apart if you want 
to do MAD. But it can be done using unique characteristics beyond the 
MAC address (be that a random nonce as in enhanced-nd, some other 
factory-assigned globally unique identifier, or something large, random 
and stable like a public key).

In think #2 is the main area where multicast is helpful. However, it 
isn't always required. For instance, in a SAVI type setup the device can 
see that the two hosts are on different ports, and send out DAD error a 
particular port to target one of the two conflicting nodes. Multicast 
wouldn't be required for such a DAD error. But it assumes that the 
detector is placed in the topology where some other binding anchor can 
be used - different L2 ports in this example.

If you were to deploy efficient-nd's ARO in a switched Ethernet network 
(with learning bridges) the duplicate MAC will be detected and there is 
a pretty good chance it would be reported to the host - the NS/ARO sent 
to the router will cause L2 learning to send the error back to the most 
recent source of the MAC address. (But the original user of the 
duplicate MAC would see some disruption.)
And the router can log the existence of a duplicate address.
> 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.
Sounds like it will require an essay instead of a single sentence...

    Erik

> --
> JINMEI, Tatuya
>