RE: mh (RE: OMB: IPv6 by June 2008)

["Tony Hain" <alh-ietf () tndh 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