Re: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion]
"Templin, Fred L" <Fred.L.Templin@boeing.com> Tue, 03 November 2015 22:37 UTC
Return-Path: <Fred.L.Templin@boeing.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 8F78D1B2CDD for <v6ops@ietfa.amsl.com>; Tue, 3 Nov 2015 14:37:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 whw3SbBfVivr for <v6ops@ietfa.amsl.com>; Tue, 3 Nov 2015 14:37:12 -0800 (PST)
Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E910B1B2CCF for <v6ops@ietf.org>; Tue, 3 Nov 2015 14:37:11 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id tA3MbAHg009872; Tue, 3 Nov 2015 16:37:10 -0600
Received: from XCH-PHX-510.sw.nos.boeing.com (xch-phx-510.sw.nos.boeing.com [10.57.37.27]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id tA3Mb3G2009825 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 3 Nov 2015 16:37:03 -0600
Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.14]) by XCH-PHX-510.sw.nos.boeing.com ([169.254.10.73]) with mapi id 14.03.0235.001; Tue, 3 Nov 2015 14:37:03 -0800
From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, Lorenzo Colitti <lorenzo@google.com>
Thread-Topic: DAD again [was: draft-ietf-v6ops-host-addr-availability discussion]
Thread-Index: AQHRFogofPNeczqv2U2vJopouDkBSA==
Date: Tue, 03 Nov 2015 22:37:02 +0000
Message-ID: <2134F8430051B64F815C691A62D9831832F3A88F@XCH-BLV-504.nw.nos.boeing.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>
In-Reply-To: <56392B6D.8030703@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [130.247.104.6]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/uIprL13vXgdPxL9CwCjSdx1glaY>
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: Tue, 03 Nov 2015 22:37:14 -0000
Hi Brian, > -----Original Message----- > From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] > Sent: Tuesday, November 03, 2015 1:47 PM > To: Templin, Fred L; Lorenzo Colitti > Cc: v6ops@ietf.org > Subject: DAD again [was: draft-ietf-v6ops-host-addr-availability discussion] > > Hello Fred, > > On 03/11/2015 20:10, Templin, Fred L wrote: > > Hi Brian, > > > >> -----Original Message----- > >> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] > >> Sent: Monday, November 02, 2015 6:55 PM > >> To: Templin, Fred L; Lorenzo Colitti > >> Cc: v6ops@ietf.org > >> Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability discussion > >> > >> Hi Fred, > >> On 03/11/2015 14:59, Templin, Fred L wrote: > >>> Hi Brian, > >>> > >>>> -----Original Message----- > >>>> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] > >>>> Sent: Monday, November 02, 2015 5:46 PM > >>>> To: Templin, Fred L; Lorenzo Colitti > >>>> Cc: v6ops@ietf.org > >>>> Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability discussion > >>>> > >>>> On 03/11/2015 14:31, Templin, Fred L wrote: > >>>>> Bumping up one level – is it clear to everyone that it is OK to assign addresses > >>>>> taken from a DHCPv6 delegated prefix to the interface over which the prefix > >>>>> was received? > >>>> > >>>> If it was legitimately received, I can't see why it wouldn't be OK. > >>> > >>> OK. When the DHCPv6 server grants a prefix delegation to the client, > >>> the server is asserting that that prefix is unique and is now the sole > >>> property of the client. So, when you say legitimately received I > >>> agree and that is actually a core requirement of DHCPv6 PD. > >>> Otherwise, if the DHCPv6 server gave out duplicate prefixes, the > >>> routing system would become hopelessly corrupted and address > >>> duplication would be the least of our worries. > >>> > >>>>> And, that DAD is not required for those addresses? > >>>> > >>>> How is that safe? What is to stop a host running SLAAC once it > >>>> sees that prefix in an RA, and hitting the same IID by chance? > >>>> At least you need to specify that the A bit must not be set. > >>> > >>> I am talking about DAD on interface "A" being the interface over > >>> which the client receives the prefix delegation. No other node on > >>> interface "A" may use the delegated prefix, and no router on > >>> interface "A" may advertise the prefix in an RA. The prefix is the > >>> sole property of the client that received the PD, so the client is > >>> free to assign addresses without needing DAD. > >> > >> That usage of "may" might confuse some people, so let's pretend > >> you used a "MUST NOT" construct instead. I could still construct > >> a host stack that would ignore the issue: its logic would be > >> "I sent an RS and got no RA/PIO with A=1; but I see traffic from > >> prefix 2bad:dead:beef::/64, so I'll do SLAAC and DAD in that prefix." > > > > The malicious (or otherwise broken) host 'A' could configure any number > > of addresses it likes, but it would do so in a vacuum because ingress > > filtering will prevent a packet with a source address from a prefix > > belonging to host B from being accepted. So, node B has no reason > > to fear address duplication by node A. > > I'm not sure how an ingress filter somewhere upstream would know that > the packet came from the "wrong" host. But I don't think that's enough; > a duplicate address on the LAN is already a problem in itself. > > > Also, what if node B in fact did do DAD and A heard it? What is to stop > > A from configuring a duplicate address and trying to use it just to mess > > up the legitimate operation of node B? > > Nothing. That, I think, is why the RFCs make DAD mandatory. > > > > > What you are describing is a broken implementation that could only > > be employed by a malicious host, and not something that honors > > the standards. > > I don't think it's malicious; it's just trying to get IPv6 connectivity > in the face of what it sees as a broken router that isn't responding > to RS. But that isn't really my point - my point is that whatever we > do, it's impossible to assert that a duplicate address will never arise. > > > Doing DAD is not going to guard against malicious > > hosts. > > No, but it might allow you to detect the resulting anomaly. Actually, the simpler answer to your question is that the node would act as a host internally, but appear to be a router on the link from an outside observer's perspective. And, routers do not do DAD for the source addresses of packets that pass through them. Thanks - Fred fred.l.templin@boeing.com > Brian > > > > > Thanks - Fred > > fred.l.templin@beoing.com > > > >>>> Come to that, a manual address might collide. > >>> > >>> The client itself is the only node that is permitted to assign addresses > >>> from the delegated prefix to an interface, so there is no risk of > >>> collision unless the client itself is somehow corrupt. > >> > >> Or another client on the same LAN gets too clever. > >> > >> Brian > >> > >>> > >>> Thanks - Fred > >>> fred.l.templin@boeing.com > >>> > >>>> Brian > >>>> > >>>>> > >>>>> Thanks - Fred > >>>>> > >>>>> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Templin, Fred L > >>>>> Sent: Monday, November 02, 2015 5:24 PM > >>>>> To: Lorenzo Colitti > >>>>> Cc: v6ops@ietf.org > >>>>> Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability discussion > >>>>> > >>>>> Hi Lorenzo, > >>>>> > >>>>> Responses below in “green”: > >>>>> > >>>>> From: Lorenzo Colitti [mailto:lorenzo@google.com] > >>>>> Sent: Monday, November 02, 2015 5:04 PM > >>>>> To: Templin, Fred L > >>>>> Cc: Fred Baker (fred); v6ops@ietf.org<mailto:v6ops@ietf.org> > >>>>> Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability discussion > >>>>> > >>>>> On Tue, Nov 3, 2015 at 8:59 AM, Templin, Fred L <Fred.L.Templin@boeing.com<mailto:Fred.L.Templin@boeing.com>> wrote: > >>>>> I have one text addition suggestion and one question. On P. 7, in Table 1, > >>>>> suggest adding a new final row as follows: > >>>>> > >>>>> requires DAD Yes Yes No N/A > >>>>> > >>>>> Meaning that multi-addresses configured by SLAAC or DHCPv6 IA_NA/IA_TA > >>>>> must use DAD to check for duplicates on the link they were obtained. In a > >>>>> multi-addressing environment where millions of addresses are required, > >>>>> this could amount to a substantial amount of DAD multicast traffic. On the > >>>>> other hand, DAD is not needed for DHCPv6 PD because the network has > >>>>> unambiguously delegated the prefix for the node's exclusive use. > >>>>> > >>>>> I don't think "Requires DAD: No" is correct. Even if the device gets a /64 prefix entirely for its own use, it still needs to do DAD > with > >>>> any other devices on that /64 (e.g., tethered devices, VMs, etc.). > >>>>> > >>>>> I'm not opposed to adding a line to the table, though I don't think it provides much value - if we put our mind to it, I'm sure we > >> could > >>>> come up with lots of things we could add to the table that aren't there at the moment. My main concern is that if we add > >> something to > >>>> the table it needs to be correct. > >>>>> > >>>>> What I mean is “Requires DAD on the interface over which the prefix was received”, > >>>>> but that was too long to fit in the table. Let’s call the interface “A”. If the node gets > >>>>> SLAAC addresses or DHCP IA_NA/IA_TA addresses over interface “A”, then it needs > >>>>> to do DAD on interface “A” for each such address. If the node gets a DHCPv6 PD > >>>>> over interface “A”, however, it does not need to do DAD over interface “A” at all. > >>>>> > >>>>> If the node assigns the delegated prefix to interface “B”, then you are right that > >>>>> that DAD will be required among all tethered devices, VMs, etc. on interface “B”. > >>>>> But, there will still be no need for DAD on interface “A”. Does that clarify? > >>>>> > >>>>> I have a question also on table 1. Under ""Unlimited" endpoints", why does > >>>>> it say "no" for DHCPv6 PD? I think it should say "yes" instead, since a prefix > >>>>> obtained by DHCPv6 PD can be used to configure an unlimited number of > >>>>> addresses on the link over which the prefix was received. > >>>>> > >>>>> The table is written from the perspective of the network assigning addresses to devices that connect to it. Therefore, it says > "no" > >>>> because if you use DHCPv6 PD you can't assign address space to an unlimited number of endpoints - you are limited to however > >> many > >>>> /64s you have available. > >>>>> > >>>>> If you use IA_NA or SLAAC, any network with a /64 subnet has, at least in theory, an "unlimited" number of addresses to assign > to > >>>> clients. Of course, that's only true in theory. In practice, there's going to be a limit due to scaling reasons. > >>>>> > >>>>> I don’t understand this. True that SLAAC and DHCPv6 IA_NA/IA_TA can be used > >>>>> to assign an unlimited number of addresses to interface “A”. But, so can DHCPv6 > >>>>> PD. When the node receives the delegated prefix (e.g., a /64), it can assign as > >>>>> many unique IPv6 addresses as it likes to interface “A”. And again, it need not > >>>>> do DAD for any of them. > >>>>> > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> v6ops mailing list > >>>>> v6ops@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/v6ops > >>>>> > >>> > >
- [v6ops] draft-ietf-v6ops-host-addr-availability d… Fred Baker (fred)
- Re: [v6ops] draft-ietf-v6ops-host-addr-availabili… Alexandre Petrescu
- Re: [v6ops] draft-ietf-v6ops-host-addr-availabili… Lorenzo Colitti
- Re: [v6ops] draft-ietf-v6ops-host-addr-availabili… Templin, Fred L
- Re: [v6ops] draft-ietf-v6ops-host-addr-availabili… Lorenzo Colitti
- Re: [v6ops] draft-ietf-v6ops-host-addr-availabili… Templin, Fred L
- Re: [v6ops] draft-ietf-v6ops-host-addr-availabili… Templin, Fred L
- Re: [v6ops] draft-ietf-v6ops-host-addr-availabili… Brian E Carpenter
- Re: [v6ops] draft-ietf-v6ops-host-addr-availabili… David Farmer
- Re: [v6ops] draft-ietf-v6ops-host-addr-availabili… Templin, Fred L
- Re: [v6ops] draft-ietf-v6ops-host-addr-availabili… David Farmer
- Re: [v6ops] draft-ietf-v6ops-host-addr-availabili… Templin, Fred L
- Re: [v6ops] draft-ietf-v6ops-host-addr-availabili… Lorenzo Colitti
- Re: [v6ops] draft-ietf-v6ops-host-addr-availabili… Templin, Fred L
- Re: [v6ops] draft-ietf-v6ops-host-addr-availabili… Lorenzo Colitti
- Re: [v6ops] draft-ietf-v6ops-host-addr-availabili… Brian E Carpenter
- Re: [v6ops] draft-ietf-v6ops-host-addr-availabili… Alexandre Petrescu
- Re: [v6ops] draft-ietf-v6ops-host-addr-availabili… Lorenzo Colitti
- Re: [v6ops] draft-ietf-v6ops-host-addr-availabili… Alexandre Petrescu
- Re: [v6ops] draft-ietf-v6ops-host-addr-availabili… Lorenzo Colitti
- Re: [v6ops] draft-ietf-v6ops-host-addr-availabili… Alexandre Petrescu
- Re: [v6ops] draft-ietf-v6ops-host-addr-availabili… David Farmer
- Re: [v6ops] draft-ietf-v6ops-host-addr-availabili… Lorenzo Colitti
- Re: [v6ops] draft-ietf-v6ops-host-addr-availabili… Templin, Fred L
- Re: [v6ops] draft-ietf-v6ops-host-addr-availabili… Templin, Fred L
- Re: [v6ops] draft-ietf-v6ops-host-addr-availabili… Templin, Fred L
- Re: [v6ops] draft-ietf-v6ops-host-addr-availabili… Templin, Fred L
- Re: [v6ops] draft-ietf-v6ops-host-addr-availabili… David Farmer
- Re: [v6ops] draft-ietf-v6ops-host-addr-availabili… Lorenzo Colitti
- Re: [v6ops] draft-ietf-v6ops-host-addr-availabili… David Farmer
- Re: [v6ops] draft-ietf-v6ops-host-addr-availabili… Alexandre Petrescu
- Re: [v6ops] draft-ietf-v6ops-host-addr-availabili… Templin, Fred L
- Re: [v6ops] draft-ietf-v6ops-host-addr-availabili… Alexandre Petrescu
- Re: [v6ops] draft-ietf-v6ops-host-addr-availabili… Templin, Fred L
- [v6ops] DAD again [was: draft-ietf-v6ops-host-add… Brian E Carpenter
- Re: [v6ops] DAD again [was: draft-ietf-v6ops-host… Templin, Fred L
- Re: [v6ops] DAD again [was: draft-ietf-v6ops-host… Philip Homburg
- Re: [v6ops] DAD again [was: draft-ietf-v6ops-host… Templin, Fred L
- Re: [v6ops] draft-ietf-v6ops-host-addr-availabili… Templin, Fred L
- Re: [v6ops] DAD again [was: draft-ietf-v6ops-host… Mukom Akong T.
- Re: [v6ops] DAD again [was: draft-ietf-v6ops-host… Templin, Fred L
- Re: [v6ops] DAD again [was: draft-ietf-v6ops-host… 神明達哉
- Re: [v6ops] DAD again [was: draft-ietf-v6ops-host… Lorenzo Colitti
- Re: [v6ops] DAD again [was: draft-ietf-v6ops-host… Hemant Singh (shemant)
- Re: [v6ops] DAD again [was: draft-ietf-v6ops-host… Alexandre Petrescu
- Re: [v6ops] DAD again [was: draft-ietf-v6ops-host… Alexandre Petrescu
- Re: [v6ops] DAD again [was: draft-ietf-v6ops-host… Hemant Singh (shemant)
- Re: [v6ops] DAD again [was: draft-ietf-v6ops-host… Gert Doering
- Re: [v6ops] DAD again [was: draft-ietf-v6ops-host… Hemant Singh (shemant)
- Re: [v6ops] DAD again [was: draft-ietf-v6ops-host… Gert Doering
- Re: [v6ops] DAD again [was: draft-ietf-v6ops-host… Owen DeLong
- Re: [v6ops] DAD again [was: draft-ietf-v6ops-host… Hemant Singh (shemant)
- Re: [v6ops] DAD again [was: draft-ietf-v6ops-host… Owen DeLong
- Re: [v6ops] DAD again [was: draft-ietf-v6ops-host… Hemant Singh (shemant)
- Re: [v6ops] DAD again [was: draft-ietf-v6ops-host… Owen DeLong
- Re: [v6ops] DAD again [was: draft-ietf-v6ops-host… Hemant Singh (shemant)
- Re: [v6ops] DAD again [was: draft-ietf-v6ops-host… Owen DeLong
- Re: [v6ops] DAD again [was: draft-ietf-v6ops-host… Hemant Singh (shemant)
- Re: [v6ops] DAD again [was: draft-ietf-v6ops-host… Owen DeLong
- Re: [v6ops] DAD again [was: draft-ietf-v6ops-host… Hemant Singh (shemant)
- Re: [v6ops] DAD again [was: draft-ietf-v6ops-host… Gert Doering
- Re: [v6ops] DAD again [was: draft-ietf-v6ops-host… Hemant Singh (shemant)
- Re: [v6ops] DAD again [was: draft-ietf-v6ops-host… Gert Doering
- Re: [v6ops] DAD again [was: draft-ietf-v6ops-host… Hemant Singh (shemant)
- Re: [v6ops] DAD again [was: draft-ietf-v6ops-host… Gert Doering
- Re: [v6ops] DAD again [was: draft-ietf-v6ops-host… Hemant Singh (shemant)
- Re: [v6ops] DAD again [was: draft-ietf-v6ops-host… Owen DeLong
- Re: [v6ops] DAD again [was: draft-ietf-v6ops-host… Hemant Singh (shemant)
- Re: [v6ops] DAD again [was: draft-ietf-v6ops-host… Hemant Singh (shemant)
- Re: [v6ops] DAD again [was: draft-ietf-v6ops-host… Templin, Fred L
- Re: [v6ops] DAD again [was: draft-ietf-v6ops-host… Owen DeLong
- Re: [v6ops] DAD again [was: draft-ietf-v6ops-host… Hemant Singh (shemant)
- Re: [v6ops] DAD again [was: draft-ietf-v6ops-host… Templin, Fred L
- Re: [v6ops] DAD again [was: draft-ietf-v6ops-host… Hemant Singh (shemant)
- Re: [v6ops] DAD again [was: draft-ietf-v6ops-host… Owen DeLong
- Re: [v6ops] DAD again [was: draft-ietf-v6ops-host… Owen DeLong
- Re: [v6ops] DAD again [was: draft-ietf-v6ops-host… Brian E Carpenter
- Re: [v6ops] DAD again [was: draft-ietf-v6ops-host… Templin, Fred L
- Re: [v6ops] draft-ietf-v6ops-host-addr-availabili… David Schinazi
- Re: [v6ops] draft-ietf-v6ops-host-addr-availabili… David Farmer