> > 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.
|
ns.sol.net> wrote:
> 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.
Or simply ask IANA to open up 256/5. After all, this is just
an entry in a
table, should be easy to do, especially if it is done on Apr
1st. 
- Alain.