RE: The state of IPv6 multihoming development

["Hesham Soliman (EAB)" <hesham.soliman@era.ericsson.se>]

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

=> Current MIPv6 mechanisms _will_ support a multihomed/
multiaddressed hosts. However, they will not give you a 
seamless switch from one path to another when one of the 
paths fail. The host will somehow need to be explicitly 
notified that it should choose a new CoA. So this will 
interrupt (but need not break) ongoing connections. 

Note that the _only_ reason for this is security. The 
MIPv6 mechanisms can easily be reused or extended to allow
for a near-seamless (very small packet loss due to link
failures) interface/address switching. 

How much interruption is acceptable? The interruption
I'm talking about is the time it takes to send an ICMP
error message (from the edge of the enterprise network) 
to a host. Not much.

Hesham



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
  > >   architecture that assigns addresses automatically, 
  > based on actual
  > >   connectivity topology.
  > 
  > 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)
  > 
  >