The 6man chairs asked me to make an additional detailed review of draft-ietf-6man-oversized-header-chain-06.
The main point of the draft is to point out the problems caused by fragmented header chains and to update RFC 2460 to require that the entire header chain is in the first fragment. This change is an incremental step towards reducing operational problems with IPv6 extension headers, so it's complementary to draft-ietf-6man-ext-transmit. It's also an incremental step towards reducing operational problems with IPv6 fragmentation. Since the rest of the fragmentation problem remains controversial, I think it's better to progress draft-ietf-6man-oversized-header-chain on its own ASAP. (We do have to be realistic though - none of these improvements will become widely deployed until many IPv6 stacks have gone through several release cycles.) IMHO this document is ready to progress, but I did find 3 minor issues and a nit. Issues: In the Introduction: > It should be noted that this requirement does not preclude the use of > e.g. IPv6 jumbo payloads but instead ... Firstly, RFC2675 says "The Jumbo Payload option must not be used in a packet that carries a Fragment header." Secondly using "e.g." as a noun is a bit ugly. I suggest: It should be noted that this requirement does not preclude the use of large payloads but instead ... In Terminology: > IPv6 Header Chain: > > The header chain contains an initial IPv6 header, zero or more > IPv6 extension headers, and optionally, a single upper-layer > header. If an upper-layer header is present, it terminates the > header chain. Maybe the "optionally" would be clearer if you also mentioned the "No Next Header" case by extending the last sentence If an upper-layer header is present, it terminates the header chain; otherwise the "No Next Header" value terminates it. I think it would be useful to mention somewhere (perhaps in Security Considerations) that stateless DPI may still cause problems. Something like: A firewall that performs stateless deep packet inspection, i.e., it examines application payload content, might still be unable to correctly process fragmented packets, even if the IPv6 header chain is not fragmented. Nit: The reference [IANA-PROTO] needs to be verified by IANA - what is their preferred URL for the registry? Regards Brian Carpenter -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
