Subject: RE: avoiding NAT with IPv6

From: Dan Lanciani <[email-masked]>
Date: Tue, 1 Apr 2003 18:01:51 -0500 (EST)

I've noticed a common theme in many of these anti-NAT dissertations: the
stupid NAT user is using NAT for stupid reasons and if we merely educate
him and/or force her to stop using NAT the world (and the particular user)
will be oh so much better off.

You will not eliminate NAT by repeatedly telling its users that they are
misguided idiots.

A new generation of NAT-hostile peer-to-peer applications is neither necessary
nor sufficient to eliminate NAT.  Many users couldn't care less about these
wonder-apps and for those who have a legitimate need, the market will provide
a NAT-friendly alternative.

MUST NOTs in RFCs are not going to stop NAT.

Eliminating NAT is actually very simple.  All you have to do is give users
that which by its lack drove them to use NAT in the first place:  plentiful,
free, stable address space.  I conclude from the effort that folks are putting
into discussing other (pointless) ways to mandate NAT away that they in fact
agree with my prediction that v6 ISPs will not magically change their business
models and offer such address space freely.  As long as address space and
stability remain profit centers, you will not be able to eliminate NAT.

|These enterprises apparently don't want/require/need global
|reachability for their hosts. Otherwise they would not NAT.

Is that really apparent?  They might be using NAT exactly because they want
global reachability for their hosts but cannot afford to rent enough global IP
addresses.  Or perhaps their ISP won't offer them additional global IP addresses
at any price.  Or perhaps they cannot cope with constant changes in the ISP's
dynamic addressing disrupting their internal connections.  Or perhaps they
simply want to be able to change ISPs without the extreme pain of renumbering.
Or perhaps they implement a poor-man's multi-homing solution to provide higher
availability (though not connection survival).

|IMHO the real solution to this and some other problems we
|are currently seeing in IPv6 is really one thing which
|must be solved before anything else: IPv6 Multihoming

I wouldn't count on this for much help.  The multi group was in effect
tasked with solving the multi-homing problem without solving the portable
identifier problem in general.  Even if they "fail" and are forced to solve
the portable identifier problem (assuming they solve anything) their solution
can easily be restricted to sites paying for connections to multiple ISPs.
In any case, don't you think it's a little late in the game to keep putting
off solving the problem in hopes that a solution will appear as a side-effect
of some other effort?  Especially when that effort is stalled?

|Another solution could be a good document outlining all
|the problems along with possible solutions when a network
|gets renumbered. IP renumbering isn't that much of a problem
|but renumbering the configuration items which contain IP's is.

So in other words, IP renumbering *is* that much of a problem...

				Dan Lanciani
				ddl@danlan.*com
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Eliot Lear <[email-masked]>
Date: Tue, 01 Apr 2003 16:03:07 -0800

> a NAT-friendly alternative.

The old generation is hard enough to support.  I think you missed the 
point of many of these folks; it's not that users are stupid, it's that 
tools are lacking.

Eliot

---

From: Michael Thomas <[email-masked]>
Date: Wed, 2 Apr 2003 09:27:47 -0800 (PST)

> stability remain profit centers, you will not be able to eliminate NAT.

Sure, but until then what does IETF do? There
seems to be a tacit game which is being played out
here which is "don't encourage NAT" which see-saws
between the architectural principles of the
NAT-less internet, and the reality of NAT's being
present. And NAT's will most likely exist going
forward primarily because we don't have any
assurance of stability of address space (eg
PI). There are some who would like to embrace NAT
as an architectural principle -- not necessarily
here, but they clearly exist -- some who hate
NAT's under any circumstance, and then many people
in the middle who don't like NAT's and the
implications of NAT's being an architectural
principle (like the Thou Shalt Consider Security
edicts from the IESG these days), but are more
pragmatic about their existence. As in, what
should we do to minimize the damage?

The deal I personally have made with this devil is
to realize that we're not going to stop their use
until all of the reasons you enumerate are
addressed, but in the mean time I'd assume we bide
our time and not throw in the towel on a NAT-free
world. What this pragmatically means is making
NAT's a poor a relation as possible so that we
aren't trapped in the quagmire of making it an
architectural principle which must be addressed
from the outset. It also means turning our back on
things that are obvious problems and often let
them get hacked on outside of the IETF context.

Thus, the fundamental argument going on here is:
how much do we allow ourselves to be sucked down
the this rathole? My opinion is "the less, the
better". Site locals will without any doubt in my
mind be primarily used as a replacement for net 10
address space -- all of the other purported uses
are marginal, redundant or false-secure. This is
why I think pointing would-be site-local people to
6to4/net 10's is probably a good compromise since
it shunts the problem off into legacy land, and
allows us to postpone having to make decisions
about the true implications of routing scope with
traditionally routing-dumb hosts.

This is obviously unsatisfying for those who would
like a more long term solution, but... well, we
ain't there. Until we've convinced ourselves we
really have no choice but to embrace NAT as an
architectural principle since we can't resolve
your laundry list of reasons people use them,
doing nothing -- or next to nothing -- looks like
a pretty reasonable option, IMHO. Taking the
*wrong* direction at this point could be extremely
harmful. Scoped addresses as have been pretty well
demonstrated take us down some pretty scary paths.
Let's not go there... yet.

		Mike

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 2 Apr 2003 10:16:45 -0800

Michael Thomas wrote:
> ... Scoped addresses as have been pretty well

This sums up the whole anti-SL campain, which is spread FUD based on one
technically valid point; applications can't arbitrarily pass around
topology information. Applications that insist on passing around
topology information must understand the topology they are describing.
If they don't understand it, they are broken. Trying to assert a
flat-earth will not make it happen. There will be filtering, therefore
there will be addresses with a limited scope of applicability. Scoped
addresses will exist with or without a dedicated prefix. Lack of a
well-known prefix only makes more work for the system manager to
manually configure devices. It will be a sad outcome for decades to come
if we trade off the one-time per app cost of a developer needing to deal
with a well-known prefix in favor of the continuous operational cost of
manual configuration.

Tony

---

From: Michael Thomas <[email-masked]>
Date: Wed, 2 Apr 2003 10:26:24 -0800 (PST)

Tony Hain writes:
 > This sums up the whole anti-SL campain, which is spread FUD [...]

   *plonk*

	Mike

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 03 Apr 2003 15:31:53 +0200

Tony, I don't much appreciate the subject field (although "avoiding NAT"
was indeed bogus). But I hear of daily operational costs caused
explicitly by ambiguous "private" addresses that suddenly stop
being private in reality - in other words, the notion of private
scope is itself bogus in the general case. We get rid of one
layer of problems if we get rid of the ambiguity built into
RFC 1918 and of SLs as currently defined.

Deprecating SL as currently defined is not a vote for the flat
earth theory.

   Brian