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
[EMAIL PROTECTED]
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
