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.

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😑

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.

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.

Biggest fail i ever saw.

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.

Same here

yeah, I think it's about 2years too slow at best ... don't expect GH IPv6 before 2030 at current rate ;(

'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/hosts works 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.

Some companies decided to support IPv6 in the early 2000s. Other waited a bit longer until around 2015 and some decided not to care at all and keep delaying because "we have plenty of IPv4 space, we don't need to learn IPv6".

Unfortunately, most company seems to think AI is the way to go. Probably because the shareholders think that it generates value.

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.

I suggest we get off and go to https://codeberg.org/

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

@kirtimaan-askin Maybe try a NAT64 gateway and DNS64?

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 😀

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.

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.

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!