IPv6 traffic crosses the 50% mark • Hacker News Board

Re: IPv6 traffic crosses the 50% mark

#581

Post by kalleboo » Fri, Apr 17, 2026, 1:20 AM UTC

lxgr wrote: post #406

kalleboo wrote: post #364

Earlier quoted context omitted.

IPv4 is provided using DS-Lite or MAP-E depending on the provider. I'm using OpenWRT and paid for a static IP so I had to manually configure all the details for the MAP-E tunnel in OpenWRT myself, I think typically the routers sold to consumers pick up the configuration automatically somehow.

Woah, MAP-E allows static v4 (and presumably inbound connections)? That seems neat and much better than DS-Lite!

I'm re-learning this right now since I kind of just set it and forgot it 2 years ago but while my provider typically uses MAP-E it looks like when you use a static IP it switches to using RFC2473 (IPIP6) directly without the extra port mapping that MAP-E adds ontop

Re: IPv6 traffic crosses the 50% mark

#582

Post by ticulatedspline » Fri, Apr 17, 2026, 1:26 AM UTC

keybits wrote: post #129

Tailscale have a great FAQ about IPv4 vs IPv6: https://tailscale.com/docs/reference/faq/ipv6 If you're not an expert in this area it's worth a read - I certainly learned a few things!

interesting read, pretty depressing take if you're pro IPV6. I think their guess that IPV6 has low value-add when considered as part of a hybrid environment is probably one of the better explanations I've heard for poor uptake.

The linked post are also interesting reads:

https://tailscale.com/blog/two-internets-both-flakey

https://apenwarr.ca/log/20170810

Re: IPv6 traffic crosses the 50% mark

#583

Post by mike_mx » Fri, Apr 17, 2026, 1:39 AM UTC

ck2 wrote: post #483

forgive dumb question but what happens when someone on IPv6 without IPv4 tunnel visits a URL with only a IPv4 endpoint? like say * https://1.1.1.1/cdn-cgi/trace vs * https://one.one.one.one/cdn-cgi/trace When ipv6 threads like this come up, someone eventually mentions T-Mobile is completely IPv6 now but they must have IPv4 tunnels because I have IPv4 turned off on my modem/router and can still visit both those URLS

Not dumb. It's not exactly a tunnel, it's a double sided conversion.

Basically to reach any v4-only resource you need a translator, typically NAT64. This maps the entirety of the v4 internet into a /96 of IPv6 space (last 32 bits).

DNS64 is one way to access this, which will return a result for 'amazon.com' like:

A = `98.87.170.74` AAAA = `64:ff9b::6257:aa4a`

Combining this with CLAT lets you punch in an IPv4 literal like 1.1.1.1 and your phone/computer will do this conversion from v4 -> v6 locally without you changing anything. So 1.1.1.1 would become `64:ff9b::101:101` on-device - and that's actually what your mobile ISP sees.

T-Mobile and most mobile operators use 464XLAT - which has been in Android & iOS for at least 8-10 years now if memory serves.

It lets you visit 1.1.1.1 because your phone is converting it automatically to T-Mobile's NAT64 prefix (CLAT - customer side), it traverses their network v6-only, and then it ends up at their translator (PLAT - provider side) and becomes normal NAT'ed v4 traffic out to CloudFlare.

Re: IPv6 traffic crosses the 50% mark

#584

Post by orangeboats » Fri, Apr 17, 2026, 1:44 AM UTC

traderj0e wrote: post #564

zokier wrote: post #27

This google metric measures adoption in access networks, but at this point I feel more interesting metric is adoption in services. One such stat is here: > adoption ranging from 71% among the top 100 to 32% in the long tail https://commoncrawl.org/blog/ipv6-adoption-across-the-top-10... Getting full coverage on AWS (/GCP/Azure) and few other key services (GitHub...) would be significant here imho.

Yeah, a large portion of those ipv6 Google searches are afterwards connecting to an ipv4 host.

I doubt it honestly. Most people are connecting to sites like Youtube, Instagram etc., which do actually support IPv6.

It's how I get 60~80% IPv6 traffic on my home network. A great portion of it was because of my mom watching Youtube.

Even when you discount the services run by FAANG, for personal sites, Cloudflare and GitHub Pages (but surprisingly, not GitHub itself) support IPv6 and enable IPv6 support by default.

Re: IPv6 traffic crosses the 50% mark

#585

Post by [deleted] » Fri, Apr 17, 2026, 1:49 AM UTC

vel0city wrote: post #439

kalleboo wrote: post #185

Earlier quoted context omitted.

I had the same issue a few months ago on AWS. All I want is a server (that pulls a container), a database, and a load balancer. It's all going behind CloudFront so there should be no need to pay for an IPv4 address for any internal machine. Couldn't do it. Since then I saw that there was some movement on IPv6 for RDS but IIRC there was still some other blocker.

> so there should be no need to pay for an IPv4 address for any internal machine At what level did you need to pay for IPv4 addresses in this stack? You should have been able to make this work with a private IPv4 space, have the ECS services be dual-stack and be on both the v6 network and the v4 network to talk to the database server, have the ALB be v6, and then have Cloudfront be v6. If you wanted, you could also j…

[deleted]

Re: IPv6 traffic crosses the 50% mark

#586

Post by kalleboo » Fri, Apr 17, 2026, 2:09 AM UTC

Galanwe wrote: post #384

kstrauser wrote: post #302

Earlier quoted context omitted.

I genuinely don’t understand this. The concepts are nearly identical between the two.

Hum no, to me they are orthogonal. v4 was built around the idea of multiple free standing networks linked by gateways. v6 was built around the idea of a universal network. I dont care about what your LAN adress space look like when I'm in my LAN, because we are not in the same v4 network. I am sovereign in my network. With v6, everyone is effectively in the same network. I have to ask my ISP for a prefix that he will…

