Network Working Group T. Herbert Internet-Draft Nvidia Intended status: Informational 6 December 2024 Expires: 9 June 2025 Limits on Sending and Processing IPv6 Extension Headers draft-ietf-6man-eh-limits-17 Abstract This document defines various limits that may be applied to receiving, sending, and otherwise processing packets that contain IPv6 extension headers. Limits are pragmatic to facilitate interoperability amongst hosts and routers, thereby increasing the deployability of extension headers. The limits described herein establish the minimum baseline of support for use of extension headers on the Internet. 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. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 9 June 2025. Copyright Notice Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights Herbert Expires 9 June 2025 [Page 1] Internet-Draft Extension Header Limits December 2024 and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Related work . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. Overview of extension header limits . . . . . . . . . . . . . 5 3. Host limits for sending extension headers . . . . . . . . . . 6 4. Host and intermediate node limits for receiving extension headers . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Router limits for receiving extension headers . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 9.1. Normative References . . . . . . . . . . . . . . . . . . 14 9.2. Informative References . . . . . . . . . . . . . . . . . 14 Appendix A. Deriving default limits . . . . . . . . . . . . . . 16 A.1. Limits on number of options . . . . . . . . . . . . . . . 16 A.2. Limits on length . . . . . . . . . . . . . . . . . . . . 16 A.3. Padding limits . . . . . . . . . . . . . . . . . . . . . 17 A.4. Limits on extension header ordering and number of occurrences . . . . . . . . . . . . . . . . . . . . . . . 18 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19 1. Introduction Extension headers are a core component of the IPv6 protocol as specified in [RFC8200]. IPv6 extension headers were originally defined with few restrictions. For instance, there is no specified limit on the number of extension headers a packet may have, nor is there a limit on the length in bytes of extension headers in a packet other than being limited by the Path MTU or 1,280 bytes for those hosts that do not discover the Path MTU [RFC7112]. Similarly, variable length extension headers typically do not have prescribed limits such as limits on the number of Hop-by-Hop or Destination options in a packet. The lack of limits essentially requires implementations to handle every conceivable usage of the protocol, including myriad use cases outside the realm of ever being realistic or useful in real world deployment. Excessive Hop-by-Hop options in a packet has also been raised as a security concern [RFC4942]. Herbert Expires 9 June 2025 [Page 2] Internet-Draft Extension Header Limits December 2024 The lack of limits and the requirements for supporting a virtually open-ended protocol have led to a current lack of support and deployment of extension headers ([RFC7872], [Cus23b]). Instead of attempting to satisfy the protocol requirements concerning extension headers, some router and middlebox vendors have opted to invent and apply their own ad hoc limits, relegate packets with extension headers to slow path processing, or have gone so far as to summarily discard all packets with extension headers [RFC9098]. For those hosts and routers that properly attempt to process all extension headers per the specifications, the lack of limits has made them susceptible to Denial of Service attacks. The net effect of this situation is that deployment and use of extension headers is currently underwhelming. This document describes various limits that hosts and routers may apply to the processing of extension headers. 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. 1.1. Related work Some of the problems of unlimited extension headers have been described or addressed in certain aspects. [RFC8200] relaxed the requirement that all nodes in the path must process all Hop-by-Hop options in a packet to be: NOTE: While [RFC2460] required that all nodes must examine and process the Hop-by-Hop Options header, 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 5.3 of [RFC8504] defines a number of limits that hosts may apply to processing extension headers. For instance, a limit on the maximum number of non-padding options allowed in a Destination Options header or Hop-by-Hop Options header is defined. This document expands on the requirements of [RFC8504] to allow limits to be set for routers and intermediate nodes. [RFC8883] defines a set of ICMP errors that may be sent if a limit concerning extension headers is exceeded and a node discards a packet as a result. [RFC8883] allows both hosts and routers to send such messages (effectively acknowledging that some routers discard packets with extension headers even though such behavior might be considered non-conformant with [RFC8200]). Herbert Expires 9 June 2025 [Page 3] Internet-Draft Extension Header Limits December 2024 Section 14 of [RFC9000] (QUIC) gives an example of limits being set on extension headers per the requirements of the transport layer protocol. Note that the default limits in this document are greater than that of [RFC9000]. From [RFC9000]: Note: 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. [RFC7872] presents real-world data regarding the extent to which packets with IPv6 Extension Headers (EHs) are discarded in the Internet. [RFC9098] summarizes the operational implications of IPv6 extension headers, and attempts to analyze reasons why packets with IPv6 extension headers are often discarded in the public Internet. Section 2.1.9 of [RFC4942] discusses security concerns with IPv6 extension headers. Excessive Hop-by-Hop options are one concern, and misuse of PAD1 and PADN options are another. [RFC4942] also provides some foundation for the limits defined in this document. This document sets the minimal upper bounds on the number of Hop-by- Hop options that a node is expected to process. The lower bound is discussed in [RFC9673]. 1.2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 1.3. Terminology This section provides definitions for some terms used in this document. Node: a device that implements IPv6 Router: a node that forwards IPv6 packets not explicitly addressed to itself Intermediate node: a node that is addressed by an entry in a Routing Header list where the entry is not the last one in the list Herbert Expires 9 June 2025 [Page 4] Internet-Draft Extension Header Limits December 2024 Host: any node that is not a router or intermediate node IPv6 header chain: the IPv6 header and the set of following IPv6 Extension Headers that precede the upper layer protocol in a packet 2. Overview of extension header limits The limits and requirements for handling extension headers defined in this document fall into the following categories: * Limits on extension header length * Limits on option length * Limits on number of extension headers * Limits on number of options * Limits on padding for extension headers with options * Limits on the length of the IPv6 header chain The limits in this document are optional. Limits are defined for both senders (sending hosts) and receivers (receiving hosts, intermediate nodes, or routers). A receiver limit is set to limit the amount of processing or the amount of data in received extension headers. Sender limits are set to limit the use of extension headers being sent. The purpose of sender limits is to increase the probability of successful delivery. For receiver limits, a recommended action when a limit is exceeded is specified. The recommended action depends on the type of the node. For a host or intermediate node, the action when a limit is exceeded is generally to discard the packet. The rationale is that hosts are required to process all of the headers in a packet to process it correctly, and intermediate nodes are required to process all the extension headers through the Routing Header to process a packet correctly. For a router, the action to take when a limit is exceeded is to stop processing the extension headers and to forward the packet; specifically, if a router is processing Hop-by-Hop options and a limit is exceeded then the router skips the option that caused the limit to be exceeded and skips any following Hop-by-Hop options per the procedures in Section 5.2 of [RFC9673]. The rationale is that the only extension header a router may process is Hop-by-Hop Options and the packet can be correctly forwarded if none or only some of the Hop-by-Hop options are processed. Herbert Expires 9 June 2025 [Page 5] Internet-Draft Extension Header Limits December 2024 This document includes limits on extension headers for their length and number of extension headers in a packet, and also includes limits on Destination or Hop-by-Hop options for their length and number of options in a header. Limits on length are useful to nodes having hardware limitations, such as a fixed size parsing buffer in routers, which inherently limits the number of bytes in headers that a node can process; a node with such hardware limitations may choose to set length limits for extension headers and options accordingly. Limits on the number of extension headers or options are useful to nodes, such as end hosts, that have no inherent processing limitations; for these nodes, limits on number of headers or options can be set to limit the cost of processing which is more a function of the number of items processed than the byte length of the items. Each receiver limit described in this document has a recommended default value or minimum value when limit is enforced. The intent of defining default limits is to establish an expected baseline of support. The default limits for senders correspond to the associated receiver default limits. The derivation for default number of options is discussed in Appendix A.1. The derivation of default length limits is discussed in Appendix A.2. Padding options in Hop-by-Hop and Destination options have a particular purpose to align the next option or to pad the length of the extension header to a multiple of eight bytes. Similar to non- padding options, padding options require processing to parse over. Unlike non-padding options, padding options serve no other purpose than padding. To that end, limits on padding can be more restrictive than those on non-padding options. The justification for padding limits is discussed in Appendix A.3. This document defines limits to optionally enforce extension header ordering and to optionally enforce that each extension header occurs at most once except for Destination options that may occur twice in a packet. The rationale for these limits is discussed in Appendix A.4. 3. Host limits for sending extension headers The requirements for limits related to a host sending packets with extension headers are: * 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. Herbert Expires 9 June 2025 [Page 6] Internet-Draft Extension Header Limits December 2024 * A source host SHOULD NOT send a packet with a Destination Options header larger than 64 bytes 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 larger header size. * A source host SHOULD NOT send a packet with a Destination option larger than 60 bytes 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 options of a larger size. * A source host SHOULD NOT send more than 8 non-padding options in a Hop-by-Hop Options header unless it has explicit knowledge that all possible routers, intermediate nodes, and the destination host in the path are able to process a greater number of options or will ignore options that exceed their limit in the case of routers. * A source host SHOULD NOT send a packet with a Hop-by-Hop Options header larger than 64 bytes unless it has explicit knowledge that all possible routers, intermediate nodes, and the destination host in the path are able to process a larger header size. * A source host SHOULD NOT send a packet with a Hop-by-Hop option larger than 60 bytes unless unless it has explicit knowledge that all possible routers, intermediate nodes, and the destination host in the path are able to process options of a larger size. * A source host SHOULD NOT send a packet with an IPv6 header chain larger than 104 bytes unless it has explicit knowledge that all possible routers, intermediate nodes, and the destination host in the path are able to process a larger IPv6 header chain. If a packet contains an IPsec header then this limit only applies through the end of the IPsec header (the IPsec header obfuscates following headers so that they are unreadable by nodes in the path). This requirement is equivalently stated as a host SHOULD NOT send a packet with more than 64 bytes of aggregate extension headers. * A source host SHOULD NOT set more than one consecutive pad option, either PAD1 or PADN, in a Destination Options header or Hop-by-Hop Options header. * A source host SHOULD NOT send a packet with more than seven consecutive bytes of padding, using PAD1 or PADN options, in a Destination Options header or Hop-by-Hop Options header. Herbert Expires 9 June 2025 [Page 7] Internet-Draft Extension Header Limits December 2024 * A source host SHOULD follow the recommendations in Section 4.1 of [RFC8200] for extension header ordering and number of occurrences of extension headers. 4. Host and intermediate node limits for receiving extension headers Per [RFC8200], a destination host that receives a packet with extension headers must process all the extension headers in the packet before accepting the packet and processing the Upper-Layer header. An intermediate node must process the Routing Header and all preceding extension headers. In the case of an intermediate node, receiver limits pertaining to Destination options are only applicable to Destination options before the Routing Header. As described in [RFC8504] a destination host may establish limits on the processing of extension headers. This document reiterates those requirements, expands the requirements to be applicable to intermediate nodes, and allows a receiving node to send an ICMP error [RFC8883] if a limit has been exceeded. The requirements for limits related to hosts and intermediate nodes receiving packets with extension headers are: * A host or intermediate node MAY set a limit on the maximum number of non-padding options allowed in a Destination Options header or Hop-by-Hop Options header. If this limit is supported then the maximum number SHOULD be configurable, the limit SHOULD be greater than or equal to 8, and the RECOMMENDED default value is 8. The limits for Destination Options headers and Hop-by-Hop Options headers MAY be separately configurable. 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. If a packet is received and the number of Destination options exceeds the limit then the receiving node MUST discard the packet. If the receiving node discards a packet because the limit is exceeded then it MAY send an ICMP Parameter Problem message with code 9 (Too Many Options in Extension Header) [RFC8883] to the packet's source address. * 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. The length limits for Destination Options headers and Hop-by-Hop Options headers MAY be separately configurable. 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 Herbert Expires 9 June 2025 [Page 8] Internet-Draft Extension Header Limits December 2024 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. If a packet is received and length of the Destination Options header exceeds the limit then the receiving node MUST discard the packet. If the receiving node discards the packet because the limit is exceeded then it MAY send an ICMP Parameter Problem message with code 6 (Extension Header Too Big) [RFC8883] to the packet's source address. * A host MAY set a limit on the maximum length of the IPv6 header chain, or equivalently a host MAY set a limit on the aggregate length of extension headers in a packet. If the limit is set then it SHOULD be greater than or equal to 104 bytes, or equivalently, the limit on aggregate header extension length SHOULD be greater than or equal to 64 bytes. If a packet is received and the length of the IPv6 header chain exceeds the limit then the receiving host MUST discard the packet and MAY send an ICMP Parameter Problem message with code 7 (Extension Header Chain Too Long) [RFC8883] to the packet's source address. * An intermediate node MAY set a limit on the maximum length of the IPv6 header chain up to an including the Routing Header, or equivalently an intermediate node MAY set a limit on the aggregate length of extension headers in a packet up to and including the Routing Header. If the limit is set then it SHOULD be greater than or equal to 104 bytes, or equivalently, the limit on aggregate header extension length up to and including the Routing Header SHOULD be greater than or equal to 64 bytes. If a packet is received and the aggregate length of the IPv6 header chain up to and including the Routing Header exceeds the limit then the receiving node MUST discard the packet and MAY send an ICMP Parameter Problem message with code 7 (Extension Header Chain Too Long) [RFC8883] to the packet's source address. Herbert Expires 9 June 2025 [Page 9] Internet-Draft Extension Header Limits December 2024 * A host or intermediate node MAY limit the number of consecutive bytes of padding in PAD1 or PADN options in a Destination Options header or Hop-by-Hop Options header to 7. If the limit is enforced and a packet is received and there are more than 7 consecutive bytes of padding in Hop-by-Hop Options then the receiving node MAY either: 1) discard the packet, or 2) stop processing of Hop-by-Hop Options header and process the rest of the packet normally. If the limit is enforced and a packet is received and there are more than 7 consecutive bytes of padding in Destination Options then the receiving node MUST discard the packet. If the receiving node discards the packet because the limit is exceeded the it MAY send an ICMP Parameter Problem message with code 9 (Too Many Options in Extension Header) [RFC8883] to the packet's source address. * A host or intermediate node MAY disallow consecutive padding options, either PAD1 or PADN, to be present in a packet. If the limit is enforced and a packet is received with consecutive padding options in Hop-by-Hop Options then the receiving node MAY either: 1) discard the packet, or 2) stop processing of Hop-by-Hop Options header and process the rest of the packet normally. If the limit is enforced and a packet is received with consecutive padding options in Destination Options then the receiving node MUST discard the packet. If the receiving node discards the packet because the limit is exceeded the it MAY send an ICMP Parameter Problem message with code 9 (Too Many Options in Extension Header) [RFC8883] to the packet's source address. * A host or intermediate MAY enforce the recommended extension header ordering and number of occurrences of extension headers described in Section 4.1 of [RFC8200]. Per the ordering recommendations, each extension header can occur at most once in a packet with the exception of Destination Options header which can occur twice. The recommended extension header ordering per [RFC8200] is: - IPv6 header - Hop-by-Hop Options header - Destination Options header - Routing header - Fragment header - Authentication header Herbert Expires 9 June 2025 [Page 10] Internet-Draft Extension Header Limits December 2024 - Encapsulating Security Payload header - Destination Options header - Upper-Layer header If a host or intermediate node enforces extension header ordering and a packet is received with extension headers out of order or the number of occurrences of an extension header is greater than one, or two for the Destination Options header, then the receiving node MUST discard the packet and MAY send an ICMP Parameter Problem message with code 8 (Too Many Extension Headers) [RFC8883] to the packet's source address. Note that a host may enforce extension header ordering for all extension headers in a packet, but an intermediate node may only enforce ordering for extension headers up to and including the Routing Header. All of the above limits, except for the limit an IPv6 header chain length and the limit on extension header ordering, are updated requirements from [RFC8504]. The changes in requirements from [RFC8504] are: * If a limit is exceeded that pertains to Destination Options then the packet MUST be discarded. The rationale is that Destination Options may contain information that is necessary for correct delivery of the packet and so the options cannot be ignored. * If a limit is exceeded an ICMP error [RFC8883] MAY be sent. 5. Router limits for receiving extension headers 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. The requirements for limits related to a router receiving packets with extension headers are: * If a router needs to parse the upper layer protocol (as discussed in Section 7 of [RFC9098]) then it MUST be able to correctly forward packets that contain an IPv6 header chain of 104 or fewer bytes, or equivalently, a router MUST be able to process a packet with an aggregate length of extension headers less than or equal to 64 bytes. Herbert Expires 9 June 2025 [Page 11] Internet-Draft Extension Header Limits December 2024 * 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. * A router MAY limit the number of non-padding Hop-by-Hop options that it processes. If a packet is received with a Hop-by-Hop Options header having a number of non-padding options that exceeds the limit then the router SHOULD stop processing the Hop-by-Hop Option header and ignore any Hop-by-Hop options beyond the limit following procedures in Section 5.2 of [RFC9673]. 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 9 (Too Many Options in Extension Header) [RFC8883] to the packet's source address. * A router MAY set a limit on the maximum length of a Hop-by-Hop Options header. If a packet is received with a Hop-by-Hop Options header having a length that exceeds the limit then the router SHOULD either: 1) ignore the Hop-by-Hop Options extension header and forward the packet normally, or 2) process Hop-by-Hop options that are contained within the extent of length limit, ignore any Hop-by-Hop options beyond the limit, and forward the packet normally. 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. * A router MAY limit the number of consecutive bytes of padding in PAD1 or PADN options in a Hop-by-Hop Options header to 7. If the limit is enforced and a packet is received and there are more than 7 consecutive bytes of padding then the router SHOULD stop processing the Hop-by-Hop Option header and ignore any Hop-by-Hop options beyond the limit. 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 9 (Too Many Options in Extension Header) [RFC8883] to the packet's source address. Herbert Expires 9 June 2025 [Page 12] Internet-Draft Extension Header Limits December 2024 * A router MAY disallow consecutive padding options, either PAD1 or PADN, to be present in the Hop-by-Hop Options header. If a packet is received with consecutive padding options that are disallowed by the router then the router SHOULD stop processing the Hop-by- Hop Option header and ignore any Hop-by-Hop options beyond the limit. 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 7 (Too Many Options in Extension Header) [RFC8883] to the packet's source address. 6. IANA Considerations There are no actions required for IANA defined in this document. 7. Security Considerations Security issues with IPv6 extension headers are well known and have been documented in several places including [RFC6398], [RFC6192], [RFC7045], [RFC4942], [RFC9098], and [RFC9673]. Of particular concern is a Denial-of-Service attack (DOS). For instance, since there is no hard limit on the number of options in an extension header, it is conceivable that an attacker could craft MTU sized packets with hundreds of small Hop-by-Hop or Destination options where the option type is chosen to be one that will be unknown to receivers and the higher order type bits are set to 00 to indicate that an unknown option is ignored. A receiver that attempts to process all the options in such packet would incur significant processing cost (TLV processing is difficult to efficiently implement). A similar attack against hosts and intermediate nodes could be orchestrated by sending an MTU sized packet filled with nothing but minimal sized Destination Options headers that only contain padding options. The potential for DOS attack exists in routers, hosts, and intermediate nodes. Routers are susceptible to the attack using Hop- by-Hop options, hosts are susceptible using Hop-by-Hop options or Destination options, intermediate nodes are susceptible using Hop-by- Hop options or Destination options before the Routing Header. Also note, the threat exists for both software and hardware implementations. Herbert Expires 9 June 2025 [Page 13] Internet-Draft Extension Header Limits December 2024 This document addresses the DOS concern of extension headers and options in extension headers by allowing receivers to configure limits on the length or number of extension headers or options that they process. Such limits cap the amount of processing needed for extension headers and hence mitigate the DOS concerns of extension headers. These limits may be set for hosts, routers, and intermediate nodes. This document does not introduce any new security concerns. 8. Acknowledgments The author would like to thank Brian Carpenter, Bob Hinden, Nick Hilliard, Gorry Fairhurst, Darren Dukes, Jen Linkova, Ole Troan, Vasilenko Eduard, Suresh Krishnan, Erik Kline, Jon Geater, and John Levine for their comments and suggestions that improved this document. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, . [RFC8504] Chown, T., Loughney, J., and T. Winters, "IPv6 Node Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504, January 2019, . [RFC8883] Herbert, T., "ICMPv6 Errors for Discarding Packets Due to Processing Limits", RFC 8883, DOI 10.17487/RFC8883, September 2020, . 9.2. Informative References Herbert Expires 9 June 2025 [Page 14] Internet-Draft Extension Header Limits December 2024 [APNIC] Huston, G., "IPv6 Extension headers revisited", October 2022, . [Cus23a] Custura, A. and G. Fairhurst, "Internet Measurements: IPv6 Extension Header Edition", IEPG, IETF-116 , March 2023, . [Cus23b] Custura, A., Secchi, R., Boswell, E., and G. Fairhurst, "Is it possible to extend IPv6?", Computer Communications X, October 2023, . [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998, . [RFC4942] Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/ Co-existence Security Considerations", RFC 4942, DOI 10.17487/RFC4942, September 2007, . [RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the Router Control Plane", RFC 6192, DOI 10.17487/RFC6192, March 2011, . [RFC6398] Le Faucheur, F., Ed., "IP Router Alert Considerations and Usage", BCP 168, RFC 6398, DOI 10.17487/RFC6398, October 2011, . [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing of IPv6 Extension Headers", RFC 7045, DOI 10.17487/RFC7045, December 2013, . [RFC7112] Gont, F., Manral, V., and R. Bonica, "Implications of Oversized IPv6 Header Chains", RFC 7112, DOI 10.17487/RFC7112, January 2014, . [RFC7872] Gont, F., Linkova, J., Chown, T., and W. Liu, "Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World", RFC 7872, DOI 10.17487/RFC7872, June 2016, . Herbert Expires 9 June 2025 [Page 15] Internet-Draft Extension Header Limits December 2024 [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, . [RFC9098] Gont, F., Hilliard, N., Doering, G., Kumari, W., Huston, G., and W. Liu, "Operational Implications of IPv6 Packets with Extension Headers", RFC 9098, DOI 10.17487/RFC9098, September 2021, . [RFC9673] Hinden, R. and G. Fairhurst, "IPv6 Hop-by-Hop Options Processing Procedures", RFC 9673, DOI 10.17487/RFC9673, October 2024, . Appendix A. Deriving default limits This appendix provides an explanation and justification for the recommended default values for limits defined in this document. The derived default values are based on current capabilities in deployment, expectations for extensibility, and an extrapolation of needs for future extensibility. A.1. Limits on number of options For the default limit for non-padding Hop-by-Hop or Destination options, consider that at the time of writing, it is observed that in the almost thirty year history of IPv6 there are only thirteen defined non-deprecated Destination options and Hop-by-Hop options and three temporarily assigned. Extrapolating for increased growth and new options, a default limit of 8 should be sufficient for the foreseeable future. A.2. Limits on length At the time of writing, the default limit 104 byte limit for the length of the IPv6 header chain is derived from an expected minimum parsing buffer size of 128 bytes. The typical sizes for parsing buffers are 64, 128, 256, or 384 bytes. [Cus23a] suggests that 128 byte parsing buffers are common and feasible on the Internet. From [APNIC]: Herbert Expires 9 June 2025 [Page 16] Internet-Draft Extension Header Limits December 2024 The experiment used five [Destination Option] extension header lengths (8, 16, 32, 64 and 128 bytes), and in our case, the 8-, 16- and 32-byte headers had the greatest success rates, while the two larger sizes experienced greater drop rates. There is nothing obvious in the Linux source code that could explain this behaviour, unlike the PadN issues. That tends to indicate that the size-related differential response for DST Extension header handling might be due to network equipment behaviours rather than host platform behaviours. Per [APNIC], the drop rate for Destination Options with sizes 8, 16, and 32 bytes was about 30%. The drop rates for Destination Options with size 64 was about 40%, and the drop rate with size 128 bytes was about 85%. As [APNIC] mentions, these differences are most likely due to network equipment. We can extrapolate from this data the effects of a parsing buffer. Support for 128 byte extension headers implies at least a 192 byte parsing buffer, support for 64 byte extension headers implies at least a 128 byte parsing buffer, and support for smaller extension headers implies a smaller parsing buffer. Based on this analysis, assuming common support for a 128 byte parsing buffer seems reasonable. A 128 byte parsing buffer accommodates 104 byte IPv6 header chain length including 64 bytes of extension headers. Note that 32 byte extension headers did have a bit more success than 64 bytes extension headers (30% versus 40% drop rate), however requiring support for just 32 bytes of extension header would significantly limit the utility of extension headers. Therefore, 128 bytes is chosen as the expected minimum parsing buffer size on the Internet. The 128 byte parsing buffer would be expected to at least contain: * 16 bytes for a Layer 2 header (for instance an Ethernet header) * 40 bytes for the IPv6 header * 64 bytes for the extension headers * 8 bytes for the transport layer (i.e. the first eight bytes of the transport layer header including transport layer port numbers) A.3. Padding limits [RFC4942] provides a rationale for limiting the number of consecutive bytes of padding: Herbert Expires 9 June 2025 [Page 17] Internet-Draft Extension Header Limits December 2024 There is no legitimate reason for padding beyond the next eight octet boundary since the whole option header is aligned on an eight-octet boundary but cannot be guaranteed to be on a 16 (or higher power of two)-octet boundary. This document allows a receiver to disallow consecutive padding options. The rationale is that a single PAD1 or PADN option can be used to provide 1 to 257 bytes of padding which is sufficient for any practical use case. Correspondingly, this document also recommends that a sender does not send a packet with consecutive padding options. A.4. Limits on extension header ordering and number of occurrences [RFC8200] allows, but clearly does not advocate, a very flexible use of extension headers: IPv6 nodes must accept and attempt to process extension headers in any order and occurring any number of times in the same packet, except for the Hop-by-Hop Options header, which is restricted to appear immediately after an IPv6 header only. Nonetheless, it is strongly advised that sources of IPv6 packets adhere to the above recommended order until and unless subsequent specifications revise that recommendation. Open ended flexibility can be problematic in deployment. For instance, as mentioned in Section 7 filling a packet with nothing but small extension headers could be the basis of a Denial of Service attack. For this reason, allowing limits on number of extension headers and number of occurrences of extension headers in a packet is justifiable. Similarly, allowing any extension header ordering would require nodes to process different combinations of headers which at the time of writing has no well defined purpose. An implementation that allows any order of extension headers would be sub-optimal performance and is potentially exposed to Denial of Service attack. Furthermore, the chances that someone in the foreseeable future might define a legitimate use case for out of order extension headers, repeated occurrences of the same extension header, or a new extension header is low. [RFC8200] strongly advises against that, a new combination of extension headers would like face issues in deployability, and historically there has never been a serious proposal for this. Herbert Expires 9 June 2025 [Page 18] Internet-Draft Extension Header Limits December 2024 Author's Address Tom Herbert Nvidia Santa Clara, CA, United States of America Email: tom@herbertland.com Herbert Expires 9 June 2025 [Page 19]