Now consider the NATv6 alternative. The average net admin is already
comfortable with NAT at the ISP boundary (hell, some even like it).
She will already be running NAT, if for no other reason than to deal
with IPv4-IPv6 transition. NATv6 is much less onerous than NATv4,
because the address mapping is one to one (and in fact is probably
a simple prefix rewriting, not a large table lookup), not many to
one like with IPv4. What's more, NATv6 will give you some rudimentary
form of multihoming (can advertise different prefixes at different
ISPs)!
I think your description is somewhat biased, Paul. Suppose that you execute
the strategy you describe, and that the address 10.3.2.1, that was mapped to
129.87.64.32, gets transparently remapped to 130.123.45.67. It seems to me
that you are going to loose all existing TCP connections, just like with any
other form of renumbering. Suppose then that the external prefix of your
site, 129.87.64.0/25, was used in the firewall access control lists of your
business partners. Well, unless these partners somehow reprogram their
firewall, the packets sourced from 130.123.45.67 are not going to get
through. What? Numeric addresses in ACL is bad? Come on -- if none were
used, if we only used DNS names, then renumbering would not be the problem
that it is known to be! Besides, do you believe that using a NAT rather than
plain renumbering would make your external DNS records to upgrade any
sooner?
Suppose now that you want to use NAT for multihoming. Suppose then that I
really care that my TCP connection survives when I loose contact with ISP-A,
the one that provided me with the prefix 129.87.64.0/25. Can I just go on
routing the packets through ISP-B, that provides me with the address
130.123.45.0/25? Well, you can source them, but not receiving them, unless
you convince ISP-B to announce your other /25 prefix in its BGP tables --
just like the old fashion no-NAT multihoming. And then, how exactly do you
tell your customers that, among the two IP addresses of your web site, they
should really use 130.123.45.3, not 129.87.64.5?
Turn it any way you want, TCP sessions can only survive renumbering through
end to end mechanisms, in effect some form of TCP-NG, and effective
multihoming requires either a single address prefix supported by multiple
ISPs, or end to end smartness to pick the best of N addresses (hey, we could
use *your* work for that!) As Steve pointed out, trying to convince your ISP
to announce random non topological prefixes will get you laughed out of
court. There is, in fact, no alternative to end-to-end smartness -- the
smarter your end systems, the more likely they are to use the network
correctly. Now, if your systems are smart and now how to choose one of many
available addresses, then we have a solution with v6 multi-homing -- the
support of multiple prefixes per site, multiple addresses per interface.