[IPv6]Re: [v6ops] Why not add loopback semantics to 2001:db8::/32?

[Owen DeLong <[e-mail]>]

> On Dec 2, 2025, at 00:09, Mark Smith <[e-mail]> wrote:
> 
> Hi,
> 
> So I proposed a /32 in
> draft-smith-v6ops-larger-ipv6-loopback-prefix-04 (specifically 1::/32)
> because it facilitates many if not all testing scenarios - support for
> multiple loopback interfaces, with each having a /64 to be consistent
> with /64 subnet convention, allowing e.g. RFC7217 / RFC8981 IIDs to be
> used if useful, in addition to human convenient 1:0:0:<subnet>::1 /64
> addresses.

I’m still trying to comprehend a testing scenario that would require this where GUA or ULA wouldn’t be a better choice. Loopback semantics imply addresses that are identical across all machines, quasi-automatically configured, and not routable outside of host scope. This is not to be confused with virtual interface semantics (which loopback interfaces iare frequently (ab)used for in IPv4) where a routable address is assigned to non-physical interface to facilitate reachability regardless of which subset of physical interfaces remain up. (e.g. the use of configured routable “loopback” addresses on routers to terminate iBGP sessions).

I remain confused as to how the former would be useful and/or how having a dedicated prefix or expanded loopback semantic addresses would facilitate the latter or, frankly, what combination of the two you’re seeking in your testing scenarios.

> Geoff and Warren's alternative proposal is currently suggesting a /96.
> 
> If a /96 ended up being the choice, then I've thought I'd use
> 2001:db8::/32 for any host-local loopback testing, since it too would
> satisfy the scenarios that 1::/32 would.

You don’t need an RFC or an ID to do whatever you want on your own local hosts. I certainly think it would be ill advised to suggest that as common practice or condone doing so in any way, but your hosts are your hosts.

> That's a questionable use of a documentation prefix, however if
> packets too and from it didn't leak from the host, and with an
> additional defence that they shouldn't leak from the network per the
> filtering advice in RFC3849, then I don't think it would cause any
> harm to use the documentation prefix this way. It would also mean that
> any testing documentation would match what is configured on the host,
> rather than the test prefix and documentation prefixes having to be
> different.

Isn’t the whole point of the documentation prefix to make sure that any instance where it appears in an actual machine configuration can be immediately and automatically assumed to be erroneous and should be corrected? It seems to me that you are intentionally changing that semantic in ways that I would, again, consider ill-advised.

> Thinking about it a bit more, why not officially add loopback
> semantics to the 2001:db8::/32 prefix?

Because 2001:db8::/32 (and any expanded documentation prefixes) should already have “this won’t work in the wild” semantics associated with them and frankly, I’d argue that in an ideal world, machines should reject these prefixes out of hand unless overridden with some sort of “this configuration being used to produce documentation only” flag.

In short, I think doing so would create unnecessary confusion while not offering any tangible benefit to the community at large.

Can you elaborate on what kind of testing scenario would require 4 billion /64 loopback interfaces on a single machine?

Owen