IPv6 support for cloning Git repositories

[aparcar]

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.

[ffrediani]

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

[ghishadow]

https://www.githubstatus.com/incidents/5y8b8lsqbbyq

This incident was the result of an infrastructure change that was made to our load balancers to prepare us for IPv6 enablement of GitHub.com. This change was deployed to a subset of our global edge sites.

looks like they are preparing for IPV6

[pmarks-net]

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.

[Rifahad]

yes of course

[davidmi4268]

Yes that's true

[ayubio]

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.

[Citrullin]

That's exactly what I keep telling people. There are companies in developing countries that will not be able to afford the high markup price on IPv4 addresses. It's a shame how little this industry actually cares about progress and standards. Makes me furious sometimes.
Hope you found at least some tunnel or something similar in order to make it more stable for you.
Can't really expect the junior or intern to be able to set up a tunnel though.

[treysis]

They'd need a NAT64 gateway to reach github not a tunnel as they already have native IPv6.

[divinity76]

what country is that?

[Malix-Labs]

@divinity76 Brazil

[14KBZFxd]

In a CGNAT scenario, it is easy to trigger a limit rate based on ip authentication.

[DanielDamito]

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?

[NiKiZe]

If GitHub can't get v6 on GitHub.com soon, maybe at least an ipv6.github.com proxy for SSH git cloning?

[andrediashexa]

IPv6 is the actual internet protocol, while IPv4 is a legacy protocol. Please, priorize this request.

[maxadamo]

[NiKiZe]

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"

[NiKiZe]

Please try it, I still think that they have issues with client IPs in logging that is causing the major delays.

[maxadamo]

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

[bjmgeek]

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.

[michaelmior]

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.

[angerman]

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.

[BroOtti]

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.

[MrLawrence]

No, no. It's apparently just more important to rename the "master" branch to "main".

[9mm]

@MrLawrence no truer words have been spoken. What an absolute joke

[ffrediani]

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.

[dwmw2]

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.

[NiKiZe]

Totally agree! Defined as current in RFC8200

[BroOtti]

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.

[xtaran]

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

[MeesJ]

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?

[danielehrhardt]

Biggest fail i ever saw.

[TheBlueMatt]

CC rust-lang/cargo#10711 this causes real issues for open source software users. This is an absurd conversation in 2022.

[pmarreck]

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"

[lalelunet]

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

[sushlala]

How can you not have ipv6? Some cloud providers charge extra for ipv4!

[pmarreck]

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.

[TeaDrinkingProgrammer]

Same here

[madalinignisca]

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?

[ffrediani]

Oen problem is the people in general complain but don't have the guts to move their work out of Github. While many may still consider IPv6 important and this delay from Github unacceptable, at the end they just want to get their work done and don't want to have the work to move things elsewhere.

[Leseratte10]

My work, as in, my private repos, is already moved off of Github and onto a private Gitlab instance. Lack of IPv6 wasn't the main reason (main reason was that I didn't want to pay for CI minutes), but it was one reason. My public work that I want others to see is still on my public Github. But neither of these really is the issue.

The issue is that everyone else has all their code on Github, so if your code has dependencies to 10 other Github repos that need to be pulled to deploy your code, good luck moving that to Gitlab to be able to pull from an IPv6-only machine ...

[ffrediani]

Well, as mentioned you have to have guts to stick to things that you believe, otherwise it is just a discourse. If you believe in something and that is the right thing to do you find a way regardless how much effort that is. At the end example is important.

[Leseratte10]

IPv6 isn't a religion, it's an internet protocol. Just because a company is stuck in the past and refuses to adopt IPv6, yes, then I can build workarounds like a NAT64, a tunnel, a proxy or whatever to still access it over IPv6, that's true.

But it doesn't mean that I'm not allowed to complain about it, or that Github is right for still not supporting IPv6.

I'm not setting an "example" for IPv6 support by making my software's development way more difficult by not using dependencies from Github. I'm setting an example by making sure MY software is hosted on an IPv6-capable host and that MY software and services fully support IPv6.

[alsutton]

At this point I doubt many, if any, engineers from GitHub are following this issue.

The point that some people want IPv6 support has been made, an extra "I want it too", or restating previously expressed viewpoints, is unlikely to change their plans.

At this point most of the posts are just adding to the noise for those folk who are subscribed to this issue to get updates on the progress, whenever that might be.

[tonymet]

But it doesn't mean that I'm not allowed to complain about it, or that Github is right for still not supporting IPv6.

Permissible yes, but not edifying

[acceleratesage]

Just wanting to bring this to your attention @github, as there is a need for it. An update regarding your plans on this would be appreciated.

[marcmengel]

You perhaps didn't realize this, but the "@" + "github" string above spams all of us GitHub users, not the owners / admins of GitHub, as I suspect you intended... I know I didn't know that, until just now...

[ArcticLampyrid]

@marcmengel Are you a member of the organization @github ? If I'm not mistaken, it should notify all members within the organization, not all GitHub users.

[marcmengel]

