Subject: Re: The state of IPv6 multihoming development

From: "J. Noel Chiappa" <[email-masked]>
Date: Wed, 23 Oct 2002 15:29:54 -0400

> From: "Craig A. Huegen" <[email-masked]>

    > Noel asked if I could suggest any other mechanisms. So far, all of the
    > multi-homing solutions I can think of that are implementable with
    > current code

I'd rather not get into the swamp of "current code only". Either way, I think
it's very useful to know what the technical alternatives are, and then you
can assess the entire cost/benefit balance of each (and yes, changing code is
a cost).

So, I'll ask again:

  there are a number of basically feasible paths you can take to support
  *widescale* multi-homing. ..
  First, you can use multiple connectivity-based addresses. .. Second, you
  can re-use a mobility mechanism. Third, you could use a radical addressing
  architecture that assigns addresses automatically, based on actual
  connectivity topology.

I've since remembered another, one that Dave Clark came up with in the early
80's (IIRC), which was "route fragments" - i.e. when you look someone up in
the DNS, you don't get back just an address, but also some partial source
routes which lead from something major (e.g. a large ISP which everyone will
have in their routing table) to the destination. There's an equivalent for
Map-Distribution based routing architectures.

Can you suggest any others (not including "let the routing do it")?

	Noel

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 23 Oct 2002 23:26:48 +0200 (CEST)

>   First, you can use multiple connectivity-based addresses. ..

Interesting choice of words... Currently, you can _have_ several
addresses, but it is extremely hard to actually _use_ them as the host
must essentially make routing decisions and IP hosts are not designed to
do this.

Obviously, this can be fixed, and it must be, in order for any "a host
has more than one address" solution to work. Making a host choose good
source and destination addresses at the start of a session should be
relatively easy (although not trivial), the trouble begins when these
have to be changed in mid-session.

> Second, you can re-use a mobility mechanism.

This is nothing more than one variation on the above. Also note that
current mobility will not support multihoming in any way, it would just
be a starting point and we can borrow the header. There are also
other tunnelling or aliasing proposals that accomplish the same thing in
ways that may be more suitable for different types of networks. (i.e.
the host wouldn't do the tunnelling/aliasing itself but a box sitting
between the host and the routers takes care of this.)

> Third, you could use a radical addressing

This is also a variation on the multi-address family of solutions.

And don't forget four, address agile transport protocols.

Some other ideas:

5. geographical aggregation
6. encoding two prefixes in one address and steal a bit somewhere in the
   header to indicate which should be used for forwarding
7. source routing
8. identifier/locator seperation (like GSE)