7 ms·

> a better web experience than IPv4 That's already the case. IPv6 is often faster because most ISPs these days use cgnat for IPv4.

mort96 3mo ago
That fraction of a millisecond doesn't meaningfully translate into a better experience for users.
- kalleboo 3mo ago
  You're assuming the ISP has dimensioned their CGNAT properly and it's not congested.
- Hendrikto 3mo ago
  Milliseconds matter for gaming, for example.
  - hdgvhicv 3mo ago
    Vast majority of people gaming are doing it via wifi
  - commandersaki 3mo ago
    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).
    - Dagger2 3mo ago
      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.
    - HDBaseT 3mo ago
      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
      - Hendrikto 3mo ago
        There is no inherent added latency. That only applies for the translation layer, when there is no native support.
        commandersaki 3mo ago
        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.
BadBadJellyBean 3mo ago
True but not deploying any IPv4 connectivity would be a worse experience than not deploying IPv6.
jck86 3mo ago
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.
- lxgr 3mo ago
  > 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.
VorpalWay 3mo ago
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.
- Hikikomori 3mo ago
  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.
- inigyou 3mo ago
  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.
  - VorpalWay 3mo ago
    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.
- fundatus 3mo ago
  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?
hdgvhicv 3mo ago
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.
- inigyou 3mo ago
  Note that most ISPs are cellphone networks and most end devices are cellphones.
commandersaki 3mo ago
Sparing a few hundred microseconds of latency is tangibly a better experience?
CrLf 3mo ago
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.

mort96 3mo ago

That fraction of a millisecond doesn't meaningfully translate into a better experience for users.

kalleboo 3mo ago
You're assuming the ISP has dimensioned their CGNAT properly and it's not congested.
Hendrikto 3mo ago
Milliseconds matter for gaming, for example.
- hdgvhicv 3mo ago
  Vast majority of people gaming are doing it via wifi
- commandersaki 3mo ago
  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).
  - Dagger2 3mo ago
    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.
  - HDBaseT 3mo ago
    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
    - Hendrikto 3mo ago
      There is no inherent added latency. That only applies for the translation layer, when there is no native support.
      - commandersaki 3mo ago
        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.

BadBadJellyBean 3mo ago

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

jck86 3mo ago

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.

lxgr 3mo ago
> 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.

VorpalWay 3mo ago

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.

Hikikomori 3mo ago
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.
inigyou 3mo ago
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.
- VorpalWay 3mo ago
  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.
fundatus 3mo ago
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?

hdgvhicv 3mo ago

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.

inigyou 3mo ago
Note that most ISPs are cellphone networks and most end devices are cellphones.

commandersaki 3mo ago

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

CrLf 3mo ago

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.