Keith Moore writes:
> 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.
Well, that's what I'm trying to tease apart
here: what's tractible, and what's intractible.
If the entire problem space is intractible,
then we probably have some pretty big problems.
It's not clear to me that it is though... read on.
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.
I'd say it's the stack, (for MIP at least) but
that's a small point.
As for
"multihoming" - these days people mean different things when they say
that, so I can't tell for sure what you mean.
Nothing exciting: two different interfaces, two
different prefixes.
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.
Correct. Naively, when you're, say, starting a TCP
connection from a mobile node, if one of your
prefixes is bound to a tunnel (eg, a home agent),
you'd almost certainly like to use a CoA prefix
instead... unless you think you might move, and
the router which owns CoA prefix can't be a home
agent for whatever reason.
So it appears that even this fairly simple bit of
policy: "Use CoA prefix on outbound TCP
connections" isn't quite as simple as it first
appears. How on earth do I know if I might move?
Thus, it sort of reduces to "only if the current
router will support mobility in case I move", or
"I'm willing to deal with a loss of connectivity
on some sessions". But, this still seems to not
rely on anything extra about the prefix itself
other than what we already know.
I think that a similar argument can be made for
renumbering. That is, we can finesse the issue
such that end hosts don't have to know any sort of
qualities about the prefix other than either what
it currently knows, or what a real router told it
to believe (eg, the preference).
So I get back to my larger point: is the real
devil here hosts trying to know policy information
about prefixes that we currently have no way (or
desire) to spread around? I mean, I've always
thought that that was a pretty basic part of the
internet architecture, which is one of the reasons
I don't like the implications of scoped addresses.
Abandoning that philosophy pretty much says there
is no practical difference between a host and a
router.
Mike