Ballot for draft-ietf-6man-eh-limits
Discuss
Yes
No Objection
No Record
Summary: Has 5 DISCUSSes. Has enough positions to pass once DISCUSS positions are resolved.
Thank you for the work put into this document. I support the editor in measures to facilitate more widespread support for extension headers. I recognise there are design limits in current host stacks, and I understand the recommendations originate from the current design in Linux. If documenting these limits encourages better support for EH, this is good. To help ensure a clear understanding of my ballot position, this is the third time I have reviewed this draft -- each in different roles, and each based on a complete read of this I-D. First, as an early reviewer for TSV-ART I raised substantial concerns when I-D -16 targeted PS. Second, as a IETF-LC reviewer of I-D -18, again for TSV-ART - but this time only focussed on transport (then targeting INFO). Each time I recorded major issues one concerning the way in which RFC2119 requirements were introduced, and also had comments. I thank the author for the improvements and updates of the I-D after each round of review. I now review this as an AD, with a different set of criteria. I am balloting this as DISCUSS because I remain deeply concerned about the potential to restricting the ability for innocation in use of EH by transport endpoints. I plan to revise this position after discussion, and have not yet decided whether to ballot Abstain or ballot No Objection. Please find below several blocking DISCUSS points: DISCUSS 1) This I-D has been submitted to target publication as Information. As such, I do not expect this to update RFC 8504, and this is the basis for the current review. However, there are still places in the text that could be interpreted as an update. I’d like to discuss if this draft could be re-worded, particularly to avoid chnaging lower case text to derive new RFC-2119 requirements. DISCUSS 2) I do not yet see the underlying evidence supporting introducing limits for intermediate nodes. I can see how intermediate nodes could be built using host stacks, but I'd like to clarify can intermediate nodes also built from other designs? I’m asking because I’d like to discuss how to add clarity on whether the set of limits are derived from constraints in deployed routers (and intermediate nodes) - or observed for end-to-end paths. DISCUSS 3) The idea of a minimum level of required support is clearer to me when related to endpoints/hosts. Once this is expressed also as a router limit for routers or intermediaries, I suggest that future extensibility is impacted. I suggest vendor designs are likely ossified to whatever limit is specified. I’d like to discuss whether the I-D could be constrained to avoid this, and allow the minimum size to evolve.
This provides some non-blocking COMMENT points (replies would be appreciated to help me understand): 1) The discussion on QUIC (RFC 9000) is not helpful, please remove. The RFC states: “This requirement to support a UDP payload of 1200 bytes limits the space available for IPv6 extension headers to 32 bytes or IPv4 options to 52 bytes if the path only supports the IPv6 minimum MTU of 1280 bytes. This affects Initial packets and path validation.” I recall that google telemetry showed a significant number of end-to-end paths had limited traversal for UDP datagrams dependent on size. The decision to set the default QUIC maximum packet size was based on the desire to enable deployability to most (but not all) access networks. Even so, the majority of networks were able to support much larger packets than the minimum packet size, so the majority of networks were not constrained in the way that this I-D seems to suggest, especially since this applies ONLY to Initial packets and path validation. 2) Please consider whether the product of the Happy WG could provide an alternative solution to the problem of heterogenous support for EH over different paths.
Thanks for the work on this document. There are a few aspects that I would like to discuss (some of the text context provided using idnits output of v19): <discuss-1> It is not very clear to me whether these limits are meant only for nodes that are involving in IPv6 traffic over the Internet (majorly end hosts and routers), or also meant for routers in limited domains that use IPv6 encapsulations and all sorts of extensions headers (e.g., an SRv6 deployment). Some clarification on this applicability will help. <discuss-2> There are parts of the document where RH related aspects are covered (most notably with the term intermediate node) and some of those limits seem to not reflect the current status (at least for some RH types). Following is a text snipped, but similar also exists in other sections related to host, intermediate nodes, and routers. 316 * A source host SHOULD NOT send a packet with an IPv6 header chain 317 larger than 104 bytes unless it has explicit knowledge that all 318 possible routers, intermediate nodes, and the destination host in 319 the path are able to process a larger IPv6 header chain. If a 320 packet contains an IPsec header then this limit only applies to 321 headers up to and including the IPsec header (the IPsec header 322 obfuscates following headers so that they are unreadable by nodes 323 in the path). This requirement is equivalently stated as a host 324 SHOULD NOT send a packet with more than 64 bytes of aggregate 325 extension headers. Going by this maths, even without any other EHs, the host cannot sent a packet with a RH (more specifically SRH) with more than 3 segments in its segment list. As of today, there are several commercial routing platforms and merchant silicon that exceed this capacity. So, the routers which are say PE routers and doing SRv6 encapsulations would be already exceeding this limit. Does the document want to include in its scope the RH header sizes and limits?
Please find below some comments that are provided inline in the idnits output of v19 of the document: 216 Limits are defined for both senders (sending hosts) and receivers 217 (receiving hosts, intermediate nodes, or routers). A receiver limit <minor> While it is obvious, a reminder would be helpful that a router device is a host (say for control/mgmt plane traffic, but more importantly also as a tunnel/encapsulation endpoint), a router that is doing IPv6 forwarding, and an intermediate node that is doing RH processing cum IPv6 forwarding. It will help place the discussion of limits in this document in a proper perspective in the reader's mind. 223 For receiver limits, a recommended action when a limit is exceeded is 224 specified. The recommended action depends on the type of the node. 225 For a host or intermediate node, the action when a limit is exceeded 226 is generally to discard the packet. The rationale is that hosts are 227 required to process all of the headers in a packet to process it 228 correctly, and intermediate nodes are required to process all the 229 extension headers up to and including the Routing Header in order to 230 process a packet correctly. For a router, the action to take when a <major> Besides the part that it is processing a RH (and any DOH before the RH), why would intermediate nodes be set for a higher bar for processing of (say HBH) EHs as compared to a router? Isn't it quite often that the node processing RH is also a router and having different characteristics as compared to an end host? 293 * A source host SHOULD NOT send a packet with a Destination option 294 larger than 60 bytes unless it has explicit knowledge that the 295 destination host, and all intermediate nodes in a Routing Header 296 in the case of a Destination Options header before the Routing 297 Header, are able to process options of a larger size. <major> How does this limit of 64/60 bytes work if the source host had to include the DOH both before and after a RH? 420 * An intermediate node MAY set a limit on the maximum length of the 421 IPv6 header chain up to an including the Routing Header, or 422 equivalently an intermediate node MAY set a limit on the aggregate 423 length of extension headers in a packet up to and including the 424 Routing Header. If the limit is set then it SHOULD be greater <major> I am finding it hard to find the difference between the two statements that are separated by that "or". Could you please clarify?
Hi Tim, Many thanks for working on this. This is great work. Appreciate that the rationale for picking limits is documented. I will be definitely balloting “Yes”. Till then, I have some DISCUSS points. ## Need to cover not only configurable parameters but readable ones as well: The document focuses exclusively on the configurable limits and makes assumptions something that a limit is known. However, and although making assumptions on intermediate nodes capabilities, the document is silent about having means to expose and retrieve the limits, including the default values that are used by a given implementation. For example, RFC9740 includes support for some of these for routers. I think that we need a set of requirements that basically mirror all the configurable limits/default discussed in the spec but as readable parameters. ## Update or not update 8504 CURRENT: All of the above limits, except for the limit on IPv6 header chain length and the limit on extension header ordering, are updated requirements from [RFC8504]. This seems a deviation from 8504. I guess we should better mark this with an “update”.
## Abstract (1) Not sure what is meant here: CURRENT: Limits are pragmatic to facilitate interoperability amongst hosts and routers (2) I think I can guess what the following is trying to convey, but I don’t think an abstract is the right place for that, let alone that we don’t know by “which” magic one can know that all routers in the path will support that. Paths are dynamics, and even placing a probe first does not guarantee that the actual data packet will follow it. CURRENT: If it is known that all communicating parties for a particular communication, including destination hosts and any routers in the path, are capable of supporting more than the baseline then these default limits may be freely exceeded. # Section 1 (1) Use consistent IPv6 wording through the doc (e.g., s/ Hop-by-Hop options / Hop-by-Hop Options). (2) Help readers find where to look at: OLD Extension headers are a core component of the IPv6 protocol as specified in [RFC8200]. NEW: Extension headers are a core component of the IPv6 protocol as specified in Section 4 of [RFC8200]. (3) nit OLD: The net effect of this situation is that deployment and use of extension headers is NEW: The net effect of this situation is that deployment and use of extension headers are (4) nit + we need to increase actual deployment not only the deployability! OLD: The goal of establishing limits is to narrow the requirements to better match reasonable use cases, thereby facilitating practical implementation and increased deployability of extension headers. NEW: The goal of establishing limits is to narrow the requirements to better match reasonable use cases, thereby facilitating practical implementation and increased deployment of extension headers. (4) “routers” can also be seen as intermediate nodes, consider the following: OLD: This document expands on the requirements of [RFC8504] to allow limits to be set for routers and intermediate nodes. NEW: This document expands on the requirements of [RFC8504] to allow limits to be set for routers and other intermediate nodes. (5) Maybe cite in related work section: RFC9740 specifies a mechanism to retrieve a limit that is typically set by hardware or software. (6) nit OLD: misuse of PAD1 and PADN options are another NEW: misuse of PAD1 and PADN options is another # Section 1.3 (1) Consider defining an entry for “non-padding” extension as I don’t think we have this defined somewhere. (2) OLD: Node: a device that implements IPv6. NEW: Node: a device that implements IPv6. It can be a host or a router. (3) (nit) add missing “.” for all entries. (4) See if we can import from RFC9740: Extension header chain: Refers to the chain of extension headers that are present in an IPv6 packet. This term should not be confused with the IPv6 header chain, which includes the IPv6 header, zero or more IPv6 extension headers, and zero or a single Upper-Layer Header. # Section 2 (1) The list of limits does not include a limit that corresponds to the ipv6ExtensionHeadersChainLength IE in RFC9740. Can we add a limit to cover that here as well? (2) indicated where it is specified: CURRENT: For receiver limits, a recommended action when a limit is exceeded is specified. (3) Split the long sentence: s/forward the packet; specifically/forward the packet. Specifically (4) Split another long sentence: s/packet and also includes/packet. Also, it includes (5) (nit) s/fixed size/fixed-size (6) Split another long sentence: s/limitations; for these nodes/limitations. For these nodes # Section 3 (1) CURRENT: * A source host SHOULD NOT send more than 8 non-padding options in a Destination Options header unless it has explicit knowledge that the destination host, and all intermediate nodes in a Routing Header in the case of a Destination Options header before the Routing Header, are able to process a greater number of options. I wonder how the “all intermediate nodes” can be known? IMO, it is unlikely to know in the Global Internet. (2) Not sure what an aggregate is well defined. Can we please have an entry for it in the terminology section? CURRENT: SHOULD NOT send a packet with more than 64 bytes of aggregate extension headers. # Section 5 (1) split a long sentence (please consider the same change for all other similar items) OLD: because the limit is exceeded; however, if it does then the router MAY send an ICMP Parameter Problem message with code 6 (Extension Header Too Big) [RFC8883] to the packet's source address. NEW: because the limit is exceeded. However, if it does then the router MAY send an ICMP Parameter Problem message with code 6 (Extension Header Too Big) [RFC8883] to the packet's source address. (2) Shouldn’t the MAY be a SHOULD here? (idem for other similar constructs) CURRENT: It is NOT RECOMMENDED that a router discards the packet because the limit is exceeded. However, if it does then the router MAY send an ICMP Parameter Problem message with code 6 (Extension Header Too Big) [RFC8883] to the packet's source address. Given the NOT RECOMMENDED part, having means to detect the problem should be encouraged to ease troubleshooting and diagnostic. # Section 7 s/DOS/DoS # Appendix (1) The causality effect is not clear to me even after rereading that section: CURRENT: a default limit of 8 should be sufficient for the foreseeable future. (2) (nit) s/the default limit 104-byte limit/the default 104-byte limit (3) (nit) s/128 byte/128-byte (idem for 64 bit, 104 bit) (4) (nit) s/Denial of Service attack/DoS attack Cheers, Med
** Section 3. Multiple list items in the section include a variant of the clause “… unless it has explicit knowledge that the destination host, and all intermediate nodes …”. On what kind of networks is such “explicit knowledge” possible? Is this a data center where there might be some notion of full administrative control? If this is the public Internet, how does one gain such knowledge?
Thank you to Peter Yee for the GENART review. ** Section 5. A router may establish limits for processing packets with received extension headers. If a limit is exceeded, routers SHOULD still forward the packet and SHOULD NOT drop packets because a limit is exceeded. What does this mean in a production configuration? If the router has established limits, why "SHOULD it still forward the packet"? When would it not? What's the point of establishing the limit if the recommendation is just to ignore it?
# Éric Vyncke, INT AD, comments for draft-ietf-6man-eh-limits-19 CC @evyncke Thank you for the work put into this document, as explained below I think that the author wants to facilitate the use of extension headers, but I am deeply concerned about having a reverse effect and actually leading to an IPv6 ossification. Please find below several blocking DISCUSS points, some non-blocking COMMENT points (but replies would be appreciated even if only for my own education). Special thanks to Suresh Krishnan for the shepherd's *incomplete (Q3-5)* write-up including the WG consensus and the detailed justification of the intended status. Other thanks to Jean-Michel Combes, the Internet directorate reviewer (at my request): https://datatracker.ietf.org/doc/review-ietf-6man-eh-limits-19-intdir-telechat-combes-2025-04-03/ (and I have read the email discussion) Other thanks to Jouni Korhonen , the IoT directorate reviewer (at my request): https://datatracker.ietf.org/doc/review-ietf-6man-eh-limits-19-iotdir-telechat-korhonen-2025-04-09/ (and I expect to read a reply soon) I hope that this review helps to improve the document, Regards, -éric ## DISCUSS (blocking) As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is just a request to have a discussion on the following topics: ### Race to the bottom Even if I can only laud the intention of the author and of the 6MAN WG, I am deeply concerned that: 1) short-term: this is wishful thinking, i.e., it won't change the existing networks (being the global Internet or private/enterprise networks) 2) long-term: if ever this I-D is published, it will most probably end up in call for tender or other BCP, i.e., vendors will limit themselves to the different limits written in this document and not try to go beyond, leading to an ossification of the Internet and preventing creative use of extension headers. The limits are based on studies done in 2022 and 2023 over the public Internet, this raises two problems: 1) the document should probably restrict its applicability to the public Internet (I find the disclaimers "unless it is known to work" rather repetitive and too vague) 2) limiting the future of the Internet based on studies of 2022/2023 (i.e., going over routers dating possibly back to 2017... and being unaware whether it is an operator policy or a router HW limitation) is too restrictive. 64 bytes for the extension header chain is really limiting. About 2), I do not know any other RFC limiting the feature set of an existing deployed protocol. I am afraid that I cannot see how the above points can be addressed. ### Conflict with RFC 8504 Section 5.3 of RFC 8504 (a BCP) uses a lot of "MAY" about the same limits as in this document. I.e., how can this informational I-D modify a BCP "MAY" into a "SHOULD" ? This is confusing at least. A way forward would be to use a normal "should" w/o BCP14 weight. ### Section 2 As the intended status is informational, please do not use "defined" in `defined in this document` but perhaps "suggested". ### Section 3 `all intermediate nodes in a Routing Header in the case of a Destination Options header before the Routing Header,` is really unclear (or at least I cannot parse it). Suggest removing "in a Routing Header". AFAIK, all IPv6 nodes are able to skip the IPsec AH, so `the IPsec header obfuscates following headers so that they are unreadable by nodes in the path` is wrong and should rather be specific to ESP. `A source host should follow the recommendations in Section 4.1 of [RFC8200] for extension header ordering`, isn't this obvious ? There is little point to repeat what is written in RFC 8200 (this is only a source of confusion IMHO). ### Section 4 `expands the requirements to be applicable to intermediate nodes,` another conflict with RFC 8504.
## COMMENTS (non-blocking) ### Section 1.1 RFC 9000 (QUIC) does not really the IPv6 extension headers length as this length is linked to the IPv6 MTU. The current text tries somehow to explain it, but it does not seem like the EH limit is done on purpose by QUIC, this is more a side effect than an explicit limit. ### Section 1.3 As the terminology is mostly the one use by RFC 8200, let's add a reference to RFC 8200. ### Section 2 This section goes over a simple overview as it also describes behaviours and rationale, the title should probably be changed. Please start a new paragraph starting with `For a router, the action to` else the text is confusing. Should there be text about layer-4 ACL for routers ? (it is briefly touched in section 5 but probably deserved some text in this section as well) `This document defines limits to optionally enforce` but as the text is informational and contains a lot of "SHOULD", does "optionally" make sense ? I.e., everything could be seen as optional. ### Section 3 As the section is `Host limits for sending extension headers`, does it not apply to routers and intermediate nodes ? I think that final node can be configured to ignored hop-by-hop options per RFC 8200, so, the text `will ignore options that exceed their limit in the case of routers` should not restrict to routers only. ### Section 4 s/As *described* in [RFC8504] a destination host /As *specified* in [RFC8504] a destination host / as RFC 8504 is a BCP. `allows a receiving node to send an ICMP error [RFC8883] if a limit has been exceeded.` I do not see why this I-D 'allows' because RFC 8883 (by the same author :-) ) is standard track, so of course nodes are allowed to send this ICMP. Same for `it MAY send an ICMP Parameter Problem message` and in other places. ### Section 5 To be honest, the first paragraph is probably the only part of the I-D that appears OK and valuable... ``` A router may establish limits for processing packets with received extension headers. If a limit is exceeded, routers SHOULD still forward the packet and SHOULD NOT drop packets because a limit is exceeded. ``` and later ``` * If a router needs to parse the upper layer protocol, for instance to deduce the transport layer port numbers, it MUST be able to correctly forward a packet containing eight or fewer extension headers that precede the transport layer header. ``` and a few other paragraph in this section including the order of extension headers. ### Appendix A.2 Who is the "we" in `We can extrapolate` ? Is it the author ? The 6MAN WG ? The IETF Community ? Please be accurate here. `At the time of writing,` does not age well... please use the date of APNIC & Ana Custura's papers. ### Section 7 Shameless plug: I would have expected to have RFC 9099 listed as well.
Thanks to Peter Yee for his secdir review. Please note: This is well outside my normal area of expertise. However, the concept does seem sensible. Both of my comments are readability type comments. Section 1.1, para 2: The sentence construction is confusing. '[RFC8200]... options in a packet to be: NOTE:...' is the part after Note: the relaxed requirement? If it were me, I'd just make it all one paragraph like this: "While [RFC2460] required that all nodes must examine and process the Hop-by-Hop Options header, [RFC8200] relaxed the requirement. It is now expected that nodes along a packet's delivery path only examine and process the Hop-by-Hop Options header if explicitly configured to do so." Section 1.1, para starting 'Section 14 of [RFC9000]: the comment above applies to this para as well. Unless the 'Note:...' component is a direct quote from RFC9000, in which case, please add quotation marks around the quote.
I support the discuss ballot from Med, Eric and Ketan. My general concern is that even suggesting limits on Extension Header capabilities, even in an informational RFC, could unintentionally restrict how payloads are transported. I worry that this might discourage future innovation by leading the industry to dismiss any solutions that go beyond the suggested EH limits. There's also a risk that some implementers might lean on wording like the snippet in the abstract as a kind of "get-out-of-EH-jail" card for simplified encodings, using it to justify hardware with limited IPv6 support for cost reasons. Over time, this could contribute to a gradual shift toward a more constrained and less flexible IPv6 networked world, which would be a real shame. " If it is known that all communicating parties for a particular communication, including destination hosts and any routers in the path, are capable of supporting more than the baseline then these default limits may be freely exceeded. " Gunter Van de Velde RTG Area Director
I support the DISCUSS ballots from Gorry and Éric. I have similar concerns, but will defer to their expertise to determine when they have been sufficiently addressed. This document currently targets Informational status, yet proposes to "expand the requirements" of RFC 8504 (BCP) and apply new requirements to nodes. I appreciate that the Shepherd's write-up discusses the background of this discussion. The write-up notes that RFC 8504 was originally published as the Informational RFC 4294, but that document begins by saying that it "summarizes requirements from other published Standards Track documents in one place," i.e. it does not introduce new normative requirements but merely collates them for easy reference. While this document's status has been updated, the language still reads as if it is a successor to and makes changes to the scope of 8504. I am concerned that expansive SHOULD NOT guidance about host behavior will translate into infrastructure not feeling the need to support higher values, creating a de facto maximum in all hardware. (As in fact the Security Considerations explicitly states is the intent, that path elements can use these limits to protect themselves from malicious hosts.) The "unless it has explicit knowledge [about] all possible [path elements]" escape clause feels ineffectual without a discovery mechanism to determine whether the path does in fact support higher limits. I would be much more comfortable if the document gave means for the hosts to determine what the limits are on a given path and guidance that paths which do not support at least the minimal stated limits should be considered unusable. The recommendations about ICMP Parameter Problem messages are a start in this direction.
I support the DISCUSS of Éric Vyncke and am also interested to follow the other DISCUSSes.