North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: 240/4

  • From: Joe Greco
  • Date: Thu Oct 18 10:54:16 2007

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

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

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" on the box with

I use a FreeBSD based router here at the house, and I had configured it
as  It does not answer a local ping for  However,
from a directly connected client on a normally addressed IP network, I
am actually able to ping

% ping
PING ( 56 data bytes
64 bytes from icmp_seq=0 ttl=64 time=0.371 ms
64 bytes from icmp_seq=1 ttl=64 time=0.379 ms
64 bytes from icmp_seq=2 ttl=64 time=0.445 ms
64 bytes from icmp_seq=3 ttl=64 time=0.255 ms
--- 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 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 

Looking to this bright point of success, I proceeded to ask Windows XP
to ping, hoping that perhaps it would be acceptable as a
destination.  Windows XP responded with "Destination specified is 

I then tried with the Mandriva, which responded with "connect: Invalid

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

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

> 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?

> 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 - Network Services - Milwaukee, WI -
"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.