[mattashii]

It was, at some point, routing. Not all (inter)continental data highways are/were IPv6-enabled, meaning that IPv6 does/did not have the performance of IPv4 (latency, bandwidth). Global websites with no global distribution of servers thus kept using IPv4-only to prevent significant performance regressions for the early adopter clients.

Similarly, IPv6 hardware accelleration was not very common on consumer/prosumer routing hardware, making it very resource-intensive (much more so than IPv4), resulting in low throughput.

... based on personal research in ~2015-2016

[AceJohnny2]

Years ago, the French ISP `Free`, after much dragging of feet, enabled IPv6 support for their customers.

Performance was abysmal, 2x-10x slower than IPv4.

Turns out many of the routers out there can perform IPv4 table lookups in the data-plane (fast-path), but IPv6 is delegated to the control-plane (slow-path), for much slower performance.

[lokedhs]

I see the opposite right now, with transfer rates being about the same but latency over IPv4 being quite bad compared to IPv6:

Pinging www.google.com with IPv6:

    $ ping www.google.com
    PING www.google.com(sc-in-x67.1e100.net (2404:6800:4003:c02::67)) 56 data bytes
    64 bytes from sc-in-f103.1e100.net (2404:6800:4003:c02::67): icmp_seq=1 ttl=108 time=4.46 ms
    64 bytes from sc-in-x67.1e100.net (2404:6800:4003:c02::67): icmp_seq=2 ttl=108 time=3.73 ms
    64 bytes from sc-in-f103.1e100.net (2404:6800:4003:c02::67): icmp_seq=3 ttl=108 time=3.73 ms

And with IPv4:

    $ ping -4 www.google.com
    PING  (142.250.186.100) 56(84) bytes of data.
    64 bytes from fra24s06-in-f4.1e100.net (142.250.186.100): icmp_seq=1 ttl=107 time=317 ms
    64 bytes from fra24s06-in-f4.1e100.net (142.250.186.100): icmp_seq=2 ttl=107 time=317 ms
    64 bytes from fra24s06-in-f4.1e100.net (142.250.186.100): icmp_seq=3 ttl=107 time=317 ms

I have no idea why that happens. It's not on all sites though, so it's not like my ISP adds latecy to all IPv4 sites, but rather something to do with routing. The IPv4 traffic might be routed to a google datacentre further away.

[ikiris]

Looks like you've got some geolocation issues, because you went across the globe for that v4 route lol.

[kazen44]

theoretically, ipv6 routing itself is far faster because the header is far simpler to parse.

also, the ipv6 space is far less fragmented then ipv4. this could lead to more direct routing aswell.

[throw0101a]

> Years ago, the French ISP `Free`, after much dragging of feet, enabled IPv6 support for their customers.

And quite a quick deployment AFAICT:

> Free deployed the IPv6 infrastructure in only 5 weeks, from 7 November to 11 December 2007, thanks to an innovative 6rd (IPv6 rapid deployment) proposal by Rémi Després.[44]

* https://en.wikipedia.org/wiki/Free_(ISP)#Internet_access

* https://en.wikipedia.org/wiki/IPv6_rapid_deployment

[blacksmith_tb]

Hmm, my experience in the US with CenturyLink Fiber's 6rd implementation suggests it's also slower than IPv4 (I went from ~900/900 to ~500/500 when I enabled it). I decided I could live with that, but it's still a little disappointing.

[kalleboo]

The main fiber network here in Japan (NTT) had the opposite development - their old PPPoE-based IPv4 core network was under-dimensioned for modern traffic patterns, so instead of upgrading it they build the next generation core network on IPv6.

So the first troubleshooting step when someone complains their home internet is slow is to say "have you enabled IPv6 service?"

Switching from PPPoE to IPv4-over-IPv6 means you get switched to CGNAT so if you want to host anything it's a downgrade, but in reward you get far greater performance.