[v6ops] Comments on <draft-horley-v6ops-lab>

[Bob Hinden <[e-mail]>]

Hi,

I commented at todays V6OPS meeting on <draft-horley-v6ops-lab-01>.  The presentation was:

https://datatracker.ietf.org/meeting/111/materials/slides-111-v6ops-ipv6-lab-prefix-draft-00

I have now read the draft and the email thread.   My comments are not significantly different from what I read in email, but I will put them in my own words by topic.

Size of Allocation:

Reserving a /7 (specifically 0200::/7) is very very large amount of address to be dedicated to “Lab Use”.

A /7 is 2^^121, or 2.6584559915698×10^36 addresses.  In words:

Eighteen quadrillion fourteen trillion three hundred ninety-eight billion five hundred nine million four hundred eighty-one thousand nine hundred eighty-four addresses.

With some sarcasm, how big is this lab going to be?

This would allow for 2^57 /64 prefixes, that is 144,115,188,075,855,872 prefixes.   Is your lab going to have that many prefixes?

This proposal seems like a waste of address space to me.   The main purpose of IPv6 was to create a larger Internet, allocating this much space for “lab use” seems very excessive.   We won’t end up with much bigger Internet, if we aren’t careful with how we allocate the address space.

I note for comparison that the original intent for this prefix was to accommodate the whole ISO CLNP Internet.

Global Filtering:

The draft says that this prefix should be added the list of non-routable prefixes.  I note that this means that every ISP in the world would need to do this.    That’s a big ask and may not actually happen operationally.

Unintended Consequences:

As noted on the email thread, this is going to have the unintended consequences of recreating a private IPv6 address space.  The IETF has gone to a lot of trouble to not have private address in IPv6.   The original design has Site Local addresses.  These were deprecated, for very good reason described in RFC 3879.

The draft call out that the allocated prefix should be declared “non-routeable” and be added to packet filters.   Exactly what would be needed to recreate a new form of Site-Local addresses.

Unique Local Addresses (ULA):

The draft describes about why it can’t use ULA addresses.   The ULA prefix also happens to be a /7 and can support the same number of prefixes as what is proposed in the draft.

Regarding special handling of ULA in source address selection.   That is default behavior that can be changed. It’s also not clear that the old NSAP prefix (0200::/7) will not have a similar or different set of issues, given it is currently reserved and not in the address blocks that are currently allocated for global unicast.

I strongly that ways can be found to use ULAs to meet the requirements of the “lab use” proposal.   For example, if you need n prefixes, run the algorithm n times and get that number of random prefixes.   Each prefix has have 16-bits for a Subnet ID, that can used to prefix aggregation.   None of this requires any change of standards, allocations, or additional global filtering.


I think that if you want something beyond what ULAs can accommodate (and can demonstrate a need), you will need to describe that in a lot more detail than what is in the current version of the draft.  I don’t see anything in the draft that justifies an address allocation of this size for “lab use”.

Bob

p.s. Thanks for the acknowledgement to Steve Deering and myself in the draft, it is nice, but many people have contributed to IPv6.   This section would be best to list people who have helped with this draft.