|
See below for comments and rejoinders on this document from an earlier discussion thread on the v6ops list. Please use this thread for any follow-up discussion. Thanks – Fred fred.l.templin@xxxxxxxxxx From: Lorenzo Colitti [mailto:lorenzo@xxxxxxxxxx]
On Tue, Feb 23, 2016 at 7:31 AM, Templin, Fred L <Fred.L.Templin@xxxxxxxxxx> wrote:
We've already gone through the draft to change the terminology once (from "assign addresses" to the current "provide addresses"). I'm not sure that changing it again from "provide addresses" to "provide a means to obtain addresses" provides
much value. FLT>>> Certainly “provide” is much better than “assign”, but it is up to the host to FLT>>> obtain (and defend) its own addresses whether it be through SLAAC, FLT>>> DHCPv6, manual config, or whatever. So, the network provides the FLT>>> means to obtain addresses while the host must act on its own behalf FLT>>> to obtain addresses (acquire might even be a better word than obtain). To me, "provide" does not a imply push operation. The network can also provide addresses / prefixes on request (e.g., if the host sends an RS or a DHCPv6 solicit.) FLT>>> I think we see this in different ways, but I understand the desire to not FLT>>> overhaul the document. As a compromise, I think this could easily be FLT>>> addressed by simply changing the abstract to read: FLT>>> FLT>>> “This document recommends that networks provide general-purpose end FLT>>> hosts with a means to acquire multiple global IPv6 addresses when they FLT>>> attach, and describes the benefits of and the options for doing so.” FLT>>> FLT>>> Then, make no other changes in the document, and readers will still FLT>>> understand what you are talking about.
It is not the intention of the draft to imply this. In fact, it explicitly says the opposite: "If the host is aware that the prefix is dedicated (e.g., if it was provided via DHCPv6 PD and not SLAAC)..." Knowing that a prefix in the RA
is dedicated or not would require protocol changes. We could consider those in the future, but not in v6ops, because protocol changes are not something that is in the remit of this WG. FLT>>> I would prefer to see the Section 9.3 sentence you cited appear earlier FLT>>> in the document, but I don’t see the point in arguing over it. OK to leave FLT>>> it as it is. The following addresses some of your inline points. I think the others are either minor editorial issues with no substantive implications or are already covered by the two main points above.
I don't think the draft needs to say this. RFC4862 does not contain anything about extending the prefix to other hosts. While the draft does cite RFC7278 elsewhere, RFC7278 is specific to only one type of link layer (3GPP links). So I think the text is unambiguous: if you're on a 3GPP network, you can use RFC7278, and if not, any ability to extend the prefix
is unspecified. There's ND proxying, but it's experimental. Also see my prior point about protocol changes. FLT>>> OK.
In section 8 the draft already says "the approximately 30 addresses that can fit into a single packet". I've modified the text you pointed to with "The maximum number of IPv6 addresses that can be provided in a single DHCPv6 packet, given
a typical MTU of 1500 bytes or smaller, is approximately 30.". FLT>>> Good.
I've changed that to No+, with "[+] Except on certain networks, e.g., [RFC7278]." There is currently no specified way for a host to do this except ND proxying, which is experimental. FLT>>> OK.
No. The network cannot provide prefix delegations to an unlimited number of endpoints. It can only provide prefix delegations to as many endpoints as it has available /64s. This is different from both SLAAC and IA_NA, where, absent scaling
limitations, an "unlimited" number of endpoints can fit in one /64. I've changed the row name from "Unlimited" endpoints to Number "unlimited" endpoints. FLT>>> I would be OK with this, but in the footnote you say that SLAAC and IA_NA are FLT>>> “Subject to network limitations”, and “unlimited but limited” is an oxymoron. FLT>>> By that same token you could say that DHCPv6 PD is “unlimited but limited FLT>>> by the number of available /64s”. In some networks (e.g., ones that have FLT>>> procured a /32 or shorter) that could result in more endpoint numberings FLT>>> than SLAAC or IA_NA. FLT>>> FLT>>> My suggestion is to use the “Number “unlimited” endpoints” reword you FLT>>> have suggested, but also place a “**” next to the “No**” for DHCPv6 PD FLT>>> and add the following sentence after the table: FLT>>> FLT>>>”[**] Subject to the available prefix space. “
I don't see a reason to reiterate one of the means to do so, given that this sentence already says "or any other means". FLT>>> OK.
Fair enough. FLT>>> OK.
The intent of that text is provide an existence proof of networks that do not use DHCPv6 but still maintain a notion of which MAC addresses associated with which IPv6 addresses. I've lost count of the number of times people have told me
that this is not possible and that stateful DHCPv6 address assignment is the only possible way to meet legal requirements. I've tried to soften this by putting the authors' networks at the end. FLT>>> OK to the above change and leave the paragraph in place, but also please FLT>>> do me the favor of changing the first sentence of the second paragraph to: FLT>>> FLT>>> “DHCPv6 address assignment is typically associated with this requirement, FLT>>> but it is worth noting that it can also be addressed through other means.”
I think that mobility is a completely orthogonal problem to how many addresses are provided to hosts, and that it's out of scope here. FLT>>> Then, add a 1-2 sentence Section 9.4 that says so, e.g.: FLT>>> FLT>>> “9.4. Mobility Considerations FLT>>> FLT>>> Mobile hosts are becoming more and more prevalent in modern networks, FLT>>> and host mobility may have interactions with IPv6 address provisioning. FLT>>> Mobility implications are out of scope for this document.” FLT>>> One final question– do we need a short section on manual address configuration FLT>>> in addition to SLAAC and DHCPv6? Cheers, Lorenzo |