I’ve worked with large organisations that have merged dozens of companies networks. There were lots of clashes.
I’ve also worked with companies where their networks filled up almost all the 10/8 space and they were running out of room. Having to do things like shrink subnets at individual locations and deal with issues around not able to install all the equipment they originally wanted. It’s a real pain.
And yes, the entire 10/8 space needed to be routable through to the corporate support desk, SIEM tools, payment systems, loyalty systems, security and other IoT systems, etc.
Yes sure you could probably NAT things, or switch to tools/approaches that don’t require every device to have an internally routable IP, but then that’s a terrible argument akin to arguments against IPv6.
My point is that if every company uses real IPs then you can merge networks with no conflicts. 10/8 is fine for home use but not for enterprise networks.
In a word where any medium sized company could just get a /20 network and any enterprise could get a /8 I would agree, but with IPv4 we live in a world where the vast majority of companies don't have anything but 10/8 (and a couple of IPs for public facing stuff).
The only real options besides 10/8 are to have been big at the advent of the internet (like IBM or Apple) or misappropriate one of those IP blocks in the hope it never becomes publicly routable.
What this has to do with anything? I'm saying that giving whole /8 (or I should say class A) to a company is wasteful. And you can only do it no more than a bit over 200 times. You are on the other hand saying that the hardware at the time wouldn't be able to handle all the companies. Why not allocate C blocks, or at very least B blocks? Or are you saying that they doubted hardware of the future would be capable of handling it?
Because of such wasteful allocation we got this "wonderful" thing called NAT which basically killed most of innovation in area of networking and IPv6 which is taking over 20 years to adapt, because most ISPs hold to IPv4 as long as they can because making this switch requires some work.
They might have to interact with a lot of devices that only support IPv4, and will never upgrade. These include a lot of industrial PLCs and various embedded devices.
10.0.0.0/8 might seem like a lot of addresses, but certain large companies have enough fans and chillers and miscellaneous things that can fill that space, and it takes a lot of effort to reorganize their network to better allocate those addresses.
At work (a larger enterprise in Europe) we already see quite a bit of pain with IPv4. B2B connections are increasingly not using globally unique addressing anymore, so we often need to use prefix NAT and application level proxies to bridge clashing address space. This in turn is a support nightmare and is hurting reliability.
Our network guys seems to love the extra complexity, though.
What would a good solution to that even look like? Giving every mid-sized company it's own PI block would massively bloat the routing table so that's not going to happen. The solution space that's left basically comes down to some form of NAT/NPT or multi-home support at the endpoints. The IETF's preferred solution is the latter which seems reasonable to me.
A lot of the need for this design is for backwards compatibility with existing corporate network designs that will likely be on IPv4 for perhaps another decade or two longer. Most corporate networks despise changes and seek to gain stability of their environment through minimizing changes.
My current contract customer absolutely wants this and requires it, in fact, for compliance with internal security policies (nevermind the litany of security issues using IPv4 in the first place). The limitations of this solution include the fact that we're unable to get much control of these instances because we use third party software galore on these type of NAT instances like IDS, firewalling, caching / proxying, and traffic shaping. So unfortunately, all this new service does for us is let us separate out one of like 12 functions to a (granted, high availability) service and in the interest of saving money on not creating 25+ instances for these 12 services it's not unheard of to collapse these into 3-4 load balanced / distributed much larger instances for the sake of easier manageability. But for a lot of folks, I can imagine this is a great service that meets their needs sufficiently well.
Yes I agree you would need to tunnel because the headers aren’t big enough.
If I had to guess the futur, the industry will most likely go towards something like few expensive IPv4 owned by major cloud and internet providers and crazy recursive NAT setups everywhere. Because that works without breaking stuff.
I help design one of big 3 cloud providers and we're about to run out of private space for customer IPv4. We are addressing this is in a number of ways but I think others have run into this same issue.
/24 can easily be moved.
And if I have 65000 /24s with varying utilization (like Apple,) and could turn that into money by coalescing and adding NAT, that would drive change.
It’s not that ipv4 space is exhausted, there’s plenty of it available. It’s that early on it was mismanaged to the point that people / companies were able to buy entire /8’s for basically nothing and hold them forever.
I originally wrote "a giant headache that never goes away", but changed it because it is possible to renumber the networks. But... that doesn't properly fix the problem. You'll hit the exact same issue the next time you go through a merger.
Worse, RFC1918 isn't actually that big. There are plenty of companies out there that have either exhausted it or have to be very very careful with their use of it to avoid running out. At some point you run out of space to renumber into. You're also going to have issues with e.g. VPNs to people's home networks, where renumbering isn't viable.
Depends on your scale.. As soon as you start to have to resort to overlapping private IPv4 networks it really starts to get fun if you have to connect certain things together that weren't planned to be able to reach each other initially.
I'm wondering how such a change would get "merged" in to begin with. I imagine even non-network engineers would get this huge itch having a large corporate contain a private IP in the changelist (I'm the non network engineer and can't really explain why it's bad. But it FEELS wrong and sometimes you at least need to use instinct to get another pair of eyes on something).
A big reason is mergers (something HP has a lot of experience with); merging two 10/8 networks is a mess but if they have unique IPs it's easier.
Also, I think the concept of a "private network" is inflexible and in some sense a premature optimization. If you use unique IPs you can decide on a subnet or even host basis what is exposed to the Internet and what isn't.
My first Networking job (2012-2015) was still like that! It was a regional health system that had a /16 from the early 90s (pre-ARIN). We were still using public IPs on printers and guest networks even. It was a bit of a pain going to the next place with 10x the devices and 1/10th the IP space.
Funnily enough the first job with all public IPs was the one with some IPv6 deployed while the 2nd was the one without. Of course it was the same manager in the early 1990s that rolled out IPv4 there that rolled out IPv6 in the 2010s so maybe it's not so surprising.
I’ve also worked with companies where their networks filled up almost all the 10/8 space and they were running out of room. Having to do things like shrink subnets at individual locations and deal with issues around not able to install all the equipment they originally wanted. It’s a real pain.
And yes, the entire 10/8 space needed to be routable through to the corporate support desk, SIEM tools, payment systems, loyalty systems, security and other IoT systems, etc.
Yes sure you could probably NAT things, or switch to tools/approaches that don’t require every device to have an internally routable IP, but then that’s a terrible argument akin to arguments against IPv6.
reply