Dan Lanciani writes:
> 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.
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
--------------------------------------------------------------------
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 PROTECTED]
--------------------------------------------------------------------
