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