And still, in the year of our lord 2026, GitHub does not support IPv6.
I remember when I was first using my alma mater's online sign up for classes in the very early 2000s, their class sign up site had office hours.
I also remember the first IPv6 Workshop on W2k SP3 back in 2002. Not that long ago.
Random Google result with a bit more:
https://www.captaindns.com/en/blog/ipv6-subnet-sizes-48-vs-5...
So if I wanted to annoy GitHub, I could connect to them without ever using the same IP twice. Their response would have to be banning my /64, or possibly /56.
Stuff like bouncing a modem, getting a new VPS, making a VPN connection I would expect to be pretty similar. And getting a block officially allocated to you is a lot of work.
No, as it's supposed to be implemented a single internet-routable /64 is used per *network* and then most devices are expected to assign themselves a single address within that network using SLAAC.
ISPs are then expected to provide each connected *site* with at least a /56 and in some cases a /48 so the site's admins can then split that apart in to /64s for whatever networks they may have running at the site. That said, I'm on AT&T fiber and I am allocated a /60 instead, which IMO is still plenty for a home internet connection because even the most insane homelab setups are rarely going to need more than 16 subnets.
> So if I wanted to annoy GitHub, I could connect to them without ever using the same IP twice. Their response would have to be banning my /64, or possibly /56.
Well yeah, but it's not like it's exactly rocket science to implement any sorts of IP rate limiting or blocking at the subnet level instead of individual IP. For those purposes you can basically assume that a v6 /64 is equivalent to a v4 /32. A /56 is more or less comparable to /25 through /29 block assignments from a normal ISP, and a /48 is comparable to a /24 as the smallest network that can be advertised in the global routing tables.
I think GitHub has just gotten so aggressive with their rate limit policies that it’s straight up incompatible with their own product. The charitable interpretation is that they aren’t keeping good track of how many requests each page actually performs in order to calibrate rate limiting.
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-...
You'd think they'd have sprinted for that feature as fast as they could go.
USG also set a whole bunch of security requirements under FedRAMP that Microsoft can never meet, but they received an ATO anyway because they are so heavily entrenched in government.
Turns out we could not connect to Twilio's API which is IPv4 only.
In corporate software development, we work the tickets assigned, and keep our KPIs up so that we don't face the wrath of the bean counters.
QA found it a couple weeks later when they were testing alerting, and SMSes weren't coming through.
An excellent reason to move away from Github, I find.
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.
* 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.
"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".
I have also found that an uncomfortable number of people do not consider it appropriate in any way shape or form. Even when it’s ultimately your call and no one else’s.
Folks don’t really like waves. They like looking at them from the shore, but freak out when it’s their turn to hang 10
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.
I've been setting up Snapcast (open-source multi-room audio), and needed to move the server to a different machine. While I was setting up the new system, I told it to only bind to localhost. Somehow this only affects the ipv4 networking stack, as some of my clients started automatically connecting to the new server even before I had finished all my testing.
Turns out that it was advertising some kind of ipv6 link-local address that showed up in autodiscovery. In my case there wasn't any harm, but this type of thing could very easily result in a major security vulnerability.
The usual convention for configuring listening interfaces usually involves listing IP addresses or interface names. There's very little room for misconfiguration here, although it's possible. More likely to be a bug in Snapcast (it's almost certainly not an issue in the Linux kernel).
Moreover, this general problem (i.e. configuring listening interfaces) is not/should not be different between IPv4 and IPv6. So introducing IPv6 should not™ incur any additional risk at this level.
But as said, it's hard to get more concrete without knowing exactly what happened in your case.
I'm sure it's totally my fault but that's the point: folks who know how ipv4 works may have huge blind spots for ipv6.
Maybe we shouldn't even measure percentage adoption and instead just if github has finally adopted..
github.com doesn’t have an IPv6 address.
github.io does have an IPv6 address. Indeed, one workaround for getting rate limited when using a carrier NAT with github.com is to have a github.io page and pull data from github.io instead of github.com.
Edit: About a decade ago, all of my hosting had full IPv6 support, and I tried to move over to IPv6. However, there was an issue with Letsencrypt certs not validating over IPv6, so I made my web pages IPv4 only. Recently, I gave IPv6 a go again, and the cert issue has been fixed, so now my webpages finally have both IPv4 and IPv6 addresses.
Are you sure? I don't see it.
Name: github.io
Addresses: 185.199.111.153 185.199.110.153 185.199.108.153 185.199.109.153
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?
> Do providers like NextDNS or RethinkDNS allow these sorts of overrides
Not on the resolver, but on the Android client (Rethink DNS + Firewall) we do (if enabled) manipulate DNS answers to implement an opportunistic 464xlat (over Kasper Dupont's public relays [0]).
[0] https://github.com/celzero/firestack/blob/c10c155464e0d4a81a...
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.
/56 is often recommended as the minimum as for a (residential) customer. /48 is considered a "site" address prefix, and is the smallest allocation that can be advertised in BGP:
* https://blog.apnic.net/2020/06/01/why-is-a-48-the-recommende...
* https://www.infoblox.com/blog/ipv6-coe/a-48-for-every-site-a...
You get 65k subnets with it, which is what you get with 10/8.
>/48 is the minimum prefix size that will be routed globally in the BGP.
If we're talking home networks, you can reliably expect a /48 to a) not be announced in BGP itself, and b) cover one to a few hundred users of one ISP. (The containing /32 or similar will be announced.) A business might structure its network so that one of its /48s corresponds to a country, but in that case the /48 would be covering just that business, which would be a sensible unit for reputation tracking.
I have a /48. The amount of "we have detected unusual activity from your network" messages I get from sites, when I'm reasonably sure the only activity coming from my network is my usual activity on those sites, suggests that they're using something bigger than /48.
That said, for their HTTP stack they use fastly (as far as I understand), which should make the shift moderately easier.
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.
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.
Most of the ipv4 world is now behind CGNAT, one user per ip is simply a wrong assumption.
For IPv6, if we block on /128 and a single machine gets /64, a malicious user has near infinite IPs. In the case of Linode and others that do /64 for a whole data center, it's easy to rate limit the whole thing.
Wrong assumption or not, it is an issue that is made worse by IPv6
Given that GitHub also offers free services for anonymous users, I can imagine they face similar problems. The easiest move is simply to just not bother, and I can't blame them for it.
~60%+ of internet traffic is mobile, which is ~100% behind CGNAT.
On desktop, only ~20% of US and European web traffic uses CGNAT, but in China that number is ~80%, in India ~70% and varies among African countries but is typically well over 70%, with it being essentially universal in some countries.
Overall, something a bit over 80% of all ipv4 traffic worldwide currently uses CGNAT. It's just distributed very unevenly, with US and European consumers enjoying high IP allocations for historical reasons, and the rest of the world making do with what they have.
Since mmbleh mentioned Linode I'm guessing they're more concerned with traffic from servers, where CGNAT is uncommon. But even that may be changing - https://blog.exe.dev/ssh-host-header
>Linode and others that do /64 for a whole data center
That's how it's supposed to work.
According to who?
It could fit best practices if your datacenter has one tenant and they want to put the entire thing on a single subnet? In general I would expect a datacenter to get something like a /48 minimum. Even home connections are supposed to get more than /64 allocated.
And Linode's default setup only gives each server a single /128. That's not how it's supposed to work. But you can request /64 or /56.