Live data from Hacker News

IPv6 traffic crosses the 50% mark

google.com

531–540 of 643 posts

Re: IPv6 traffic crosses the 50% mark

#531
post #54

Earlier quoted context omitted.

Nearly all ISPs these days are deploying IPv6 for their mobile networks and core service networks, especially in less developed markets^1. The reason is simple, a cost justification. What doesn't exist is a cost justification for Enterprises to deploy IPv6, and for ISPs to deploy Residential / Corporate Internet IPv6. IMO with the right market conditions, IPv6 could spread really fast within 6-24 months. For example,…

Hetzner makes you pay 1 € per IPv4, while IPv6 is free. I'd gladly get rid of all IPv4's given that I have many servers.

But their VLANs still only support ipv4, which makes it hard to route external ipv6 traffic through the VLANs. You need tunnels.

Re: IPv6 traffic crosses the 50% mark

#532
post #54

Earlier quoted context omitted.

Hetzner makes you pay 1 € per IPv4, while IPv6 is free. I'd gladly get rid of all IPv4's given that I have many servers.

I don't even know why clouds offer public IP addresses. In my opinion all clouds should only have a gateway that routes via host header for millions of customers. IPv4 should be a special priv for special situations at a higher price. Then these clouds could own maybe 20 IPs total instead of millions.

> In my opinion all clouds should only have a gateway that routes via host header for millions of customers.

This is incompatible with TCP/IP networking. In TCP connections, (sender_address, sender_port, receiver_address, receiver_port) is a unique combination. Those numbers together uniquely identify the sender talking to the receiver. For a public webserver:

* sender_address is the client machine's IP address

* sender_port is a random number from 0..65535 (not quite, but let's pretend)

* receiver_address is the webserver's IP address

* receiver_port is 443

That means it'd be impossible for one client IP to be connected to one server IP more than 65535 times. Sounds like a lot, right?

* sender_address is the outbound NAT at an office with 10,000 employees

Now each user can have at most 6.5 connections on average to the same webserver. That's probably not an issue, as long as the site isn't a major news org and nothing critical is happening. Now given your scheme:

* receiver_address is the gateway shared by 10000 websites

Now each user can have at most 6.5 connections to all of those 10000 websites combined, at once, total, period. Or put another way, 100,000,000 client/website combos would have to fit into the same 65535 possible sender_ports. Hope you don't plan on checking your webmail and buying airline tickets at the same time.

Re: IPv6 traffic crosses the 50% mark

#533

Earlier quoted context omitted.

> It should be ISPs doing that to prepare for the transition. Yeah, I dont get why more ISPs don't offer carrier-grade NAT64 instead of the typical CGNAT

NAT64 doesn't make sense for consumers. There are too many apps that hardcoded IPv4 in their code. People are going to complain that their old Xbox games don't work. For most people, dual stack works fine. For mobile, the solution is 464XLAT that translates locally. There is MAP-E that does translation on gateway with IPv4 on local network. For businesses, NAT64 makes more sense cause they can control what software i…

> There are too many apps that hardcoded IPv4 in their code

That would work over CLAT, which most operating systems support. Steam has this issue, clat works around it while still using a ipv6-only net.

https://github.com/ValveSoftware/steam-for-linux/issues/3372...

Re: IPv6 traffic crosses the 50% mark

#535

Earlier quoted context omitted.

Yes, over 32 years ago. It was before ARIN and is considered a legacy block.

With your own /24 you can get an AS number and potentially BGP multi-home it.

Yes, I've already done that. I have the /24 tunneled to my home network.

Re: IPv6 traffic crosses the 50% mark

#537
post #264

I still do not support IPv6 on my servers and I think I will skip it and wait for IPv8: https://www.ietf.org/archive/id/draft-thain-ipv8-00.html Avoiding a dual-stack and making IPv4 a part of whatever superseeds it seems like the right choice to me. IPv6 always seemed to me like throwing away all existing telephone numbers, just to support longer numbers.

Maybe you didn't read the draft. It's either a delayed April's Fool joke or AI slop. Even if you take it seriously, it will require updating every v4 device in existence.

Re: IPv6 traffic crosses the 50% mark

#538
post #149

Zoom in on that graph using the controls at the bottom, and you'll see a repeating pattern of crests and troughs, weekly. There's about a 5% difference between the crests and the troughs: the crests are hitting the 50% line or just below it, and the troughs are down around 45%. The real question is, why are the crests so predictable? They're always on Saturdays; Sunday dips down a little below the crest, then Monday-…

This matches what I've seen too. Mobile carriers have been way ahead on IPv6 - T-Mobile in the US has been IPv6-only with NAT64 for years. The weekend pattern is pretty much a smoking gun for mobile being the driver. It also explains why the Google metric (which skews consumer) looks so much better than the Wikipedia numbers someone else posted (35% IPv6) or the server-side adoption stats from Common Crawl.

Re: IPv6 traffic crosses the 50% mark

#539
post #13

And still, in the year of our lord 2026, GitHub does not support IPv6. https://github.com/orgs/community/discussions/10539

Kinda sorta. github.com doesn’t have an IPv6 address. github.io does have an IPv6 address. Indeed, one workaround for getting rate limited when using a carrier NAT with github.com is to have a github.io page and pull data from github.io instead of github.com. Edit: About a decade ago, all of my hosting had full IPv6 support, and I tried to move over to IPv6. However, there was an issue with Letsencrypt certs not vali…

>github.io does have an IPv6 address

Are you sure? I don't see it.

Name: github.io

Addresses: 185.199.111.153 185.199.110.153 185.199.108.153 185.199.109.153

Post reply on HN