Subject: [v6ops] Comments on draft-ietf-v6ops-host-addr-availability-05

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 22 Feb 2016 22:31:02 +0000

Hi,

I told Fred B. that I would review this document and post comments.
Overall, I think the document is in reasonably good shape but I have
 two primary suggested areas for improvement.

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

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.

See below for detailed comments, including those related to the two
primary themes as well as others:

Fred
[email-masked]

---

1) Introduction, "It recommends that networks provide
   general-purpose end hosts with multiple global addresses"
   suggest changing to: "It recommends that networks provide
   general-purpose end hosts with a means to obtain
   multiple global addresses".

2) Section 3, "Today there are many host functions that
   require more than one IP address to be available to
   the host:" suggest changing to: "Today there are many
   host functions that require more than one IP address to
   be available to the to the host, including:"

3) Section 4, "Providing a restricted number of addresses"
   suggest changing to: "Restricting the number of
   addresses".

4) Section 4, "e.g., if the network provides only one IPv6
   address per host" suggest changing to: "e.g., if the
   network permits only one IPv6 address per host".

5) Section 5, "and even when the decision to provide only
   one IPv6 address per device ... because devices can
   share their IPv6 address with other devices." suggest
   changing to: "and even when the decision to permit only
   limited numbers of IPv6 addresses per device ... because
   devices can share their IPv6 addresses with other devices."

6) Section 6, title: "Options for providing more than one
   address" suggest changing to: "Multi-addressing Options".

7) Section 6, "Multiple IPv6 addresses can be provided in
   the following ways:" suggest changing to: "Hosts can
   obtain multiple IPv6 addresses in the following ways:"

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. If the intention
   is the latter, then the host would need to have some
   means of knowing that the prefix is indeed dedicated,
   but RFC4861 only says that "L=0" means that the PIO
   contains no information about the on/off-link property
   of the prefix.

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

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:

   (**) If the host has knowledge that the prefix has been
        dedicated for its own exclusive use.

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

12) Section 8, "it is RECOMMENDED that IPv6 network deployments
   provide multiple IPv6 addresses from each prefix to general
   purpose hosts." suggest changing to: "it is RECOMMENDED that
   IPv6 network deployments provide general-purpose hosts with
   a means to obtain multiple IPv6 addresses from each prefix".

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.
   Second (as with comments 8 and 10), for SLAAC-based methods
   the document needs to say that the host must have some way
   of knowing that the prefix has been dedicated for its own
   exclusive use beyond the existing IPv6 node requirements
   (i.e., beyond RFC4861).

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

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.

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

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 24 Feb 2016 17:06:39 +0900

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

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

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

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.

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

>    Suggest adding a trailing phrase giving some rationale

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

>    RFC4861. Can be addressed by adding a "**" next to the

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.

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

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

>    the section covers both stateful and SLAAC.

Fair enough.

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

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

Cheers,
Lorenzo

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Wed, 24 Feb 2016 23:29:17 +0000

Thanks for the review. The document was just sent to IETF Last Call by the IESG, having finished working group processes some time ago. I might suggest you repeat this note in that context.

My personal (as in, not chair) thoughts on the two points are:

On the first point, I can go either way. SLAAC and DHCP/DHCPv6 have the device "obtaining" addresses from the network, while DHCP-PD has the network "providing" a prefix to the system. In language designed to cover both cases, which this is, either wording is arguably right and arguably wrong. I'm personally OK with the existing language.

The second, SLAAC delivering knowledge of a non-/64 prefix from which the network is requiring to to select addresses, is a protocol change, which is out of scope for v6ops. I think I understand what you're getting at, and 6man may want to consider that, but I don't believe that there is a current consensus in v6ops to make such a change.

The other Fred

> On Feb 22, 2016, at 3:31 PM, Templin, Fred L <[email-masked]> wrote:
> 
> Hi,
> 
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops