RE: The state of IPv6 multihoming development

[Iljitsch van Beijnum <iljitsch@muada.com>]

On Sat, 26 Oct 2002, Tony Li wrote:

> Unless I'm the one that's mistaken, the original complaint was that
> changing bits (and specifically -- the locator) at the border router
> would break applications that carry full addresses around in them.

How can this be a problem if the bits are changed back later?

> Ok, if apps (or the underlying transport) can use more than one address,
> then that implies that the host has to make a decision about WHICH address
> to use, which is what Craig was objecting to in the first place.  If the
> host has to decide, then it's making a routing decision and it certainly
> shouldn't have enough information to make that decision.

That's why it would be good if this functionality can be moved outside
the end host to a place where this information is available.

If this is done on the host, this host must select two addresses: the
source address and the destination address. If we assume the source
address must match the outgoing ISP, there are two ways to handle this:

1. The host selects a source address, and the routers choose the right
   ISP to match the source address.
2. The host selects a source address, and the routers don't care and
   route as per the destination address so the packet is filtered if the
   host selected the "wrong" source address.

1. would seem to provide better functionality. However, if the ISP the
host implicitly selects by its choice of source address is unable to
deliver the packet, the host must jump to another source address, just
like it should if it selects the wrong source address in the case of 2.
So for the host, the solutions are really equivalent and the choice
should depend on the needs of the routers rather than the needs of the
host.

Then there is the destination address. If all destination addresses are
routed/routable over the same ISP (which would alway be the case in
source address handling mechanism 1. and a good percentage of the time
in mechanism 2.) the host has no reason to prefer one over the other, so
if the other end requests the use of another destination address, there
is no reason to deny this request. Note that in the presence of source
address mechanism 1. you'd have four rather than two functional paths in
the following topology:

    A---C
   / \ / \
src   +   dst
   \ / \ /
    B---D

src -> A -> C -> dst
src -> A -> D -> dst
src -> B -> C -> dst
src -> B -> D -> dst

can all be used.

> Thus, the suggestion is to push the decision to the border router and
> move the policy information there.  The host still specifies the end
> system identifier, but the border router then determines the locator.

That would be one way to do it. The (border) router could also
communicate its preferences back to the host. Either by dropping enough
packets to force a rehoming event, or by sending back a message or
some such. The host could set the router alert option for the negotation
packets and the router could inspect these and let its preferences be
known.