> Tom Taylor <mailto:tom.taylor.s...@gmail.com> > 14 June 2013 17:06 > > Best answer I can see is that the limit applies except for routers > supporting specific features. Corollary is that not all routers will > do so, and people defining such features should be aware of that. > > Tom Taylor > Ray Hunter <mailto:v6...@globis.net> > 14 June 2013 16:21 > FWIW I agree. > > But what would a standard limit of 256 octets on the header chain mean > if one single option can be as long as the limit for the entire header > chain? > Is the limit only applicable across AS boundaries? On high speed devices > only? YMMV? > > regards, > RayH > Tom Taylor <mailto:tom.taylor.s...@gmail.com> > 14 June 2013 15:58 > On 14/06/2013 9:25 AM, Ray Hunter wrote: >> > ... > >> I've been trawling through various standards trying to identify sane >> extension header combinations myself. >> >> I've come across a couple of problematic standardised options already >> defined that don't appear to have individual length limits below the >> overall generic limit of 256 octets per option (derived from the "Opt >> Data Len" field being 1 octet), so limiting the overall header length to >> 256 octets could have direct impact on those. >> >> PadN (of course) >> >> The lineID option rfc6788. >> >> The Routing Protocol for Low-Power and Lossy Networks (RPL) Option >> rfc6553 >> >> regards, >> RayH > ... > > Neither of these should appear outside of limited domains. The Line > Identification option passes from the Access Node in a broadband > deployment to the edge router (BNG) and goes no further. The RPL > option is used only inside of RPL networks. > > Tom Taylor > What about nested Generic Packet Tunneling in IPv6 [rfc2473]?
That'll add another 48 octets per nesting level. [fresh IPv6 tunnel header + destination options including IPv6 Tunnel Hop Limit] On the one hand I can see they'll be really useful, certainly during a transition period, to allow operators to bypass core devices that cannot cope with switching more complex header chains in hardware. On the other hand, their very ability to hide L4 headers and complex header chains will likely make them unlikely to survive traversing firewalls. regards, RayH -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
