> I don't get your point. IPv6 is at "boring, just works". The majority of the worlds devices run on it dual-stack and it handles a considerable amount of traffic.
Most of the world runs on IPv4. If we shut down IPv6 on the core routers tomorrow, pretty much nobody is going to blink an eye. And now I believe that we should do it and start again.
The 50% stat is really mostly mobile phones on cellular networks, which remain the _only_ major success story for IPv6. Mostly because there's not enough private or even squattable IPv4 space available for many large mobile phone operators.
> IPv6 is very much alive. And it's so boring and working so well, that you don't even notice it.
Sigh. No, it's not. In a thread a couple of weeks ago, I gave several examples:
1. You're a SOHO-type business. How can you do multiple WAN uplinks with IPv6 without NAT?
2. How do you prevent your printer on IPv6 from breaking when your Internet connection goes down?
For context: I deployed IPv6 in my networks in 2006. I have war stories.
> How can you do multiple WAN uplinks with IPv6 without NAT?
Advertise the addresses offered by the primary uplink, then retire those addresses [0] and advertise the secondary when the primary fails. Or are you talking about load balancing, which is its own thing? Either way, this situation is inherently not boring, so the way you solve it is going to be quite a bit more complex -regardless of IP protocol version- than the very boring single-upstream situation.
> How do you prevent your printer on IPv6 from breaking when your Internet connection goes down?
I'll flip this around on you:
How do you prevent your printer from "breaking" when its ISP-provided DHCP lease on its globally-routable IPv4 address expires? How about when the ISP refuses to renew the lease on the printer's current globally-routable IPv4 address and forces it to get a new one?
Obviously, you use the ISP-assigned globally-routable IPv4 address and also assign an RFC 1918 address to the printer.
How to solve this with IPv6? Use ULAs! They're the equivalent of 1918 space in the IPv6 world. Just like in IPv4, IPv6 globally-routable addresses are for global communication and can be used for LAN-local communication. And -just like 1918 addresses- ULAs are for LAN-local communication. Just like with IPv4, if you can't control the addresses that you get from your upstream provider, and/or if your router is set up to retire your upstream provider's delegated address space when your upstream link goes down, then you use ULAs. [1]
I know that OpenWRT has a setting in LuCi to enable advertisement of a ULA prefix, and fifteen seconds of searching revealed that at least some Linksys combination router/APs seem to just generate and advertise a ULA prefix by default. [2]
So, if you're not configuring your LAN this way and upstream provider renumbering is getting in your way, then you really should bother to.
[0] ...by advertising their valid lifetime as zero seconds...
[1] ...or if you happen to like to be able to assign fixed IP addresses to certain pieces of hardware...
[2] <https://support.linksys.com/kb/article/3744-en/>
> Use ULAs
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.
> Isn't that the default for modern routers?
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...
ULA are useless for most practical purposes because of the source address selection rules.
There is some truth to it, because they only work well if used directly (either hard coded IPs or DNS).
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)
> ULA are useless for most practical purposes because of the source address selection rules.
/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_.
The problem is real. In IP discovery GUA is prioritized over ULA. And if the GUA goes away or changes regularly it leads to connectivity issues.
ULA work well in combination with DNS though.
> In IP discovery GUA is prioritized over ULA. And if the GUA goes away or changes regularly it leads to connectivity issues.
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:
Notice how actual application behavior doesn't match what folks in this thread are saying that source address selection dictates. Android behaves the same way, and -weirdly- my OpenWRT hosts have the exact opposite behavior and prefer using global addresses to ULA or 1918 ones, regardless of IP protocol version.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.
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...
OK, do you _think_ my questions were that easy?
> Advertise the addresses offered by the primary uplink, then retire those addresses
Prefix withdrawal doesn't work reliably on Android. And neither is it required to work, btw. Neither does this solution allow for load balancing, as all traffic will just go through one connection.
Bonus points: triangular routing to your local NAS through the router.
> How do you prevent your printer from "breaking" when its ISP-provided DHCP lease on its globally-routable IPv4 address expires? How about when the ISP refuses to renew the lease on the printer's current globally-routable IPv4 address and forces it to get a new one?
Printers get an RFC1918 address and don't care about global connectivity.
> How to solve this with IPv6? Use ULAs! They're the equivalent of 1918 space in the IPv6 world.
They're not. IPv6 is nothing like IPv4 operationally. Back to my challenge, ULA will NOT work.
The scenario is very simple: the printer gets a ULA prefix and a GUA prefix. Your computer also gets a GUA and a ULA from the same router.
So far so good.
Now the uplink goes down, and the router withdraws the prefix. The printer sees the withdrawal and removes its GUA address. Your computer misses it, and still has the GUA and the ULA addresses.
Whoops. The printing is now broken somehow. Why?
> Prefix withdrawal doesn't work reliably on Android.
Works fine on the Android hardware I have. Are you attempting to retire prefixes that have an infinite lifetime? That doesn't work, and I don't think it's supposed to work.
> Neither does this solution allow for load balancing...
As I said
> Printers get an RFC1918 address and don't care about global connectivity.Okay, so why are you complaining about your printer being broken by GUAs that you're not permitting it to have? ;)
> IPv6 is nothing like IPv4 operationally.
For anyone who's not an IP stack developer, network hardware developer, or Enterprise sysadmin it absolutely is. And other than the fact that every endpoint is able to get a global address in v6, the sysadmin-visible differences between v4 and v6 are minor. RAs instead of... well, nothing, and DHCP for both.
> Whoops. The printing is now broken somehow. Why?
Exactly.
Why isn't your DHCPv6 server putting either both the GUA and ULA, or -better- only the ULA addresses in your LAN's DNS server? This Just Works™ on dnsmasq, which is one of the most widely-deployed DNS+DHCP servers on SoHo gear. [0] dnsmasq's default TTL for hosts added to the DHCP lease file appears to be 0, so -worst case- your sleepy computer tries to continue its conversation with the printer a couple of times, does ND and discovers that the IP it was using is gone, then looks up the hostname again and gets the new address of the printer. I think the trendy term for this back in the 2000s was "self-healing".
If you're going to retort "But we don't use dnsmasq in the companies I'm sometimes talking about!"... well, if you can't figure out how to not register upstream-controlled GUA addresses for your LAN hosts in your DNS, then do what dnsmasq does and serve them up with a TTL of 0.
[0] To head off the "Android doesn't really do DHCPv6" retort: Even though Android refuses to use anything other than DHCPv6-PD for managed address assignment, -AFAIK- Android still sends DHCPv6 ADDR_REG_INFORM messages for addresses it autogenerates on networks with either the "OtherConfig" or "Managed" flags set. I haven't bothered to set up my Linux systems to do this, but I'd be surprised if Windows and Darwin systems didn't do this.
> Why isn't your DHCPv6 server putting either both the GUA and ULA, or -better- only the ULA addresses in your LAN's DNS server?
I don't have a LAN's DNS server or a DHCPv6. BTW, I have had an IPv6-only home network for 10 years, with NAT64 and 464XLAT.
You still haven't solved my puzzle or even understood what's happening. The current source address selection rules result in hosts prefering a GUA address pair over ULA. This _will_ result in broken connectivity when GUA addresses change.
There is currently no standards-compliant way to solve my challenge, except getting an ASN, an IPv6 assignment, and announcing it through your uplinks. Which I've also done in my home network, btw.
There's an in-progress RFC to change this, by preferring ULA-ULA address pairs over GUA-GUA. So it might be usable some time in the 2030-s ( https://www.ietf.org/archive/id/draft-ietf-6man-rfc6724-upda... ).
And no, this is not a theoretic problem. It affects protocols like SIP or even mDNS that exchange the IP addresses. They will consistently prefer unstable GUAs over ULAs.
> I don't have a LAN's DNS server or a DHCPv6.
Yeah, that's why you think that this is a "puzzle".
Though, it does invalidate every complaint you've made about IP source address priority. The only ways you'll get multiple addresses for a given host are to either hard-code them, or use DNS [0]. Given that you're not using DNS, then you either have automation to update all those hard-coded configs, or you do it all by hand. Either way, you're deliberately recording addresses that you don't control for your LAN hosts, and considering it a "puzzle" when you have trouble reaching those LAN hosts when your upstream provider changes their address.
[0] Given that every resolver I've ever used pulls data from '/etc/hosts', I'm considering that to be part of DNS for the purposes of this conversation. I'm also considering Avahi and friends to be DNS. [1]
[1] And if you've talked to any long-term Avahi user, you've certainly heard about its habit of -on daemon or host restart- erroneously considering host name of the machine it's running on to be "in use" and appending a "-N" to the end of it. The remarkable eagerness of Avahi to engage this collision-avoidance mechanism makes it entirely unsuitable for discovery of LAN hosts whose hostname is actually important. This fact breaks my heart, but Avahi has been doing this shit for a very, very long time, so it's probably never going to get fixed.
> The only ways you'll get multiple addresses for a given host are to either hard-code them, or use DNS
mDNS exists. As does SIP and SMB.
I first discovered the ULA/GUA issue when my TimeMachine backup dropped mid-session when I was testing Internet connection failover. Apple later fixed it by allowing multiple SMB sessions in parallel and preferring IPv4 connections. I have a pure IPv6-only network, as I said.
The same issue happens with SIP, as phones send their own addresses during the media connection negotiation.
(I have another funny story about SIP: Asterisk used to send a Cartesian product of available codecs and IP addresses, so if you had IPv6 privacy addresses on, it eventually accumulated enough of them to overflow the MTU, causing connections to silently drop)
> I first discovered the ULA/GUA issue...
Check out my research on this issue. [0] The results might surprise you.
[0] <https://news.ycombinator.com/item?id=50299152>
> The 50% stat is really mostly mobile phones on cellular networks, which remain the _only_ major success story for IPv6.
The largest ISPs in the US are Comcast, AT&T, Charter, Verizon, T-Mobile, Starlink, and Google Fiber. They all support IPv6. The only top-10 US provide that didn't support it is Frontier Communications, who is rolling it out.
In other words, the biggest companies who actually do this for a living all demonstrate that you're wrong.
As to your questions, read up on IPv6 ULA which solves all of them. None of the hosts on my LAN depend on having an outbound connection.
> For context: I deployed IPv6 in my networks in 2006. I have war stories.
Early IPv6 was a mess. It took a surprising amount of time for IPv6 to become mature and usable.
I'd argue that it's still not mature. ULA/GUA mess is one example, I recommend reading this delightful thread with beer and popcorn: https://mailarchive.ietf.org/arch/msg/v6ops/7-SuigPyP0R-C6ZC...
Having to waste 64 bits for the local part of the address is another one. There's an RFC in progress to allow neighbor discovery with shorter prefixes, so we might be able to use it by 2045.
And Android _still_ doesn't support DHCPv6.