> a better web experience than IPv4
That's already the case. IPv6 is often faster because most ISPs these days use cgnat for IPv4.
> a better web experience than IPv4
That's already the case. IPv6 is often faster because most ISPs these days use cgnat for IPv4.
In my experience not true in practice cause I have experienced way more issues with the IPv6 endpoints of sites than their IPv4 counterparts.
This becomes noticeable when pipelines on IPv6 connected servers suddenly have random request/post failures to public services. Then either the whole service is temporarily having issues or there are a few bad IPv6 endpoints while all the IPv4 endpoints are fine.
Seemingly this failure mode can go unnoticed for days while the same won't be true for IPv4 due IPv4-only still being the norm for corporate networks. And no, current form of happy eyeballs v2 won't account for this.
Besides bad endpoints it could also be a problem with bgp route advertisements where the IPv6 prefix takes a weird path and ends up being blocked by a CDN at the other side of the ocean. This happens more than you'd think. Obtaining pypi packages was quite a challenge last year for us for a couple of weeks due to this.
Not really a fault of IPv6 technology wise, and in general can be solved client side through retry functionality, but in practice it still can lead to a worse outcome due to lackluster IPv6 adoption.
I used to think ISPs, organisations, admins and users were just being lazy for not implementing IPv6 or turning it off as the first thing to do when network problems happen, but when this far in the rollout such basic things still lead to difficult troubleshooting sessions then perhaps time has come to say something has gone terribly wrong.
It saddens me to say that I totally understand that businesses do not want to pay the price for implementing IPv6 unless absolutely necessary, because until the majority of traffic is IPv6 or even IPv6-only it does not make a lot of sense.
The flipping point is nearer than ever, though I fear it will in the short term lead to even worse stability for both protocols until IPv6 truly becomes the norm, whenever that may be.
> In my experience not true in practice cause I have experienced way more issues with the IPv6 endpoints of sites than their IPv4 counterparts.
If you've ever visited a website from your smartphone (over 4G/5G), your first hop has in all likelihood been over IPv6. If you have visited a website from your phone that only had an A record then you probably went through a CG-NAT box, which added latency.
If you streamed a Youtube video to your phone, or checked Gmail, or Instagram or Facebook, then it was over IPv6.
People (including probably you) use IPv6 everyday, multiple times, without knowing it.
Without disputing the added latency of CGNAT, the v6-only peering fights (not just the infamous Cogent-HE dispute but smaller regional ISPs peering only on v4) means that there are indeed cases where v6 is worse than v4 in practice. Again, nothing inherently wrong with v6 itself, but peering disputes means bad latency on v6, which means that protocols relying on TCP (like plain FTP, SFTP and rsync) really takes a hit in transfer speeds.
Also there are cases where the ISP didn't bother even optimizing their routing in v6. I understand that some ISPs in Asia (and especially in Japan, where it shows up on ordinary customers in terms like MAP-E and VNEs) have separate backplanes for v4 and v6 (some are legacy reasons, some are business reasons). Guess which one is being devoted more in practice (hint: not the one being devoted more by IETF).
Edit: I thought this was just in Asia, but apparently this is also the case in an ISP in UK (https://news.ycombinator.com/item?id=48618403)
> This becomes noticeable when pipelines on IPv6 connected servers suddenly have random request/post failures to public services. Then either the whole service is temporarily having issues or there are a few bad IPv6 endpoints while all the IPv4 endpoints are fine.
Do you have examples for this? I've never experienced this, and I've been using IPv6 for years.
Also, how can you be sure that the same request to IPv4 would have been fine? Did you actually see consistent failures on v6 and consistent success on v4? Otherwise, if a service has a reasonably low error rate, success on retry is the expected outcome, regardless of the path the retry takes.
There were indeed consistent failures to specific IPv6 endpoints, clearly identifiable through curl, while all the IPv4 endpoints were ok.
This happened with pypi (IPv6 BGP routing problem caused by a bad route from one of our peers combined with their fastly CDN not reply to us on IPv6 from the other side of the ocean for some weird reason), but also with yum and apt mirrors (seemingly random problems with the IPv6 service or firewall of the remote endpoint), and various other web resources accessed from pipelines.
The solution always was to temporarily block the bad IPv6 endpoint(s) or temporarily completely disabling IPv6 on the server itself or on the squid proxy server for workloads without direct connectivity.
Obviously it also can be the other way around, but in practice it appears to happen less often with IPv4, and if it does things get addressed quickly instead of taking hours or days or weeks.
Open source download mirrors often have much better targetting for v4 than v6. Just a few days ago, I was downloading installer images to check an issue and adding -4 to the command line reduced the download time significantly.
I saw HE stop routing to europe over ipv6 for an extended period of time two-ish years ago.
I have been on a dual stack IPv4 and IPv6 connection for a while now. IPv6 is the preferred protocol. I think I'd have noticed if there were widespread IPv6 issues. It used to be worse, but that was years ago.
True but not deploying any IPv4 connectivity would be a worse experience than not deploying IPv6.
I have yet to see any ISP use CGNAT here in Sweden. It seems to be a highly regional problem for some reason. Both on mobile and on broadband I get publicly routable IPv4.
That's because Sweden joined the internet relatively early when enough addresses were available. It's like that in most 1st-world countries. Places like Argentina, on the other hand, may have to share 8 IPv4 addresses per city.
That makes sense. However, I also don't get IPv6 on either my broadband or my mobile. So we seem to be far behind there.
Wow a publicly routable IPv4 address on a mobile phone? Wouldn't that drain the battery a lot? Or is there some kind of carrier-level firewall still?
Telia does it for mobile, I think Tele2 and 3 as well? Bahnhof, Bredband2 and other small ones also use it for wired customers, but you can usually get a public if you ask for it.
When CGNAT is present, my guess is that's the case. It would be nice to see a study on that; don't know if there is one already.
Users doing speed tests in CGNAT may be seeing numbers that aren't exactly real for a (still) mostly IPv4 Internet.
That depends on your isp. Mine certainly doesn’t, and I’ve never had an isp on the U.K. which didn’t give me at least a dynamic ipv4 address to my router.
Infact the only isp I have seen do it is starlink and I have contacts with ISPs in 60 different counties.
Note that most ISPs are cellphone networks and most end devices are cellphones.
That fraction of a millisecond doesn't meaningfully translate into a better experience for users.
You're assuming the ISP has dimensioned their CGNAT properly and it's not congested.
Milliseconds matter for gaming, for example.
We are still talking a fraction of a millisecond, a few hundred microseconds at most. People are blowing out of proportion latency saved with v6, it's negligible at best, or at worst let's not forget IPv6 is two separate island because two tier-1 carriers refuse to peer (Cogent & HE).
Vast majority of people gaming are doing it via wifi
Sparing a few hundred microseconds of latency is tangibly a better experience?