RE: The state of IPv6 multihoming development

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

On Sun, 27 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?

> Why would they get changed back?

To avoid the above problem.  :-)

If the multihoming processing is done outside the host, then packets all
packets must be presented to the host with the identifiers as the source
and destinations addresses. If this is done inside the host then this
isn't strictly required, but it is likely the transport layer will want
to see just the identifiers so the IP layer will have to reconstitute
those.

> |   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.

> The host should select the identifier, both for itself and for the
> destination.  The border router selects the locators for both the
> source and the destination.  This allows the border router to implement
> policy in a reasonable way.

Agree. However, do we want to involve a border router in the locator
discovery process?

> One thing that we can do to speed the conversation is to
> first have the discussion at the architectural level.  Then we can
> worry about the mechanisms.

Ok, that should work as long as we don't run into any "that can't work"
"yes it can" arguments.

The basic idea is simple: the IP addresses the transport layer uses
become the identifiers of a session. In transit, these identifiers
may/must be replaced by locators, but they identifiers are restored
before the packet reaches the transport layer at the other end.

The idea is that identifiers are also valid "regular" IP addresses that
can be used whenever multi-address multihoming isn't supported by both
ends or otherwise not desired.

I think there is some rough consensus that this should be done at the IP
layer, but it's probably advantagious to include some way for transport
protocols to provide hints that a rehoming might be in order.

Making this functionality "portable" so it can be located either inside
the host, or at a border router or some intermediate device would
greatly help in easy deployment and makes it possible to better address
the needs to implement multihoming or traffic engineering policies and
address management in large networks.

Then there is the issue of locator discovery or negotion. Negotiation is
much simpler to do, but has the disadvantage the it can't occur a priori
so it doesn't protect against an unreachable identifier. However, this
could be solved by having several potential identifiers located at
different places in the topology. This does NOT imply the alternative
identifiers are also alternative locators. It may be necessary to have
some mechanism for IP to learn from the transport protocol whether the
negotiation data pertains to a valid session if negotiation is done at
the network layer.

Discovery is hard to do, but if we can solve the associated problems it
provides a much stronger mechanism because then a host can have a
single, portable identifier. It would be good if we could provide an
upgrade path from negotiation to discovery.

An interesting consequence of all this multi-address stuff is that a
range of addresses becoming unreachable is no longer a huge problem that
must be fixed immediately, but rather an inconvience that can be
tolerated for some time. This means routing protocols can become much
less dynamic. For instance, the mapping from address prefixes to AS
numbers can become very static. It could even be done out of band, and
the mapping could be stored on semi-permanent storage. This makes it
possible to include much stronger security mechanisms. Changes in
inter-AS connectivity can then be propagated throughout the network much
faster than they are now, and there is room to exchange much more
information that can be used to optimize inter-AS routing,
such as link-state mechanisms.

Iljitsch