I think your description is somewhat biased, Paul. Suppose that you execute
Sure...I was making a point, not publishing a full analysis. But
my position did take into consideration everything you mention.
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
I agree with everything you say here about the difficulties
of NAT as a renumbering-avoidance mechanism. But I would
point out that these difficulties effect external connectivity
only, not internal connectivity. (The same external difficulties
also exist even if you do full renumbering, so the fact that
they also exist in the NAT case does not necessarily change my
assertion that NAT will be the path of least resistance for
net managers.)
For most net managers, intra-company connectivity is way more
important than external connectivity. Renumbering problems
effect intra-company connectivity, whereas NAT problems only
effect external connectivity.
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,
I also agree with the statements you make about the problems
of multihoming with NAT. You'll notice that I specifically
said "rudimentary form of multihoming". I considered going
into what that meant when I wrote it, but didn't want to water
down my main point. (Good communications sometimes necesitates
telling a biased and partial story.)
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.
I agree completely with what you say about needing to push
the multi-address complexity to the host. As you kindly
pointed out (and I self-servingly expand on here), this is
an architecture I put forth about a decade ago in a sigcomm
paper (in Zurich, I don't remember the year).
But that architecture (hosts having multiple addresses
representing a site's multiple aggregation prefixes and
selecting among them) requires some method of identifying
hosts when they switch from one address to another
mid-connection. I would assume that what people have in
mind for this are the mobility mechanisms? (The alternative
is 8+8 or some variant, which I understand to be contentious
enough that it is a defacto non-starter.)
PF