Change at tier one telecoms providers tends to be glacial. It follows hardware upgrade cycles that take ages to plan and implement.

I spent a decade writing element management systems. An element is a network device - switch, router, ROADM, etc. Often you give the customer kit & software and they spend a couple of years assessing it. This software would be installed on secure out of band networks with no route to the internet. 10/8 would have been adequate for the lifetime of the hardware currently in service - 200G stuff. However, that's not how things played out.

When I started working on EMS software IPv6 support was a requirement but it was just a box ticking exercise. No one was actually going to use it. A decade later IPv6 HAD to work for northbound and southbound traffic, on an internal network. Otherwise, no sale. IPv6 is being used in anger in telecoms. I have no idea how long that will take to filter to in band networks.

> telecoms that deal with consumers have at best 0 (zero) incentive to deploy ipv6 unless there's regulatory pressure.

I don't think this is true. The IPv4 address exhaustion is still a problem and it's getting worse, and telecoms which also provide internet services need to allocate addresses to their clients. With the 5G rollout these telecoms need to make room for new devices, and that's not feasible with IPv4.

I was under the impression that cell carriers famously went all in on v6 because it saves them money?

Yes that don't have to allocate an IPv4 address for each customer or deploy ugly solutions like CGNAT. They simply cooperate with phone OS makers (Apple and Google) to make sure the OS and the apps work in an IPv6-only environment. Apple then forces app developers to make their app work in an IPv6+NAT64+DNS64 environment.

> telecoms that deal with consumers have at best 0 (zero) incentive to deploy ipv6 unless there's regulatory pressure.

Not entirely true. 10/8 is only so big, so the management of addresses very much has a nonzero opex cost.

And on top of that there's capex on "carrier grade NAT".

For the biggest providers 10/8 is not even big enough for their production environment. And then they acquire some some company that (obviously) also uses 10/8.

No, there's definitely incentive there. Just… not enough.

240/4 is usually used when 10/8 isn't enough.

Do you have data on that? I've heard rumors, but never seen it actually done.

It was never a viable option for the Internet (million or billions of devices would never support it, and anyway it'd only buy us like 3 months), but in theory it should work better in the (more, but not entirely) controlled environment of a large prod environment.

I know of several massive setups that when running out of 10/8 evaluated 240/4 but deemed it less feasible, riskier, and definitely more work, than to "just" move to IPv6. Sorry, can't namedrop them, since I don't want to doxx myself. I've never seen 240/4 actually chosen.

We use them in AWS as IPv6 hasn't been feasible, though its become better in the last 1-2 years. AWS uses it internally, likely other big providers probably also do. If you can get away with IPv6 only, ie not constrained by provider/device, its likely worth going that direction instead.

Works fine in Linux, doesn't really work on Windows and some BSDs.

https://blog.benjojo.co.uk/post/class-e-addresses-in-the-rea...

240/4 is multicast range, and mobile devices WILL wreak havoc in that range (though it's not impossible to simply drop all such traffic at ingress). I usually see service providers using 172.16/12 instead.

224/4 is multicast. AWS uses it, we use it in AWS, as do others. Works fine with Linux, Windows not so much, afaik android and osx are fine with it.