RE: mh (RE: OMB: IPv6 by June 2008)
From: Joe Abley [mailto:jabley@isc.org] On 2005-07-07, at 10:10, Kuhtz, Christian wrote:
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
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
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. -- d/ Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net
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
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Dave Crocker Sent: Friday, July 08, 2005 4:12 AM To: Kuhtz, Christian Cc: Joe Abley; NANOG list Subject: Re: mh (RE: OMB: IPv6 by June 2008)
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.
--
d/
Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net
participants (4)
-
Dave Crocker -
David Andersen -
Kuhtz, Christian -
Tony Hain