> IMHO, those who think
> that hosts or apps should have to bear the burden of picking which
> address or interface to use in order to get packets to their
> destination need to explain (a) where the hosts or apps get the
> information necessary to make those choices in a reliable and
> timely fashion, and probably (b) how to provide a usable endpoint
> identifier under those conditions that can be passed between hosts
> at arbitrary locations.
It seems to me that what needs to be answered first is whether we are
already resigned to dealing with that problem with mobility,
renumbering, and multihoming.
If we're resigned to dealing with an intractable problem, maybe we need
to rethink that assumption. But it's not clear that either mobility or
renumbering presents the same kind of challenge. In the case of
mobility I think it's fairly simple to decide whether to use a home or
in-care-of address as the source address, and this can be dictated by
the application. In the case of renumbering then both old and new
prefixes should be valid for a considerable overlap period, which would
make the choice less critical except for apps that maintain
associations for a very long time (say, for several weeks). As for
"multihoming" - these days people mean different things when they say
that, so I can't tell for sure what you mean. But I think the
assumption that having multiple prefixes for a site and advertising
multiple addresses for hosts through DNS will provide sufficient
redundancy in network access to that site, across all or most
applications, is dubious at best.
There's good reason to want to use a
local prefix rather than mobile IP for new communiation if possible
since it more cleanly eliminates the dog leg through the home agent.
Taken in isolation, that's certainly true. But it presumes several
things, one of which is that a sending host can tell which of several
prefixes is the best to use. (or if not the best, which ones are more
likely to work well than others). It's easy to construct cases where
it's possible for the sending host to do this; somewhat more difficult
to construct a convincing argument that this can be done in general.
For instance, I spent some time investigating an idea which I'll call
"relative addresses" - the idea being that if source and destination
absolute/global addresses share enough bits of a common prefix the
sending host can assume they're on the same network, it can substitute
that many bits of "relative address prefix" for the global prefixes in
those addresses, the local network will route the traffic to the same
destination, and the addresses don't need to change when the network's
global prefix changes. The idea has some nice properties. In
particular, this is an optimization between hosts and the network -
applications can use it explicitly if they wish, but they don't have to
be aware of it to benefit from it. There's no need to advertise the
"relative addresses" in DNS or in referrals between apps because they
can automatically be inferred by hosts. And it would even work well
in conjunction with mobile IP-like mechanisms for forwarding and/or
redirecting traffic to PI prefixes - since local traffic would bypass
such mechanisms completely.
However - at least in its current incarnation, it doesn't work if a
network has multiple prefixes that aren't available to the same set of
hosts. In other words, just because a source and destination share *a*
common prefix doesn't mean that the conversion from absolute to relative
address is invertable - the substitution of a single common prefix
can create an address that is ambiguous even within the local site.
(But I'm still working on the idea...)
Ketih