|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical RE: mh (RE: OMB: IPv6 by June 2008)
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: [email protected] [mailto:[email protected]] 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
|