I am not now, nor have I ever been, in an organization named "github".|
( see: https://github.com/orgs/github/people?query=marcmengel )
I'm just a user with a few dozen repositories.
Or I may just be getting these notifications 'cause I've commented on this ticket before, and I'm totally confused about the other; So nevermind, and apologies for the spam. I blame insufficient caffeine.

[RokeJulianLockhart]

Or I may just be getting these notifications 'cause I've commented on this ticket before, and I'm totally confused about the other; So nevermind, and apologies for the spam.

@marcmengel, commenting does indeed subscribe you.

[metaverseguy]

Is there a public roadmap or update from GitHub regarding the implementation of IPv6 support for their core services, including git repository cloning and the GitHub API, as currently only some services like github-releases.githubusercontent.com support it?

[danielmotaleite]

gitlab have ipv6, btw!

[josteink]

I can't use Github from IPv6 only hosts. That's quite unexpected for a platform from a mature provider like Microsoft.

Please, pretty please... Can we have IPv6 support? 😄

[cloph]

As a workaround, you can use https://nat64.net/ – depending on whether you're willing to use a custom DNS server or set up DNS64(or use google's DNS64) & your own Nat64 gateway (if you're using it on larger scale)...

[dragetd]

I just found this out myself why a IPv6 only access did not work. Granted, it is not an issue for me to use IPv4 in this case, yet it really is rather silly that IPv6 is not yet supported. =/

[tonymet]

the upside is increased ipv6 awareness

[MyZeD]

https://github.blog/news-insights/company-news/github-microsoft/

As for me, I’ll be taking on a new role at Microsoft working closely with Nat and the team, and will share more details on that in the future.

They love NAT (Network Address Translation) 🤣

[ffrediani]

As mentioned earlier, this issue with Github looks like more a bad technical management issue.
The people in carge to make such decisions are in another world concerning about other stuff or at least bad managing what need to be done for improvements. May be that the highest person in charge doesn't have much clue what IPv6 means and doesn't even consider it to be organized to be deployed and things are left that way.
The point is that there is always someone above that person or that team for when finding out take that into account for taking actions.

When a team, of any project, disregard IPv6 in such way it sends a very clear message about the team capacity to deal with other stuff even unrelated to IPv6. Shows they have limits in their technical capacity to identify things and take the necessary actions.

[tonymet]

making a judgement like this without knowing the cost/benefit for github is naive.

[ffrediani]

Whoever considers IPv6 deployment a cost in end 2024 for such products or services show a lot about their way of thinkin about the subject.

[tonymet]

run a business and write checks

[ffrediani]

Much larger and complex companies like Google, Facebook, Netflix, Akamai, Cloudflare, etc did their job, organized their team, proportionally to their complexity and made it happen and didn't hide behind the "cost" excuse. When management doesn't understand it well it will always be a prohibitive cost.

[tonymet]

every company is different and has different priorities. Anyway, how do you think this approach will help github make the change?

There are a few ways you can help. Help github understand how it impacts their paying customers. Help them complete the migration.

Shaming github won't make them move faster.

[JuniperChris929]

Not deploying IPv6 only in 2024 thus thinking „it’s not worth it / will go away“ is the only naive thing here…Am 15.11.2024 um 20:14 schrieb Tony Metzidis ***@***.***>: making a judgement like this without knowing the cost/benefit for github is naive. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: ***@***.***>

[jenic]

It was in the year 2024 when I encountered this hilariously embarrassing situation while I was attempting to create a hugo automated deployment using a post-update hook to publish to an AWS S3 bucket whenever I git push to an IPv6-only EC2 git server (love you soft-serve).

For anyone encountering this in the future and you're trying to do specifically what I was trying to do here is my workaround:

[module]
# We need to use golang's module proxy on AWS IPv6-only git servers since github doesn't
# support IPv6 yet in 2024 lmaoooo
proxy = "https://proxy.golang.org"
[[module.imports]]
    path = 'github.com/McShelby/hugo-theme-relearn'
    
[deployment]

[[deployment.targets]]
name = "production"
URL = "s3://mah-buckett?region=my-region-1&endpoint=https://s3.dualstack.my-region-1.amazonaws.com"

[fsa]

“Fun” news from competitors. Gitlab banned me over IPv6. I can't do a git push and go to https://gitlab.com without disabling IPv6.

[rettichschnidi]

I can't do a git push and go to https://gitlab.com without disabling IPv6.

Likley an issue on your end. I just tried and I was able to check out my repos hosted by GitLab via Git as well as HTTPS using IPv6.

[tonymet]

are all sockets filtered (both 22 & 443)? have you tried other addresses? i would be curious how broad the block was.

[autoantwort]

If you only want to download something from github one could use https://gh-v6.com/ as a workaround.

[tonymet]

@mph4 The community understands ipv6 is a big project, and it seems there has been some active work on the upgrade about 6 months ago. What could we do to help improve the updates on this? Even a quarterly progress report would do a lot for this community. There are a number of charity projects providing ipv6 workarounds, like gh-v6 , https://danwin1210.de & isgithubipv6 . Lots of passionate customers & open source contributors are rooting for a solution!

[NiKiZe]

And that is only the insecure GH proxy's (they might in theory log or manipulate data going thru them) but there is also several NAT64 solutions posted above that can be used with GH certificates and fingerprints in place, almost eleminating the mitm vector.

Please GH, make sure that your users and customers do not get into security issues when using third party solutions. Instead ensure that you yourselves provide a solution, even if it at this time don't have to be to enable IPv6 top-level.

[schnoog]

"The community understands ipv6 is a big project"
YMMD, a first good laugh today.
It was a big project 26 years ago. There's no valid excuse for a leading tech company not offering IPv6 in 2024.

[andres-moya]

GitHub unsupported. GitHub is not secure as the only method to access it is to use insecure 3rd party proxies. Or 3rd parties tunnels over modifying /etc/hosts. What is the conspiracy? Reptiloids?

[RokeJulianLockhart]

https://github.com/orgs/community/discussions/10539#discussioncomment-11344154

...@andres-moya, what?

[RokeJulianLockhart]

https://github.com/orgs/community/discussions/10539#discussioncomment-11346679

@JorenVsyntra, don't spam peoples’ e-mail inboxes for that.