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

From: Bob Hinden <[email-masked]>
Date: Thu, 29 Jul 2021 20:11:15 -0700

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.

---

From: Jen Linkova <[email-masked]>
Date: Fri, 30 Jul 2021 14:00:58 +1000

Oh thank you Bob - I was writing an email about the draft when I
noticed your response. So I decided to delete whatever I wrote and
just second your comments.

The draft says that ULAs can't be used because they are treated
differently by end nodes. I'm afraid that if we allocate 0200::/7 for
labs, as draft requests, we'll face the same problem with that prefix,
so we might end up treating it differently as well. Back to square
one.

On Fri, Jul 30, 2021 at 1:12 PM Bob Hinden <[email-masked]> wrote:
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

-- 
SY, Jen Linkova aka Furry

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 30 Jul 2021 09:53:02 +0200

I fully agree. There is no need for draft-horley-v6ops-lab neither draft-horley-v6ops-expand-doc.

I've been doing trainings and labs about IPv6 since 2001 and already trained over 75.000 engineers, probably a bit more. I don't recall any of the participants on the trainings or other consultancy and deployment activities to have been confused with just the 2001:db8::/32 prefix, even if the real situation for their own case was a bigger allocation. They were smart to figure out the equivalence and in fact, forcing them to use that helped in better understanding how IPv6 addressing works.

I've trained and consulted people designing networks that required from the RIR allocations close to /24. Always have been able to do any kind of address planning and lab exercises using what we have standardized up to now.

I'm not saying I can't be convinced about an additional documentation prefix or something similar, but not at the scale depicted in those documents.

Note that I'm for doing a good/balanced usage of IPv6 addressing space, and that includes that every subscriber, even residential should get a /48 by default. However, I'm also for a good balancing of real needs. So not being ultra-conservationist, but avoiding unnecesary waste.

Regards,
Jordi
@jordipalet

El 30/7/21 5:12, "v6ops en nombre de Bob Hinden" <[email-masked] en nombre de [email-masked]> escribió:

    Hi,

    Size of Allocation:

    Global Filtering:

    Unintended Consequences:

    Bob

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

---

From: Ca By <[email-masked]>
Date: Fri, 30 Jul 2021 10:20:23 -0700

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

I agree with Bob. Don’t do this to us operators.

Broadly, i oppose the i-d. It is not needed. Any lab can use gua or ula or
bogon

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 31 Jul 2021 09:41:44 +1200

On 31-Jul-21 05:20, Ca By wrote:
> Broadly, i oppose the i-d. It is not needed. Any lab can use gua or ula 
or bogon

I agree. However, I did see one comment earlier: that the RFC6724 precedence table needs to be tweaked in all hosts to avoid special handling for fc00::/7. Is there a good way to do that remotely?

There's also an argument in the draft that RFC4193 specifies pseudo-random bits in the prefix. In the lab context, that's a requirement than can be (and often is) ignored.
 
    Brian

---

From: Mark Smith <[email-masked]>
Date: Sat, 31 Jul 2021 11:19:57 +1000

> I agree. However, I did see one comment earlier: that the RFC6724 precedence table needs to be tweaked in all hosts to avoid special handling for fc00::/7. Is there a good way to do that remotely?

I've been wondering if that is really the case, or there is something
else going on in the example that Nick posted to the list.

The only way for IPv4 to be preferred over ULA per the precedence
table is if IPv4 addresses are represented as IPv4-mapped addresses
(per RFC6724, 3.2).

The example we've seen on the list was with SSH under Ubunto, so using
glibc getaddrinfo().

AI_V4MAPPED | AI_ADDRCONFIG are the default flags for getaddrinfo() if
NULL is specified for the 'hints' structure for the getaddrinfo()
call.

However, the call to getaddrinfo() in openssh-portable in the current
github version (ssh.c, resolve_host()) always supplies a 'hints'
structure, and doesn't ever set AI_V4MAPPED.

Here's a getaddrinfo() test using the same flags that SSH uses by default:

    memset(&hints, 0, sizeof(hints));

    hints.ai_family = AF_UNSPEC;        /* Allow IPv4 or IPv6 */
    hints.ai_socktype = SOCK_STREAM;    /* Stream socket */

    s = getaddrinfo(argv[1], NULL, &hints, &result);

looking up a domain name with only IPv4 and IPv6 ULA DNS records. The
output order shown is the order getaddrinfo() supplied:

[mark@opy getaddrinfo]$ ./gai v6opstest.nosense.org

getaddrinfo(v6opstest.nosense.org)

    AF_INET6, fd68:1e02:dc1a:ffff::3, sin6_scope_id = 0
    AF_INET, 10.255.255.3

[mark@opy getaddrinfo]$

So the ULA address should be preferred as a DA over IPv4.

I'm wondering if perhaps the preference of IPv4 over IPv6 ULA was
instead caused by source address selection. Perhaps Nick's test host
only had IPv4 and IPv6 GUA addresses, so IPv4 became the SA choice
when there was only IPv6 ULA and IPv4 DAs. OTOH, if the DA choices
were IPv4 and IPv6 GUA, then IPv6 GUA was the chosen source address.

So perhaps source address selection made it appear that IPv4 was
preferred over ULA for destination address selection.

Regards,
Mark.