2012/3/28 Rémi Després <despres.r...@laposte.net> > > Le 2012-03-28 à 06:10, Satoru Matsushima a écrit : > > > FYI, section 5 of RFC5082 ( > http://tools.ietf.org/html/rfc5082#section-5.2) generalize a technique > that TTL is used to help tunnel packets security. Anyway, > > > > On 2012/03/27, at 14:02, Rémi Després wrote: > > > >> > >> Le 2012-03-27 à 13:12, Maoke a écrit : > >>> 2012/3/27 Rémi Després <despres.r...@laposte.net> > >>> With TTL transparency added, I don't see what would be missing, even > with all requirements you expressed. > >>> > >>> well, it is still uncertain how 4rd-u will do this. it is uncertain if > the new ad hoc complement doesn't introduce new problems. could we see it > by the end of IETF83? > >> > >> Sure. > >> basic ID: > >> - At domain entry, put TTL bit 0 as leftmost bit of the IPv6 hop count, > and bits 1-7 in the remaining space of the IPv6 packet ID. Put 127 in bits > 1-7 of the hop count. > >> - A exit, take bit 0 from the hop count, and bits 1-7 from the packet > ID. > >> > > > > Too much. Don't change deeply well understand/deployed semantics, PLEASE. > > Semantics isn't changed for any existing function. > CEs and BRs (the only ones to be concerned) use unused bits to convey some > IPv4 bits that need to be conveyed for e2e transparency. >
unfortunately the first bit of Hop Limit is NOT "unused" at all. please also pay attention the reference that others suggested. - maoke > No implementation or operational problem can result. > > If I missed a practical problem you have identified, sharing this > information would of course be useful. > > Thanks, > RD > > > > > > > > > >> The only constraint it introduces is that the longest IPv6 path within > the domain must not exceed 127 (something that AFAIK shouldn't be a problem) > >> OK? > > > > NO. > > > > cheers, > > --satoru > >
_______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
