Feature Request: Provide a centralized resource and GitHub Public Roadmap tracking of IPv6-support for GitHub Services

[ScriptAutomate]

Select Topic Area

Product Feedback

Body

Summary

Our OSS project is running into difficulties with users and community members that are accessing GitHub via IPv6-only networks/services. People are left to find alternative solutions (such as people in Brazil and other countries).

I don't really know where to point them to when it comes to any estimates about when certain GitHub services will support it, and what services/endpoints don't.

This really is an extension of threads like this that have been opened over time, where it is difficult to tell when it is because IPv6 is not supported in some cases or because of something specific in user error or their env:

• IPv6 support for cloning Git repositories
• Support ipv6 connect to repositories
• Support IPv6 for Repository Cloning
• ipv6 and webhooks - 2024
• Self-hosted runners are offline (mentions possible an IPv6-specific issue?)
• GitHub Runners Issue: IPv6 unsupported
• webhook URL to IPv6-only server

GitHub Changelog, Roadmap, and Docs: Limited presence of IPv6 mentions

I've been unable to find anything related to IPv6 in the GitHub Public Roadmap.

The GitHub changelog is pretty limited when it comes to any updates or plans related to IPv6 support of infra:

• GitHub Blog: ipv6 tag (only one article with label)
  • GitHub Blog (2021-09-30): Enabling IPv6 Support for GitHub Pages

A past GitHub incident where GitHub mentioned working on IPv6 enablement:

• GitHub Status Incident Report: Jan 31, 2024 - Load balancer incident

Docs References

I know that when we have used GitHub Pages, it supported IPv6. This was mentioned in the GitHub blog post above.

As for other services, I can find scattered references throughout GitHub docs about IPv6 support where it isn't supported such as:

GitHub is gradually rolling out support for IPv6. As GitHub services continue to add IPv6 support, we will start recognizing IPv6 addresses of GitHub users. (source)

GitHub webhooks do not currently support IPv6 but will in the future. (source)

This endpoint (API endpoint for Get GitHub meta information) returns both IPv4 and IPv6 addresses. However, not all features support IPv6. You should refer to the specific documentation for each feature to determine if IPv6 is supported. (source)

Wishlist

Centralized Resource

Is there a centralized list anywhere by GitHub that we can point people to for seeing what GitHub services do/don't support IPv6? If one doesn't exist, I'd definitely like to make a feature request for this. It would be helpful since when people run into it, they end up going down a rabbit hole to only find community discussions about the lack of support, and a large lack of official resources or references. If a page simply said the service/endpoint they are trying to use does support it, it would rule that out as a path to investigate.

Could perhaps even include known workarounds/solutions that GitHub or users tend to be providing to the same questions related to accessing each service until IPv6 is officially supported.

GitHub Public Roadmap Presence

Having the centralized resource would also be especially helpful if there continues to be no plans in the GitHub Public Roadmap for them. But, in the event that there are plans or ongoing work for particular services supporting IPv6, then having them somewhere on the GitHub Public Roadmap under a status of Future would be amazing as a place to refer people. I have a feeling you'd end up getting a lot of issue backlinks and insight into the larger scope of OSS projects impacted across GitHub.

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams.
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences.
• GitHub staff may reach out for further clarification or insight.
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[cron2]

Yes, please. Full IPv6 support to all internet-facing github endpoints is overdue.

[1q23lyc45]

The main reason for not being able to enable v6 is probably more of an logging and abuse management issue.

Couldn't this be done by network prefix?

No. It is a waste of IPv6 resources.
Even if there are many IPv6 addresses, you can't waste it too much!

[NiKiZe]

The main reason for not being able to enable v6 is probably more of an logging and abuse management issue.

Couldn't this be done by network prefix?

Yes that is what they should do, but which prefix size? This is going from being one or several users behind one IPv4 address to be one behind /64, /56, /48 in IPv6 (and for some it's multiple behind one /64, but that's just bad implementation)

But I suspect the challenge is more in terms of modifying old, highly optimised, internal magical logic, it could be some int32s in a database that no-one dares to touch, maybe with many layers in-between or integrations to 3rd party tools that lacks support etc.

[dpc]

No. It is a waste of IPv6 resources.

I'm just thinking about rate limiting based on address prefix, if inability to rate limit abuse was the problem.

Yes that is what they should do, but which prefix size?

That's a good question, especially given that (and anyone nowadays) probably have some software that might be running on ipv6 and uses rate limiting.

[GoetzGoerisch]

Yes that is what they should do, but which prefix size?

That's a good question, especially given that (and anyone nowadays) probably have some software that might be running on ipv6 and uses rate limiting.

Rate limits typically should follow the nibble boundaries /64 /60 /56 /52 /48

With /64 being the equivalent to a single v4 address.

[mrmelon54]

But I suspect the challenge is more in terms of modifying old, highly optimised, internal magical logic, it could be some int32s in a database that no-one dares to touch, maybe with many layers in-between or integrations to 3rd party tools that lacks support etc.

Could be optimised by using two uint64s (a start and end column, only the network part needs storing) in a database or other searchable medium. A /64 prefix is represented by start == end and the other prefixes are defined by their inclusive start to end range.

Assuming these values are indexed and efficiently searchable in the database or cache, then searching if an address is banned or rate-limited is as simple as finding if the address is between a start/end pair in the database or cache.

[Mynacol]

There are some GitHub domains pointing to Fastly but lacking AAAA records. You can add them with the linked DNS Response Policy Zone or just insert them in your hosts file. Enjoy!
https://codeberg.org/IPv6-Monostack/delegacy-rpz/src/branch/main/dnsconfig.js#L1278-L1542