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

"Templin, Fred L" <Fred.L.Templin@boeing.com> Tue, 03 November 2015 02:21 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 BE5B41ACDBC for <v6ops@ietfa.amsl.com>; Mon, 2 Nov 2015 18:21:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 rghAmk8lgiJK for <v6ops@ietfa.amsl.com>; Mon, 2 Nov 2015 18:21:12 -0800 (PST)
Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (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 447041ACDCB for <v6ops@ietf.org>; Mon, 2 Nov 2015 18:19:36 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id tA32Ja8M038770; Mon, 2 Nov 2015 19:19:36 -0700
Received: from XCH-BLV-101.nw.nos.boeing.com (xch-blv-101.nw.nos.boeing.com [130.247.25.116]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id tA32JVwc038766 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 2 Nov 2015 19:19:31 -0700
Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.14]) by XCH-BLV-101.nw.nos.boeing.com ([169.254.1.14]) with mapi id 14.03.0235.001; Mon, 2 Nov 2015 18:19:31 -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: [v6ops] draft-ietf-v6ops-host-addr-availability discussion
Thread-Index: AQHRFS2IJ4h76jRqCkuPztS49pNk7Z6JZjuggACchgD//3qXcIAABmrAgACKz4D//3oXYIAAB83A
Date: Tue, 3 Nov 2015 02:19:30 +0000
Message-ID: <2134F8430051B64F815C691A62D9831832F3957A@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>
In-Reply-To: <2134F8430051B64F815C691A62D9831832F394F7@XCH-BLV-504.nw.nos.boeing.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/P8o0INb2sVysvBk6Gy-FWzX7QRc>
Cc: "v6ops@ietf.org" <v6ops@ietf.org>
Subject: Re: [v6ops] 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 02:21:15 -0000

Bumping up again, here is a valid and useful instance of multiaddressing:

1) Client gets a /64 prefix delegation from a DHCPv6 server over interface "A"
2) Client assigns the /64 to a loopback interface
3) Client assigns as many addresses from the /64 as it likes to
    interface "A" (could be millions or more)
4) Client is a pure host (IP forwarding turned off)
5) No DAD needed on any interface

Thanks - Fred

> -----Original Message-----
> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Templin, Fred L
> Sent: Monday, November 02, 2015 5:59 PM
> To: Brian E Carpenter; Lorenzo Colitti
> Cc: v6ops@ietf.org
> Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability discussion
> 
> 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.
> 
> > 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.
> 
> 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 mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops