Most deployments only use 127.0.0.1/32. Some niche cases use 127.0.0.0/24. Vanishingly few use more than that. Keep the /24 reserved for local use, and repurpose the rest for global unicast.
Agreed that it would be impractical to actually use these. Maybe for linknets?
If any big site (or even better, many big sites together) were willing to go that far, a much better measure would be announcing that they'll go IPv6-only on the next IPv6 day. Just for that day. And then again the next year, but for a week. Then for a month the year after. Then permanently. That would give ISPs the kick in the butt to fix it, because nobody wants their hotline to field a day full of "my Internet doesn't work" calls, only to then have to fix it anyways because otherwise it'll be a week next time.
inet 127.0.0.1 netmask 0xff000000
inet 127.0.0.1 netmask 255.0.0.0You can as soon as you define it as an alias.
> Linux's behavior of allowing the whole /8 to be used, even when only a single address is assigned, is a bit of an oddity here.
Per the RFC: "127.0.0.0/8 - This block is assigned for use as the Internet host loopback address. A datagram sent by a higher level protocol to an address anywhere within this block should loop back inside the host."
Linux special-cases 127/8 on the virtual loopback interface and will treat all looped-back packets as if they were addressed to the host, even when the destination isn't explicitly configured as an alias. This behavior is not required by the quote from RFC3330.
uname -a
Darwin LT-JT6692XPXJ 23.5.0 Darwin Kernel Version 23.5.0: Wed May 1 20:12:58 PDT 2024; root:xnu-10063.121.3~5/RELEASE_ARM64_T6000 arm64
~
ifconfig lo0
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
options=1203<RXCSUM,TXCSUM,TXSTATUS,SW_TIMESTAMP>
inet 127.0.0.1 netmask 0xff000000
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
nd6 options=201<PERFORMNUD,DAD>
~
ping -c 1 127.0.0.2
PING 127.0.0.2 (127.0.0.2): 56 data bytes
--- 127.0.0.2 ping statistics ---
1 packets transmitted, 0 packets received, 100.0% packet loss
~ 11s
sudo ifconfig lo0 add 127.0.0.2
Password:
~
ping -c 1 127.0.0.2
PING 127.0.0.2 (127.0.0.2): 56 data bytes
64 bytes from 127.0.0.2: icmp_seq=0 ttl=64 time=0.824 ms
--- 127.0.0.2 ping statistics ---
1 packets transmitted, 1 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.824/0.824/0.824/nan ms
~
ifconfig lo0
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
options=1203<RXCSUM,TXCSUM,TXSTATUS,SW_TIMESTAMP>
inet 127.0.0.1 netmask 0xff000000
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
inet 127.0.0.2 netmask 0xff000000
nd6 options=201<PERFORMNUD,DAD>
~[1] I needed a lot of localhost connections to run a TLS terminator separate from the underlying service which didn't support unix sockets. Using the 127.0.X.0 bits in addressing was very helpful for diversity in the hash used for kernel socket tables, otherwise most slots had few sockets and some slots had way too many and perf was bad. Configuring multiple loopback interfaces using more address space was a lot more tractable than changing the kernel hashing behavior, adding unix socket support to the underlying service, or adding good TLS to the underlying service. Although probably since then all three things have happened.
For your TLS thing, is it whatever application you were using expected to use a whole swath of TCP ports at whatever IP address, so expected separate IPs?
Feels like dedicating some range of addresses to "private use" would have been useful, then if you needed a bunch of local loopbacks, could configure it so, or if your local network wants some magic, tada.