Actually, if your assumption is that NATv6 is better than IPv6 with
renumbering, then IPv4 and NATv4 was good enough to start with and
I'm not prepared to say that NATv6 is better than IPv6+renumber,
simply because what is better depends on what is important to
the user. By some general architectural criteria IPv6+reunumber
is better, but I guess if pushed I would have to say that, for
a net manager with a limited budget, for whom internal connectivity
is far far more important than external connectivity, and with
some tricky mix of hosts and routers for instance, yes NATv6 is
"better".
I can easily imagine being a consultant and recommending to a
certain class of customers in certain situations that they use
NATv6. (Boy I may regret this sentence...its going to be used
against me someday... :-(
applications, operational and administrative costs, etc.). But if
NATv4 doesn't cut it, I don't see how NATv6 between IPv6 sites cuts it
either.
NATv4 doesn't cut it, but net managers use it anyway. NATv6 won't
cut it, but net managers may very well use it anyway.
I may be wrong...the motivations for using NATv6 will be weaker
than the motivations for using NATv4. But at the same time, the
problems with using NATv6 will be less than the problems with
using NATv4.
On the motivation side, NATv6 won't have the lack-of-addresses
problem. While this is the major motivation for NATv4, I don't
think it is the only motivation. On the problems side, NATv6
won't have the problems of port mapping or of having to dynamically
map lots of internal addresses into a small number of external
addresses.
I guess my assertion, to the extent that I'm making one at all,
is that one should take into account these least paths of
resistance when designing new protocols. This may mean not
designing the protocol you'd otherwise like to design if
practically speaking nobody is going to use it. Unfortunately
I'm not able to translate this vague assertion into any
concrete suggestion for IPv6 per se...
PF