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

"Templin, Fred L" <Fred.L.Templin@boeing.com> Tue, 03 November 2015 07:02 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 BAF1C1B2F0A for <v6ops@ietfa.amsl.com>; Mon, 2 Nov 2015 23:02:19 -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 6BcTi7ks1U-L for <v6ops@ietfa.amsl.com>; Mon, 2 Nov 2015 23:02:18 -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 B73251B2EF9 for <v6ops@ietf.org>; Mon, 2 Nov 2015 23:02:08 -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 tA3728Qj050288; Tue, 3 Nov 2015 00:02:08 -0700
Received: from XCH-PHX-110.sw.nos.boeing.com (xch-phx-110.sw.nos.boeing.com [130.247.25.39]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id tA3726IO050283 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 3 Nov 2015 00:02:06 -0700
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:02:06 -0800
From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
To: Lorenzo Colitti <lorenzo@google.com>
Thread-Topic: [v6ops] draft-ietf-v6ops-host-addr-availability discussion
Thread-Index: AQHRFS2IJ4h76jRqCkuPztS49pNk7Z6JZjuggACchgD//3qXcIAAnxsA//+/N6A=
Date: Tue, 3 Nov 2015 07:02:05 +0000
Message-ID: <2134F8430051B64F815C691A62D9831832F399D2@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> <CAKD1Yr14B0Mvj5x9QvK58cD4OxrGMBWAa++_+n4vFUiHWYsxFQ@mail.gmail.com>
In-Reply-To: <CAKD1Yr14B0Mvj5x9QvK58cD4OxrGMBWAa++_+n4vFUiHWYsxFQ@mail.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/P_gjXfBh-CTdL-Cov5VPR8VICGE>
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 07:02:19 -0000

Hi Lorenzo,

From: Lorenzo Colitti [mailto:lorenzo@google.com] 
Sent: Monday, November 02, 2015 6:36 PM
To: Templin, Fred L
Cc: Fred Baker (fred); v6ops@ietf.org
Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability discussion

On Tue, Nov 3, 2015 at 10:24 AM, Templin, Fred L <Fred.L.Templin@boeing.com> wrote:
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 didn't need clarification, I already knew what you meant. My point is that:
• I don't think we can clarify it without overflowing the space in the table cell
• If we clarify it using text outside the table cell, then that means we need to explain the other table rows as well, for consistency.
• That opens us up to fresh discussions on what text to write in those explanations, which could potentially become long and involved.
• It's not clear to me that the above is worth having this extra row in the table.
Thus I'd prefer not to an extra row.

FLT >>> It seems to me you did need clarification, and yes DAD avoidance is a
FTL >>> big deal worth noting in the table.

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.

FLT>>> But, there are billions of /64s available even in just a /32. If you want to
FLT>>> delegate /64s to billions of nodes, just use DHCPv6 PD.
 
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.

FLT>>> Scaling limits apply to the number of nodes that can be accommodated
FLT>>> on a link that is serviced by SLAAC and/or DHCPv6 IA_NA/IA_TA, yes.
FLT>>> It is probably a research question as to whether the scaling limits for
FLT>>> DHCPv6 PD are more or less pressing than the scaling limits for
FLT>>> SLAAC/DHCPv6 IA_NA/IA_TA. The line in your table is therefore
FLT>>> meaningless and could be removed.
 
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.

I think you're confusing unlimited addresses with unlimited endpoints. With IA_NA or SLAAC, you can number billions of endpoints, each of which might only have a few addresses. With DHCPv6 PD, you can only number as many endpoints as you have /64s. Each of those endpoints might be using an unlimited number of addresses, but there is still a limited number of them.

FLT>>> Again, the scaling question comes to whether a single link can accommodate
FLT>>> more endpoints using SLAAC/DHCPv6 IA_NA/IA_TA or DHCPv6 PD if the
FLT>>> number of eligible /64s numbers in the billions.