Re: multi-homing vs multi-connecting

Christian Huitema wrote:
> 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",

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
> additional work to support "small site multi-homing"; essentially, you
> have to get around egress filtering.

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