Re:Reclaiming IPv4 Class E's 240.0.0.0/4
by zamadatix on Monday May 27, 2024 @10:52PM
(#40496906)
I've previously talked about opening this space up (sometimes here [1]) in similar light to how Ben does in regards to it (more or less) being "an extra source of pain" rather than a solution to anything. My opinion has been the same through multiple proposals for this, though some have had minor differences to considers. There are two main reasons I believe this across all of them:
The first is, particularly on opening it up for public assignment, all of the compatibility issues mentioned. It's not enough that in 2035 99% of things could be compatible when talking about existing internet infrastructure - it has to be 100% going to work (without hoping everyone just catches up, this isn't a separate internet like IPv6's rollout is) if you want to bet interoperability of the established internet on it. The alternative is let people use it but not on the internet, that way they own their own interoperability with themselves or anyone directly interacting with their internal network. If this were a security issue I'd have different feelings on it but it's about convenience so it isn't enough that it's possibly more convenient to most 10 years from now. Especially since the problem and solutions will have evolved so much 10 years from now anyways.
The second reason is, even if it does work out 100%, it's not much a solution to anything anyways. IPv4 pressure has started causing places with large blocks of old IPv4 space moving to NAT, carries deploying double NAT via CG-NAT, cloud providers looking at public IPv4 address fees, and the entire mobile world being IPv6 first with some going as far as IPv6 only with NAT64. Each one of these solutions already in place has resulted in more usable IP space than this would open up so this solution could neither replace them or stop them from being needed in the future. Each existing alternative (however non-ideal) is either a longer term mitigation or step towards a long term solution to the shortage instead of a small basket of addresses to throw on the fire. In particular the NAT64 and 464xlat solution have proven to be a long term permanent answer for the vast majority of the cases people thought they needed these kinds of addresses for that would have left them less prepared when these too ran out. I particularly don't buy the idea that the world just so happens to need exactly a /4 more of space and everything would be alright - it only looks that way because of the above methods being pressured into happening. Remove that pressure and it (at best) can hope to delay the rollout numbers of those methods by a decade.
All that said I'm still in support of opening it up for private use cases like enabling 0.0.0.0/8 in Linux [2] did (think use cases like another /8 of space you can slap your Docker container NATs behind or your HA networks behind for software that doesn't support v6). Not only do I think that would result in less pain for the internet at large I think it would actually result in a larger decrease in IPv4 pressure long term by giving more spaces to NAT to/from for those not ready/able to NAT64 all of their internal services.
The first is, particularly on opening it up for public assignment, all of the compatibility issues mentioned. It's not enough that in 2035 99% of things could be compatible when talking about existing internet infrastructure - it has to be 100% going to work (without hoping everyone just catches up, this isn't a separate internet like IPv6's rollout is) if you want to bet interoperability of the established internet on it. The alternative is let people use it but not on the internet, that way they own their own interoperability with themselves or anyone directly interacting with their internal network. If this were a security issue I'd have different feelings on it but it's about convenience so it isn't enough that it's possibly more convenient to most 10 years from now. Especially since the problem and solutions will have evolved so much 10 years from now anyways.
The second reason is, even if it does work out 100%, it's not much a solution to anything anyways. IPv4 pressure has started causing places with large blocks of old IPv4 space moving to NAT, carries deploying double NAT via CG-NAT, cloud providers looking at public IPv4 address fees, and the entire mobile world being IPv6 first with some going as far as IPv6 only with NAT64. Each one of these solutions already in place has resulted in more usable IP space than this would open up so this solution could neither replace them or stop them from being needed in the future. Each existing alternative (however non-ideal) is either a longer term mitigation or step towards a long term solution to the shortage instead of a small basket of addresses to throw on the fire. In particular the NAT64 and 464xlat solution have proven to be a long term permanent answer for the vast majority of the cases people thought they needed these kinds of addresses for that would have left them less prepared when these too ran out. I particularly don't buy the idea that the world just so happens to need exactly a /4 more of space and everything would be alright - it only looks that way because of the above methods being pressured into happening. Remove that pressure and it (at best) can hope to delay the rollout numbers of those methods by a decade.
All that said I'm still in support of opening it up for private use cases like enabling 0.0.0.0/8 in Linux [2] did (think use cases like another /8 of space you can slap your Docker container NATs behind or your HA networks behind for software that doesn't support v6). Not only do I think that would result in less pain for the internet at large I think it would actually result in a larger decrease in IPv4 pressure long term by giving more spaces to NAT to/from for those not ready/able to NAT64 all of their internal services.
[1] https://news.ycombinator.com/item?id=39804231, https://news.ycombinator.com/item?id=32796355
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...