[ Removed by moderator ]

Generate a random ULA prefix and assign it to lo. It'd be nicer if they had a allocated fixed block for this, but this works too.

/etc/systemd/network/lo.network:

[Match]
Name=lo

[Address]
Address=fd<YOUR PREFIX HERE>::/48
Scope=host
AddPrefixRoute=false

[Route]
Destination=fd<YOUR PREFIX HERE>::/48
Scope=host
Table=local
Type=local

$ ping fda9:c604:724::3
PING fda9:c604:724::3 (fda9:c604:724::3) 56 data bytes
64 bytes from fda9:c604:724::3: icmp_seq=1 ttl=64 time=0.031 ms

$ ping fda9:c604:724::9001
PING fda9:c604:724::9001 (fda9:c604:724::9001) 56 data bytes
64 bytes from fda9:c604:724::9001: icmp_seq=1 ttl=64 time=0.036 ms

Also, ipv4 loopback will be with us for a while, it's probably the last v4 feature to die since it'll never suffer from NAT.

IPv6-mapped IPv4?

Fun Fact: If you prefix ::fff to the start of a IPv4 address, it is a valid IPv6 address. That whole block is "reserved for private Internets". Permitting organizations can do cursed backward compatibility stuff on their NATs/WANs for legacy hardware. Effectively making IPv4 a subset of IPv6. That block is 2⁸⁰ addresses, but only 2⁴⁸ are 'well formed' IPv4 addresses.

There are so much room for activities, there is a duplication of this within 2002::/16. Which is basically that, but externally route-able IPv6 to IPv4 mapping.

Additionally the whole fc00::/7 of 2¹²¹ addresses is "reserved for local networks" (basically the new 10.0.0.0/8).

fe80::/64 to fe80::/10 a block of 2⁶⁴ is reserved for link local addresses (the new 169.254.0.0/16 block)

yeah that's the limitation. It downgrades them to ipv4 `127.x.x.x`, so the bind will succeed but you lose ipv6 :\

ipv5 was supposed to have that /j

IPv6 has ULA addresses, which are in the [fc::0]/7 range, and also link-local addresses from the range fe80:: (forgot the netmask, but similarly large). You can add these to your localhost interface as you desire and in the case of ULA addresses you can even use them todo cool stuff like giving containers a sable IPv6 address on changing network conditions like a laptop with WiFi moving between networks.

Kubernetes CNIs also use it extensively, albeit they should probably stop defaulting to do NAT since servers usually have dedicated IPv6 ranges like a /56. But alas, some cloud providers only give you a /64, a /112 (digital ocean I think) or even a /128 (oracle cloud, but can't complain since I'm on the free plan). So there are definitely upsides of this since it works on more networks but also kinda sucks because it is an artificial limitation and goes against what IPv6 tries to do.

Barrier to entry is a good thing. Now instead we have daily posts about a new impressive project, until you look inside and everything is actually impressive or new in the project is "TODO". Being forced to acquire skills to implement crazy ideas is a good thing actually.

don't give me more cursed ideas

U hope and pray

you hope and pray 😂 joking you'll just get errors and should override manually with --ip flag. I wanted this thing to be stateless so no collision detection is built in

She'll script, but will she engineer?

I feel you and there are things that are inherently unsolvable with this approach, but we always have containers to the rescue