You may have seen something making the rounds on Twitter this week about a couple of proposed drafts designed to alleviate the problems with IPv4 exhaustion by repurposing some old IP spaces that aren’t available for use right now. Specifically:
Ultimately, this is probably going to fail for a variety of reasons and looks like it’s more of a suggestion than anything else but I wanted to take a moment to talk about why this isn’t an effective way of fixing address issues.
Error Bearers
The first reason that the Schoen drafts are going to fail is because most of the operating systems in the world won’t allow you to use reserved spaces for a system address. Because we knew years ago that certain spaces were marked as non-usable the logic was configured into the system to disallow the use of those spaces. And even if the system isn’t configured to disallow that space there’s no guarantee the traffic is going to be transmitted.
Let’s take 127/8 as a good example. Was it a smart idea to mark 16 million addresses as loopback host-only space? Nope. But that ship has sailed and we aren’t going to be able to easily fix it. Too many systems will see any address starting with 127 in first octet and assume it’s a loopback address. In much the same way as people have been known to assume the entire 192/8 address space is RFC1918 reserved instead of 192.168.0.0/16. Logic rules and people making decisions aren’t going to trust any space being used in that manner. Even if you did something creative like using NAT and only using it internally you’re not going to be able to patch every version of every operating system in your organization.
We modify rules all the time and then have to spend years updating those modifications. Take area codes in North America for example. The old rules used to say that an area code had to have a zero or a one for the middle digit – ([2-9][0-1][2-9]) to use the Cisco UCM parlance. If your middle digit was something other than a zero or a one it wasn’t a valid NANP area code. As we began to expand the phone system in 1995 we changed those rules and now have area codes with all manner of middle numbers.
What about prefixes? Those follow rules too. NANP prefixes must not start with a zero or a one – (area code) [2-9]XX-XXXX is the way they are coded. Prefixes that start with a zero or a one are invalid and can’t be used. If we suddenly decided that we needed to open up the numbers in existing area codes and include prefixes that start with those forbidden numbers we would need to reset all the dialing rules in systems all over the country. I know that I specifically programmed my CUCM servers to send an immediate error if you dialed a prefix with a zero or a one. And all of them would have to be manually reconfigured for such a change.
In much the same way, the address spaces that are reserved today as invalid would need to be patched out of systems from home computers to phones to networking equipment. And even if you think you got it all you’re going to miss one and wonder why it isn’t working. Worse yet, it might even silently fail because you may be able to transmit data to 95% of the systems out there but some intermediate system may discard your packets as invalid and never tell you what happened. You’ll spend hours or days chasing a problem you may not even be able to fix.
Avoiding the Solutions
The easiest way to look at these proposals is by understanding that people are really, really, really in love with IPv4. Despite the fact that using the effort of the changes necessary to implement these reserved spaces would be better spent on IPv6 adoption we still get these things being submitted. There is a solution but people don’t want to use it. The modern Internet relies so much on the cloud that it would be simple to enable IPv6 in your provider space and use your engineering talent to help provide better adoption for that instead. We’re already seeing that all over places with address space has been depleted for a while now.
It may feel easier to spend more effort to revitalize the IPv4 space we all know and love. It may even feel triumphant when we’re able to reclaim address space that was wasted and use it for something productive instead of just teaching that you can’t configure devices with those spaces. And millions of devices will have IP address space to use, or more accurately there will be millions of addresses available to sell to people that will waste them anyway. Then what?
The short term gain from opening up IPv4 space at the expense of not developing IPv6 adoption is a fallacy that will end in pain. We can keep putting policy duct tape on the IPv4 exhaustion problem but we are eventually going to hit a wall we can’t overcome. The math doesn’t work when your address space is only 32 bits in total. That’s why IPv6 expanded the amount of information in the address space.
Sure, there have been mistakes in the way that IPv6 address space has been allocated and provisioned. Those mistakes would need to eventually be corrected and other configurations would need to be done in order to efficiently utilize the space. Again, the effort should be made to fix problems with a future-proof solution instead of trying our hardest to keep the lights on with the old system that’s falling apart for a few more years.
Tom’s Take
The race to find every last possible way to utilize the IPv4 space is exactly what I expected when we’re in the death throes of using it instead of IPv6. The easy solutions are done. The market and hunger for IPv4 space is only getting stronger. Instead of weaning the consumers off their existing setups and moving them to something future proof we’re feeding their needs for short term gains. If the purpose of this whole exercise was to get more address space to be rationed out for key systems to keep them online longer I might begrudgingly accept it. However, knowing that it would likely be opened up and fed to providers to be auctioned off in blocks to be ultimately wasted means all the extra effort is for no gain. These IETF drafts have a lot of issues and we’re better off letting them expire in May 2022. Because if we take up this cause and try to make them a reality we’re going to have to relearn a lot of lessons of the past we’ve forgotten.
If you believe in IPv6, why is networkingnerd.net only reachable over IPv4? That really sums up the problem.
It’s kind of odd to argue against reassigning free address spaces as “that ship has sailed”- while promoting IPv6.
Even if some subnet logic is hardcoded in some stacks, that’s easily fixed with a system update. Sure, some IoT systems can’t be updated – but those could be even less updated to support IPv6!
On IPv6, let’s face it: World IPv6 Day was nearly 10 years ago. Address exhaustion has come and gone already. And even if it miraculously did catch on, it wouldn’t do anything about address exhaustion unless IPv4 can be turned off.
And yet, even though the RFCs are a quarter century (!) old at this point, outside of Google, Facebook, Netflix and some CDNs, no major domain uses IPv6 (except for some www that are redirected to a CDN).
Even those you would expect to are all IPv4-only. microsoft.com, apple.com, tesla.com, verizon.com. att.com. No IPv6 on amazon.com, either (although if you really work hard at it, you can make it work on AWS). Not ebay.com, not wordpress.com, not pinterest.com,
At this point, IPv6 should get a new logo: the dead horse.
Sorry, that ship really has sailed.
It’s achievable, but there’s really no point in doing that because the solution is already there; IPv6
I’m going to disagree as well.
My organization will spend zero time implementing 0/8, 127/8 and 240/4. That’s for someone else to spend their time on. Some people like weird hobbies, so let’s let them put effort into lighting up these weird prefixes.
It will take another 25 years to turn off IPv4. That means we have 25 years to live with it as best we can. Coexisting means making the most of our IPv4 resources while spending 100% of my efforts deploying IPv6.
The prefix 43/8 was recently released into the market because the owner literally didn’t need it anymore. More of that kind of thing will continue as we move forward but I expect it to be rare for another ten years.
At some future point when Windows 11 (and maybe backported to Windows 10) can support these three new prefixes then our organization will automatically get the update and it will be usable. Sounds like a fun project to me (for other people to spend their time on).
So I suggest moving the draft to RFC status. Zero cost to me and a little bit of an upside (possibly) down the line. And anyone that tries to use these three prefixes in a production environment knows they may have problems. That’s on them.
Pingback: The Tyranny of Technical Debt, Numerically | The Networking Nerd