[82135] in North American Network Operators' Group
Re: mh (RE: OMB: IPv6 by June 2008)
daemon@ATHENA.MIT.EDU (David Andersen)
Fri Jul 8 16:01:39 2005
In-Reply-To: <59A442ECD83D0F408ECEA3A84D3AE2EC03090B90@bre2k26p>
Cc: "NANOG list" <nanog@merit.edu>, "Joe Abley" <jabley@isc.org>
From: David Andersen <dga+@cs.cmu.edu>
Date: Thu, 7 Jul 2005 13:22:16 -0400
To: "Kuhtz, Christian" <christian.kuhtz@bellsouth.com>
Errors-To: owner-nanog@merit.edu
On Jul 7, 2005, at 1:09 PM, Kuhtz, Christian wrote:
>> As an easy-to-read overview of the shim6 approach, the following
>> rough draft may be useful:
>>
>> http://www.ietf.org/internet-drafts/draft-ietf-shim6-arch-00.txt
>>
>
> Thanks, I'm fully aware of where shim6 is right now. I'm asking if
> anyone feels this is headed anywhere useful or if we got anything else
> we can use to facilitate mh.
>
> To me, this is still a glaring hole as it has been for years now and
> nobody seems to be making any fundamental progress here. Partially
> probably because the deck seems to be fundamentally stacked against mh,
> which doesn't appear to have been a design criteria in the first place.
I've been poking around with end-host / end-network multihoming at the
transport and application layers. See, e.g., MONET, a multi-homed Web
proxy designed to achieve high availability:
http://nms.lcs.mit.edu/ron/ronweb/
In general, this kind of end-host informed multihoming has a lot of
potential for improving availability and performance (because the
end-points actually see what they're getting), but at the cost of some
extra implementation complexity. The shim6 mechanism (in the general
sense, not speaking to the specifics of shim6 negotiation, etc.), when
augmented with some end-host smarts, could be a nice way to do end-host
based multihoming in the ipv6 context.
-Dave
