240/4

Mailman List Mirror (Read Only)
1

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

2

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.

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

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.

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.

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.

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.

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. First, if
it is bundled up in a patch release with other stuff. 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.

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

And this ... would cause some people to delay IPv6. So it's bad.

IPv6 is not a universal good. The Internet is far more complex with far
more dark corners than you realize. 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?

--Michael Dillon

3

Joe,

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.

I am told by people who have inside knowledge that one of the issues they are facing in deploying IPv6 is that an IPv6 stack + IPv4 stack have a larger memory footprint that IPv4 alone in devices that have essentially zero memory for code left (in fact, they're designed that way). Fixing devices so that they can accept 240/4 is a software fix that can be done with a binary patch and no additional memory. And there are a _lot_ of these devices.

Regards,
-drc

4

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.

step awaaaay from the crack pipe...

Joe's facts were excellent. I read his email and thought "wow, this will kill this thread for sure"

why on earth would you want to go and hack this stuff together, knowing that it WILL NEVER WORK

so, as using these IPs publically isnt feasible why bother privately. you may as well use RFC1918 or IPv6. the latter whilst not without issues is at least being rolled out as part of a series of standards that are 10+yrs old

i am really struggling with some of the logic being given here. more specifically the omissions in that logic are glaring.

not attempt to engineer a solution that will work for everybody

..

not our reponsibility to fix every problem out there

..

I believe that people are not that stupid.

..

We do not have a good reason to deny them that possibility.

..

This is easy for vendors to fix.

..

It is a trivial amount of work for the IETF to release the address space

..

removing the 240/4 blockages could also be considered a trivial level of effort.

..

those of us who do not want or need 240/4 addresses can ignore it.

..

The cost is effectively zero in the first case,

..

why should anyone try and convert them to the one true Internet architecture?

i think you are somewhat deluded.

Steve

5

I almost wrote a message similar to Joe's (actually did, and then canceled it). I think (realy hope) that there's a misunderstanding here about exactly what 240/4 space would be used for.

I think Michael's point is that it can be allocated as "unique space for internal use". i.e. kind of like 1918 space, but you know your slice of 240/4 is only used on your network[1]. For that purpose, it's fine, as long as you determine that all your gear allows it.

If anyone really thinks it can be announced into the global routing table and expected to function, I'm afraid they've swallowed the crack pipe so far down that this thread is pointless for them. Too many devices will never (can never[2]) be upgraded and are unlikely to go away in the forseeable future. You just can't expect 240/4 (regardless of how trivial the code change would be) to ever work as globally & reliably as people expect the internet to work.

I could see bits of 240/4 perhaps being of use to large cable companies for whom there just isn't enough 1918 space to address all their CPE gear...and/or they really want unique addressing so that if/when networks merge IP conflicts are avoided.

1) As much as this can ever be known...you can't stop random IP squatters from picking random IP space out of their hats for use as "private" networks behind NAT. Eventually, they realize some bit of the internet is unreachable...because it's their LAN. The various squatters using 1/8 and the other "not-yet-allocated" /8s will all get the rude awakenings they deserve in time.

2) Anyone care to guess how much network gear is deployed that either won't or can't be upgraded? i.e. Old cisco gear without the RAM and/or flash to handle a newer code train...the old one in use long since unsupported, or gear from vendors that no longer exist? As long as this stuff generally works, nobody's likely to replace it.

6

I do work for one of those "large cable companies" and no, 240/4 is not
useable for us either for the exact same reasons that you pointed out to
explain why 240/4 will not work in public space: there are just too many
devices that can't easily be upgraded.

   - Alain.

7

Alain,

Correct me if I’m wrong, but Comcast started moving to IPv6 addressing because they ran out of 10. space.

My 0.02: Hacking together IPv4 solutions involving retasking previously reserved address space simply delays the inevitable exhaustion of said address space.

-brandon

8

Absolutely. I made the point earlier, making 240/4 work is about the same
order of magnitude as moving to IPv6. Not worth it for us.

   - Alain.

9

Consider an auto company network. behind firewalls and having thousands and thousands of robots and other factory floor machines. Most of these have IPv4 stacks that barely function and would never function on IPv6. One company estimated that they needed 40 million addresses for this purpose.

  Cutler

10

why on earth would you want to go and hack this stuff together,
knowing that it WILL NEVER WORK

Because I have read reports from people whose technical expertise I
trust. They modified the TCP/IP code of Linux and FreeBSD and were able
to freely use 240/4 address space to communicate between machines. This
means that IT WILL WORK.

The reports stated that the code patch was simple because it involved
simply removing a line of code that disallowed 240/4 addresses.

This demonstrates that enabling 240/4 is a very simple technical issue.
The only real difficulty here is getting the right people to act on it.

Companies like Cisco don't even need to wait for the IETF in order to
implement a command like
   ip class-e
as long as they ship it with a default of
   no ip class-e

