alt Hacker News> a better web experience than IPv4
That's already the case. IPv6 is often faster because most ISPs these days use cgnat for IPv4.
Replies
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.
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.
That fraction of a millisecond doesn't meaningfully translate into a better experience for users.
Sparing a few hundred microseconds of latency is tangibly a better experience?
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.