Live data from Hacker News

IPv6 traffic crosses the 50% mark

google.com

361–370 of 643 posts

Re: IPv6 traffic crosses the 50% mark

#361

Earlier quoted context omitted.

I’m guessing the app works but their prod servers don’t? If they can point the app during review at a “self hosted” GitHub Enterprise server on a test domain with AAAA that would pass the requirement as stated by gp , without requiring GitHub.com actually support ipv6.

The prod servers work. The app does a DNS lookup, receives something like 64:ff9b::140.82.112.5 and 140.82.112.5 from the ISP's DNS servers, and then connects to 64:ff9b::140.82.112.5. Some part of the ISP network translates the connection into a v4 connection to 140.82.112.5. The requirement is simply that the app does AAAA queries, and that it attempts to connect to them if they exist. It doesn't matter whether the…

That’s DNS64, which is pretty annoying in practice. (For one thing, you can’t use your own DNS server anymore, but more importantly, anything using v4 literals will 100% break.)

What’s nicer is 464XLAT, or more generally NAT64 prefix announcements. Then your local OS can just synthesize NAT64 addresses from v4 literals, either at the socket library or kernel networking (via “bump in the stack” translation) layer.

Re: IPv6 traffic crosses the 50% mark

#362

Earlier quoted context omitted.

GitHub is at the point where it immediately rate limits me if I try to look at a project's commit history without being logged in, as in the first time I even open a single URL to the commit history, I get "Too Many Requests" from GitHub thrown at me. I don't know if my work's antivirus stack is causing GitHub to be suspicious of me, but it's definitely egregious.

Your work is probably all exiting through the same IP, you competing with others on the same IP is causing the rate limit.

I've considered this, but the company is small enough that the number of people who would be on GitHub at any moment (instead of our internal git forge) can be counted on one hand, and when I'm the first one there in the morning it still rate limits me.

Re: IPv6 traffic crosses the 50% mark

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

great resource. Common crawl is a goldmine

Re: IPv6 traffic crosses the 50% mark

#364
post #355

Earlier quoted context omitted.

Yeah in Japan my ISP even lets me choose which IPv4 provider I want to use, as the fiber network is IPv6-native and IPv4 is "just another service" like IPTV.

Wow, that’s very cool! Do you know how that works? Do they just connect you to a NAT64 gateway of your choice?

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.

Re: IPv6 traffic crosses the 50% mark

#365

Earlier quoted context omitted.

Your work is probably all exiting through the same IP, you competing with others on the same IP is causing the rate limit.

I've considered this, but the company is small enough that the number of people who would be on GitHub at any moment (instead of our internal git forge) can be counted on one hand, and when I'm the first one there in the morning it still rate limits me.

Maybe your company's ISP is CGNat'ting you?

Re: IPv6 traffic crosses the 50% mark

#366

What I have asked myself the last few months: I've read about IPv4 becoming sparce a few years ago. I haven't read much about it lately. And I've thought maybe the advance of cloud computing and load balancer kind of mitigated the issue of sparce IP4?

It officially started becoming scarce in 2011, when IANA, and then APNIC, depleted their IPv4 "free" pools, FWIW. Things have only gotten worse from there.

Cloud computing doesn't mitigate IPv4 issues, it just moves it around. The big cloud providers buy up any IPv4 space they can, leaving less for everyone else. The difference is that they then get to collect rent, by the hour, on any IPs their customers use.

Load balancers...yeah, actually that is a valid approach to reduce IPv4 use, assuming you mean the "reverse proxy" variety of load balancer. Cloudflare's proxy service is doing exactly this, on a pretty huge scale. (CLoudflare can then send the traffic on to an IPv6-only server, regardless of the client's protocol.) The downside is, like cloud, consolidating a lot of infrastructure into the hands of a small number of companies.

Re: IPv6 traffic crosses the 50% mark

#368
post #182

Can someone reconcile for me the constant chatter about how IPv6 isn't getting impemented, versus this result that more than half of all traffic (as measured by google) is now IPv6? It sounds to me like its a tool which is available to be used when needed and when no better workarounds exist, and it is slowly but surely being adopted as needed.

Most of the chatter comes from the peanut gallery who have no real insight on what ISPs and other large networks are actually doing.

This. "Vibes," vs. data.
Post reply on HN