IPv6 support for cloning Git repositories · community · Discussion #10539

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😑

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.

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.

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.

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.

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

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.

That doesn't help when a third-party repository you want to pull from is hosted on GitHub.

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

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 😀

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.

There are alternatives. Rust, Zig...

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!

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!

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?

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.

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.

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

why hasn't github migrated?

This is the same question all of us have in this discussion. Obviously their network and configuration is quite complex, but given the relative simplicity of dual-stack or IPv6-mostly, they should have easily been able to support IPv6 back in 2012 when Google did.

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.

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.

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.

why hasn't github migrated?

This is the same question all of us have in this discussion. Obviously their network and configuration is quite complex, but given the relative simplicity of dual-stack or IPv6-mostly, they should have easily been able to support IPv6 back in 2012 when Google did.

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.

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.

There is no reason to link AI generated slop here

The date is wrong, it should be the first.

"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.

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.
And in reality 464XLAT requires ISPs to use special CPEs that implement a part of it (which is not the end of the world, just confirms again that IPv6 was not designed for smooth transition).

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.

But if all service providers would have taken their responsibility, such as GitHub, then this wouldn't have been an issue.

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.
And let's be honest: if the adoption reached 50% only now, and doesn't show the tendency to speed up, the original adoption plan failed.