...Which is why people use NAT's to do this...
Except that NATs don't do this, unless the only apps you care about are local apps. And experience indicates that users don't just care about local apps.
Keith, your mileage may, and probably does, differ. But, in many enterprise/organizational situations, and at least some home networking ones, communication among hosts on the local network is very important, perhaps equally important as communication with outside hosts. That is especially true in the enterprise "intranet" context, in which many users are, on a given day, likely to exclusively access internal web sites, directories, calendaring systems, etc. Those usage patterns are independent of whether the addresses are global but inaccessible from the outside due to filtering or firewall restrictions or whether they are "private" space with external connectivity, if any, going through a NAT.
Now, in the IPv6 "multiple addresses per host" model, it would make perfect sense to assign every host on such a subnet an address that was specific to that subnet (or enterprise) and, for those hosts that needed external accessibility, an additional, presumably globally-routable, address. If the subnet-specific address was appropriately obtained*, it could be completely independent of external providers and completely stable. That would confer some small, but non-trivial advantages over having a single set of addresses that are provider-dependent. Among other things, I can imagine several ways in which having one set of stable addresses that could be relied upon for local (intra-enterprise) host management would be a help in working through a provider-switch renumbering exercise (on the other address(es)).
Of course, none of this is dependent on whether those subnet-specific addresses are from a reserved "private" range rather than being unique addresses that no one intends to route outside the LAN (or enterprise/organization).
Of course, as soon as a given host has more than one address, at least some of the issues that Tony has been trying to describe become important: _something_ needs to figure out which one(s) to use, even if only by the trial and timeout process which, as you have pointed out, is much too slow (at least in the general case).
The irony is that in the architectural discussion phase (such as it was) of IPng, it was proposed that these two functions (location and identification) be split,
Lots of good ideas got passed over in the IPng discussion. Despite that, I think that IPv6 ended up "about right" - modulo a few warts like A6 and SL and over-reliance on address selection. By "about right" I mean that I think that if the warts are fixed it will become feasible to gracefully extend the IPv6 architecture in useful ways - such as to provide the capability to use identifiers rather than locators - without invalidating hosts or apps that were written to the basic IPv6 model.
Keith, I think I agree with you about the "despite that" part of the above (I certainly agree about the "passed over" part). However, if our confusion about how to best handle multiple addresses per host, and where to do so, results in our moving to a "one host, one address" model and a flat, IP-level, address space, I think some of the "graceful extension" potential will disappear. Indeed, if we go down that path --which I think you have been advocating, although I'm not sure-- I suspect that we had better have a general routing solution that is not dependent on address aggregation before we move much further forward with IPv6 deployment.
john
