Subject: RE: multi-homing vs multi-connecting

From: "Christian Huitema" <[email-masked]>
Date: Thu, 2 Jan 2003 10:37:40 -0800

>     > Other than adding the non-trivial problem of source address
> selection to
>     > the mix, I don't see that IPv6 changes things.
> 
> Classical IPv6 dosn't. That's a big part of its problems.

Depends what you call classical IPv6. If you throw in the support for
"binding update", then IPv6 does a reasonable job at "host
multi-homing", and I believe that we only need a limited amount of
additional work to support "small site multi-homing"; essentially, you
have to get around egress filtering.

On the other hand, I certainly agree with your assessment of the more
complexes forms of multi-homing, and the data explosion that occurs if
we want to have site connected to N providers also choose the path
through M upstream providers. But we must be aware that the problem here
is not just graph theory; there are also economic/business issues that
affect the willingness of downstream providers to let customers choose
an upstream path.

-- Christian Huitema

---

From: Pekka Nikander <[email-masked]>
Date: Fri, 03 Jan 2003 10:11:52 +0200

Christian Huitema wrote:
> multi-homing",

Well, depends what you mean with reasonable.  With the new
security design, mandated by the desire to make MIPv6 to work
without security infrastructure, MIPv6 always generates some
signalling load.  That is, if a host is away from home, it
must keep sending signalling packets to all its active peers
to maintain the mobility state.  By default the state must be
refreshed about every five minutes.

Furthermore, I don't quite find the requirement of having a
separate home agent, i.e. a piece of infrastructure, as a
reasonable design for multi-homing.

> and I believe that we only need a limited amount of

Another difficulty is associated with the home agents, too.  If
a home agent is unreachable, the mobile node also becomes unreachable
as soon as it needs to refresh the mobility state, i.e., in about
five minutes.  Thus, you can't simply put a home agent in the
"small site multi-homed" network, that just doesn't work if the
home agent becomes unreachable due to a link failure.

Thus, IMHO, the signalling load and the requirement of having the
home agent always on-line make MIPv6 not-quite-reasonable as a
end-host multi-homing or "small site multi-homing" solution.
But I agree that your milage may vary.

Taking a few steps back, it looks like the required security
*solutions* for host-multihoming and end-host mobility are
different as long as the identifiers and locators are *not*
separated.  That is, in the case of mobility there is one primary
identifier, the home address, and it must not be "stolen".  The
current active address (care-of address) is more ephemeral.

For end-host multi-homing, on the other hand, the multiple
addresses are more or less equal.  Thus, the right security
solution would be to make them interchangeable at the peer end,
and just to create a strong association between the alternative
addresses.  That is, the peer must know that these addresses
(identifiers) do belong to the same host.  There is no requirement
of "defending" one of the addresses for the case it becomes
unreachable.

The situation seems to change as soon as we separate identifiers
and locators.  It is no more so important what locators you use
right now, used in the past, or will use in the future, since you
are not identified by the locators.  Instead, you must be able
to show that you are entitled to "speak for" your identifier.
Thus, end-host mobility and end-host multi-homing become
more similar, at least from the security point of view.

--Pekka Nikander