> v4 was built around the idea of multiple free standing networks linked by gateways

It was absolutely not. This is why early companies like Apple and Ford got massive IP allocations - each computer was expected to have a unique IP address.

NAT didn't exist until 14 years after IPv4 was created, in response to the shortage of IPv4 addresses, and in the RFC it is described as a "short-term solution", very clearly stated that his not how the internet is designed to work and it should only be used as a stopgap until we get longer addresses.

Re: IPv6 traffic crosses the 50% mark

#587

Post by Dagger2 » Fri, Apr 17, 2026, 2:14 AM UTC

GoblinSlayer wrote: post #507

throw0101d wrote: post #254

Earlier quoted context omitted.

I have not had a deal with this, but if I was going to, I would start at the /64 and move up by nibble (4-bit) boundaries: /64, /60, /56, /52, /48. /56 is often recommended as the minimum as for a (residential) customer. /48 is considered a "site" address prefix, and is the smallest allocation that can be advertised in BGP: * https://blog.apnic.net/2020/06/01/why-is-a-48-the-recommende... * https://www.infoblox.com/b…

APNIC blog says /48 prefixes are for global routing, i.e. site=country there, not web server. >/48 is the minimum prefix size that will be routed globally in the BGP.

I'm not sure if I'm misreading you, but a /48 would never be an entire country's v6 allocation.

If we're talking home networks, you can reliably expect a /48 to a) not be announced in BGP itself, and b) cover one to a few hundred users of one ISP. (The containing /32 or similar will be announced.) A business might structure its network so that one of its /48s corresponds to a country, but in that case the /48 would be covering just that business, which would be a sensible unit for reputation tracking.

Re: IPv6 traffic crosses the 50% mark

#588

Post by Dagger2 » Fri, Apr 17, 2026, 2:36 AM UTC

dsl wrote: post #548

keeperofdakeys wrote: post #24

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,…

Imagine if one day someone came up with a "better" way to chew food, but you had to learn how to do a super complex jaw movement and it wouldn't work in restaurants. It has no obvious benefit to you. The only motivation is that a small group of obsessively passionate (but not in a good way) people say at some unknown point in the future food won't be edible anymore. IPv6 just tried to do too much so it failed at ever…

Meanwhile, everybody else is using a plastic skull that they carry around with them to pre-chew the inedible food, which is the majority of the food you can get these days.

"It's not inedible," they say. "Just let me get my skull out."

> IPv6 just tried to do too much so it failed at everything. Putting letters in IP addresses made it near impossible to remember what your network settings were supposed to be.

People said the same sort of thing about v4: that it was hard to configure because you needed to know four separate addresses (IP, netmask, default route AND the DNS server) and if you mix up any of these it doesn't work.

As it turns out, in both cases it's just a lack of familiarity, not actual difficulty. The super complex jaw movement is just a regular bite, but you puff your cheeks out a bit. Or er, something.

> This lead to Cisco, Microsoft, and Google all taking completely different approaches [...] but this time they forgot to add a way to communicate a default route

"There should only be one way to do things... wait, no, not like that."

Re: IPv6 traffic crosses the 50% mark

#589

Post by kalleboo » Fri, Apr 17, 2026, 2:39 AM UTC

marginalx wrote: post #373

Is most of that due to mobile? The real migration challenges are in the server side/consumer home internet space which I'm not sure if there are clear stats around the adoption there. I think IPV6 is a great example of over engineering, trying to do too much in one iteration. In an ideal scenario this could work, but in the context of large scale change with no single responsible party, it usually doesn't work well.

On the server side, everyone is moving behind CDNs that support IPv6 by default.

On the consumer home internet side, consumer ISPs are slowly one by one lighting up IPv6, and it just works since consumer routers are mostly auto-configure (often literally controlled by the ISP). Mobile is largely IPv6 already.

The biggest challenge is in corporate/academic/medium-size business networks where they have lots of obscure subnets and firewall rules and old software and hardware running a critical task under a dusty table somewhere.

Re: IPv6 traffic crosses the 50% mark

#590

Post by rmunn » Fri, Apr 17, 2026, 2:42 AM UTC

Xirdus wrote: post #274

rmunn wrote: 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-…

Residential vs. business. If the graph was hourly and per country, you'd see the same rise every morning and drop every evening (likely by more than 5pp).

Your mention of per-country reminded me that Google is probably using UTC for those timestamps. 11:59 PM UTC is 8:59 AM the next day in Japan (UTC+9), so Japanese people getting online early Saturday morning would register as accessing Google services on "Friday" until the time hits 9:00 AM in their timezone. Likewise Korea (also UTC+9) until 9:00 AM local, China (UTC+8) until 8:00 AM local, Vietnam (UTC+7) until 7:00 AM local, and so on.

Which means that if Japan, Korea, China, Vietnam, and other east Asian countries have a higher IPv6 adoption in residential vs business ISPs, then their Saturday-morning Internet access is likely part of the 1-2pp bump on Fridays in this chart.

P.S. Also, none of Japan, Korea, China, or Vietnam use daylight savings time (very sensible of them), so their UTC offsets are the same year-round. So their Saturday-morning contributions to the Friday chart will not vary from month to month due to timezone slippage, because they will never gain nor lose an hour relative to UTC. It might vary a little with actual seasons, as the sun rises later or earlier... but so many people use alarms to get up at 6:00 AM no matter what the sun is doing, rather than rising with daylight, so the amount of early-morning Internet access in winter months is not going to change significantly compared to summer when the sun rises earlier.