From: Joe Abley [mailto:jabley@isc.org]
> Anyone here care to share operator perspectives shim6 and the
> like? Do
> we actually have anything that anyone considers workable (not
whether
> somebody can make it happen, but viable in a commercial
> environment) for
> mh?
There is no operational or implementation experience with shim6 at
this time, that I know of (the technical specifications for shim6 are
currently incomplete). The shim6 working group has its first meeting
in August in Paris, after which the goal is to progress quickly to a
set of specifications which can be implemented.
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.
Thanks,
Christian
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. 163
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
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.
a shim layer seems like a promising enhancement. ietf-shim6 is taking an approach to a shim layer that will, I suspect, take some time to mature. I'd be surprised if it saw significant deployment anytime within the next 5 years, at the earliest.
(a more ascerbic view would probably suggest that it is not even likely to produce a complete specification within that time, with deployment taking another 5 years...)
the effort is relying on IPv6 and on the disappearance of NATs, for v6. one might consider these to be critical dependencies that are rather risky.
Given that shim breaks fundamental assumptions about the stable relationship
between the packet header and the application context, there will be many
security related issues to be resolved after the shim spec stabilizes. Shim
is a 'more than a decade' effort if it ever completes.
The disappearance of NAT is not as bad as the FUD that keeps coming up. See:
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-nap-01.txt
and please send comments if some use of NAT is not covered.
As far as alternatives for multi-homing, the IESG has focused on shim and
denied a request for a bof in August to discuss interim options.
I submitted updates to the ID editor early last month but for some reason
they have not popped out yet, but I am always accepting comments on:
http://www.tndh.net/~tony/ietf/draft-hain-ipv6-pi-addr-08.txt
http://www.tndh.net/~tony/ietf/draft-hain-ipv6-pi-addr-use-08.txt
Like the approach or not, it is straight up existing BGP and existing host
stacks. It will never be the highly optimized 400 entry routing table, but
it doesn't pretend to be. It does however create PI space that has some hope
of aggregating.
Tony