Telechat Review of draft-ietf-6man-eh-limits-18
review-ietf-6man-eh-limits-18-tsvart-telechat-fairhurst-2025-02-18-00

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.