I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Draft draft-ietf-6man-ext-transmit-03 describes some of the problems of deployment of new IPv6 extension header types. It updates RFC 2460 and RFC 2780 to clarify how extension headers, particularly unrecognized extension headers, should be treated by intermediate nodes. It also creates a new IANA registry for extension headers. The security considerations section discusses mandated behavior for firewalls in particular, but without explaining the security implications of that mandated behavior. The section also mentions the possibility of exercising previously unused code paths and slow deployment. Section 1 and 2.1 do a better job of describing the potential safety problem of accepting unknown extenstion header types and the connectivity problem of dropping them. RFC 4727 security considerations section speaks of the security concerns of experimental values that would apply to unrecognized extension headers as well. RFC6564 mentions the potential for a covert channel through forwarded unrecognized extension headers. The security considerations section here would be improved by using or referring to those sorts of discussions. Aside from the security considerations section, I puzzled over many parts of this document. I am not an IPv6 implementers (or of anything else), but I believe that some of the language would be ambiguous in implementing this draft. standardized vs standard vs experimental ---------------------------------------- The draft text says "standardized" in many places where it appears it means "published in an IETF specification", and in other places where it appears it means "an extension header defined as a standard". Sometimes "standardized" and "experimental" seem to be mutually exclusive. Sometimes "experimental" seems to be one of the set of "standardized' extensions. That language should be cleared up. I read this presuming that "standard/standardized" and "experimental" mean "defined in an IETF Standards Track RFC" and "defined in an IETF Experimental RFC". That should be clearer. "by default" and "configuration" and "policy" -------------------------------------------- Section 2.1 says: I found the text concerning configuration of policy to discard unrecognize extensions and default behavior to be unclear: The section starts with: Exceptionally, if this node is designed to examine extension headers for any reason, such as firewalling, it MUST recognise and deal appropriately with all standardised IPv6 extension header types and then RFC 2460 requires destination hosts to discard packets containing unrecognised extension headers. However, intermediate forwarding nodes SHOULD NOT do this by default, and then Experimental IPv6 extension headers, including types 253 and 254 defined by [RFC3692] and [RFC4727], SHOULD be treated in the same way as standardised extension headers, but they MAY be dropped by default. The text "SHOULD NOT do this by default" and "MAY be dropped by default" sound inconsistent to me. The text goes on to say: Forwarding nodes MUST be configurable to allow packets containing unrecognised extension headers, but such packets MAY be dropped by default. The text "SHOULD NOT do this by default" and "MAY be dropped by default" sound inconsistent to me. I'm not clear of the intent. The first paragraph above, I believe, is arguing against having a hard coded response to unrecognized extension headers. The later text mandating configurability is intended, I believe, to force/allow the operator to make a deliberate choice. But then allowing the configuration to have a default that would drop unrecognized extension headers seems to me to return to the situation the first paragraph warns against. IANA considerations section --------------------------- IANA is requested to clearly mark in the Assigned Internet Protocol Numbers registry those values which are also IPv6 Extension Header types defined by an IETF action, for example by adding an extra column to indicate this. I believe "an IETF action" is unclear. By RFC5237, these fields in the current registry are presently assigned by "IESG Approval or Standards Action". I don't know that you want IESG Approval (which requires no RFC) for new extension types. If I'm right that you expect standard extension headers to be defined in Standrads Track RFCs and experimental extension headers to be defined in Experimental RFCs, I believe that you want "Standards Action or IETF Review". But I'm not an expert in IANA registries, you probably should get another opinion. Additionally, IANA is requested to replace the existing empty IPv6 Next Header Types registry by an IPv6 Extension Header Types registry. Given that the new registry has a new name, there is no need to replace the existing registry with the renamed registry. True, it is empty except for a reference to the protocol numbers registry, but there are references in documentation etc. to the Next Header Types registry that would become dangling references. Might as well leave it. Section 4.2 of RFC5226 has an explicit template for "What to Put in Documents That Create a Registry". The information in this section covers most of what is needed, but not all. It would be easiest to just follow the template. Section 2.1 says Packets containing standardised and undeprecated Routing Headers SHOULD be forwarded by default. At the time of writing, these include Type 2 [RFC6275], Type 3 [RFC6554], I am not certain what the new extension header IANA registry should say in this case. The protocol numbers registry lists only the type 43, with routing types in a subregistry of the Internet Protocol Version 6 (IPv6) Parameters registry. The IPv6 parameters registry also shows that some of the registered options for Destination Options and Hop-by-Hop Options are Standards Track and some are Experimental, so I'm not sure what the registry entries should say for those extension headers. That's particularly important given the encouragement to use these Destination Options in lieu of creating new extension headers. Not that it looks like anyone is paying any attention to that advice. Quibbles ------- Section 1 says: This document focuses on clarifying how the header chain should be traversed in the current IPv6 architecture. I don't believe that this document changes how the header chain is traversed, but how unrecognzied headers are treated. In section 3 Security Considerations In particular, packets containing standard extension headers are only to be discarded as a result of a configurable policy. This disagrees with Section 2.1, which says that The default configuration SHOULD allow all standardised extension headers. and Forwarding nodes MUST be configurable to allow packets containing unrecognised extension headers, but such packets MAY be dropped by default. which both seem to allow discarding without an explicit configuration to discard. In Section 3 will need to take account of them. I think you mean "take them into account". --Sandy Based on checking RFC4727, RFC3692, RFC6564, RFC2460, RFC5237, RFC2780, RFC5226, IANA registry for Assigned Internet Protocol Numbers, RFC6275, RFC6554, and IANA registry for Destination Options and Hop-by-Hop Options. So I could easily be confused.