| Well...  Not just addresses.  Since the reason for NAT is that there
| are too few "real" addresses in the first place, it also of necessity
| changes port numbers to create the many-to-few relationship.

Actually, NAT was there in the first place because of the observation
that very large organizations prevented most of the things inside
their organizational networks from communicating with the outside
world in the first place.   Thus, they could use RFC-1597/1918 address
space, and a NAT with an "outside" prefix just big enough to allow
one address per inside host allowed to talk to the rest of the world.

This is still a very common use of NAT, although judging by comments
here, the use of NAT-derived techniques to have multiple "inside" hosts
share a single "outside" address is growing more common.

I imagine that mixed-policy translating gateways are popping up too,
with inside things which really want a single stable address seeing
a simple pure 1:1 NAT, while ordinary workstations and the like by
default would share single addresses with each other.

| I've had my share of troubles
| because of such misdesign, for instance in trying to get Kerberos to
| work right on machines with several IP interfaces.

A "purist" design mindset sets in sometimes, and if things change
for whatever reason in the middle, the purist's assumptions cause
things to fail.   Multiple addresses per host is one example of
running into the "any host has just one IP address" purism of the
past.  This conflicts with IPv4-based hosts now, and probably with 
future IPv6-based hosts, too.

Designing applications on the "purist" assumptions of IPv4, or 
with a view to a transition _only_ to IPv6, is likely to cause 
the applications to break eventually.

	Sean.