GitHub Community
IPv6 support for cloning Git repositories #10539
Replies: 236 comments 624 replies
|
I am unable to understand what in 2022 still holds full IPv6 support for a platform like GitHub. |
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 |
|
yes of course |
|
Yes that's true |
|
No. Nobody needs assistance in understanding how IPv6 works. Please stop this spam, as I already said in my comment two weeks ago: https://github.com/orgs/community/discussions/10539#discussioncomment-11684249 |
|
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. |
|
They'd need a NAT64 gateway to reach github not a tunnel as they already have native IPv6. |
|
what country is that? |
|
@divinity76 Brazil |
|
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. Is there any plan on the github's roadmap to fully adopt IPv6? |
|
Now it's 2026 and nothing yet. It's baffling. |
|
If GitHub can't get v6 on GitHub.com soon, maybe at least an ipv6.github.com proxy for SSH git cloning? |
|
IPv6 is the actual internet protocol, while IPv4 is a legacy protocol. Please, priorize this request. |
|
Seems like they instead prioritized AI features nobody wants 🫣 |
|
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 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. |
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 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. |
|
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. |
|
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. 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 ? 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. |
|
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 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 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: |
|
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? |
|
Biggest fail i ever saw. |
|
CC rust-lang/cargo#10711 this causes real issues for open source software users. This is an absurd conversation in 2022. |
|
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" |
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 |
|
Microsoft itself is far more ipv6-friendly or ipv6-forward than github. It's sad and there's no excuse. |
|
Outlook only has IPv4 A records. If MS never bought GitHub then we could have had IPv6 support already. |
True for outlook.com, Not true for the actual web frontends such as outlook.live.com and outlook.office.com. One difference for github.com is that it isn't only http/https, you also have SSH, all of these services, and rate limiting + abuse prevention + logging, needs to be fully IPv6 capable (all of this has been covered a couple of times over, and Stackoverflow has a great post on similar challenges that they have for anyone interested.) There is absolutely no excuse for this, but it's not just flipping a switch that many seems to think it is. |
|
After migrating my company (including our gitlab instance) and a university from IPv4-only to full dual-stack, I would say it's closer to flipping a switch than it is to...the epic project/struggle many of my former colleagues treated it as. Also, there are huge advantages to migrating to IPv6 as primary, as opposed to using IPv4-only...which lots of admins don't see because they've gotten so used to the problems of IPv4 that they treat them as the baseline/normal. |
|
How can you not have ipv6? Some cloud providers charge extra for ipv4! |
|
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. |
|
Same here |
|
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? |
|
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). |
|
How is GitHub classed as a global technology company if they can't even keep up with the current (30 year old) Internet Protocol standard? Realistically we needed IPv6 as the first global IP addressing, IPv4 was only made in the lab and never originally intended for global consumption. Unfortunately many companies take your irony seriously, and I will forever hate them for it. |
|
It is because people keep complaining about but have no balls to move their projects to another platform with IPv6 support because they have created a emotional dependency of Github or just because of lazyness. |
|
And besides, 4MM addresses ought to be enough for anybody! |
|
found out about it because no provisioning was possible for my ipv6 only hosts. Ask Copilot maybe? Or better Claude? |
Neither those work |
|
How should Copilot or Claude help you with IPv6 when Github does not support IPv6 at all? |
|
IPv6 reached 50% adoption worldwide and still no timeline from github. |
IPv6-mostly can be used with DNS64 and NAT64 to provide IPv4 to devices when the router only has IPv6 (with DNS64 and NAT64) from the ISP. Assuming the ISP actually configures everything properly then there would be no issues for customers access IPv4 or IPv6 resources. From the IPv4 perspective, translating to v6 and back acts like CGNAT anyway, so it is no worse for users. The management layer would be easier as IPv4 only needs to be dealt with at the very edges of their network.
For ISPs the benefit isn't as large as for datacentres, but there is still some benefit to simplifying traffic across the internal network to a single protocol (in the case of an IPv6-mostly network). |
Yes "mostly". Can only work if an ISP would intercept all DNS requests and direct them to their DNS64 (that breaks DNSSEC BTW). And also means won't work for anything that is not DNS based.
Except that it doesn't cover all usage scenarios. So ISPs can't switch to IPv6 only, they have to still keep CGNAT for either dual-stack or just IPv4 then.
It would be a huge benefit for ISPs it that would work. ISPs were first who struggled by limited IPv4 availability. They would be happy to switch to IPv6 only for their consumers if that work. But it does not work. |
Few here are asking the question sincerely. You’re asking rhetorically. I’ve provided a solid hypothesis, as have a few others. IPv6 isn’t easy. GitHub recognizes there are legitimate costs. They had attempted a migration 2 years ago, it caused an outage, and they put it on hold. They have a unique stateful service with SSH connections. Layers of proxies would be expensive for them. Moreover, they are migrating to Azure, and likely have deferred IPv6 support until that migration resolves. For some segments on the internet 75% have yet to migrate. And for good reason. |
CGNAT is quite expensive and has limits with regards to scaling. ISPs that rely on CGNAT gain significant breathing room when they deploy IPv6 alongside as it will reduce the load on their CGNAT infrastructure. Things that use a significant amount of traffic such as software updates and video streaming usually support IPv6 so bandwidth-wise moving to dual-stack will immediately show a big difference. |
2 years ago they added preparations to support IPv6 in enterprise filtering. They have not done any public actual switch of the main site, but they have moved some related hosting to IPv6 support. |
This comment was marked as off-topic.
This comment was marked as off-topic.
|
There is no reason to link AI generated slop here |
|
The date is wrong, it should be the first. |
|
Indeed, sorry |
Azure and Office really don't support IPv6? I mean office, maybe, although at least Regarding Reddit and Twitch -- do you really think a vital infrastructural tool for companies around the globe should adhere to the same standards as degenerate social media platforms? I mean the Twitch CEO is widely considered a voyeur with a cowboy hat... The Reddit CEO used to be a mod on the /r/jailbait subreddit. These are your idols? |
|
Microsoft 365 supports IPv6. You can observe it especially with MS Teams conference calls. |
|
"Except that it doesn't cover all usage scenarios. So ISPs can't switch to
IPv6 only, they have to still keep CGNAT for either dual-stack or just IPv4
then."
T-Mobile does it just fine with their home Internet, their entire network
is IPv6 only except for the edge, and behind the CPE.
The CPE has 464xlat so all IPv4 literal traffic, or traffic not handled by
the DNS64 can still work just fine.
…----------------------------------
Brandon Jackson
***@***.***
On Sat, Apr 18, 2026, 12:30 Mykola Dzham ***@***.***> wrote:
It doesn't work with IPv6 because IPv6 was not designed for smooth
transition. Why ISPs can't deploy IPv6 only networks today and gracefully
degrade on the edge when connect to IPv4 only resource? Why they have to
build dual-stack? And why would they build dual-stack then if IPv4 only
will also just work for them? Sure they have to run CGNAT these days,
however they have to run it anyway.
IPv6-mostly can be used with DNS64 and NAT64 to provide IPv4 to devices
when the router only has IPv6 (with DNS64 and NAT64) from the ISP. Assuming
the ISP actually configures everything properly then there would be no
issues for customers access IPv4 or IPv6 resources.
Yes "mostly". Can only work if an ISP would intercept all DNS requests and
direct them to their DNS64 (that breaks DNSSEC BTW). And also means won't
work for anything that is not DNS based.
So no smooth transition, no back compatibility, and no way for ISPs to
deploy IPv6 only.
From the IPv4 perspective, translating to v6 and back acts like CGNAT
anyway, so it is no worse for users. The management layer would be easier
as IPv4 only needs to be dealt with at the very edges of their network.
Except that it doesn't cover all usage scenarios. So ISPs can't switch to
IPv6 only, they have to still keep CGNAT for either dual-stack or just IPv4
then.
The migration is slow because it gives little benefits directly to those,
who migrated, until ideal future will come and IPv4 can be turned off
For ISPs the benefit isn't as large as for datacentres, but there is still
some benefit to simplifying traffic across the internal network to a single
protocol (in the case of an IPv6-mostly network).
It would be a huge benefit for ISPs it that would work. ISPs were first
who struggled by limited IPv4 availability. They would be happy to switch
to IPv6 only for their consumers if that work. But it does not work.
—
Reply to this email directly, view it on GitHub
<#10539?email_source=notifications&email_token=AEOYHG55WSOX4G3MVUGMNW34WOUSXA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNRWGEZTQMBWUZZGKYLTN5XKM3LBNZ2WC3FFMV3GK3TUVRTG633UMVZF6Y3MNFRWW#discussioncomment-16613806>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AEOYHG6WBYESN36UZ6XVMOT4WOUSXAVCNFSM5MYNB6L2U5DIOJSWCZC7NNSXTOSENFZWG5LTONUW63SDN5WW2ZLOOQ5TCNRWGEZTQMBW>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***
com>
|
Yes exactly: 464XLAT. And that only confirms that IPv6 was not designed for smooth transition: 464XLAT is not the part of the IPv6 specification and was introduced way after. |
|
Most ISPs today is doing CGNAT, doing NAT64 instead is no different. Windows will be doing native CLAT soon. 464XLAT is only needed for legacy devices. But if all service providers would have taken their responsibility, such as GitHub, then this wouldn't have been an issue. Also Google could do more, just like they have done with https and mobile friendly site, punish sites in the result that isn't up2snuf. |
And that is exactly the reason why original IPv6 adoption plan failed - it required "all service providers" to adopt it so it will start working for others. And until then this adoption is only additional work (and money) for these service providers, with no benefits for them. |
|
Github gotta be the largest website to not support IPv6, right? |
Interesting question. It's only rank 35 on https://whynoipv6.com/domain/github.com/ (based on Tranco) |
|
35 is their overall Tranco ranking. They're 8th on the list of sinners. |
|
Not before the dead bird site and every Microslop services domains. |
|
Yes, there are a lot of Microsoft entries on the first page. |
|
We have been calling for the adoption of IPv6 for years, yet have received no response. This is unacceptable in the times we live in. it holds back the progress and development of the Internet. Therefore, we are going to migrate to solutions that support IPv6; I suggest everyone switch to Codeberg or similar platforms. We can no longer wait. |
|
It is fascinating how hard Github seems to be trying to become the next SourceForge. |
|
By the way: Codeberg developed Forgejo for their platform, a fork of Gitea. Forgejo is also free software and be also be self hosted, if you need a private space. And it is possible to do a complete migration of existing Github repositories including all issues etc.. Also see https://github.com/arnowelzel/ - I did the switch nearly a year ago and did not regret it once. Only for Nextcloud I still need to use Github, since they can not just move to a self hosted platform with that many projects and users in their organization. |
|
This all is a excellent example of very bad technical management. People that were put in charge and have no clue about what they should be doing. |
|
there are also no confidential issues since apparently microslop is only focusing on the big enterprise corpos and expects everyone to have a dedicated security team with a dedicated email address. no care for the pragmatic needs of the majority of one person maintainers that keep FOSS going... |
|
how in the world in big 2026 there is no ipv6 support |
|
This starts to remind me of the infamous 11471 mysql bug ticket that was open for 20 years. Eventually people started writing poems and congratulating it for it's 18th birthday. We might need to do that as well soon. |
|
On 2013-03-15 15:38, Petros Amiridis (GitHub Staff) wrote:
That's 16 years. My initial request is old enough to drive in the United States. |
|
https://api.github.com/meta has some ipv6 addresses now |
|
FTR (might not be relevant), yesterday I had |
|
Packages, the importer ,actions_macos and codespaces seem to be the services that are v4 only. |
|
Every decent service provides IPv6 nowadays, the ones which doesn't are obsolete, deprecated. Period. It's a shame that in 2026 GitHub doesn't have IPv6 addresses on its servers, who can trust a service which are incapable of following a 20 years old standard. |
|
not Ziply |
|
Also, microsoft is moving forward with adding IPv6 on their mail servers. Many private o365 are already on it.One would see a pattern with github entreprise here.Next year, at FOSDEM, NAT64 will be disabled.
Github in it’s current state will break with a lot of FOSS projects there. Let’s observe what happens…
|
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
|
Yes, indeed, database |
and others
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Hi, I'm surprised I didn't find an existing discussion with this topic. Some services like github-releases.githubusercontent.com or user pages do support IPv6, however the webpage (github.com) itself, including cloning of git repositories, does not work.
Is there a public roadmap on enabling IPv6 for GitHubs very core business, distributing Git repositories? If I'm wrong and there is already IPv6 support, please guide me.
The same issues exists for api.github.com and thereby making CLIs unusable on IPv6 only connections.
EDIT: I left this topic on "Subscribe" to receive notifications if GitHub ever responds, after 3 years I lost hope and will unsubscribe now. I'm sure I'll get the news somewhere else - if IPv6 on Github it ever happens.
All reactions