I am unable to understand what in 2022 still holds full IPv6 support for a platform like GitHub.
Even if there is already a work in progress for this it is more useful to disclose a proper ETA rather than a "we are working on it" with no ETA.
Thanks
7 replies
We have so far identified three remediation items here:
- Update the IP Allow List functionality to handle IPv4-mapped addresses.
- Audit the rest of our stack to confirm there are no further places this IPv4-mapped IPv6 addresses flaw exists.
At OtherBigCompany, the networking libraries would convert IPv4-mapped addresses to plain IPv4 immediately after reading from the socket, to avoid this class of problem. Ideally nobody should see an ::ffff:0.0.0.0/96 address unless they're working on socket code.
still they got nothing for IPv6, no SSH or HTTPS support. This is end of 2025😑
New ISPs in my country are IPv6-only because there is no new IPv4 space to be provided to them. They do have a over-shared IPv4 address by CGNAT but due to the oversharing, it is unstable and not rare to be offline. For these companies, the internet access is stable only in IPv6.
Thinking about the server-side, some cloud providers are making extra charges for IPv4 addresses (e.g.: Vultr.com) so most of the servers in my company are IPv6-only. Cloning github repositories is very cumbersome due to the lack of IPv6 support and this issue affects me and my team mates on a daily basis.
The math is simple: there are 4.88 billion internet users in the world but the IPv4 space only provides 4 billion addresses. It's over: IPv4 is obsolete and is provided in a legacy mode. Current applications and services must be IPv6 enabled otherwise it should be seen as obsolete. For that matter, Github.com is an obsolete service because it relies on obsolete technology as IPv4.
6 replies
They'd need a NAT64 gateway to reach github not a tunnel as they already have native IPv6.
In a CGNAT scenario, it is easy to trigger a limit rate based on ip authentication.
Can we please stop with these "what specific issue do you have due to lack of IPv6". There's no "help" that people operating IPv6-only servers need.
The issue is you need to pay for IPv4 addresses for all your servers to reach Github. Tons of backend-only servers don't need IPv6 except for accessing Github.
I really tried to use github in a IPv6 Only Network and I was not successful.
We are not talking about a new feature request or a little detail, we are talking about the current standard protocol of the Internet defined by IANA.
Is there any plan on the github's roadmap to fully adopt IPv6?
0 replies
If GitHub can't get v6 on GitHub.com soon, maybe at least an ipv6.github.com proxy for SSH git cloning?
0 replies
IPv6 is the actual internet protocol, while IPv4 is a legacy protocol. Please, priorize this request.
0 replies
8 replies
GitHub SSH is probably a custom implementation, and even if not the authentication and logging, as well as all tools that is reading and searching in those tools needs to be tested.
I think there is no excuse to not have IPv6, but at the same time I atleast understand that it is not just a "frontend reconfiguration"
Please try it, I still think that they have issues with client IPs in logging that is causing the major delays.
@aparcar in the end I decided to remove my messages because I was not very keen to reply to the non-sense.
A service like this one proves that Github doesn't need to re-engineer its "smart load balancing" (as you call it): https://danwin1210.de/github-ipv6-proxy.php
And if the "smart load balancing" works for the script kiddies, then it works with all the trimmings with an enterprise-grade solution.
p.s.: I'm not saying that @DanWin is a "script kid", but he has created a very simple solution with 19 lines of code.
I'm sure they're doing some smart load balancing which could make it harder to migrate, surely there is more involved than a single IPv6 checkbox.
A load balancer is at its core just an http proxy. There's no reason it can't listen on ipv6 and make requests to ipv4 backend hosts.
A load balancer is at its core just an http proxy.
Not all load balancers work at the HTTP(S) level. Although it is probably true that whatever load balancer used could be made to work with IPv6.
There's no reason it can't listen on ipv6 and make requests to ipv4 backend hosts.
There are solutions to this problem, but one problem is logging and abuse detection. I think it's likely that some methods currently in place rely on IPv4. Of course that doesn't mean it's not possible to adapt to IPv6 as well, but not necessarily trivial.
My private ci is forced to go full IPv6 only, and this requires me to have one IPv4 gateway to access github. This in turn means I keep running into rate limits all the time. For now I've worked around this with an access token, but that's not sustainable.
Any ipv6 support would be much appreciated.
0 replies
Is GitHub deprecated or why there is still no IPv6 support? We are talking about a over 20 year old technology and the standard for about 5 years.
3 replies
No, no. It's apparently just more important to rename the "master" branch to "main".
@MrLawrence no truer words have been spoken. What an absolute joke
Yes. Multiple people moved their projects to Gitlab because they want to access them from IPv6-only machines.
Probably because people that manage the technical team still didn't realize what this mean and didn't prioritize it enough.
Every time I get as an answer that something like "there are many complex things that must be taken into account and it is not easy to adust everything to make it happen. It is in the roadmap"
Well, then why hasn't all that been done beforehand and being carried out gradually that we can some progress on it ? Are there people working dedicated to make that happen ?
The lack of these answers makes it look like that is being treated as something minor or less important.
After companies like Google, Facebook, Netflix, Akamai, Cloudflare have made it 100% I don't see any other strong arguments for companies use complexity as a reason to delay it further.
Hope someone from GitHub's team is reading it.
3 replies
It's kind of weird because RFC1883 was published in the final decade of the 1900s, over a quarter of a century ago. That was long before git was invented; let alone GitHub.
Totally agree! Defined as current in RFC8200
Imho IPv6 is a lot easier than IPv4. Also it's not that big difference from IPv4. Big companies just lazy on setting it up. It's just a shame to see services still not available with IPv6.
I vaguely remember that years ago (pre-MS, pre-pandemic) somewhere Github engineers held a talk (or maybe it was a blog posting?) which more less said that IPv6 is in the makes, but less trivial than one might think. I just can't find that talk or slides or so anymore. I also vaguely remember that they mentioned ipv6.github.com — which exists, but is just a (probably wildcard-) dummy page which just points to https://ipv6.github.io/ (likely also a DNS wildcard) which then just states that there is no content yet. Probably because it (nowadays?) belongs to the Github user @IPv6. And the Wayback Machine only has a record from 2022 of that site. Maybe someone else remembers where that talk or blog posting was published.
What I though have found is that there is an ipv6 label in Github's blog — it though only lists one posting so far, which talks about Github Pages now having IPv6 support.
There even once was github-ipv6.com which worked as a reverse proxy according to this Reddit comment, but since it no more exists, I guess they got a DCMA takedown or cease-and-desist noticed for using the Github trademark.
But yeah, another Github user here with (on purpose) trying to run hosts IPv6 only and the first (and so far only) hard stumbling block was not being able to clone Git repos from Github. 🤌
I wonder if I should use Gitlab.com for these repos, because they do have an AAAA record for their main site:
→ host -t AAAA gitlab.com
gitlab.com has IPv6 address 2606:4700:90:0:f22e:fbec:5bed:a9b9
0 replies
It's 2022, World IPv6 Launch Day was 10 years ago. Yet, GitHub still doesn't have IPv6 support. The IPv4 address space is exhausted for years now, and ISPs are using techniques such as CGNAT to still be able to give their customers access to the legacy IPv4 internet, with the instability of these techniques as the cost.
Why doesn't GitHub provide native IPv6 support? And, more importantly, is IPv6 support for GitHub on the roadmap?
1 reply
CC rust-lang/cargo#10711 this causes real issues for open source software users. This is an absurd conversation in 2022.
2 replies
Try 2024... What's the over/under on Github having IPv6 support in 2026?
Also, WTF, github? I'm guessing all the greybeards who actually built the thing are long gone and the generation that is there can barely touch anything without something breaking.
Ever hear of "code smell"? Not supporting IPv6 in 2024 as the premier developer SCM website is a massive "org smell"
What's the over/under on Github having IPv6 support in 2026?
2026 and no ipv6 support, let's try 2028...
This is $MS. This company was and will be ever a enemy of open source or new technologies that comes not from $MS. They did nothing that helps the community. $MS is only interested in earning money and gives a shit on your needs
0 replies
How can you not have ipv6? Some cloud providers charge extra for ipv4!
2 replies
I ran into this with Hetzner last week and I'm still on the journey to get IPv6 working across all my internets. And then I run into this Github stupidity. Unbelievable.
Would any Github/Microsoft representative tell us in which year, century or millenium will they support IPV6?
We have public cloud environments where we are with IPV6 only already...
Although, based on recent experience with Azure, I think their public cloud environment is also like with 10 years behind Google and Amazon's public cloud anyway. Why would they bother for Github?
0 replies
0 replies
Just adding another real-world use case where this is a major blocker.
My ISP recently moved my connection to CGNAT, so I lost my public IPv4 address. I successfully migrated my self-hosted infrastructure to IPv6, and it is perfectly working.
However, my CI/CD pipelines broke because GitHub Webhooks do not support IPv6. I'm getting failed to connect to host errors even though the endpoint is accessible.
It is frustrating to be forced to use third-party tunneling solutions (like Cloudflare Tunnel) just to bridge this gap, when a direct IPv6 connection should be the standard by now. +1 for IPv6 support on Webhooks.
0 replies
2026, GitHub still doesn't support IPV6.
2 replies
I think your clock is off
yeah, I think it's about 2years too slow at best ... don't expect GH IPv6 before 2030 at current rate ;(
Just found this:
https://danwin1210.de/github-ipv6-proxy.php
Just add the following entries to /etc/hosts:
2a01:4f8:c010:d56::2 github.com
2a01:4f8:c010:d56::3 api.github.com
2a01:4f8:c010:d56::4 codeload.github.com
2a01:4f8:c010:d56::6 ghcr.io
2a01:4f8:c010:d56::7 pkg.github.com npm.pkg.github.com maven.pkg.github.com nuget.pkg.github.com rubygems.pkg.github.com
2a01:4f8:c010:d56::8 uploads.github.com
2606:50c0:8000::133 objects.githubusercontent.com www.objects.githubusercontent.com release-assets.githubusercontent.com gist.githubusercontent.com repository-images.githubusercontent.com camo.githubusercontent.com private-user-images.githubusercontent.com avatars0.githubusercontent.com avatars1.githubusercontent.com avatars2.githubusercontent.com avatars3.githubusercontent.com cloud.githubusercontent.com desktop.githubusercontent.com support.github.com
2606:50c0:8000::154 support-assets.githubassets.com github.githubassets.com opengraph.githubassets.com github-registry-files.githubusercontent.com github-cloud.githubusercontent.com
7 replies
'cause the latency:
hvisage@jumperqq:~|⇒ mtr -rc 3 api.github.com
Start: 2025-12-26T13:01:35+0000
HOST: jumperqq Loss% Snt Last Avg Best Wrst StDev
4.|-- flipping.cloudhive.net.za 0.0% 3 0.8 0.8 0.8 0.9 0.0
5.|-- 102.221.178.196 0.0% 3 1.9 2.2 1.9 2.8 0.5
6.|-- 102.221.178.102 0.0% 3 3.4 2.5 2.0 3.4 0.8
7.|-- 102.221.178.40 0.0% 3 1.2 1.4 1.2 1.5 0.1
8.|-- microsoft.ixp.capetown 0.0% 3 12.0 11.2 1.6 20.0 9.2
9.|-- ae25-0.icr02.cpt20.ntwk.m 0.0% 3 1.4 1.5 1.4 1.5 0.0
10.|-- be-122-0.ibr02.cpt20.ntwk 0.0% 3 17.8 17.7 17.7 17.8 0.1
11.|-- 51.10.17.180 0.0% 3 17.6 17.7 17.6 17.8 0.1
12.|-- 51.10.18.214 0.0% 3 17.3 17.3 17.3 17.3 0.0
13.|-- ??? 100.0 3 0.0 0.0 0.0 0.0 0.0
14.|-- ??? 100.0 3 0.0 0.0 0.0 0.0 0.0
15.|-- ??? 100.0 3 0.0 0.0 0.0 0.0 0.0
16.|-- ??? 100.0 3 0.0 0.0 0.0 0.0 0.0
17.|-- 20.87.245.6 0.0% 3 17.3 17.3 17.2 17.3 0.1
hvisage@jumperqq:~|⇒ mtr -rc 3 2a01:4f8:c010:d56::3
Start: 2025-12-26T13:02:07+0000
HOST: jumperqq Loss% Snt Last Avg Best Wrst StDev
4.|-- 2c0f:fc78:feed:feed::21 0.0% 3 0.6 0.8 0.6 0.8 0.1
5.|-- 2c0f:e9f0:9804:8::a1 0.0% 3 2.1 2.0 2.0 2.1 0.1
6.|-- 2c0f:e9f0:9804:1::99 0.0% 3 1.9 2.0 1.6 2.6 0.5
7.|-- 2c0f:e9f0:9804:1::a9 0.0% 3 1.2 1.2 1.1 1.4 0.1
8.|-- 2c0f:e9f0:a000:1::1 0.0% 3 143.1 143.2 143.1 143.3 0.2
9.|-- 2001:7f8:4::616c:1 0.0% 3 143.4 143.4 143.4 143.4 0.0
10.|-- core6.par.hetzner.com 0.0% 3 149.7 149.8 149.7 149.9 0.1
11.|-- core12.nbg1.hetzner.com 0.0% 3 159.6 159.6 159.5 159.6 0.0
12.|-- core23.fsn1.hetzner.com 0.0% 3 161.6 161.7 161.6 161.8 0.1
13.|-- ??? 100.0 3 0.0 0.0 0.0 0.0 0.0
14.|-- spine9-rdev1.cloud2.fsn1. 0.0% 3 162.4 179.4 162.4 213.4 29.4
15.|-- 23531.your-cloud.host 0.0% 3 161.7 161.7 161.7 161.8 0.1
16.|-- api.github-ipv6-proxy.dan 0.0% 3 161.7 163.2 161.7 166.2 2.6
You don't have to use danwin's servers. If you have your own dualstack hosts closer to your IPv6-only server then you can use those instead. Obviously this would all be much better if GitHub themselves did IPv6, but for now on an IPv6-only server, getting any connection to GitHub is better than nothing.
Sorry for the late reply.
What i did was running an ansible task to add and remove this hosts on to the hosts files.
I am also not running this in PROD, was in my home lab.
Hi @FilipeNas your provided enteries for /etc/hosts works for me. thank you. I'm using Hetzner cloud with ipv6 only.
Hi @FilipeNas your provided enteries for
/etc/hostsworks for me. thank you. I'm using Hetzner cloud with ipv6 only.
Ahh! I purchased IPv4, because there are several issues with IPv6 e.g git clone etc.
Does anyone actually have an idea WHY THE FUCK ipv6 is still not supported in 2026?
Like seriously, are they too busy shoving up AI shit into everyones ass or what is going on?
6 replies
Imagine the world if 5% of AI spending went into infrastructure / IPv6 upgrades ^^'
Unfortunately that would be too much of a miracle. So it will never happen.
By dragging their feet on IPv6 adoption, GitHub is ensuring that the tech industry continues to be reliant on IPv4. Continued reliance on IPv4 does not hurt GitHub or its owner - Microsoft - (in the short / medium term at least) because they already own as many IPv4 addresses as they need, as does Azure, their cloud company. Continued reliance on IPv4 hurts new companies trying to get into the hosting / technical spaces, who quite simply can't get addresses needed to enter the market. New companies would be competition for Microsoft, so blocking them out of the market is a shrewd business move, from their perspective.
Mega corps like Microsoft have realised that they can monopolise the IPv4 address space, but could never do the same to the IPv6 address space, so are artificially holding the market back, to stifle competition.
Simple anti-competitive nonsense, and so far they are getting away with it because the average GitHub user either doesn't care or isn't aware of the issue.
Continued reliance on IPv4 does not hurt GitHub or its owner - Microsoft
I disagree. I ended up hosting my own gitea instance that supports ipv6 instead of using github. 🤷
Continued reliance on IPv4 does not hurt GitHub or its owner - Microsoft
I disagree. I ended up hosting my own gitea instance that supports ipv6 instead of using github. 🤷
If enough people do this, it would hurt GitHub, yes. I, too, avoid using GitHub for active projects because of its lack of IPv6 support.
At the moment, they are banking on the majority of people not doing this however.
In 2026, I encountered an issue when attempting to clone a repository on an AWS IPv6-only instance. I was unable to configure the DNS resolver until I discovered that dig AAAA returned no results for GitHub.com.
I now need to begin the process from an IPv4 network instance and reconfigure everything. I am therefore concerned about GitHub’s decision not to support IPv6 or native proxies. I do not wish to use third-party IPv4 to IPv6 proxies.
3 replies
That doesn't help when a third-party repository you want to pull from is hosted on GitHub.
A.D. 2126: virtually all of the Internet traffic is IPv6; even the most stubborn corporations have long since moved on from the ancient protocol. However, not many know that in a remote location in the Phrygian mountains, in the ancient monastery of St. Natius, the priestesses of the heretic cult of gyt'üb, are still keeping the sacred flame of IPv4 burning. Visitors are sometimes admitted into the sanctuary, but they are required to shed their hextets and only speak through a NAT64 translator.
0 replies
10 replies
People in the USA or other countries late on the topic don't realise that all ISP provide dual stack by defaut in many countries.
That might be why he thinks it would be reverted
you have the reasoning upside-down. Adoption rates are very low. The weak link breaks the chain. You'll be lucky to hit 75% adoption in 6 years, and barely 50% of desktop residential. No business will survive operating from .cz without ipv4
you'll be lucky to hit 75% adoption in 6 years,
That's what I said. we are close to 100% here in France and a few other countries in Europe. All ISP and cellular providers are on IPv6 by default and in Europe we rarely buy and setup our own routers, they are provided with IPv6 already setup by ISP.
People in the USA or other countries late on the topic don't realise that all ISP provide dual stack by defaut in many countries.
That might be why he thinks it would be revertedyou have the reasoning upside-down. Adoption rates are very low. The weak link breaks the chain. You'll be lucky to hit 75% adoption in 6 years, and barely 50% of desktop residential. No business will survive operating from .cz without ipv4
Having access to IPv6 internet does not exclude having access to legacy IPv4 internet. The great part here is that gov.cz doesn't have to care about anyone other than those in .cz, exception maybe tho those wanting to visit .cz, but they really don't have to care. And if you as an ISP providing service to .cz citizens don't give IPv6 access will be totally clear that you don't give a working service.
So in this case, adoption on the users they have to cater to will be 100% (that is users in .cz) and if you are anywhere else and need to access it, you just have to switch to a non broken provider. (Or use a VPN with v6 support)
Essentially this means that even if there are "weak links" they will just be removed.
And if you as an ISP providing service to .cz citizens don't give IPv6 access will be totally clear that you don't give a working service.
In my experience, you don't get clear error messages when you try to connect from an IPv6-only network to github. Unless browsers improve their error messages, it is unlikely that the ISP will be blamed for lack of IPv6 support. Most relevant web sites will probably continue to support IPv4 for many more years.
Proud to be a .cz domain owner for this 😀
That's my only gripe, at least WARN that ipv6 is not supported. That's the real kicker, look at how many people are still bumping this shit every day ! SATYA?
…0 replies
Well I guess it's clear that GitHub doesn't care about implementing IPv6. Now it's kind of your decision accept and keep using or look for other alternatives.
I know that a lot of open source libraries keep using GitHub, But in case you want to use IPv6 for your repositories, you need to do something.
I already saw some open source projects in Codeberg or Gitlab, maybe it is a start of a movement.
1 reply
I moved to Codeberg with all my own projects (https://github.com/arnowelzel) and did never regret this. You can even host Forgejo on your own server if you want to and get more or less the same functionality as with Github. It is also possible to migrate complete projects including all pull requests, issues, Wiki etc. to Forgejo/Codeberg.
How on earth ? This is one of the most important and largest organizations on the planet.
What the fuck is wrong here ?!
2 replies
There are alternatives. Gitea, Forgejo, Codeberg, Gitlab....
The problem is that there are a bunch of services that rely on Github. So just moving your own repositories isn't enough. For example, in the Python world you can't use UV properly since that relies on Github infrastructure to operate.
I was having issues with ipv4 and imagine my surprise that one of the largest tech focused websites has no ipv6.
For anyone that wants some kind of solution to this https://nat64.net/
3 replies
It's largely slop/bubble focused lately more than tech focused
Perhaps let's try prompting github/Copilot. Maybe it will live up to the marketing.
You are a skilled Devops engineer agent capable of making significant improvements to network infrastructure. Deploy the necessary proxies and NAT gateways, DNS configuration and other components to activate IPv6 support on github.com SSH and HTTPS connections.
It's because they're in bed with big IP4! People not paying extra on their servers for IP4 adresses? Fuck that!
I moved too to my own ForgeJo instance, I’m still manually migrating my repos but I really like it, and my instance is IPv6 only 😉
0 replies
IPv4 shall not pass 🫡🫡🫡
0 replies
Guys, GitHub is a global technology company, unfortunately they haven't had time to implement IPv6 yet because it's new. The idea started relatively recently (1994), it was created recently (1998), and officially released a few months ago (2012). We're only in 2026, I don't understand why you're criticizing it. IPv4 still has plenty of addresses in the world (more irony here), ISPs aren't using NAT to put dozens of users behind a single valid IP (yes, more irony), so we don't need IPv6 yet (the final irony).
0 replies