Meanwhile, CGNAT really solved most issues with IPv4. Yes, even the voice/video chat issues.
Want another fun example? Try to find a SIP telephony provider in the US that supports IPv6. Go on. I do this exercise about once a year.
/me glances over at my phone, which only has an IPv6 address when connected via cellular modem.
/me thinks back to the decade+ of incredibly boring IPv6 service from the residential ISPs I've used.
Sure.
If an ISP wants to provide only IPv6 addresses to CPE, they can set things up so that happens. But if you won't be satisfied until IPv4 no longer passes over the Internet, then you're going to die unhappy about that. The goal for our lifetime is one where every residential site has a global /56 and is behind IPv4 CGN, and servers hosted by commercial entities get to choose whether they assign IPv4 addresses, IPv6 addresses, or both to their servers.
Seriously, this drives me mad. There is NO WAY to get IPv6 on mobile networks in Switzerland. Neither Swisscom, nor Sunrise, nor Salt, and of course no reseller.
And Android handles this particularly poorly. I have some servers set up in my tailscale network on private IPv6 addresses, but android doesn't query AAAA addresses if it has no ::/0 route, so I HAVE to route all my traffic through my VPN which often creates other complications (with corporate wifi etc.)
- 2001:4860:4860::/112 (for chrome)
- 2000::/128 (for the system)
The drawback is that this breaks happy eyeballs, and you may notice slower response times on requests (since now your phone will start by quering AAAA results first which always fail for sites not on your VPN, and then fall back to the A result). In practice however I haven't really noticed any difference.
But I'd claim it failed completely. Many very public services (eg. github.com, sentry.io, office365.com, archive.org) outright don't support it. And the fact that infrastructure providers (like mobile network carriers) don't support it either, proves that it is far from "alive". In fact, I'd say it is deader than MMS, Fax and landline. For these I can still get service. For IPv6 (on the phone) I can't.
Email didn't replace letters on paper. But I wouldn't say email failed completely.
Given the number of scaredy-ass ISPs out there who refuse to offer IPv6 service, I disagree with this. But I do strongly agree with the rest of your comment.
I also very strongly assert that claims of the form "IPv6 is not the only version of IP used on the Internet, therefor it is a complete failure." maybe with a side of "And this 'failure' means that IPv6 is a dead protocol." are just plain stupid. v4 and v6 were very deliberately designed to coexist, and if v4 continues to run on the Internet until the day the Internet is shut down, that's totally fine.
In my opinion, the most plausible future is one I mention in my second paragraph here. [0]
Check my reply to your post. [0] I wrote it up before I noticed your message here. ;)
IPv6 is very much alive. And it's so boring and working so well, that you don't even notice it.
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.
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...
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.
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...
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)
/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_.
ULA work well in combination with DNS though.
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.
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...
> 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?
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
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.
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.
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.
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.
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)
Check out my research on this issue. [0] The results might surprise you.
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.
Early IPv6 was a mess. It took a surprising amount of time for IPv6 to become mature and usable.
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.