What is multihoming was (design of a real routing v. endpoint id seperation)

Tue Oct 25 08:06:15 UTC 2005

On Mon, 24 Oct 2005, Owen DeLong wrote:

> Yes... The network is still multihomed, but, instead of using routing to
> handle the source/dest addr. selection, it is managed at each end host
> independent of the routers.  The routers function sort of like the
> network is single homed.  It's very convoluted.

That is to say the least. Offices who want to be multihomed would want
to do it once for all the computers there using one device like they
now can do with a router. Web farms would similarly want to do it for 
all the servers there again as they now do with one router or 
load-balancer, etc. Managing it if multihoming is entirely host-based 
would be hard (I note that for office multihoming you could potentially 
create one router that would do shim6 on its out interfaces and would do
NAT between that and its inside network - but we don't want NAT for ipv6 
if I understand IETF and IAB direction).

So while I really do think that we need some-kind of multi6 design which 
works for small multi-homing networks without need for them to have to
use ASN and have their routes in global BGP table (leaving all that
primarily to NSPs with /32 and larger as IETF envisioned), the current
shim6 design does not seem properly done to be usable for that audience
and as somebody noticed yesterday it would instead be great for multi-dsl 
users, especially gamers and p2p.

Now if we resurrected A6 with its ability to separately enter ip address 
with host and network parts at the dns level - then we're at least part 
the way done as far as multi6 multi-homing setup in dns for entire network 
at once. But I still don't see easy way to do it for the device management
and yet another new protocol would probably be needed for automatic 
assignment of locators and secondary ipv6 addresses (BTW - did I hear 
right that there is going to be new WG related to MIP6 to work out issues 
of assignment and using of multiple ipv6 addresses and interfaces - IETF 
seems to be doing lots of things in parallel at this potential L3.5 layer 
that could be done lot better together as part of proper TCP/IP redesign).

---
William Leibzon
Elan Networks
william at elan.net