|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: 240/4
Okay, this has descended to a point where we need some fact injection. This very morning, I have done some simple research. My research focused on the question, "what if 240/4 were released for use on the public Internet." I am not interested in the question of "what if 240/4 were released for RFC1918 use behind NAT devices," though implementors may find some of the same problems that I did. I attempted(!) to configure: Windows XP FreeBSD 4 FreeBSD 6 Mandriva Linux for use with 240/4 on a standard Ethernet interface. Both Windows XP and Mandriva Linux refused to accept 240 as a valid first octet. Both FreeBSD 4 and FreeBSD 6 accepted the 240 address, but would not put traffic on the wire, and did not answer a local ping of the address (i.e. "ping 240.0.0.2" on the box with 240.0.0.2). I use a FreeBSD based router here at the house, and I had configured it as 240.0.0.1. It does not answer a local ping for 240.0.0.1. However, from a directly connected client on a normally addressed IP network, I am actually able to ping 240.0.0.1: % ping 240.0.0.1 PING 240.0.0.1 (240.0.0.1): 56 data bytes 64 bytes from 240.0.0.1: icmp_seq=0 ttl=64 time=0.371 ms 64 bytes from 240.0.0.1: icmp_seq=1 ttl=64 time=0.379 ms 64 bytes from 240.0.0.1: icmp_seq=2 ttl=64 time=0.445 ms 64 bytes from 240.0.0.1: icmp_seq=3 ttl=64 time=0.255 ms ^C --- 240.0.0.1 ping statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.255/0.363/0.445/0.068 ms However, pings for 240.0.0.2 do not result in any traffic on the 240.0.0.* wire. Quagga did not seem to be interested in propagating the route to the other router, though I did not bother to investigate this. Looking to this bright point of success, I proceeded to ask Windows XP to ping 240.0.0.1, hoping that perhaps it would be acceptable as a destination. Windows XP responded with "Destination specified is invalid." I then tried with the Mandriva, which responded with "connect: Invalid argument." So. We can draw some interesting and useful conclusions. A number of major client and server operating systems do not currently work with "IPv4-240+". It is certainly possible to make any given major client or server operating system work with "IPv4-240+", but doing so only fixes one endpoint. The Internet works because there's a general property that any node can talk to any other node. Introducing nodes that can only talk to other nodes with shiny new IP stacks introduces a problem similar to the transition to IPv6, except that the transition to IPv6 is at least a fairly obvious and readily- identifiable issue. If you ask someone "do you support IPv6", it's pretty easy to know. If you ask someone "do you support IPv4-240+", that's less easy to know. Getting all nodes to upgrade to "IPv4-240+" is simply not possible. I have no idea where I'd get the upgrade for the Ascend GRF's (okay, well, they're not in production, but point remains). The ROI on the move to v6 is immense compared to the ROI on the move to v4-240+, which will surely only benefit a few. Do the math. This is stupid. If you happen to have all WinXP clients, a patch to make 240 work, and you stick them all behind NAT, well, golly, by all means, have fun. > > the other point as was mentioned later in the thread is that > > this buys you very little in terms of time before v4 is gone. > > On average, it buys everybody very little time. But that assumes that > 240/4 is being released as a general solution for everybody. > > This is not the case. We want to release 240/4 as a solution for those > organizations that are in a position to control enough variables to make > it useful. For those organizations, 240/4 space could buy a LOT of time, > maybe even years. And for the rest of us, the IPv4 addresses that are > NOT used by those organizations, do indeed buy only a little extra time. The problem is that it's not useful space if it can't talk to most of the Internet. And if you're proposing it as NAT space, then it isn't really relevant if the space is "released" or not. Just use it. It's a virtual certainty that Class E space will never find some new magic use. > But the point is that we are not gods. We cannot foresee all the > variables. Yeah, well, maybe YOU can't, but *I* can see enough of the variables to reliably predict a "doomed to failure." I don't need to see all the variables. > 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? Great. > Therefore, even if 240/4 only gives us a few extra months > before IPv4 is exhausted, it is still worthwhile because it is likely to > help some more organizations get their IPv6 transition completed before > hitting the brick wall. So, what's your game plan to replace all these broken IPv4 stacks? > Since the value of the Internet, IPv4 or IPv6, > is in the near universality of access, it is to the benefit of > everyone's bottom line for more organizations to complete the transition > to IPv6 before IPv4 runs out. Certainly. So why would we distract them with an intermediate transition to "IPv4-240+"? Remember, I was not able to find any case that successfully worked; even if there are some cases that work without patching, it seems that the vast majority of sites will need to change to move from IPv4 to your transition "IPv4-240+". > We cannot cop out on releasing 240/4 just because it is no magic bullet. 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. > How would you feel if your arguments against 240/4 and other > half-measures resulted in them not being carried out. And then we hit > the brick wall of IPv4 exhaustion and some businesses start to lose > serious money? 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. > --Michael Dillon > > P.S. and how will you feel if those businesses trawl the record on the > Internet to discover that you, and employee of one of their competitors, > caused 240/4 to not be released and thereby harmed their businesses. You > will be explaining in front of a judge. Whatever. I can sue you for having blue skin. Doesn't make me right, and doesn't mean I'll win. I could even sue you for releasing 240/4 and causing me economic harm by forcing me to upgrade a bunch of infrastructure. Funny how that blade can cut both ways. > We should do everything we can to remove roadblocks which would cause > IPv4 to run out sooner, Where practical. This ... isn't. > or would cause some people to delay IPv6 deployment. And this ... would cause some people to delay IPv6. So it's bad. Hey, I have an idea, how about we recycle all that dead air up in 224/4? ... 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.
|