Folks, I've volunteered to provide a detailed review of this document, in response to the 6man wg chairs' request.
Overall, I believe that this is a very useful document, and I support its publication as an RFC. However, I think it would be great if the technical comments below could be addressed before we ship it. *** Technical **** * Section 1: > Thus, new extension headers > could be introduced progressively, used only by hosts that have been > updated to create and interpret them. You should probably reference RFC6564 here. I believe it's an important piece that enables progressive introduction of new extension headers. * Section 1: > Unfortunately, experience has showed that as a result, > the network is not transparent to IPv6 extension headers. I'd probably rephrase this sentence. A firewall's goal is, for instance, to police packets. So that lack of "transparency" is actually a goal they have (whether we like it or not). * Section 1: > Unfortunately, because not all > IPv6 extension headers follow a uniform TLV format, this process is > clumsy and requires knowledge of each extension header's format. You should probably note that the upper-layer header might not even be there, and reference draft-ietf-6man-oversized-header-chain. * Section 1: > If they encounter an unrecognised extension header type, some > firewalls treat the packet as suspect and drop it. Unfortunately, it > is an established fact that several widely used firewalls do not > recognise some or all of the extension headers standardised since RFC > 2460. Is it that they don't recognize them? Or is it rather that they default to "drop packets with extension headers"? Or maybe that they are sloppy enough that they consider whatever follows the IPv6 header to be the "upper-layer header" (and hence a "pass tcp" wouldn't work as expected if the packet contains an extension header). * Section 1: > This applies in particular to firewalls > that attempt to inspect packets statelessly at very high speed, since > they cannot take the time to reassemble fragmented packets, > especially when under a denial of service attack. This would be a form of stateful inspection rather than stateless: a stateless firewall wouldn't try to reassemble a packet, since that requires state. * Section 1: > This will alleviate concerns > that stateless firewalls cannot handle a complete header chain as > required by the present document. The problem for stateless firewalls is two-fold: 1) Being able to find the upper-layer information -- this is addressed by draft-ietf-6man-oversized-header-chain 2) Being able to process the header chain with decent performance -- this one still needs to be addressed. * Section 2.1: > > Any forwarding node along an IPv6 packet's path, which forwards the > packet for any reason, SHOULD do so regardless of any extension > headers that are present, as required by RFC 2460. I find this particular requirement a bit troublesome. Truth is that many devices violate this requirement, and will always will. OTOH, the rest of the document is perfectly fine in this respect -- it acknowledges that some devices will look at the extension headers, and provides advice on what to do (e.g., "you should have an explicit policy regarding what to do with extension headers"). I guess I could live with a SHOULD (at least, it's not a "MUST") -- however, in the light of reality, I'd probably relax this requirement. * Section 2.1: > > The IPv6 Routing Header Types 0 and 1 have been deprecated and SHOULD > NOT be used. However, as specified in [RFC5095], this does not mean > that the IPv6 Routing Header can be unconditionally dropped by > forwarding nodes. I don't think you need the "SHOULD NOT" above - RFC5095 should be taking are of that. As an aside, and in the light of e.g. bringing HBH to the real world, I think that requiring nodes to inspect the contents of RHT0 is unrealistic. I would align this with the processing of HBH extension headers. And in doing so, this document should update RFC5095. * Section 4: > > This list excludes both type 59, No Next Header, [RFC2460], which is > not an extension header as such, and type 139, HIP, [RFC5201], which > is experimental. If RFC5201 specifies an extension header, why shouldn't it be listed in the registry? (Disclaimer: I haven't even looked at RFC5201... so I might be missing something). **** Nits **** * Section 1: > It has also been observed that certain firewalls do not even > handle all the extension headers standardised in RFC 2460, including > the fragment header [I-D.taylor-v6ops-fragdrop], causing fundamental > problems of connectivity. I'd probably s/connectivity/interoperability/ * Section 1: > It cannot be widely deployed, because > existing middleboxes will render large parts of the Internet opaque > to it. I'm not sure this conveys the information that those packets will be dropped. Maybe rephrase? Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: [email protected] PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
