GitHub Community
Feature Request: Provide a centralized resource and GitHub Public Roadmap tracking of IPv6-support for GitHub Services #151477
Replies: 3 comments 11 replies
-
|
💬 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 ⏩
Where to look to see what's shipping 👀
What you can do in the meantime 💻
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. ⭐ |
Beta Was this translation helpful? Give feedback.
-
|
Yes, please. Full IPv6 support to all internet-facing github endpoints is overdue. |
Beta Was this translation helpful? Give feedback.
-
No. It is a waste of IPv6 resources. |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
I'm just thinking about rate limiting based on address prefix, if inability to rate limit abuse was the problem.
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. |
Beta Was this translation helpful? Give feedback.
-
Rate limits typically should follow the nibble boundaries /64 /60 /56 /52 /48 With /64 being the equivalent to a single v4 address. |
Beta Was this translation helpful? Give feedback.
-
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 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. |
Beta Was this translation helpful? Give feedback.
-
|
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! |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
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:
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:
A past GitHub incident where GitHub mentioned working on IPv6 enablement:
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:
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
Futurewould 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.Beta Was this translation helpful? Give feedback.
All reactions