</chair> >> The entire IPv6 header including the header chain SHOULD NOT exceed >> 256 octets. > > If you think about it, the whole point of extension headers is to help "the > network." If it was merely end-to-end information, whatever hosts send in the > EH could just as well be encoded as options in the application layer. If it > is really meant to be private, encrypt the whole thing, and show just the ESP > header. You really have to wonder why anyone would send complex chains of > extension headers that cannot be parsed by routers.
historical revisionism? ;-) I thought the invention of extension headers was there to strongly compel routers not to parse into the packet. a router does ECMP on the 5-tuple. the extension header chain doesn't help with that. a middlebox makes some policy decision on arbitrary bits in the packet (including L7). I'm not sure I see what help the middlebox gets from the extension header chain here? in my view there is no difference between the following cases: - 2nd fragment - extension header chain longer than first packet - unknown extension header - unknown L4 - ESP a firewall/filtering router with the policy of only allowing packets with known L4, will drop the packet in all the above cases. only fixing the extension header issue doesn't solve the "problem" (in quotation marks since I'm not sure we all agree there is one). what should we as the IETF do? we could accommodate our protocols to become more firewall friendly, e.g. deprecate IP layer fragmentation, deprecate extension headers (or limit their length). but, do we then also push the Internet further away from an open end to end capable Internet, stifle innovation in transport etc? cheers, Ole -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
