| ▲ | rtdq 5 hours ago |
| And still, in the year of our lord 2026, GitHub does not support IPv6. https://github.com/orgs/community/discussions/10539 |
|
| ▲ | growse 5 hours ago | parent | next [-] |
| A non-trivial minority of the time, they don't support IPv4 either! |
| |
|
| ▲ | throw0101a an hour ago | parent | prev | next [-] |
| > And still, in the year of our lord 2026, GitHub does not support IPv6. Especially given that it is now owned by Microsoft, which has been working on IPv6-only (at least on their corporate network) for almost a decade: * https://blog.apnic.net/2017/01/19/ipv6-only-at-microsoft/ * https://www.arin.net/blog/2019/04/03/microsoft-works-toward-... |
| |
| ▲ | rekoil an hour ago | parent [-] | | I mean Azure doesn't really support IPv6 well either for a lot of the big-ticket services. | | |
|
|
| ▲ | Landing7610 4 hours ago | parent | prev | next [-] |
| Our university has bad problems with ipv4. Every few days you'll notice some websites being unreachable, including github. Although with their uptime recently, you never know who's to blame... |
|
| ▲ | jeroenhd 5 hours ago | parent | prev | next [-] |
| They supported IPv6 for a short time, but then stopped their experiment. An excellent reason to move away from Github, I find. |
| |
| ▲ | literalAardvark 2 hours ago | parent [-] | | I've been there. Management was fine with the testing but it added too much overhead for nearly no benefit to us. One more thing to troubleshoot at 3 am, one more thing to teach to a disinterested tier 1 support team, one more thing for Chrome to be weird about, hundreds more rules to manage in a hostile load balancer, logging tools that don't understand ipv6. Turned it off. End customer asked why the site got a little slower (CGN) and when we can turn ipv6 back on. As far as I know it's still on the backlog. | | |
| ▲ | jeroenhd an hour ago | parent | next [-] | | One of the big challenges with IPv6 remains that many of the knows-just-enough-about-networking people, like support staff, often never received any IPv6 training (or, for that matter, even enough IPv4 training that they don't need to Google things that come up in real life). Another is that the weird, awful, everyone-hostile corporate "solutions" often break IPv6 in stupid ways (like load balancers and logging tools being unable to cope with minor changes and requiring a full configuration rework). Things have definitely gotten better over time, though. The massive 90s style corporate networks will probably never transition, but smaller and more modern companies don't have that issue. Apple mandating that apps are IPv6 compatible and various government legislation forcing companies to make their shitty middleware IPv6-compatible has improved things quite a bit so far. As uptake keeps rising, the need for technologies like STUN and TURN will slowly start decreasing, and as a result more and more people will end up in "untested" situations where not having IPv6 and falling back to legacy paths starts becoming a problem. | |
| ▲ | throw0101a an hour ago | parent | prev [-] | | Facebook is (AIUI) 100% IPv6-only on their internal network, and has been for many years: * https://engineering.fb.com/2017/01/17/production-engineering... * https://www.internetsociety.org/blog/2014/09/facebook-launch... IPv4 is actually the "leftover" stuff they have to deal with at the front end. But they are an eye-balls heavy service, with a lot of mobile devices, which also tend to be IPv6-native. | | |
| ▲ | tialaramex 3 minutes ago | parent [-] | | It also just takes actual policy will. Somebody has to actually say "No" when the supplier who promised an IPv6 product says afterwards actually they meant IPv6 "ready" and they should have put an asterisk because really only the next version will be "ready", and er, so the product they've delivered doesn't actually work with IPv6 but that's fine right? "No". Not every human is psychologically prepared to do that. They want to acquiesce, to go along to get along, you need somebody to be firm. "No". |
|
|
|
|
| ▲ | sschueller 5 hours ago | parent | prev | next [-] |
| Just found this little site. https://isgithubipv6.web.app/ Maybe we shouldn't even measure percentage adoption and instead just if github has finally adopted.. |
|
| ▲ | farfatched 3 hours ago | parent | prev | next [-] |
| GitHub should absolutely support IPv6, but until then... transip.eu provide IPv6 addresses which transparently proxy to github.com:
https://www.transip.eu/knowledgebase/5277-using-transip-gith... You'll need to update your DNS server to include those as AAAA records. Do providers like NextDNS or RethinkDNS allow these sorts of overrides? |
| |
| ▲ | voltagex_ 2 hours ago | parent [-] | | >The Github IPv6 Proxy can only be used for traffic to Github using a VPS from TransIP which uses IPv6. |
|
|
| ▲ | globular-toast 5 hours ago | parent | prev | next [-] |
| Do we know any technical reason for this? Or are we left to think this is somehow a political thing? |
| |
| ▲ | michh 2 hours ago | parent | next [-] | | Perhaps a little tin foil hatty and definitely not the only reason but Microsoft owns Github and also makes a boatload of money off of Azure. Incumbent cloud providers like Azure have a major advantage in terms of having plenty of IPv4 addressing available whereas a new entrant to that market would have to buy or lease that space at a premium. Thus, these companies have an incentive to keep IPv4 a necessity. | | |
| ▲ | IshKebab 2 hours ago | parent [-] | | IPv4 is going to be a necessity for many many decades no matter what Microsoft do. Even when IPv6 is at 99%, people aren't going to want 1 in every 100 people to not be able to access their site at all. It'll need to be like 99.9% before we start seeing serious IPv6-only services. | | |
| ▲ | michh 7 minutes ago | parent | next [-] | | I don't know what the percentage would be, but we do have some historical precedent that could give us a clue. Best one I can think of is when bigger websites started actually dropping SSLv3 and TLSv1.0 (and later TLSv1.1) support, cutting off older browsers and operating systems. Google and Amazon still support TLSv1.0, but plenty of others (including Microsoft) have dropped 1.0 and 1.1. HN itself doesn't accept 1.1 anymore either. Then there's browser support. Lots of websites - big and small - cut off support for Internet Explorer 6 when it was somewhere below 5% marketshare because the juice was no longer worth the squeeze. Of course, few of those actually fully cut off the ability to browse the (now broken) website fully but it's a datapoint suggesting trade-offs can and will be made for this sort of thing. Or to put it in the present: a significant amount of webapps don't support Firefox (3% market share) to the extent their product is completely unusable in it. | |
| ▲ | jiggawatts 2 hours ago | parent | prev [-] | | Sure, but the implementation in the public clouds is totally backwards. What they should have done is have their core network default to IPv6 with IPv4 an optional add-on for things like public IP addresses, CDN endpoints, edge routers, VPNs, etc... Instead, their core networks are IPv4 only for the most part with IPv6 a distant afterthought. | | |
|
| |
| ▲ | mmbleh 43 minutes ago | parent | prev | next [-] | | IPv6 is very difficult to implement and enforce reliable rate limits on anonymous traffic. This is something we've struggled a lot with - there is no consistent implementation or standard when it comes to assigning of IPv6 addresses. sometimes a machine gets a full /64, other times a whole data center uses a full /64. So then we need to try and build knowledge of what level to block based on which IP range and for some it's just not worth the hassle. | | |
| ▲ | Tuna-Fish 31 minutes ago | parent [-] | | ... But that's no different from IPv4. Sometimes you have one per user, sometimes there are ~1000 users per IP. Most of the ipv4 world is now behind CGNAT, one user per ip is simply a wrong assumption. |
| |
| ▲ | alex_duf 4 hours ago | parent | prev | next [-] | | It's a possibly a managerial thing, which KPI are you improving when spending engineering time on adding IPv6 support? That said, for their HTTP stack they use fastly (as far as I understand), which should make the shift moderately easier. | |
| ▲ | denkmoon 5 hours ago | parent | prev | next [-] | | Outdated beliefs probably. When I talk about v6 support in our b2b saas, PM laughs and says nobody uses that shit. Big tech are massive laggards on this funnily enough. | | |
| ▲ | throw0101d 13 minutes ago | parent | next [-] | | > Outdated beliefs probably. When I talk about v6 support in our b2b saas, PM laughs and says nobody uses that shit. Nobody except the 140M subscribers on T-Mobile US's network: * https://www.youtube.com/watch?v=d6oBCYHzrTA But sure, be IPv4-only and add latency by forcing traffic through an extra translation box. | |
| ▲ | ViscountPenguin 4 hours ago | parent | prev | next [-] | | It's because big tech is USA based mostly, where there's still a glut of ipv4 available. | |
| ▲ | 10000truths 2 hours ago | parent | prev [-] | | Definitely not for the biggest ones. Google and Meta have so many machines in their data centers that IPv6 addressing becomes a technical necessity due to the risk of exhausting the RFC 1918 address space. Naturally, they were early adopters of IPv6. |
| |
| ▲ | direwolf20 4 hours ago | parent | prev | next [-] | | It could be that they don't want to implement IP bans in IPv6. | | |
| ▲ | merpkz an hour ago | parent | next [-] | | How does IP bans work in IPv6 case? One just blocks whole /64 or /56 address range? | | | |
| ▲ | c0balt 3 hours ago | parent | prev [-] | | Or the most likely more expensive rate limiting (computational wise) | | |
| ▲ | michh 2 hours ago | parent [-] | | I mean, given how the site performs on average I don't think they've optimized so much that the extra cpu cycles of ANDing with the fixed constant of 2^64-1 and then looking up or hashing a 16 byte integer - whatever they do - rather than a 4 byte one would increase the load significantly. Let's be pessimistic and say it's 20 extra cpu cycles, that's not gonna be much of a problem if their load balancers were made in the past 20 years. |
|
| |
| ▲ | AtNightWeCode 3 hours ago | parent | prev [-] | | You probably need a hefty security reimplementation if you want to add IPv6 to Github. |
|
|
| ▲ | jiggawatts 2 hours ago | parent | prev | next [-] |
| The irony of this is that pretty much all they'd have to do to enable IPv6 support is to use Azure Front Door as their CDN. Or... use any other CDN, they pretty much all default to providing IPv6! |
|
| ▲ | sandeepkd 5 hours ago | parent | prev | next [-] |
| Came here to exactly check on this to see if there are any changes on Github side too |
|
| ▲ | missingdays 4 hours ago | parent | prev [-] |
| Most websites still don't |