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