Hacker News Reader

Comment by BadBadJellyBean | Hacker News Reader

I wonder if there will ever come a day when IPv6 will provide a better web experience than IPv4.

At the moment pretty much every website is reachable via IPv4 but a lot not via IPv6. Will there be a day when this turns around?

View on HN

> a better web experience than IPv4

That's already the case. IPv6 is often faster because most ISPs these days use cgnat for IPv4.

True but not deploying any IPv4 connectivity would be a worse experience than not deploying IPv6.

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.

Vast majority of people gaming are doing it via wifi

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).

Google's stats claim that it's 10-20ms for many countries, for example both the US and Canada show the latency impact of v6 as being -10ms. This is per round trip too -- between the connection handshake, congestion window slow-start and serialized requests it adds up to something significantly bigger than a few hundred microseconds.

> let's not forget IPv6 is two separate island because two tier-1 carriers refuse to peer (Cogent & HE).

The Cogent island must be very small, because I'm single-homed on HE and had actually forgotten about that.

Or perhaps v6 isn't split into two separate islands after all, and this is just yet another weird claim people make about v6 that doesn't match reality.

Latency wise, I am not noticing any difference (at least in ICMP).

ycombinator@Mainframe:~$ ping 8.8.8.8

PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.

64 bytes from 8.8.8.8: icmp_seq=1 ttl=119 time=24.3 ms

64 bytes from 8.8.8.8: icmp_seq=2 ttl=119 time=24.1 ms

64 bytes from 8.8.8.8: icmp_seq=3 ttl=119 time=23.9 ms

64 bytes from 8.8.8.8: icmp_seq=4 ttl=119 time=23.9 ms

^C --------------- 8.8.8.8 ping statistics --------------------

4 packets transmitted, 4 received, 0% packet loss, time 3004ms

rtt min/avg/max/mdev = 23.901/24.053/24.291/0.157 ms

ycombinator@Mainframe:~$ ping6 2001:4860:4860::8844

PING 2001:4860:4860::8844 (2001:4860:4860::8844) 56 data bytes 64 bytes from 2001:4860:4860::8844: icmp_seq=1 ttl=118 time=23.5 ms

64 bytes from 2001:4860:4860::8844: icmp_seq=2 ttl=118 time=24.0 ms

64 bytes from 2001:4860:4860::8844: icmp_seq=3 ttl=118 time=23.9 ms

64 bytes from 2001:4860:4860::8844: icmp_seq=4 ttl=118 time=24.0 ms

^C ------- 2001:4860:4860::8844 ping statistics -------------------

4 packets transmitted, 4 received, 0% packet loss, time 3005ms rtt min/avg/max/mdev = 23.517/23.845/24.008/0.200 ms

There is no inherent added latency. That only applies for the translation layer, when there is no native support.

OP was making the case that CGNAT adds to the latency in some significant way. Yes it adds latency, but it is of negligible concern.

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.

> 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.

Try `ip link set mtu 1280 dev eth0` (or equivalent for your OS).

pMTUd breakage exists on v6 just like it exists on v4, and requires workarounds just like it does on v4. I get the impression a lot of people are applying a workaround on v4 but not on v6, then blaming the resulting failures on v6 without bothering to do any troubleshooting to figure out what's actually wrong.

This was not a path mtu problem since it was random IPv6 endpoints having issues.

And if all the IPv6 endpoints of a major service go down we should pin our mtu to the bare minimum? Nonsense.

The inconvenient truth is that IPv4 will be more stable than IPv6 until the former gets demoted to second class fallback protocol instead of the major driver of the internet. And when that happens no one knows.

People running servers don't seem to be reliably capable of making sure that either pMTUd works or isn't needed on their network, so... it is indeed broken on random servers.

We've mostly decided to go with TCP MSS clamping rather than using the minimum MTU, which is still nonsense but it's nonsense that we already decided to go with for the same problem in v4.

Of course, I don't have enough info to tell if this was the problem or if it was something else, or a mix of the two, but pMTUd does seem to be a leading cause of "fails to load for some weird reason" problems.

I saw HE stop routing to europe over ipv6 for an extended period of time two-ish years ago.

I'm in Europe and I use a tunnel from HE for v6. I feel like that's something I would have noticed if it was as widespread as you make it sound.

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 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.

It is not widespread. Not for the major services at least. But saying IPv6 is better than IPv4 with lower latency due to better routing and lower overhead simply is not true. Apparently there are other factors at play that also matter a great deal and still lead to teething problems.

> 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)

Yeah, I tried to switch ISP. Was thinking everything was fine, then tried to watch on ClaroTV+ here (similar to Youtube TV, Hulu Live, etc), and it was... awful. Then I figured out, the IPv6 route was going from Brazil > US > Argentina, or some other crazy crazy route. While IPv4 was just inside Brazil.

So I tried to complain to the ISP, and they just said they couldn't do anything, and if I wanted, they could disable IPv6 for me...

Of course, I canceled the ISP.

Sadly it's pretty common for several ISPs have smaller peerings with IPv6, so this is not uncommon.

My other other ISP worked super fine, but even then, they had two ASN. One for IPv4 and the other for IPv6, just to show how different they were...

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.

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.

Sparing a few hundred microseconds of latency is tangibly a better experience?

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.

Faster webrtc establishments and other negotiated connections. CGNAT means more relayed than P2P connections so it should be possible to have more direct traffic for services that want to save that bandwidth.

It already does. With IPv6, you don't go through some CGNAT box, that could misbehave or just break (and since the biggest chunk of content is available through IPv6, this may not be a priority). Also, a shared IPv4 can be banned by various sites if one of the owner misbehaves. This issue is not present with IPv6.

More on this: https://vincent.bernat.ch/en/blog/2024-why-ipv6

I would expect online video games to be a more important driver.

and anything P2P. Maybe that would have been a driver 20 years ago, but now everything is expected to be centralised. Our culture has shifted. Remember when people used to host their game servers? If you're under 16, you don't because it was never in your lifetime.

I have to open a hole in my firewall to host any service. Nat doesn’t change that.

Unless you want to host multiple minecraft servers on the same port on different servers at home?

Indeed hosting anything at home is such a rare workflow that someone wanting it can choose an isp which gives them the facilities they need.

Unless you don’t live in a competitive market based economy and just have the single government mandated isp aimed at the lowest common denominator, in which case you’ve got far worse problems.

The average person finds port forwarding much more confusing than "allow Minecraft y/n"

Or unless you do live in a competitive market based economy, and have a choice of several ISPs with practically equivalent offering aimed at the lowest common denominator, none of whom supports something niche like "giving you facilities for hosting stuff at home".

If there's one thing market competition does well, is remove any kind of meaningful variety - because supporting a niche offering costs money, and is not worth it unless it nets positive, otherwise it's just a drag that makes you fall behind your competition.

it's more like that the IPv6 switchover was so fumbled that we went from fast P2P like with Skype, to shitty, centralized and data-mined Discord.

The internet would be much less centralized if IPv6 happened when it was supposed to.

Reply on news.ycombinator.com