Okay, this has descended to a point where we need some fact injection.
You get a D on those facts because you did not review the "literature", did not attempt reasonable coverage of the problem space, and did not investigate whether or not there were other versions of the software that have been patched to support 240/4.
And what's your grade, because you aren't displaying a realistic worldview that takes into account that there are tons (tons!) of sites where these "patched" versions of software simply will never run. We've been UNABLE to get the vast majority of customers to automatically patch their Windows installs. There are still deployed fleets of Cobalt Raq's. There's a TON of problems on both the client and server sides of this. I'm not sure what magic "literature" I'm supposed to review which describes how this will all magically fix itself. I have no idea why you are unable to see the extent of the problem space. I am confused as to why you would think that patches make a difference, when we're talking about a need to patch billions of devices. That you might someday be able to get an IP packet from one 240.* net to another halfway around the globe isn't unthinkable. You can patch devices under your control and make clients and servers under your control work. You just won't get the global interoperability that is what the Internet is famous for.
We cannot engineer a set of solutions that will work for everybody.
Therefore, you want to engineer a solution that'll work for mostly nobody?
No, therefore we should not attempt to engineer a solution that will work for everybody but merely remove the barriers that allow others to engineer solutions for their situation.
Unless you have some magic wand that can update a few billion IPv4-capable devices to be IPv4-240+ capable, it would appear that you have no method to remove these barriers. That would seem to be a showstopper bug.
So, what's your game plan to replace all these broken IPv4 stacks?
Again, we are not the gods of the Internet. It is not our reponsibility to fix every problem out there, but neither do we have to sit on our hands when we could enable others to deal with the issue.
There's a vast difference between enabling others to deal with an issue, and requiring everyone else on the Internet to change something for your convenience to fix your issue so that you don't break catastrophically.
Certainly. So why would we distract them with an intermediate transition to "IPv4-240+"?
I believe that people are not that stupid. The only organizations that go after the 240/4 solution space will have good reasons for doing so. We do not have a good reason to deny them that possibility.
The problem, then, is that if they go after that space, and nobody else does, then they don't reach about.... oh... well, by my (admittedly small) sample set, 100% of the Internet. Let's be generous and say that even 90% of the Internet is upgraded, somehow. Does 10% unreachability sound good? How do the customers you put onto that address space feel about not being able to reach (at least many parts of) the rest of the 'net?
Remember, I was not able to find any case that successfully worked;
Your investigation showed that the software appears to have an extra line of code here and there which explicitly disallows 240/4 addresses. This is easy for vendors to fix.
When the vendor still exists, and the user is willing to upgrade, and the user actually does upgrade, but in many cases, that's not true.
But we could cop out on releasing 240/4 because it's just too much work for a small benefit to a few sites on the Internet, at a huge cost to the rest of the Internet. That's not fair.
It is a trivial amount of work for the IETF to release the address space and for ARIN to add an extra question to their allocation forms "Do you want 240/4 addresses?". As for fixing code, given the level of code patching that is already done on a regular basis, removing the 240/4 blockages could also be considered a trivial level of effort. After that, it is not a public problem any more, and those of us who do not want or need 240/4 addresses can ignore it.
Yes, but then when you get allocated space out of 240/4, what's going to happen is that one of your customers is going to try to reach my web site, and when your customer contacts you, you're going to tell them that I'm broken, because heaven knows it's not your problem . So then I get to be called broken, and I'm coerced into doing something to upgrade services, or, worse, I have no idea because I'm just a guy running a web site, and therefore I don't (or maybe even can't) do anything.
I'm fine with that, especially since it appears that implementing "IPv4-240+" will incur even more serious money for every participating network on the Internet, in upgrades, adminitrative time and effort, etc.
There are only two reasons that we would do such an upgrade.
Mmm.
First, if it is bundled up in a patch release with other stuff.
Oh. So, um, like, you're talking about Flag Day! Party like it's 1983?
And secondly if a customer requests it. The cost is effectively zero in the first case, and in the second case it will be covered by revenue.
That seems very self-centered. There's no cost to anyone else to have to make this work? Really? Because the minute the words "you have to patch" utter forth from your mouth telling me how I have to patch my stuff, that's taking time away from me, which I value in dollars.
We should do everything we can to remove roadblocks which would cause IPv4 to run out sooner,
Where practical. This ... isn't.
What is impractical with asking the IETF to revise an RFC?
Asking the IETF to revise an RFC is not impractical. Asking the IETF to revise an RFC, however, has no effect on the installed base. We have all kinds of RFC's out there for services that flopped and failed and no longer are in use anywhere. The existence of an RFC is fairly meaningless. The BEST RFC's document things that either currently /are/, or that /could be/, where we're trying to guide new creation. They don't try to /change/ the installed base in some radical way. Actually, though, I have a better solution. Let's ask the IETF to revise an RFC, and define the first octet of an IPv4 address as being from 0- 65535. That's asking the IETF to revise an RFC, too, such request being just as practical as what you suggest, and yet I'd say that the overall solution is just as likely to work well as IPv4-240+. It'd probably also solve the transition to IPv6 issue; we wouldn't need to.
What is impractical in asking ARIN to add a question to their forms just as they have already done for 32-bit AS numbers? What is impractical in asking vendors to remove the code blocks in their next patch release cycle?
Because it's not backwards compatible in the least, and it is a major distraction from making forward progress. You want this? Run it on your network. Have fun. Once you put it on the public Internet, it's not going to work. Have more juicy funness.
And this ... would cause some people to delay IPv6. So it's bad.
IPv6 is not a universal good.
No, but it's a path forward that doesn't rely on all of the badness we have today.
The Internet is far more complex with far more dark corners than you realize.
I'm not sure that's true. I'm aware of a *lot* of dark corners that have a *huge* amount of stuff and I can tell you that the *vast* *majority* of it will not be upgraded to handle IPv4-240+. That there may be more dark corners above and beyond the ones I am actually aware of is a fact that I'm also aware of; my inability to quantify all possible dark corners doesn't mean that there's some magic dark corner where all the dark corners I'm aware of will be transformed to be IPv4-240+ capable.
But for the owners of those dark corners it makes economic sense so why should anyone try and convert them to the one true Internet architecture?
Possibly because they want to be connected to it? Just a thought. If you want to be part of the community, it is probably a good idea to go along with the basic rules agreed upon by the community. If it makes economic sense for you to use IPv4-240+ internally, by all means, allocate and NAT it. I tried that just this morning. I'm sure that given enough hammering and patching, it could be made to work for some limited use, but it's going to require a significant amount of work. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.