Re: [v6ops] new draft: draft-colitti-v6ops-host-addr-availability

[Tore Anderson <[e-mail]>]

* [e-mail]

> A new draft has been posted, at
> http://tools.ietf.org/html/draft-colitti-v6ops-host-addr-availability.
> Please take a look at it and comment.

I read this draft. I strongly agree with its recommendation, and would
support WG adoption.

I have some feedback and suggestions, see below:

1) The abstract and section 6: What exactly is meant by "multiple"?
Would a network conform to the recommendation by allowing 2 global
addresses per host (given the current wording, I think so)? Or should
it be 20? 200? I'd like to see a specific number, or at least a
ballpark number, or failing that some text that explains why no attempt
is being made to quantify what is OK and what is not. (I know this is a
tough one. Sorry..)

2) Section 1.1: Includes the RFC 2119 key words but doesn't appear to
make use o f them anywhere. Maybe s/recommended/RECOMMENDED/ in section
6?

3) Section 2 makes a reference to RFC 6433 section 5.9.4. I think there
must be a typo on the RFC number; RFC6433 doesn't contain a section
5.9.4.

4) In Section 2: «DHCPv6 [RFC7217]». s/7217/3315/, surely?

5) In Section 2: «IPv6 hosts have the ability to configure additional
IPv6 addresses from the on-link prefix without explicit requests to the
network» isn't 100% correct, the hosts need to perform DAD first.
Furthermore, that mechanism could be (ab)used by the network to block
the host from obtaining additional addresses.

6) Nit: In section 3, some of the bullet points terminate with a full
stop, some do not. Looks inconsistent.

7) Section 4: Just like to note that an address-unrestricted network
will still be subject to the first three problems listed thanks to DAD.
(Except DHCPv6-PD.)

8) Section 5: «the problems listed in section without disabling» is
missing a reference to (I assume) section 4.

9) Section 7: «If the prefix is a /64, it can also reshare that prefix
with any downstream clients via [RFC7278] /64 sharing». I think the
reference to RFC7278 is improper. First, RFC7278 is 3GPP specific while
DHCPv6-PD is not. Second, it discusses how to take a /64 that is a link
prefix on an upstream interface and re-use it on a downstream
interface. If you receive a delegated prefix (regardless of what its
length is), that prefix is *not* a link prefix on your upstream
interface and can simply be used on your downstream (or loopback)
interfaces without restrictions. I suggest rewriting something like
this: «The delegated prefix can also be reshared with any downstream
clients, cf. [RFC3633] section 5.»

10) Table 1: Mentions that SLAAC provides "unlimited" addressing. I
think that's a bit of a stretch, given hardware limitations. You can
buy devices today that can only handle a very limited amount IPv6
neighbours (Juniper EX45x0 for example: 1000 NDP entries according to
the datasheet). Given that each node needs at least two addresses
(LLA+GUA), you won't need many nodes with multiple addresses before you
start hitting some hard limitations.

11) Table 1: Might want to say "IA_NA/IA_TA" instead of just "IA_NA".

12) Table 1: The table says DHCPv6 IA_NA gives "unlimited" addressing
while DHCPv6 PD does not. I think maybe it was meant to be the other
way around?

13) Table 1: What's the difference between the rows «Stateful,
request-based» and «Request-based» supposed to be? (You might want to
take into account DAD for SLAAC in one of them, cf. point #4.)

14) Section 7 / Table 1: I think you should discuss whether or not an
approach can be cascaded, or at least easily so. As an example,
consider a 3GPP mobile network. It provides a /64, so it conforms with
the recommendation in this document. However, if you use RFC7278 to
create a tethering wireless network, a tethered host on that network
cannot easily share that network further using because RFC7278 requires
the upstream interface to be a point-to-point one, which the wirel ess
network is not.

15) Section 8.1: «y large enterprise networks, including the enterprise
networks of the authors, are fully dual-stack but do not use or support
DHCPv6.». Not that there's anything wrong with this statement, it left
me wondering: 1) How do you communicate DNS servers to your Windows
hosts, assuming you have any? (Maybe you meant to say «does not use or
support DHCPv6 *address assignment*»?) 2) What happens if you try to
configure a gazillion addresses on your host when connected to this
network? Does it actually work, does the network break, are (some of)
the addresses rendered unusable and if so is it due to simultaneous
addresses per host being limited somehow (hardware or policy) and if so
what is that limitation exactly?

16) Section 8.2: «The total size of net 10 is roughly 2^24». Roughly?
Isn't it *exactly* 2^24?

17) Section 8.2: The reference to RFC1918 should probably be, well, an
(actual) reference.

18) Section 8.2: Echoing what Sander said, a /40 isn't easy to get as
an enterprise (end-user), you'll need something like 128 sites for that
or become your own LIR. I don't think saying you want to assign a /64
per host provides adequate justification for more than the standard /48
per site, at least not in the RIPE region. (But it is of course
possible to do something about that.)

19) Section 8.2: «Currently, residential users receive one IPv4
address» - except that more and more of them are receiving *less than*
one IPv4 address nowadays...

20) Sections 10, 11, A: Text that appears to be from a RFC template is
left over.

Tore