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.

It could be that they don't want to implement IP bans in IPv6.

Or the most likely more expensive rate limiting (computational wise)

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.

How does IP bans work in IPv6 case? One just blocks whole /64 or /56 address range?

I have not had a deal with this, but if I was going to, I would start at the /64 and move up by nibble (4-bit) boundaries: /64, /60, /56, /52, /48.

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

Yes, /64 is a reasonable starting point for blocking outright, but /48 is the right unit for scoring reputation.

APNIC blog says /48 prefixes are for global routing, i.e. site=country there, not web server.

>/48 is the minimum prefix size that will be routed globally in the BGP.

I'm not sure if I'm misreading you, but a /48 would never be an entire country's v6 allocation.

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.

Reputation unit is /64 block, so if you want to see a 100 people ISP as one reputation unit, it should get a /64 block. But AFAIK today in practice reputation unit is a country.

Country would be far too coarse to be useful. I suspect it's more likely to be at the AS level, or /32 or somewhere around there.

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.

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.

It's because big tech is USA based mostly, where there's still a glut of ipv4 available.

IPv4 was exhausted at ARIN in 2011. Last time I bought a /24 on the open market, it was around $6k. I assume it is much more, now.

It's close to that right now. Prices more than doubled as covid set in, then dropped back down to about where they were before.

Where can I get it, asking for a friend?

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.

Yeah, I can't imagine managing fleets like that with only v4. Our network config is so convoluted with gateways and NATs everywhere, paying AWS through the nose for it all, when it could all be so much simpler.

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

Well it’s over 50%…

You probably need a hefty security reimplementation if you want to add IPv6 to Github.

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.

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.

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.

a browser you at least have the ability to change though. if your ISP doesn't offer v6 you're SOL really

ISPs almost all offer IPv6. The reason the US number is not higher is lazy corporate networks.

That depends on the country though. Southern Europe is way behind in terms of IPv6 adoption even by ISPs

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.

IPv6 is the protocol of the future. And will be so.

Meanwhile big gaming companies when Linux users are 5% of Steam users: 'eff off'.

I don't buy that. Do Netflix or YouTube care that people on 56k can't use their service?

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.

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

Anonymous rate limits for us are skewed towards preventing abusive behavior. Most users do not have a problem, even there is a CGNAT on IPv4.

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

I don't doubt your experience, but I wouldn't expect it to continue. I don't think Tuna-Fish is correct that "most" of the IPv4 world is behind CGNAT, but that does appear to be the trend. You can't even assume hosting providers give their subscribers their own IPv4 addresses anymore. On the other hand, there's a chance providers like Linode will eventually wise up and start giving subscribers their own /64 - there are certainly enough IPv6 addresses available for that, unlike with IPv4.

> I don't think Tuna-Fish is correct that "most" of the IPv4 world is behind CGNAT

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

Oh wow, thanks for those numbers!

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

Yeah, our traffic is more from automated systems/servers, nothing from mobile

Yeah, absolutely no expectations for the future. My point was more that while there may be clear benefits for users, IPv6 presents real problems for service operators with no clear solutions in sight.

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.

If a single machine gets /64 and you rate limit by /64, what doesn't work?

>Linode and others that do /64 for a whole data center

That's how it's supposed to work.

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

If the OS uses SLAAC by default, then it will just work, but SLAAC is for humans and makes less sense for web servers (yet can make sense for vpn servers). For web servers /128 is more meaningful.

Well, even if there was a standard, that's still not a guarantee that the other side of the /64 would be following it. It's correct for you to rate-limit the whole /64.

IPv6 rollout is a lot of operational work that ends with next to no immediate quantifiable benefit. So I’ll never be prioritized in a cost-cutting environment.

I mean, all your numbering woes vanished, so, that's probably an immediate quantifiable benefit unless you're so tiny you never needed any renumbering effort, in which case your "operational work" to deploy IPv6 was probably zero.