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

Alexandre Petrescu <alexandre.petrescu@gmail.com> Fri, 13 November 2015 13:00 UTC

Return-Path: <alexandre.petrescu@gmail.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 8EFD51A6F27 for <v6ops@ietfa.amsl.com>; Fri, 13 Nov 2015 05:00:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.983
X-Spam-Level:
X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 0Rd3gXA6EbV9 for <v6ops@ietfa.amsl.com>; Fri, 13 Nov 2015 05:00:21 -0800 (PST)
Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 536191A6F32 for <v6ops@ietf.org>; Fri, 13 Nov 2015 05:00:21 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id tADD0ISr013794 for <v6ops@ietf.org>; Fri, 13 Nov 2015 14:00:19 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id B0B68204FAD for <v6ops@ietf.org>; Fri, 13 Nov 2015 14:06:30 +0100 (CET)
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id A920D204F10 for <v6ops@ietf.org>; Fri, 13 Nov 2015 14:06:30 +0100 (CET)
Received: from [127.0.0.1] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id tADD0ICU028415 for <v6ops@ietf.org>; Fri, 13 Nov 2015 14:00:18 +0100
To: v6ops@ietf.org
References: <8D175A1F-B1AE-44B4-838E-1C853B6C937D@cisco.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> <CAKD1Yr1X8UzQ58FeG6PYG9L1MyibV0J-JpcS2hxwzCdV=HizXg@mail.gmail.com>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <5645DEE2.5050108@gmail.com>
Date: Fri, 13 Nov 2015 14:00:18 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <CAKD1Yr1X8UzQ58FeG6PYG9L1MyibV0J-JpcS2hxwzCdV=HizXg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/GQ8p2eCXRskGUF1QLK_qevd-nEg>
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 13:00:23 -0000


Le 13/11/2015 04:06, Lorenzo Colitti a écrit :
> On Fri, Nov 13, 2015 at 11:36 AM, 神明達哉 <jinmei@wide.ad.jp
> <mailto: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.

YEs, but there are additional cases of assigning an address of the 
delegated prefix.  The device is a non-tethering device, forms an 
address out of the delegated prefix, and assigns it on its egress interface.

Since the prefix is delegated to that device exclusively then the device 
is safe to assume no-one else would form an address ouf of it.  Hence no 
need of DAD.

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

That sounds reasonable for the loopback interface.

Alex

  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.
>
>
> _______________________________________________ v6ops mailing list
> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops
>