Re: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion]

Lorenzo Colitti <lorenzo@google.com> Fri, 13 November 2015 03:07 UTC

Return-Path: <lorenzo@google.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFF5E1B3F29 for <v6ops@ietfa.amsl.com>; Thu, 12 Nov 2015 19:07:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.088
X-Spam-Level:
X-Spam-Status: No, score=-1.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 3tvXHdofK_eZ for <v6ops@ietfa.amsl.com>; Thu, 12 Nov 2015 19:07:16 -0800 (PST)
Received: from mail-yk0-x235.google.com (mail-yk0-x235.google.com [IPv6:2607:f8b0:4002:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 514F01B3F28 for <v6ops@ietf.org>; Thu, 12 Nov 2015 19:07:16 -0800 (PST)
Received: by ykdv3 with SMTP id v3so127195441ykd.0 for <v6ops@ietf.org>; Thu, 12 Nov 2015 19:07:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=BvHKjUkjtF65UpHlb/YC058HZx+HQgeXcJWJqCzcnP8=; b=PwoEo+xR3vuQxMW148tsZhagWpC0WnAu6rtKk7aN4tRy6IfdcCGMzmk2I/aVZXWd0y HW2FV2yAdZx/ddQiQqBv4xJGJU20WG0JvsQ6iEBM1LlBu/wZniHcM/gv6aOWCyrX9VlL iJ7MrtvRvMYTW3VPtluSSwamDSUknX0s1uSvU1JHUqVpmQ8PdcPKJXGwL/B31SS2qVN6 /x1E9LpEk5iQd5ZJCYfezvj6bxpR1B9RM2EDBxDhNU/OJi5gXySZvFEdlXGyERZ7tLy3 H3DtGAqHQ+MW/CIxr3DEkGCWSJlxFlyVq5lx40RSp2/MQsrziVmK+gfz0s2Hj5k63hjV xpoQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=BvHKjUkjtF65UpHlb/YC058HZx+HQgeXcJWJqCzcnP8=; b=WK3ubSRtPYMdniWxG5H0oRe+yojrWPY2t5ezJvx6w0C//5xpVWyTK8e8RKv5MRXq7D zTrRvLuJAA7ahkAPEURMrZeW2zWb5bvIGZ9MyQXxLsWn1J9pXFLxukPCznZ2Fr8QjaF2 jRpOU3IXOJ09gc7EF0Hctu5iyn3r4ZvyhV7xAdB0js7mQK85dX282bbl1JjumoNWXt75 whacq6iKKFhySkvYwi6TD0rWI0jy2VNAybeNeBSzNxR6NfS7rNsqmxXWreZXtyut5cLO ActdSjuYoTgUtcqExSB3vO7CMl18hm/fdLaLZuy8kexupBoYKd0jsOpT/m3++ULvXhtw ekfA==
X-Gm-Message-State: ALoCoQlmmI9Z3B8oCrt7rXG85ndduKH9EKgzG4LlJwSVSrymOt/0EG/PC5g8y0zRsKOOgnCDyL/E
X-Received: by 10.129.136.5 with SMTP id y5mr20051388ywf.35.1447384035434; Thu, 12 Nov 2015 19:07:15 -0800 (PST)
MIME-Version: 1.0
Received: by 10.37.115.131 with HTTP; Thu, 12 Nov 2015 19:06:55 -0800 (PST)
In-Reply-To: <CAJE_bqd-1x5EJ=rkebiBFdNds6so5+iNGftiUf+MUu9P1up1bA@mail.gmail.com>
References: <8D175A1F-B1AE-44B4-838E-1C853B6C937D@cisco.com> <2134F8430051B64F815C691A62D9831832F391A7@XCH-BLV-504.nw.nos.boeing.com> <CAKD1Yr15C-uoxUw0kgWO-d=LmUK8qWGLS7vt+22W+k8xXtDY+g@mail.gmail.com> <2134F8430051B64F815C691A62D9831832F393F1@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3941D@XCH-BLV-504.nw.nos.boeing.com> <563811DF.9020603@gmail.com> <2134F8430051B64F815C691A62D9831832F394F7@XCH-BLV-504.nw.nos.boeing.com> <563821EB.3040508@gmail.com> <2134F8430051B64F815C691A62D9831832F39A09@XCH-BLV-504.nw.nos.boeing.com> <56392B6D.8030703@gmail.com> <2134F8430051B64F815C691A62D9831832F3A88F@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3A97F@XCH-BLV-504.nw.nos.boeing.com> <CAHDzDLBG8xZxUFsAuN-7WuruZcULF1QAS_ch=gD5rGQMZfskow@mail.gmail.com> <2134F8430051B64F815C691A62D9831832F3E8B0@XCH-BLV-504.nw.nos.boeing.com> <CAJE_bqd-1x5EJ=rkebiBFdNds6so5+iNGftiUf+MUu9P1up1bA@mail.gmail.com>
From: Lorenzo Colitti <lorenzo@google.com>
Date: Fri, 13 Nov 2015 12:06:55 +0900
Message-ID: <CAKD1Yr1X8UzQ58FeG6PYG9L1MyibV0J-JpcS2hxwzCdV=HizXg@mail.gmail.com>
To: =?UTF-8?B?56We5piO6YGU5ZOJ?= <jinmei@wide.ad.jp>
Content-Type: multipart/alternative; boundary=001a114effba49d1880524635bd2
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/Cu53jS3WEQ8ko3-LgVQ8dUe7xaE>
Cc: "v6ops@ietf.org" <v6ops@ietf.org>
Subject: Re: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion]
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Nov 2015 03:07:18 -0000

On Fri, Nov 13, 2015 at 11:36 AM, 神明達哉 <jinmei@wide.ad.jp> wrote:

> I think I understand what you are trying to say, and I tend to agree
> that it would be quite unlikely that someone else than node 'N' is
> using address 'A' in the WAN link in practice in this scenario.
> However, I think it's dangerous to just jump to the conclusion that
> DAD is not necessary in this case in some kind of standard document.
> In my understanding, DAD is designed to cover "quite unlikely
> scenarios" including cases with some broken implementations/operation.
> In this particular scenario, I would say that the original intent of
> DAD covers an "unlikely" case where the remote (or some other,
> depending the type of link) node of the WAN link is broken or some
> invalid operation and is actually using address "A".
>

RFC 4862 is says:   Duplicate Address Detection MUST be performed on all
unicast addresses prior to assigning them to an interface.

That is true in almost all cases, including DHCPv6 PD. For example, if a
device gets a /64 via DHCPv6 PD, and shares that /64 via a wifi hotspot,
then any address that the device itself forms out of that /64 MUST perform
DAD so that other devices connected to the wifi hotspot do not use the same
address.

At most we could slightly amend this to ..."MUST be performed on all
unicast addresses prior to assigning them to an interface except a loopback
interface". Even node-internal interfaces are not necessarily safe to omit
DAD on. For example, in a mobile device the application processor and
baseband processor might both be on the same link, and because they are two
separate processors running two separate network stacks, they need to do
DAD.