On 18/02/2025 16:38, Tom Herbert wrote:
Yes, that was a summary of why I thought this document was relevent.Hi Gorry, Thanks for your comments. Responses in line. On Tue, Feb 18, 2025 at 3:26 AM Gorry Fairhurst via Datatracker <noreply@xxxxxxxx> wrote:Reviewer: Gorry Fairhurst Review result: Ready with Issues 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@xxxxxxxx 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, whichSuch limitations already exist on the Internet. The data on drop rates of packets with extension headers confirms that. Right now, there is no guidance on what sending hosts need to do to avoid drops (other than not using EH). This document provides some useful guidance.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.Yes, hopefully the outcome is fewer packet drops!
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!I assume you mean Destination Options before and after the Routing Header? That's from RFC8200 to allow two Destination Options in the same packet with different semantics. I'm not sure what you mean by "only one of these EH is concerned with end-to-end transport!"
Yes. From the IETF transport perspective the two DO EH have
different functions and different needs, one relates to what you
have named "Intermediate nodes" and one to end-to-end aka endpoint
transport.
My comments in this review concern the intermediate node, and
what needs to happen when there is an intermediate node on the
path between the sending and recieving transport endpoint.
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.I will change that to "should"
Yes, that's calling this out to my AD so he may check more if he/she needs to. Imposing limits to devices on the path could add new challenges to understanding some paths - but setting sensible limits could help in the general case.=== 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.That seems to be a general concern not specific to this draft: when routers or intermediate nodes discard packets the end hosts will not understand what's happening. The goal of this draft is to reduce such discards.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 recommendations for sending ICMPv6 messages when nodes drop packets. E.g. "If the receiving node discards the packet because the limit is exceeded, then it MAY send an ICMP Parameter Problem message"There are several places where this applies for intermediate nodes, in Section 4.
The thing I am not hearing is what needs to happen when there is an intermediate node, that forms a part of the path between the transport endpoints.=== 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]./The requirements you are quoting only apply to destination nodes (hosts and intermediate nodes in a routing header). Section 5 describes the router requirements which match what you are proposing.
=== 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.Again, note that this text only applies to hosts and intermediate routers. Option #1 is what is currently supported in LInux stack. Either all Hop-by-Hop and Destinations options must be processed or the packet is dropped. This is done to maintain a strong security posture, that is hosts should not blindly accept packets without inspection. Option #2 allows a node to avoid processing partial Hop-by-Hop options and this degenerates to skipping HBH options entirely which is allowed by RFC8200. Option #3 follows RFC9637. Also note the inherent ambiguity of RFC9673 in trying to avoid "adversely impacts the aggregate forwarding rate"-- that is not something that can be normatively defined. However, the lengths of headers are more concrete because of typical parsing buffer design.
I understand the point for a end host.
The comments relates only to limits at Intermediate nodes.
RFC9672 is also postured to allow the HBH extension header to be incrementally deployed and used. I don't see that (2) helps, or should be specified as an alternative to RFC9672.
=== 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)”.Intermediate nodes on process Destination Options before the routing header, and hosts process both Destination Options. The requirements apply in those applicable cases. Also, note that implementations don't need to distinguish between Destination Options before or after the Routing Header-- all instances of Destination Options in a packet can be processed the same way.
Before I read this document, I did not think further about this - but since this introduces the concept of an Intermediate node, it leads me at least to question if this really is the case. I'll let others decide.
=== 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.
Thanks Tom, for getting back quickly, I think my comments are understood, and I'll leave those reading the reviews to see if they wish to follow-up on any of these topics.
Best wishes,
Gorry
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
