Isn't that the default for modern routers? They just generate a random ULA during setup and assign it.
Random ULAs are also great for LAN-to-LAN VPNs, because there aren't any private IP overlaps. Everyone setting up their LAN on 192.168.0.x makes it quite a mess on IPv4.
[–] simoncion 9 hours ago
[–] cyberax 8 hours ago
[–] andix 7 hours ago
This problem seems to be addressed already and might be solved in the future: https://datatracker.ietf.org/doc/draft-ietf-6man-rfc6724-upd...
(once again it's surprising how long it takes to clear up all IPv6 quirks)
[–] simoncion 8 hours ago
/me glances over at my LAN which has been happily using ULAs for local communications and GUAs for global for the past I don't even know how long.
_Sure_.
[–] andix 7 hours ago
ULA work well in combination with DNS though.
[–] simoncion 4 hours ago
Sure, but you're generally not going to get both addresses associated with a single host unless you either hard-code them or use DNS. For any non-stupid network, source address selection for reaching LAN hosts doesn't really matter. And for many-to-most SOHO networks, you're going to be running dnsmasq, which will quickly set you right after any GUA change.
And like, the thing to be noticing here is that source address selection priorities for both IPv4 and IPv6 seem to give us the same actual behavior. Consider a pair of hostnames served up by BIND 9 and some applications running on bog-standard Gentoo Linux whose '/etc/gai.conf' contains only comments and blank lines:
# getent ahosts dumbhost.invalid
1.1.1.1 STREAM dumbhost.invalid
1.1.1.1 DGRAM
1.1.1.1 RAW
192.168.30.30 STREAM
192.168.30.30 DGRAM
192.168.30.30 RAW
# ping -n -c1 dumbhost.invalid
PING dumbhost.invalid (192.168.30.30) 56(84) bytes of data.
From <redacted> icmp_seq=1 Destination Host Unreachable
--- dumbhost.invalid ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms
# curl -v dumbhost.invalid
* Host dumbhost.invalid:80 was resolved.
* IPv6: (none)
* IPv4: 192.168.30.30, 1.1.1.1
* Trying 192.168.30.30:80...
* connect to 192.168.30.30 port 80 from <redacted> port 47140 failed: No route to host
* Trying 1.1.1.1:80...
* Established connection to dumbhost.invalid (1.1.1.1 port 80) from <redacted> port <redacted>
<snip>
# getent ahosts dumbhost6.invalid
fd00::1 STREAM dumbhost6.invalid
fd00::1 DGRAM
fd00::1 RAW
2002:db8::1 STREAM
2002:db8::1 DGRAM
2002:db8::1 RAW
# ping -n -c1 dumbhost6.invalid
PING dumbhost6.invalid (fd00::1) 56 data bytes
From <redacted> icmp_seq=1 Destination unreachable: No route
--- dumbhost6.invalid ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms
# curl -v dumbhost6.invalid
* Trying [fd00::1]:80...
* connect to fd00::1 port 80 from <redacted> port <redacted> failed: Network is unreachable
* Trying [2002:db8::1]:80...
* Host dumbhost6.invalid:80 was resolved.
* IPv6: fd00::1, 2002:db8::1
* IPv4: (none)
^C
# ip addrlabel list | sort -hk 4
prefix ::1/128 label 0
prefix ::/0 label 1
prefix 2002::/16 label 2
prefix ::/96 label 3
prefix ::ffff:0.0.0.0/96 label 4
prefix fc00::/7 label 5
prefix 2001::/32 label 6
prefix 2001:10::/28 label 7
prefix fec0::/10 label 11
prefix 3ffe::/16 label 12
Anyway. If he put both IPv4 GUAs and 1918 addresses in DNS or his '/etc/hosts', he'd be having the same problem he's complaining about here... depending on -I guess- the OS he's using and how his resolver treats the ordering of entires in '/etc/hosts'.
This isn't an IPv6 problem, this is a "Things break for a little while when I use addresses to communicate with a host that can change out from under me instead of addresses that I control and those addresses happen to change." problem.
> ULA work well in combination with DNS though.
Yep! Most everything works great with DNS. Remembering IP addresses is for the birds.
[–] simoncion 1 hour ago
2002:db8::1
The 'getent ahosts' output remains unchanged.
When dealing with IPv4, all Linuxes, Android, and Windows 10 intermittently switch between preferring the GUA or the 1918 address. I seem to have gotten unbelievably (un?)lucky when testing v4 on Android, Gentoo Linux, and OpenWRT the first go around.
When dealing with IPv6, Android and Windows 10 always preferred the v6 GUA to the ULA. Every Linux I tried -and I tried several, each from different distros, some with and some without systemd, spread across years of releases- always preferred the ULA to it... except for OpenWRT, which always preferred the GUA. The only way I could get OpenWRT to prefer the ULA was to remove its GUA address but keep its v6 default route in place. Odd behavior. I wish I had a Steam Deck to see if "prefer the GUA" is something that appliance vendors tend to do, or if it's just a dubious OpenWRT customization.
The IPv6 behavior of all the OSs I tested is far better than the v4 behavior... predictability is always good. But it is remarkable that even many years ago, Linux was doing the sane thing for v6 address selection, while its commercial cousins and competitors -apparently- hadn't [1] bothered to think through how best to arrange things for "residential" users.
[0] ...even when no 6to4 addresses are configured on the host!
[1] ...and still haven't...
I assumed so because it's the obviously correct thing to do, but I haven't used a SoHo router in so many years, so I don't know.
> Random ULAs are also great for LAN-to-LAN VPNs, because there aren't any private IP overlaps.
Yep! Extremely low chance of prefix collision is their most important purpose. I've been part of several corporate acquisitions, and it inevitably took 6->18+ months to do enough of the IPv4 renumbering and server-discommissioning [0] process to begin to merge the LANs of the merging companies. Had they used ULA addressing, the odds of having to do that massive amount of work would be effectively zero.
And if collisions aren't something you give any shits about, nothing stops you [1] from setting your ULA to fd00::/48 and advertising fd00::/64 on your LAN for static IP addresses that are notably shorter than you can get with IPv4!
[0] ...because there's so little space in the 1918 range...
[1] ...well, unless your router's configuration system doesn't let you specify your ULA prefix...