It's not about number of addresses available, it's about reflection of organization hierarchy in the octets. The 10.0.0.0/8 range is useful for breaking a distributed company's network up so each major office gets a 10.x.0.0/16, and each department a 10.x.y.0/24.
This is why 192.168.0.0/16 is often used for services like libvirtd, kubernetes and docker. And the use of the range by those services makes it even more unwieldy to try and put some other LAN in there.
You can work around these considerations if you want, but many people won't. When you're the network engineer responsible for designing a company's networks, you'll be wanting to keep things simple and robust. When you're called in at 3am on a Sunday because the network is down, you better hope your ability to recover doesn't require making a bunch of subnet calculations because you decided to try and use the pool of available IP addresses efficiently.
Unlike 1.1.1.1, 10.20.30.40 is reserved in RFC1918, you mustn't use it on the Network. So I don't have to care
(No I don't use RFC1918 addressing at home; Yes, every machine in my home has public IPv4 and/or IPv6 addresses; No that doesn't make it "really easy to break in" because having an address is not the same thing as being accessible)
Exactly this. There is no "backwards compatible" way to have more addresses in a protocol that's wedded to 32-bit addresses. That's just how numbers work. The protocol with a larger address space will be incompatible, and so anybody who seems surprised/ disappointed hasn't even really thought about the problem.
Using the 10/8 or any of the other RFC1918 had great potential to step on their customers toes. That is exactly why rightly or wrongly they used the 1.1.1.0/24 range. Hardware manufacturers generally used the range for interfaces that were local to the device and often only used on interfaces internal to the device. They knew this equipment would be deployed into environments where RFC1918 addressing would be used but they had no idea what RFC1918 address ranges, so using addressing from the RFC1918 networks meant potentially impacting their customer's data. They chose to instead use addressing which at the time they believed would not impact their customers.
APnic is not blameless here. They knew the issues with this space when it was assigned to them as a research network. For quite awhile they allowed Google to advertise the space and collect data on it's usage. I assume Google no longer was providing the infrastructure to do so and APnic saw an opportunity to have someone collect data for them for free.
Collecting data on traffic sent to this ip range is one thing but approving its use for a service available to the public knowing the accompanying issues much of the public would have accesssing it is in my opinion not responsible use of a research network.
So you're saying that providers are using these address ranges where you'd usually expect to see something like 10., 172.16-31. or 192.168.*? That is, purely internal traffic that's not routed over the public net?
If so, I could buy that, but my question is "why?" That is, why not use an actual RFC1918 private address?
Or is your point actually something different, and I'm just missing it?
IPv4 didn't provide a variable-length header, so the number of address bits is fixed. Any extension to add more addresses is inherently going to break interoperability.
Specifically ::10.20.30.40 is for a system that speaks both, and ::ffff:10.20.30.40 is for a system that only speaks IPv4. You don't even have to convert to hex.
Two things that come to mind are running out of private address space (a /8 isn't that large), or wanting address space that doesn't clash with other private networks (e.g. to ensure a VPN doesn't overlap with home networks). There's probably more reasons.
> The 10.0.0.0/8 block provides 16 million addresses
> and there's also 172.16.0.0/12 and 192.168.0.0/16.
> There are certainly enough addresses in these ranges
> that running out is not a concern
With the constraints of subnetting, it is a concern. I know a very large telco that ran out of private IPv4 addresses - and that specific issue was the reason for finally launching a proper IPv6 project.
reply