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.
It’s not you or your setup. I experience the same behavior. Tried with and without Private Relay, residential and commercial ISPs at different locations, and more to debug it. Same results.
I think GitHub has just gotten so aggressive with their rate limit policies that it’s straight up incompatible with their own product. The charitable interpretation is that they aren’t keeping good track of how many requests each page actually performs in order to calibrate rate limiting.
My theory is that they rate limit that URL aggressively due to AI scrapers. At this point it's faster to just clone the repo and do your searching locally.
The very same thing happen on my residential connection, I can do one search query, then I'm rate limited for 15+ minutes, same if I access any list of commits.
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.
Hm, I've also noticed sites being more aggressive about verifications after I started using LLMs locally. They think I'm a bot (which... fair), even on completely unrelated sites I seem to be getting prompted for human verification much more often.
IPv1, IPv2, and IPv3 were very early experimental versions of the Internet Protocol developed in the 1970s during the ARPANET era (the precursor to the modern internet). Has anyone tried to find out if GitHub is reliable on those?
Same with Twilio. We have an internal server that does system alerts. We recently moved it to an IPv6 only host, and a few weeks went by and noticed there were no longer receiving alerts.
Turns out we could not connect to Twilio's API which is IPv4 only.
Our university has bad problems with ipv4. Every few days you'll notice some websites being unreachable, including github. Although with their uptime recently, you never know who's to blame...
The irony of this is that pretty much all they'd have to do to enable IPv6 support is to use Azure Front Door as their CDN. Or... use any other CDN, they pretty much all default to providing IPv6!
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 validating over IPv6, so I made my web pages IPv4 only. Recently, I gave IPv6 a go again, and the cert issue has been fixed, so now my webpages finally have both IPv4 and IPv6 addresses.
It has barely hit 50% and it's already plateauing. This adoption rate is ridiculous despite basically all network interfaces supporting it. I thought I would see IPv6 take over in my lifetime as the default for platforms to build on but I can see I was wrong. Enterprise and commercial companies are literally going to hold back internet progress around 60 to 75 years because it's in their best interest to ensure users can't host services without them. Maybe even 75 years might be too optimistic? They are literally going to do everything in their power to avoid the transition, either being dragged out kicking and screaming or throwing their hands up and saying they can't support IPv6 because it costs too much.
Try going IPv6-only by disabling IPv4 on your computer as a test and notice that almost nothing works except Google. End users shouldn't need to set up NAT64/6to4 tunneling. It should be ISPs doing that to prepare for the transition.
Also, notice how Android and iOS don't support turning off IPv4.
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-Friday is down in the 45% range before the next Saturday jumps up to 50% again. (Fridays usually have a small rise, up to the 46-47% area).
My theory: mobile access rises on weekends. People are more often accessing Google services from their work computers Monday-Friday, but on Saturdays and Sundays most (not all) people are away from the office. Many of them will end up using smartphones rather than laptops for Internet access, for various reasons such as being outdoors. And since smartphones are nearly all using IPv6 these days, that means an uptick in IPv6 usage over the weekends.
If GitHub flipped a switch and enabled IPv6 it would instantly break many of their customers who have configured IP based access controls [1]. If the customer's network supports IPv6, the traffic would switch, and if they haven't added their IPv6 addresses to the policy ... boom everything breaks.
This is a tricky problem; providers don't have an easy way to correlate addresses or update policies pro-actively. And customers hate it when things suddenly break no matter how well you go about it.
Sometimes TCP/IP is a leaky abstraction, and recently ipv6 peeked through in two separate instances:
- In a cafe wifi, I had partial connectivity. For some reason my wifi interface had an ipv6 address but no ipv4 address. As a result, some sites worked just fine but github.com (which is, incredibly, ipv4-only) didn't
- I created a ipv6-only hetzner server (because it's 2026) but ended up giving up and bought a ipv6 address because lack of ipv4 access caused too many headaches. Docker didn't work with default settings (I had to switch to host networking) and package managers fail or just hang when there's no route to the host. All of which is hard to debug and gets in your way
It's only a matter of time before laptops get 5G. Macbooks have been rumoured for a while to get cellular modems. [1]
This will probably help adoption. On the one hand it will generate more IPv6 traffic. On the other hand it will expose more developers to IPv6; which will expose them to any lack of support for IPv6 within their own products.
I get an IPv6 address from my ISP (a /56 I believe), but I wish there was some good information on how to update my OpenWRT VLAN configuration, routing, and firewall rules to be able to support native IPv6 on my devices. Would love to be able to have direct IPv6 connections to the internet from my devices, but I want to make sure I can do it safely.
NB: this is not "IPv6 traffic crosses the 50% mark" but "availability of IPv6 connectivity among Google users", which is a very important difference. This means roughly half of Google users have IPv6 capability, which does not 1:1 correspond how much traffic is actually transferred over IPv6, which is what this submission says in the title.
It amuses me to see that according to the map, France is best in class or close to be, while just a few weeks ago, my ISP in France stopped providing me IPv6 connectivity…
The story is that at the beginning I had IPv6, and a shared dynamic IPv4 behind a CGNAT, I asked for a rollback to a full duplex static IPv4 and for three years I had both a static personal IPv4 and an IPv6. A few weeks ago my router went down and since it went back up, I no longer have an IPv6 address. I called my ISP and they explained that I could either have IPv6 or a static IPv4, but not both, and that it's abnormal that I had both for so long… welp, it's sad to see IPv6 but getting it back is not worth abandoning my static IPv4 and going back to a dynamic shared IPv4.
The question is, "what will the graph look like in the next 10 years?"
I get the whole s-curve trend but if I squint at 2017, there is an inflection to slow the s-curve down.
Annoyingly, when setting up service with a fiber company in the last couple months, I explicitly asked about IPv6 connectivity and they said, "yes." Turns out "yes, but not in my region."
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.
Meanwhile: one of the major mobile network in my country announced cisco collab/ipv6 ~5 years ago, but still doesn't provide v6, just v4 CGNAT.
Personal web server running dual stack since early 2010s currently sees 18-20% v6 traffic. When split by type, counting only mobile users it reaches 30% at peak.
Bot/crawler traffic is ironically 100% v4.
Meanwhile: enabled h3 in september last year for the fun of it, instantly at >40% traffic by request count, passing 50% since the beginning of the year, h2 accounting almost all the remaining traffic and plain ssl/http requests <1% being just bots.
I consistently get 100x as many captchas from google over V6 as over V4, on many different networks: it is obnoxious and obviously broken on their end.
Everyone's saying progress is slow, but maybe this is just how long it takes to do massive decentralized global migrations affecting billions of people. What are we comparing against? Maybe the ICE-to-EV transition?
Currently my IPS provides IPv6, but I set up my firewall in the access router of my home LAN to block all IPv6 in both directions.
- I don't want to have a permanent global unchanged ipv6 as in id of my traffic.
- IPv6 privacy extensions would change that but then I can not reach my two devices I do want to reach from outside anymore as my access router only supports DynDNS for its own address and no NAT in IPv6
One of the foremost obstacles to wide adoption is that IPv4 still works great and it's ubiquitous. There is no advantage or up-side to deprecating or abandoning IPv4 support at all. The only result of disabling IPv4 is a denial of service to a certain sector of customers or clients.
The only way this will change is by increasing pressure on the resource of IPv4 networks. It was a few years ago that AWS broke the news to me that I'd be paying for IPv4 addresses but IPv6 would remain free. If enough services are forced, financially, to abandon an IPv4 presence, then their clients would be likewise forced to adopt IPv6 in order to retain connectivity.
But with the ubiquity of CGNAT and other technologies, it seems unrealistic that IPv4 will become so rare that it becomes prohibitively expensive, or must be widely abandoned. So that availability of the legacy protocol will inhibit widespread adoption and transitions to IPv6.
I wish EU make it mandatory at least for all ISP to make mandatory support for IPv6 by end of this decade. I think that would push the needle even globally.
Setting up my own server (migrating off GCP LB) taught me so much about networking. I was especially surprised that providing IPv6 is such a performance boost for low bandwidth phones since they mostly only operate on IPv6 by now and IPv4 needs some sort of special roundtrip.
I am in the middle of building infrastructure in GCP. The workload is your typical stateless web + db workload.
As of now, there is no way to have a 100% internal ipv6. Many of the services, including CloudSQL or the connection between external and internal load balancers do not support ipv6, even when the external load balancer support ipv6 forwarding rules at the front end.
This means that careful internal ipv4 allocations still matter.
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.
My interest was piqued 20 years ago, then there was talk about Internet2 with all these amazing optimisations.
Things have developed so much, a Internet2 is still going on I take it, however is more focussed on university research.
As ever a killer strength is something that draws people to a new technology, I imagine there's various demographics that benefit from use of ipv6.
Further I imagine that there are some levels of criticality which when reached are more self sustaining (dare I say it the network effect?).
I've been posting this graph over the years, and it really has slowed down hugely close to this 50%. This is a global ipv6 support, so some countries are racing ahead, others weirdly like Denmark have a stash of ipv4 addresses and seems content.
France and Germany are at about 80%, but there's the rest of the world of course.
Random related data point: for HTTP requests to Wikipedia (and related) for the past 7d, the IP protocol split is roughly 35% IPv6 / 65% IPv4. (this is counting by-request, so heavy usage from a small number of IPv4s can skew it).
The failure wasn't in the technical design of v6, but in the economic assumption. When the cost of migration exceeds the cost of 'hacks' like NAT, people will stick to the hacks for as long as humanly possible.
I just recently noticed that my ISP, Frontier, quietly turned on IPv6. I know it wasn't enabled back in December, so it has to have been sometime in the past few months.
I am aware of at least 2 telecoms, one publicly traded, that have very little to no IPv6 in their core networks and only use IPv6 when they have to.
Personally I think the design of IPv6 offers very little benefit; supposedly the Dept of Defense/Dept of War holds some 175 million IPv4 addresses, with other companies also holding large allocations - that should have been addressed 25-30 years ago as an administrative matter.
A hidden benefit is it's no longer possible to have another "we typed the wrong IP address" raid story. IPv6 is larger than the total number of heartbeats of all heart-bearing life that has ever existed. You either nailed the abuse address or you're raiding something that doesn't even exist.
Some internet-drafts contain useful knowledge because they specify an existing protocol that never continued through the IETF process to reach the level of an informational standard. For example, TACACS+ is best specified in a dead internet-draft.
However, in most cases, internet-drafts are just that - drafts. They are usually requests for comment (ironically enough) on the author's idea. Someone had an idea and put it out there to see what other people think. Sometimes they don't even get to that stage but die immediately upon being uploaded as the author realizes they are silly.
15 years ago I would have dismissed this immediately as an elaborate troll but nowadays you cannot be sure anymore.
I'm suggesting moving on to IPvNN which requires device and ISP forced guarantees that the originator is not under the effect nor the lack of any medication or other substance, not being coerced and not using non-human assistants in content creation.
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.
while it looks like its slowing down, I am pretty sure it will speed up once IPv4 get even more expensive, sites start to be hosted on IPv6 only and become inaccessible to some users that dont have IPv4. Thats surely going to put pressure on ISPs
Outside of hobbyist niche uses, sites won't start being hosted IPv6-only. The financialization of IPv4 addresses will simply get worse and be even more pay-to-play than it is now. Amazon raises the price of IPv4 and everyone goes along as a cost of doing business.
My prediction is that sites will be half-IPv6 only; backends will be IPv6 and IPv4 traffic will get proxied to IPv6 by CDNs / edge LBs. I think CloudFront for example supports that scenario, avoiding IPv4 costs (in theory).
that may be true, but not being able to access hobbyist sites still feels like "being locked out" of something. My ISP provides /48 IPv6 addresses for free, and I already run a couple sites only on IPv6 - because an IPv4 would cost 20 bucks a month - it's not important enough to me personally to pay that.
As long as no significant websites are IPv6-only qnd no significant user base is IPv6-only, why would anyone join IPv6? What proponents could do is make their websites IPv6-only. The IETF website, for instance, should be IPv6-only.
Nice. But note that the average is still significantly below 50%. It's also a bit concerning that the growth rate seems to be levelling off. It currently looks like a sigmoid curve with a maximum far below 100%.
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
Interesting to see Spain having such low IPv6 adoption. Perhaps that's exacerbated the issues caused there by blocking IPs during football matches that we've seen mentioned in recent HN posts.
worth noting that the google stat measures ipv6 availability among users who access google, not general internet traffic -- so it's a bit of a self-selecting sample skewed toward consumer isps that have deployed ipv6, which probaly overstates adoption for enterprise and datacenter traffic where the github situation is much more representative of reality.
There really should have been proper government pressure and fines long ago.
Say if you have 10% of market share or x million monthly users you must support IPv6 in say 5 years. If not you are fined say 2% revenue per year until you do...
621 comments
https://github.com/orgs/community/discussions/10539
I think GitHub has just gotten so aggressive with their rate limit policies that it’s straight up incompatible with their own product. The charitable interpretation is that they aren’t keeping good track of how many requests each page actually performs in order to calibrate rate limiting.
>
And still, in the year of our lord 2026, GitHub does not support IPv6.Especially given that it is now owned by Microsoft, which has been working on IPv6-only (at least on their corporate network) for almost a decade:
* https://blog.apnic.net/2017/01/19/ipv6-only-at-microsoft/
* https://www.arin.net/blog/2019/04/03/microsoft-works-toward-...
Turns out we could not connect to Twilio's API which is IPv4 only.
An excellent reason to move away from Github, I find.
Maybe we shouldn't even measure percentage adoption and instead just if github has finally adopted..
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 validating over IPv6, so I made my web pages IPv4 only. Recently, I gave IPv6 a go again, and the cert issue has been fixed, so now my webpages finally have both IPv4 and IPv6 addresses.
You'll need to update your DNS server to include those as AAAA records.
Do providers like NextDNS or RethinkDNS allow these sorts of overrides?
If you're not an expert in this area it's worth a read - I certainly learned a few things!
Try going IPv6-only by disabling IPv4 on your computer as a test and notice that almost nothing works except Google. End users shouldn't need to set up NAT64/6to4 tunneling. It should be ISPs doing that to prepare for the transition.
Also, notice how Android and iOS don't support turning off IPv4.
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-Friday is down in the 45% range before the next Saturday jumps up to 50% again. (Fridays usually have a small rise, up to the 46-47% area).
My theory: mobile access rises on weekends. People are more often accessing Google services from their work computers Monday-Friday, but on Saturdays and Sundays most (not all) people are away from the office. Many of them will end up using smartphones rather than laptops for Internet access, for various reasons such as being outdoors. And since smartphones are nearly all using IPv6 these days, that means an uptick in IPv6 usage over the weekends.
This is a tricky problem; providers don't have an easy way to correlate addresses or update policies pro-actively. And customers hate it when things suddenly break no matter how well you go about it.
[1] https://docs.github.com/en/enterprise-cloud@latest/organizat...
- In a cafe wifi, I had partial connectivity. For some reason my wifi interface had an ipv6 address but no ipv4 address. As a result, some sites worked just fine but github.com (which is, incredibly, ipv4-only) didn't
- I created a ipv6-only hetzner server (because it's 2026) but ended up giving up and bought a ipv6 address because lack of ipv4 access caused too many headaches. Docker didn't work with default settings (I had to switch to host networking) and package managers fail or just hang when there's no route to the host. All of which is hard to debug and gets in your way
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.
This will probably help adoption. On the one hand it will generate more IPv6 traffic. On the other hand it will expose more developers to IPv6; which will expose them to any lack of support for IPv6 within their own products.
[1]: https://9to5mac.com/2025/08/14/apples-first-mac-with-5g-cell...
The story is that at the beginning I had IPv6, and a shared dynamic IPv4 behind a CGNAT, I asked for a rollback to a full duplex static IPv4 and for three years I had both a static personal IPv4 and an IPv6. A few weeks ago my router went down and since it went back up, I no longer have an IPv6 address. I called my ISP and they explained that I could either have IPv6 or a static IPv4, but not both, and that it's abnormal that I had both for so long… welp, it's sad to see IPv6 but getting it back is not worth abandoning my static IPv4 and going back to a dynamic shared IPv4.
Does anybody know why that might be the case? What's the story of IPv6 deployment in France?
I get the whole s-curve trend but if I squint at 2017, there is an inflection to slow the s-curve down.
Annoyingly, when setting up service with a fiber company in the last couple months, I explicitly asked about IPv6 connectivity and they said, "yes." Turns out "yes, but not in my region."
amazon.com needs to get with the program. Still IPv4 only.
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.
> IPv6 traffic crosses the 50% mark
Graph description:
> The graph shows the percentage of users that access Google over IPv6
There are reasons to expect both much more and much less traffic per user on IPv6 compared to IPv4...
Personal web server running dual stack since early 2010s currently sees 18-20% v6 traffic. When split by type, counting only mobile users it reaches 30% at peak.
Bot/crawler traffic is ironically 100% v4.
Meanwhile: enabled h3 in september last year for the fun of it, instantly at >40% traffic by request count, passing 50% since the beginning of the year, h2 accounting almost all the remaining traffic and plain ssl/http requests <1% being just bots.
- I don't want to have a permanent global unchanged ipv6 as in id of my traffic.
- IPv6 privacy extensions would change that but then I can not reach my two devices I do want to reach from outside anymore as my access router only supports DynDNS for its own address and no NAT in IPv6
The only way this will change is by increasing pressure on the resource of IPv4 networks. It was a few years ago that AWS broke the news to me that I'd be paying for IPv4 addresses but IPv6 would remain free. If enough services are forced, financially, to abandon an IPv4 presence, then their clients would be likewise forced to adopt IPv6 in order to retain connectivity.
But with the ubiquity of CGNAT and other technologies, it seems unrealistic that IPv4 will become so rare that it becomes prohibitively expensive, or must be widely abandoned. So that availability of the legacy protocol will inhibit widespread adoption and transitions to IPv6.
As of now, there is no way to have a 100% internal ipv6. Many of the services, including CloudSQL or the connection between external and internal load balancers do not support ipv6, even when the external load balancer support ipv6 forwarding rules at the front end.
This means that careful internal ipv4 allocations still matter.
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.
That seems to be a promising approach.
Things have developed so much, a Internet2 is still going on I take it, however is more focussed on university research.
As ever a killer strength is something that draws people to a new technology, I imagine there's various demographics that benefit from use of ipv6.
Further I imagine that there are some levels of criticality which when reached are more self sustaining (dare I say it the network effect?).
I've been posting this graph over the years, and it really has slowed down hugely close to this 50%. This is a global ipv6 support, so some countries are racing ahead, others weirdly like Denmark have a stash of ipv4 addresses and seems content.
France and Germany are at about 80%, but there's the rest of the world of course.
Is it because they have more carrier NAT?
In Denmark I can get cheap 1 / 1 Gbit/s fiber, but still no ipv6 :(
0/10 in Latvia with a local ISP, fun times.
google published the latest data only yesterday, hence the delay.
Personally I think the design of IPv6 offers very little benefit; supposedly the Dept of Defense/Dept of War holds some 175 million IPv4 addresses, with other companies also holding large allocations - that should have been addressed 25-30 years ago as an administrative matter.
Does it mean we better put our chips on IPv8?
However, in most cases, internet-drafts are just that - drafts. They are usually requests for comment (ironically enough) on the author's idea. Someone had an idea and put it out there to see what other people think. Sometimes they don't even get to that stage but die immediately upon being uploaded as the author realizes they are silly.
I'm suggesting moving on to IPvNN which requires device and ISP forced guarantees that the originator is not under the effect nor the lack of any medication or other substance, not being coerced and not using non-human assistants in content creation.
I guess we both agree that both humor and sarcasm are difficult to convey on the internet and LLMs do not make the job any easier :-)
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.
https://clintonwhitehouse1.archives.gov/
https://clintonwhitehouse2.archives.gov/
But I wouldn't be surpised if we start seeing self-hosted minecraft or factorio servers with ipv6 only.
There might be a child behind the NAT, thus IPv6 requirement.
My company is ipv4 still, and some customers are having issues with ipv6 only connections.
Also we log the ip addresses, and that's only in ipv4.
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
Say if you have 10% of market share or x million monthly users you must support IPv6 in say 5 years. If not you are fined say 2% revenue per year until you do...