This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information. When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC tsv-art@ietf.org if you reply to or forward this review. Review for "Limits on Sending and Processing IPv6 Extension Headers" The document seeks to provide informational guidance on how to best configure limits to IPv6 Extension Header processing. My previous archived TSV-ART review highlighted several concerns. This is a new review following substantive changes by the editor (thanks Tom) that has resolved many of the comments in that last review. Although this is a proposed INT Area specification, this has impact on whether an endpoint is able to include destination and HBH options in packets that it sends, and therefore it impacts has implications on the transport, which includes methods such as racing, the use of tunnels/encapsulation by the end-to-end transport, and methods such as OAM. It also impacts the design of middle boxes. The support for two Destination Options Extension Headers in IPv6 is also potentially confusing for a reader - only one of these EH is concerned with end-to-end transport! Major: === 1. Extensibility language In section 3: /A source host SHOULD follow the recommendations in Section 4.1 of [RFC8200] for extension header ordering and number of occurrences of extension headers./ - This is the place where I noted in my earlier review that the document seeks to make lower case descriptive recommendations into RFC2119 requirements. This type of update is unusual, although within the context of this draft I can understand the intent and the desirability of this approach. - If this approved - I think this needs to be called out to the iESG - and the wording here likely needs to be strengthened to explained that the are now recommended, and that the rationale for why the SHOULD can be changed needs to be explained- I was assuming this is to permit future experimentation, standardisation and deployment of new extension headers? - I also think a reference to RFC8504 is needed here to explain how to define a new extension header. === 2. Discard by an Intermediate Node As a transport person, the end host recommendation is fine - if a packet reaches the end and has a problem, i expect it to fail to be delivered. This is not a show-stopper, but it is a concern. I’m less familiar with intermediate nodes on-path processing the routing header and how they impact my end to end view of the path. In many ways I welcome making this more explicit. However, it also raises a concern when the routing functions possibly lead to unexpected loss, making path more difficult for the transport to understand. This is a special case where an ICMPv6 message would be really helpful to trace and debug operation (albeit with the usual caveat that the ICMPv6 message may not reach the sender). I think the appropriate action when a limit is reached is an INT AREA question, so I’ll flag this as a major issue. There are several places where this applies for intermediate nodes, in Section 4. === 3. Rules relating to HBH Options. Section 4: /If a packet is received and the number of Hop-by-Hop options exceeds the limit, then the receiving node MAY either: 1) discard the packet, or 2) stop processing the Hop-by-Hop Options header and process the rest of the packet normally./ - I think (2) and the following MUST are incorrect. This is a special case of the forwarding extensibility, and as such we need a clear guidance, as defined in RFC 9673. An end host cannot know the set of router configurations along its path, and hence this needs to not result in discard. The specific requirement added in that RFC was: / If a router is unable to process a specific Hop-by-Hop option (or is not configured to do so), it SHOULD behave in the same way specified for an unrecognized Option Type when the action bits are set to "00", and it SHOULD skip the remaining options using the "Hdr Ext Len" field in the Hop-by-Hop Options header. / - I was hoping to see text that was more like this: /If a packet is received and the number of Hop-by-Hop options exceeds the limit, then the receiving stops processing the Hop-by-Hop Options header and process the rest of the packet normally, see Section 5.2 of [RFC9673]./ === 4. Limits to HBH Size in Section 4: / If a packet is received and the length of the Hop-by-Hop Options header exceeds the limit, then the receiving node MAY either: 1) discard the packet, 2) skip processing of Hop-by-Hop Options header and process the rest of the packet normally, or 3) process the options up to the one that causes the limit to be exceeded and then stop processing of the Hop-by-Hop Options header and process the rest of the packet normally. / - There are three suggested options provided in the I-D for a length limit when a packet includes a HBH EH. Para 2 of Section 5.2 in RFC 9673 recommends approach 3. - I think that RFC2119 recommendation ought to be stated in this I-D. === 5. Which of the two Destination Options EH is being discussed in Section 4 relating to Intermediate nodes? IPv6 [RFC8200] clearly identifies two usages of the DO. I think in the context of this I-D, when a DO is checked by an intermediate node, it refers only to “or options to be processed by the first destination that appears in the IPv6 Destination Address field plus subsequent destinations listed in the Routing header.” As in note 1 of Section 4.1 of RFC8200. - This needs to be clarified. I also think this the citation to “: note 1 of Section 4.1 of RFC8200” is necessary and also a later citation when speaking of host limits to “options to be processed only by the final destination of the packet (see note 3 of Section 4.1 of RFC8200)”. === I have the following editorial comments on the latest revision: === 1. Editorial: In section 2 there is a helpful list of limits. This does not include an item stating the: * ordering and type of extension header. - although this time is later presented as a limit that could be checked. === 2. Editorial: /Excessive Hop-by-Hop options in a packet has also been raised as a security concern [RFC4942]./ A packet that includes an excessive number or size of Hop-by-Hop options in a packet has also been raised as a security concern [RFC4942]./ - This is a suggestion to improve reading. === 3. Editorial: /The limits in this document are optional./ - I understand this, but it seems slightly terse and possibly a confusing statement, I’d recommend it could be refined or removed. === 4. UK English. This sentence reads OK in US English, but is difficult to correctly read for someone familiar with UK English /If a packet contains an IPsec header then this limit only applies through the end of the IPsec header / - Please could the word /through/ be replaced by /up to and including/ or something else?. ==== 5. Two or one Llimits to HBH and DO Size in Section 4: / * A host or intermediate node MAY set a limit on the length of a Destination Options header or a Hop-by-Hop Options header. If this limit is supported then the limit SHOULD be configurable and the limit SHOULD be greater than or equal to 64 bytes. / - Is that a separate limit for each size, or a combined size of 64 bytes, this is not clear. === 6. The rules relating to HBH and DO at intermediate nodes do not seem to be the same. I think it would be easier on the reader, if the limit checks in section 4 text relating to HBH Option & DO were now divided into two paragraphs of text, one about HBH and one about DO.