On Tue, 25 Apr 2000, J. Noel Chiappa wrote:
> > From: Brian Lloyd <[EMAIL PROTECTED]>
>
> I was thinking about your message, and something from my exchanges
> with Keith Moore suddenly popped into my head with great clarity. I
> think it's the answer to your question immediately below - and it has
> some very grave consequences.
>
> ...
>
> > whatever happened to IPv6? 128 bit addresses would certainly allow us
> > to continue using IP addresses as endpoint identifiers thus eliminating
> > the need for NAT. It seems that this is a more reasonable solution than
> > trying to make NAT work under all circumstances.
>
> The basic key *architectural* problem with NAT (as opposed to all the
> mechanical problems like encrypted checksums, etc, some of which can
> be solved with variant mechanisms like RSIP), as made clear by Keith's
> comments, is that when you have a small number of external addresses
> being shared by a larger number of hosts behind some sort of
> "address-sharing" device, there's no permanent association between an
> address and a host. It's *that* that causes many of the worst problems
> - problems for which there *is* no good work-around (because the
> problem is fundamental in nature).
Right. NAT, or any other technology that breaks the static relationship
between identifiers and the hosts they identify, is basically flawed.
You can never again count on the address/identifier as a means to identify
a given host. I saw that one coming back in '92 and managed to scrounge a
class-B for my little grassroots ISP so that I wouldn't have to deal with
that problem nor would my customers. I am sooooo glad I did that. It is
still paying dividends to me today.
> Now, if you have a site which has more hosts than it can get external
> IPv4 addresses for, then as long as there are considerable numbers of
> IPv4 hosts a site needs to interoperate with, *deploying IPv6
> internally to the site does the site basically no good at all*. Why?
That seems obvious to me. IPv6 over IPv4 is NAT all over again. Once
again you are trying to cram 100 kg of routing drek into a 5 kg bag.
> Because for interactions with those external IPv4 hosts (who will be
> the vast majority of the hosts one wants to talk to, in the initial
> stages of deployment), *you have exactly the same architectural
> problem*. No matter what IPv6<->IPv4 interoperability mechanism you
> use, you still have that same *fundamental* problem - no permanent
> association between a host and an address (in this case, the IPv4
> address that it *has* to use to communicate with an IPv4-only host).
Right. But it is safe to go the other way ... oops, no it's not. I still
have only 32 bits locally to identify all those remote hosts. Sure I can
give every local host a virtual IPv6 address by making the 'v4 address the
low order 32 bits of the 'v6 address but that doesn't help my local host
find a remote host across the 'v6 network.
But it does seem that we could begin deploying 'v6 in the backbone
piecemeal while leaving the high order 96 bits zero'd out. Sun, Linux,
MacOS, and Win-whatever add IPv6 to their stacks as part of their ongoing
upgrade and you have the means for a relatively peaceful transition.
> When one looks at the overall business/economic case for deploying
> IPv6, in the light of this, the results are fairly devastating - and
> explain perfectly what we've been seeing for the last couple of years
> (rapid increase in the number of NAT boxes, and basically no traction
> for IPv6).
There are hard decisions to be made. You can begin do it now for $$$ or
you can do it later for $$$$$$. What is the future cost and what is the
future value of money? It seems to me that the business folk can
understand that equation.
> A site considering deploying IPv6 is in one of two cases: it already
> has enough IPv4 addresses, or it doesn't. In the foremer case, what's
> the upside to deploying IPv6? Autoconfiguration, etc aren't enough to
> outweigh all the costs of switching (to software which is less
> available, less tested, less tuned, etc).
It may be cheaper to deploy IPv6 now because I don't have as many hosts
now as I will have to convert in the future.
> In the latter case, it's equally as bad: they are going to have to
> struggle with the problems inherent in IPv4-address-sharing technology
> whether they go with IPv6 or not, and again, the remaining advantages
> of IPv6 (autoconfig, etc) are outweighed by the costs.
>
> I'm still sorting through the implications from this, trying to put
> them all with equal clarity, but one thing that does seem clear is
> that this kind of upgrade model is economically unworkable in the
> current large-scale Internet. Exactly what will work is something that
> needs to be pondered for a while.
What works is a function of the motivation of the people involved. What I
am about to say will undoubtedly violate the libertarian and anarchistic
bent of most of the people I have known who are involved with the IETF
(myself included). That said, sometimes government intervention can be
useful. If 'v6 is legally mandated, it will get done. This approach has
driven the development of more efficient and cleaner automobiles. This
has driven a cleaner environment. Moving from IPv4 to IPv6 has all the
flavor of an EPA clean-up effort. It is expensive, nasty work that
doesn't buy you anything in the short run but it may keep your progeny
from dying in a generation.
> One possible lesson is that we need think about how any new stuff is
> going to make peoples lives significantly easier overall as soon as
> they start to deploy it, because without that, probably very little is
> going to get done.
Sometimes you just have to do something whether it is easy or not. As I
said, the endpoint problem will solve itself in time if IPv6 is an itegral
part of Solaris, Linux, MacOS, and Win-whatever. People eventually
upgrade their hardware and their operating software. They already pay to
do that whether or not IPv6 is in there, hence my comment about M$
possibly making this easier. (Gawd, I can't believe that I, a rabid
M$-phobe, am saying this.) Likewise, if Cisco makes IPv6 an integral part
of IOS, the other router mfgrs will follow suit because they want to be
competitive. The key point is that the money for upgrading is already
there, we just have to "hide the hat" and see to it that IPv6 is part of
that upgrade. Once that happens all the pieces are in place to do the
transition. The only question is how to handle coexistance of IPv4 and
IPv6. The transition plan is really, really important.
I don't know about you but I just can't see applying band-aids forever.
We can apply the efforts of the many bright people of this group to
solving the problem or we can fragment and continue to work on band-aids
until band-aids no longer work and the cost of transition is astronomical.
But I remember that old saying, "There is never time or money to do it
right, but there is always time and money to do it over." I think I will
go out and ride the horses for a bit and then go flying. That brings me
comfort and pleasure where watching people perpetuate stupidity does not.
Whether or not this gets done right now or later, it will eventually get
done, and my email will manage to get through somehow.
Brian Lloyd
[EMAIL PROTECTED]
+1.530.676.6513
