[IPv6]Why I chose 1::/32 (Re: [v6ops] Re: Why not add loopback semantics to 2001:db8::/32?)

[Mark Smith <[e-mail]>]

Hi,

So I've suggested adding loopback semantics to 2001:db8::/32 because
it would satisfy the easy to remember requirement.

When I originally thought about this problem for my draft, I thought
about what had been convenient and useful about 127/8 even though it
would appear (and probably has been) excessive since IPv4 addresses
became precious, and what couldn't be done with ::1/128.

The things I realised:

- 127, "127/8" and "127.0.0.1" are easy to remember, because 127 is a
"magic" number in binary, "127/8" is a large prefix for a local host
function so it sticks out in the broader context of IPv4 addressing,
and "127.0.0.1" is easy to remember because it is the first address
within 127/8.

- 127.0.0.1 is easy to type if your testing involves dealing with IPv4
addresses directly.

- 127.0.0.1 is automatically configured and enabled on all IP implementations.

- One some implementations, all addresses within 127/8 are
automatically and effectively assigned to the host, even though they
aren't configured on the loopback interface. Linux hosts don't just
respond to 127.0.0.1, they also respond to
127.<0-255>.<0-255>.<0,2-255> even though those addresses aren't shown
on the 'lo' interface.

- 127/8 is large enough that it can be easily and conveniently
subnetted at octet boundaries and used on multiple loopback
interfaces, which could be useful for testing of multi-process
applications e.g 127.0.1.1/24:loopback1, 127.0.2.1/24:loopback2, etc.

For example, you can test the impact of a process failure by just
admin downing one of the loopback interfaces, rather than having to
remove and then restore an additional 127 address on a single loopback
interface. 127.0.<subnet>.1, or 127.0.<subnet>.1 etc. is also almost
as easy to type as 127.0.0.1.

- Furthermore, subnetting 127/8 doesn't cause traffic with addresses
from within 127/8 subnets to leak, since the whole of 127/8 is local
to the host.


Those observations resulted in the following IPv6 larger loopback
requirements (https://datatracker.ietf.org/doc/html/draft-smith-v6ops-larger-ipv6-loopback-prefix-04#section-2)

." Larger Loopback Prefix Requirements

   A new larger loopback prefix should attempt to satisfy all of the
   following requirements.  It should:

   o  be a well known prefix,

   o  be within an existing special purpose prefix, such as 0000::/8
      (the parent prefix of the current IPv6 loopback address),

   o  be easy for a human to remember [EASY-NUMBERS],

   o  be easy for a human to type accurately [DOET],

   o  cover the existing IPv6 loopback prefix,

   o  support 64 bit Interface Identifiers,

   o  provide a large number of /64 subnets."

Covering the existing IPv6 loopback prefix wasn't possible, however
all of the other requirements could be met.

Note that a ULA /48 doesn't. Properly formed, it will have a hard to
type and remember 40 bit random number in the address. Link-locals
don't really either, because every link-local address has to have a
Zone ID specified.

I chose what I thought would be the next best rememberable, easy to
type and large enough prefix of 1::/48, and then eventually expanded
it to 1::/32 since why not... there are 4 billion /32s in IPv6, making
a larger loopback prefix that large should ensure the problem is
solved fully and finally the 2nd time around and never ever needs to
be revisited.

I don't think a /96 would do that. What if somebody wants to do some
64 bit IID related testing local to the host?

For example, 1::/32 could easily accommodate testing of something like
"Transient Addressing for Related Processes" -
https://www.usenix.org/legacy/events/sec01/full_papers/gleitz/gleitz_html/

Even though 1::/32 is very large, at one 4 billionth of the IPv6
address space, it is much much smaller than 1/256th of the IPv4
address space that 127/8 is.

Regards,
Mark.









On Thu, 4 Dec 2025 at 10:59, Nick Buraglio <[e-mail]> wrote:
>
> No hat
>
> My gut reaction is that any use of the doc space (either 3fff or 2001:db8) would cause significant confusion and invite potential issues, and that we would regret that choice sooner rather than later. I do think that expanding the loopback is worth while, I don't have a strong feeling on size. /96 s probably enough, but if we feel like we need more, we have enough to work with. I do agree th Brian that a dedicated range is a holdover, but there *is* some value in that. The more easily developers and operators can shift their thinking, the easier the transition is, and this is a fairly simple win. A well known, dedicated prefix has that value, and like link local, visual cues make them easier for operators. I would be in favor of something visually different (not 2000::) and dedicated.
>
> nb
>
> On Wed, Dec 3, 2025 at 12:08 AM David Farmer <farmer=[e-mail]> wrote:
>>
>> Riffing on your 2001:db8::/32 suggestions, I think I would rather avoid overloading the documentation or any other prefix currently allocated.
>>
>> So, I would suggest something from 2001::/23, like 2001:1ff::/32 or 2001:1ff:ff00::/48.
>>
>> But, as I said, ::/2, ::/3, etc... seems very intuitive. So, I still slightly prefer ::/104 or ::/96, as an individual solution, but I don’t oppose adding a shorter prefix in addition to to one of them.
>>
>> Thanks
>>
>> ===============================================
>> David Farmer               Email:[e-mail]
>> Networking & Telecommunication Services
>> Office of Information Technology
>> University of Minnesota
>> 2218 University Ave SE        Phone: [phone]
>> Minneapolis, MN 55414-3029   Cell: 612-812-9952
>> ===============================================
>>
>>
>> On Tue, Dec 2, 2025 at 02:10 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.
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> Thinking about it a bit more, why not officially add loopback
>>> semantics to the 2001:db8::/32 prefix?
>>>
>>> Comparing ::1/128 and 2001:db8::/32 in the IPv6 special address registry:
>>>
>>> https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml
>>>
>>> all of their attributes already match, with exception to the Reserved
>>> By Protocol attribute. This attribute specifies:
>>>
>>> This value is "TRUE" if the RFC that created the special-purpose
>>>       address block requires all compliant IP implementations to behave
>>>       in a special way when processing packets either to or from
>>>       addresses contained by the address block.
>>>
>>> Adding loopback semantics to 2001:db8::/32 would save having to assign
>>> a new prefix, be plenty big enough for all test use cases, and is
>>> already a well known prefix.
>>>
>>> Regards,
>>> Mark.
>>>
>>> --------------------------------------------------------------------
>>> IETF IPv6 working group mailing list
>>> [e-mail]
>>> List Info: https://mailman3.ietf.org/mailman3/lists/[e-mail]/
>>> --------------------------------------------------------------------
>>
>> _______________________________________________
>> v6ops mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]