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

From: "J. Noel Chiappa" <[email-masked]>
Date: Tue, 25 Apr 2000 12:55:32 -0400

> From: Brian Lloyd <[email-masked]>

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.

Although it's something which has basically been said before, I find this new
formulation makes the problem - and its implications - especially clear (and
so I hope everyone will take the time to read it - it's not long).

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

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?

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

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

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

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.

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.

	Noel

---

From: Matt Holdrege <[email-masked]>
Date: Tue, 25 Apr 2000 11:47:54 -0700

At 12:55 PM 4/25/00 -0400, J. Noel Chiappa wrote:
>the site basically no good at all*.

I think we've been through all this already and we explored it deeply at 
the IAB Network Layer Workshop. One of the conclusions is that an IPv6 
network NAT'ed to the IPv4 Internet isn't any better than what we have 
today with
IPv4-NAT-IPv4, yet it will allow the given network to move to IPv6 in hopes 
of someday connecting to other IPv6 networks without using NAT.

So if you are NAT'd to the public Internet today, you shouldn't have a 
problem with converting internally to IPv6. At least from an architectural 
sense. :)

---

From: Keith Moore <[email-masked]>
Date: Tue, 25 Apr 2000 15:05:27 -0400

> the site basically no good at all*. Why?

this sounds like a slight exaggeration, but I do think that the main 
incentive to deploy v6 will come from the need to communicate with global 
addresses to points *outside* of folks' internal networks.

it doesn't follow that deploying IPv6 internally to a site does no good
at all - it will of course do some good if the site has applications
on internal hosts that need to communicate with external hosts using 
global addresses.  and of course having v6 deployed internally would 
allow the site to run those same applications interally without any 
configuration changes.

but if you're trying to make the point that there's little purpose in
having your own IPv6 island - I think that's basically right.
 
Keith

---

From: Brian Lloyd <[email-masked]>
Date: Tue, 25 Apr 2000 13:23:43 -0700 (PDT)

On Tue, 25 Apr 2000, J. Noel Chiappa wrote:

> 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.
>
> ...
> 
> 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-masked]
+1.530.676.6513

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 25 Apr 2000 13:52:41 -0700

Hello Matt,

I probably shouldn't tread into these waters, but...

> of someday connecting to other IPv6 networks without using NAT.

The last sentence isn't internally self-consistent.  NATting from IPv6
to IPv4 creates the potential that you mention, and that is a benefit.
SO, it _is_ better.

If we get to a model where large new domains use IPv6 addressing
with NAT to global IPv4 address space, that would be quite useful.
Before too long, services will appear on the IPv6 network that
can't get the IPv4 global addresses they need.  IPv6 clients will
work at least as well as privately-addressed IPv4 clients, so that
there is no downside to going IPv6.  As this happens more and more,
the IPv6 domains will begin to dominate and interconnect efficiently.

Since the Internet continues to grow rapidly, today's dominant
deployment may well be tomorrow's sad legacy.  Or not, depending
on who knows what?

> problem with converting internally to IPv6. At least from an architectural

Indeed.  And, to re-use an old bit of wisdom: "You're either part of
the problem, or part of the solution".

Regards,
Charlie P.