Re: Last Call: <draft-ietf-v6ops-host-addr-availability-05.txt> (Host address availability recommendations) to Best Current Practice

["Templin, Fred L" <[e-mail]>]

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
[e-mail]

From: Lorenzo Colitti [mailto:[e-mail]]
Sent: Wednesday, February 24, 2016 12:07 AM
To: Templin, Fred L
Cc: [e-mail] WG
Subject: Re: [v6ops] Comments on draft-ietf-v6ops-host-addr-availability-05

On Tue, Feb 23, 2016 at 7:31 AM, Templin, Fred L <[e-mail]<mailto:[e-mail]>> wrote:
First, the document throughout uses expressions of the form "networks
provide hosts with multiple global addresses" but IMHO that implies  a
sort of "push" operation where the network pushes addresses onto the
host which is not the way things work in practice. I think a more appropriate
expression form would be "networks provide hosts with a means to obtain
multiple global addresses".

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.

Second, the document seems to imply in several places that SLAAC can
be used as a sort of implicit prefix delegation service; presumably in the
same spirit as RFC7278. If that is the intention, then it also needs to say
that the host needs to have some way of knowing outside of the scope
of the node requirement standards that the prefix is being delegated
for the host's exclusive use. For example, an unmodified host that obeys
RFC4861 on a WiFi link would have no way of knowing that a prefix
advertised in a PIO with (A=1; L=0) is in fact being delegated for its own
exclusive use. The document therefore needs to note this rather than
imply that an unmodified host can use SLAAC for prefix delegation.

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.

8) Section 6, under the heading "Using Stateless Address
   Autoconfiguration [RFC4862]." This section does not make
   a statement as to whether the "dedicated /64 prefix" is
   to be used only for SLAAC on the interface over which the
   prefix is advertised, or whether the prefix can be
   extended to a LAN link as in RFC7278.

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.

9) Sectin 6, under the heading "Using Stateful DHCPv6 address
   assignment [RFC3315]" final sentence in the paragraph says
   "The number of IPv6 addresses that can be provided in a
   single DHCPv6 packet is approximately 30." but it does
   not say where the "30" came from. Is it because of packet
   size limitations? Some protocol constant? Something else?
   Suggest adding a trailing phrase giving some rationale
   for the "30".

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.

10) Table 1, "Extend network" is listed as "Yes" for SLAAC,
   which would seem to imply that SLAAC is intended to extend
   the prefix to a LAN link as in RFC7278. But, that can only
   be possible when the host has some way of knowing that the
   prefix has been "delegated" which is outside the scope of
   RFC4861. Can be addressed by adding a "**" next to the
   Yes with the footnote:

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.

11) Table 1, ""Unlimited" endpoints is listed as "No" for
   DHCPv6 PD. Shouldn't it be a "Yes"?

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. “

13) Section 8, "The prefix MAY be provided using DHCPv6 PD,
   SLAAC with per-device VLANs, or any other means." Two issue
   with this - first, the text earlier also included "wireless
   network where every MAC address is placed in its own
   broadcast domain" which should also be reiterated here.

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.

14) Section 9.1, rename section as simply "Host Tracking", since
   the section covers both stateful and SLAAC.

Fair enough.

FLT>>> OK.

15) Section 9.1, paragraph beginning "Many large enterprise
   networks, including the enterprise networks of the authors'
   employers" seems to be advocating for a specific approach
   while the rest of the document is appropriately neutral.
   IMHO, this paragraph could be removed.

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.”

16) The document could benefit from adding a section on mobility.

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