ietf
[Top] [All Lists]

Re: draft-ietf-nat-protocol-complications-02.txt

2000-04-25 15:00:03
On Tue, 25 Apr 2000, J. Noel Chiappa wrote:

    > From: Brian Lloyd <brian(_at_)lloyd(_dot_)com>

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
brian(_at_)lloyd(_dot_)com
+1.530.676.6513