--Michael Dillon

11

Guys, this thread has gone over 50 posts, and doesn't seem to want to end.

By now, everyone has had a chance to advance their argument (at least
once), and we are just going in circles, increasing noise and not
contributing to signal.

I'd like to summarize arguments advanced - and if you don't have something
new (not listed here) to say, can you please avoid posting to this thread?

If you disagree with me, please take it to nanog-futures.

Summary of arguments:

In favor of experimental use only:
Alain Durand: at your own risk, this stuff can blow up your network

In favor of private use:
Randy Bush: if it works for you, why mark it experimental
Dillon: why shouldn't people use it if they can

In favor of no use at all:
Joe Greco: "it doesn't work now (today) on current-generation OSes, there
is no chance to get it to work in any shape of form by the time v4 space
is exhausted".
Steve Wilcox: "it will never work"

Mixed:
Daniel Senie: Allocate some as private, reserve rest as 'allocatable' once
vendors get the gear fixed to accomodate those who use as private

Additional points:
David Ulevitch: If it is ever designated rfc1918, it cannot ever become
public.

Many: It will buy us some time before v4 address space is
exhausted, and much less painful than v6 deployment

Many: Old gear cannot be v6-enabled, but it can be 240-enabled

Dillon: This is not our decision, this is IETF/IANA decision.

-alex [mlc chair]

12

I think Michael's point is that it can be allocated as
"unique space for internal use". i.e. kind of like 1918
space, but you know your slice of
240/4 is only used on your network[1]. For that purpose,
it's fine, as long as you determine that all your gear allows it.

Not quite. I don't want to see 240/4 space considered to be like RFC
1918 space in any way shape or form. I just want it available for use
between consenting partners which is why I suggest that the RIRs only
give it to people who ask for it.

Eventually I expect that some ISPs will support this due to customer
demand and because it isn't that hard to install the patches required in
routers. Anyone who doesn't want to support it need not do anything
because the packets will fall on the floor as soon as they hit a router
that doesn't support 240/4 addresses.

Depending on how the IPv6 transition pans out, there might be a day when
240/4 addressing is widely supported on the Internet. Or there might
not. I would just like to see the "reserved" status removed for 240/4
because it is no longer appropriate or necessary.

If anyone really thinks it can be announced into the global
routing table and expected to function, I'm afraid they've
swallowed the crack pipe so far down that this thread is
pointless for them. Too many devices will never (can
never[2]) be upgraded and are unlikely to go away in the
forseeable future.

Agreed. Routing between consenting networks is not the same as universal
routing (if that even exists anymore). Unfortunately, many people do not
understand that Internet connectivity is not an all-or-nothing
proposition. There are many extranets that function using only a small
group of certified ISPs, for instance.

I could see bits of 240/4 perhaps being of use to large cable
companies for whom there just isn't enough 1918 space to
address all their CPE gear...and/or they really want unique
addressing so that if/when networks merge IP conflicts are avoided.

I think that RFC 1918 exhaustion is a separate issue and can only be
solved by setting aside another /8 for RFC 1918 space. Either take 125/8
or else see if Softbank Japan is willing to allow 126/8 to be set aside
for that purpose.

1) As much as this can ever be known...you can't stop random
IP squatters from picking random IP space out of their hats
for use as "private"
networks behind NAT. Eventually, they realize some bit of
the internet is unreachable...because it's their LAN.

Not necessarily. In many cases they only want to reach a subnet of the
Internet so they never see the unreachability problem. Or they don't
route packets into or out of the public Internet and use split-horizon
DNS.

2) Anyone care to guess how much network gear is deployed
that either won't or can't be upgraded? i.e. Old cisco gear
without the RAM and/or flash to handle a newer code
train...the old one in use long since unsupported, or gear
from vendors that no longer exist? As long as this stuff
generally works, nobody's likely to replace it.

That's why we will see IPv4 in widespread use for at least the next 20
years.

--Michael Dillon

13

Actually, to do the job right, you have to change a handful of conditionals
in about five different files in the Linxux kernel: in.h (really just
cleanup to remove unused macros), devinet.c, fib_frontend.c, ipconfig.c,
and route.c.

Attached are the diffs for a 2.6 kernel (implemented and tested on an Ubuntu
7.04 system) and for a 2.4 kernel (implemented and tested on a Linksys
WRT45GL running OpenWRT whiterussian 0.9).

As mentioned in an earlier message, Mac OSX, at least the version that came
with a Powerbook G4 that I have, will accept a 240/4 address without any
modifications - I used it to test the Linux patches. There does appear to be
a one line change needed to FreeBSD and/or OSX for it to act as a router.

Have fun.

  --Vince

diff-2.6 (6.02 KB)

diff-2.4 (6.04 KB)

14

Did you all miss this post?

Thanks.

Alex Pilosov wroteth on 10/18/2007 3:26 PM: