Re: [v6ops] draft-ietf-v6ops-host-addr-availability discussion - address out of the delegated prefix, on the egress - no DAD

"Templin, Fred L" <Fred.L.Templin@boeing.com> Tue, 03 November 2015 07:13 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 C20461B2F20 for <v6ops@ietfa.amsl.com>; Mon, 2 Nov 2015 23:13:52 -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 o2-uyWIYdPv2 for <v6ops@ietfa.amsl.com>; Mon, 2 Nov 2015 23:13:50 -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 AA43D1B2F1E for <v6ops@ietf.org>; Mon, 2 Nov 2015 23:13:50 -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 tA37Dnmb000580; Tue, 3 Nov 2015 01:13:49 -0600
Received: from XCH-PHX-110.sw.nos.boeing.com (xch-phx-110.sw.nos.boeing.com [130.247.25.39]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id tA37DeNF000567 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 3 Nov 2015 01:13:41 -0600
Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.14]) by XCH-PHX-110.sw.nos.boeing.com ([169.254.10.147]) with mapi id 14.03.0235.001; Mon, 2 Nov 2015 23:13:40 -0800
From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
To: Alexandre Petrescu <alexandre.petrescu@gmail.com>, "v6ops@ietf.org" <v6ops@ietf.org>
Thread-Topic: [v6ops] draft-ietf-v6ops-host-addr-availability discussion - address out of the delegated prefix, on the egress - no DAD
Thread-Index: AQHRFgcqdk6EvbJyb0KpuVefeTAGTg==
Date: Tue, 3 Nov 2015 07:13:40 +0000
Message-ID: <2134F8430051B64F815C691A62D9831832F39A27@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> <5638223E.5090404@gmail.com>
In-Reply-To: <5638223E.5090404@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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/tEuOAlmnLMUsZ0RrhgFHQhso3ZY>
Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability discussion - address out of the delegated prefix, on the egress - no DAD
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 07:13:52 -0000

Hi Alex,

> -----Original Message-----
> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Alexandre Petrescu
> Sent: Monday, November 02, 2015 6:56 PM
> To: v6ops@ietf.org
> Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability discussion - address out of the delegated prefix, on the egress - no DAD
> 
> 
> 
> Le 03/11/2015 10:31, Templin, Fred L a écrit :
> > 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? And, that DAD is not required for those addresses?
> 
> This indeed new enough at least to me.
> 
> I agree that if the prefix is delegated for Host with DHCP-PD then it
> has a tighter bind to that Host, tighter than a prefix _advertised_ to
> it with an RA.
> 
> In that sense, certainly yes the Host may self-form and assign an
> address on its interface over which the application DHCP-PD received it
> earlier.
> 
> And, since the prefix is administratively unique, it would make little
> sense for the Host to DAD that address on that interface.
> 
> Moreover, it would bring some advantages for privacy.  Privacy addresses
> as we know them make only the IID variable, while still keeping a
> trackable prefix (the advertised prefix).  With this way of prefix
> delegation, the Host may decide more ways to obfuscate its identity: use
> sometimes the allocated prefix, other times the advertised prefix, in
> some hard-to-detect sequence.
> 
> But, if a Host forms an address out of the delegated prefix and wants to
> talk to its Gateway on that interface, maybe it wants to send an RA to
> that Gateway so the Gateway forms an address out of the delegated prefix
> too.  At that point DAD would be needed.

"Host sends an RA to the Gateway" doesn't make any sense that
I am aware of.

Thanks - Fred

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