Limits on Sending and Processing IPv6 Extension Headers
draft-ietf-6man-eh-limits-12

Network Working Group                                         T. Herbert
Internet-Draft                                                   SiPanda
Intended status: Best Current Practice                  18 December 2023
Expires: 20 June 2024

        Limits on Sending and Processing IPv6 Extension Headers
                      draft-ietf-6man-eh-limits-12

Abstract

   This specification defines various limits that may be applied to
   receiving, sending, and otherwise processing packets that contain
   IPv6 extension headers.  The need for such limits is pragmatic to
   facilitate interoperability amongst hosts and routers in the presence
   of extension headers, thereby increasing the feasibility of
   deployment 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 20 June 2024.

Copyright Notice

   Copyright (c) 2023 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.

Herbert                   Expires 20 June 2024                  [Page 1]
Internet-Draft           Extension Header Limits           December 2023

   Please review these documents carefully, as they describe your rights
   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.  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 . . . . . . . . . . . . . . . . . . . . . . . . .   7
   5.  Router limits for receiving extension headers . . . . . . . .  10
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  12
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  12
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  12
   Appendix A.  Deriving default limits  . . . . . . . . . . . . . .  14
     A.1.  Limits on number of options . . . . . . . . . . . . . . .  14
     A.2.  Limits on length  . . . . . . . . . . . . . . . . . . . .  14
     A.3.  Padding limits  . . . . . . . . . . . . . . . . . . . . .  16
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  17

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 a myriad of use cases those are obviously 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 a
   security concern [RFC4942].

   The lack of limits and the requirements for supporting a virtually
   open-ended protocol have led to a significant lack of support and
   deployment of extension headers ([RFC7872], [Cus23b]).  Instead of

Herbert                   Expires 20 June 2024                  [Page 2]
Internet-Draft           Extension Header Limits           December 2023

   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
   underwhelming to the extent that they are sometimes considered
   unusable on the Internet, and hence IPv6 extension headers have not
   lived up to their potential as the extensibility mechanism of IPv6.

   As an example, consider that there is no limit on how many Hop-by-Hop
   or Destination options may be in an extension header in a packet, nor
   any limits as to how many options a receiver must process.  A single
   1,280 byte MTU size packet could legally contain a Hop-by-Hop or
   Destination Options header with over six hundred two byte options.
   There is no use case for this in the foreseeable future other than a
   Denial of Service attack where an attacker simply creates packets
   with hundreds of small unknown Hop-by-Hop or Destination options with
   the two high order bits in the option type set to 00 meaning to skip
   the unknown option.  Any node in the path that attempts to dutifully
   process all these options could be easily overwhelmed by the
   processing needed to parse these options, hence this is an effective
   DOS attack.  Note that this is a problem for both hardware and
   software implementations, as well as for both hosts and routers.

   This specification 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.
   Subsequently, this increases the viability of extension headers as
   the extensibility mechanism of IPv6.

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.

Herbert                   Expires 20 June 2024                  [Page 3]
Internet-Draft           Extension Header Limits           December 2023

   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
   specification 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 non-
   conformant with [RFC8200]).

   [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] provides some
   foundation for the limits defined in this specification.

   This specification 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 [I-D.ietf-6man-hbh-processing].

1.2.  Terminology

   This section provides definitions for some terms used in this
   specification.

      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

      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

Herbert                   Expires 20 June 2024                  [Page 4]
Internet-Draft           Extension Header Limits           December 2023

2.  Overview of extension header limits

   The limits and requirements for handling extension headers defined in
   this specification 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 specification are optional.

   Limits are defined for both sending hosts and receivers.  A receiver
   limit is set to limit the amount of processing or the amount of data
   for 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 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; if a
   router is processing Hop-by-Hop options and a limited 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 for
   skipping options in Section 5.2 of [I-D.ietf-6man-hbh-processing].
   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 some of the Hop-by-Hop options are processed.

   This specification specifies limits on extension headers and their
   options both for byte length and number of headers or options.
   Limits on length are useful to nodes having hardware limitations,
   such as a fixed size parsing routers, which inherently limits the
   number of bytes of headers that a node can process.  A node with such
   hardware limitations may choose to set length limits for extension

Herbert                   Expires 20 June 2024                  [Page 5]
Internet-Draft           Extension Header Limits           December 2023

   headers and options accordingly.  Limits for the number of 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 are 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 specification has a recommended
   default value or minimum value when limit is enabled.  The intent of
   default limits is to establish an expected baseline of support.  The
   default limits for senders correspond to the associated receiver
   default limits, thereby establishing the same default limits for
   senders and receivers.  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.

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.

   *  A source host SHOULD NOT send a packet with a Destination Options
      header larger than 64 bytes unless 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 option
      size.

   *  A source host SHOULD NOT send a packet with a Destination option
      larger than 60 bytes unless 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.

Herbert                   Expires 20 June 2024                  [Page 6]
Internet-Draft           Extension Header Limits           December 2023

   *  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 options of 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 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.

   *  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 payload.  An
   intermediate node must process the Routing Header and all preceding
   extension headers.

Herbert                   Expires 20 June 2024                  [Page 7]
Internet-Draft           Extension Header Limits           December 2023

   As described in [RFC8504] a destination host may establish limits on
   the processing of extension headers.  This specification reiterates
   those requirements, expands the requirements to be applicable to
   intermediate nodes, add allows a receiving node to send an ICMP error
   [RFC8883] if a limit has been exceeded.

   The requirements for limits related to a host or intermediate node
   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 Destination or Hop-by-Hop options exceeds the
      limit, then the receiving node SHOULD discard the packet and 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 an extension header exceeds the limit, then the
      receiving node SHOULD discard the packet and MAY send an ICMP
      Parameter Problem message with code 6 (Extension Header Too Big)
      [RFC8883] to the packet's source address.

   *  A host or intermediate node 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 aggregate length of the IPv6 header chain exceeds
      the limit, then the receiving node SHOULD 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.

   *  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 enabled
      and a packet is received and there are more than 7 consecutive

Herbert                   Expires 20 June 2024                  [Page 8]
Internet-Draft           Extension Header Limits           December 2023

      bytes of padding, then the receiving node SHOULD discard the
      packet and 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 a
      packet is received with consecutive padding options that are
      disallowed by the receiving node, then the receiving node SHOULD
      discard the packet and 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

      -  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 SHOULD 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.

Herbert                   Expires 20 June 2024                  [Page 9]
Internet-Draft           Extension Header Limits           December 2023

      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.

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, for instance
      to deduce the transport layer port numbers, 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.

   *  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 packets 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 than 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.
      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 20 June 2024                 [Page 10]
Internet-Draft           Extension Header Limits           December 2023

   *  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 the 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 enabled 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 the 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 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 the 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.  Security Considerations

   Security issues with IPv6 extension headers are well known and have
   been documented in several places including [RFC6398], [RFC6192],
   [RFC7045], [RFC4942], and [RFC9098].

   Of particular concern is a Denial-of-Service attack (DOS) wherein an
   attacker sends many Hop-by-Hop options or Destination options in a
   packet for the purposes of forcing receivers to consume inordinate
   resources processing packets.  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

Herbert                   Expires 20 June 2024                 [Page 11]
Internet-Draft           Extension Header Limits           December 2023

   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
   attempting to process all the options in such packet would require a
   lot of resources as TLV processing is notoriously difficult to do
   efficiently.  The potential for this DOS attack exists 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, and 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.

   This specification 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 specification does not introduce any new security concerns.

7.  Acknowledgments

   The author would like to thank Brian Carpenter, Bob Hinden, Nick
   Hilliard, Gorry Fairhurst, Darren Dukes, Jen Linkova, Ole Troan, and
   Vasilenko Eduard for their comments and suggestions that improved
   this specification.

8.  References

8.1.  Normative References

   [RFC8200]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", STD 86, RFC 8200,
              DOI 10.17487/RFC8200, July 2017,
              <https://www.rfc-editor.org/info/rfc8200>.

   [RFC8504]  Chown, T., Loughney, J., and T. Winters, "IPv6 Node
              Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504,
              January 2019, <https://www.rfc-editor.org/info/rfc8504>.

   [RFC8883]  Herbert, T., "ICMPv6 Errors for Discarding Packets Due to
              Processing Limits", RFC 8883, DOI 10.17487/RFC8883,
              September 2020, <https://www.rfc-editor.org/info/rfc8883>.

8.2.  Informative References

Herbert                   Expires 20 June 2024                 [Page 12]
Internet-Draft           Extension Header Limits           December 2023

   [APNIC]    Huston, G., "IPv6 Extension headers revisited", October
              2022, <https://blog.apnic.net/2022/10/13/ipv6-extension-
              headers-revisited/>.

   [Cus23a]   Custura, A. and G. Fairhurst, "Internet Measurements: IPv6
              Extension Header Edition", IEPG, IETF-116 , March 2023,
              <http://www.iepg.org/2023-03-26-ietf116/eh.pdf>.

   [Cus23b]   Custura, A., Secchi, R., Boswell, E., and G. Fairhurst,
              "Is it possible to extend IPv6?", Computer
              Communications X, October 2023,
              <https://www.sciencedirect.com/science/article/pii/
              S0140366423003705>.

   [I-D.ietf-6man-hbh-processing]
              Hinden, R. M. and G. Fairhurst, "IPv6 Hop-by-Hop Options
              Processing Procedures", Work in Progress, Internet-Draft,
              draft-ietf-6man-hbh-processing-12, 21 November 2023,
              <https://datatracker.ietf.org/doc/html/draft-ietf-6man-
              hbh-processing-12>.

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
              December 1998, <https://www.rfc-editor.org/info/rfc2460>.

   [RFC4942]  Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/
              Co-existence Security Considerations", RFC 4942,
              DOI 10.17487/RFC4942, September 2007,
              <https://www.rfc-editor.org/info/rfc4942>.

   [RFC6192]  Dugal, D., Pignataro, C., and R. Dunn, "Protecting the
              Router Control Plane", RFC 6192, DOI 10.17487/RFC6192,
              March 2011, <https://www.rfc-editor.org/info/rfc6192>.

   [RFC6398]  Le Faucheur, F., Ed., "IP Router Alert Considerations and
              Usage", BCP 168, RFC 6398, DOI 10.17487/RFC6398, October
              2011, <https://www.rfc-editor.org/info/rfc6398>.

   [RFC7045]  Carpenter, B. and S. Jiang, "Transmission and Processing
              of IPv6 Extension Headers", RFC 7045,
              DOI 10.17487/RFC7045, December 2013,
              <https://www.rfc-editor.org/info/rfc7045>.

   [RFC7112]  Gont, F., Manral, V., and R. Bonica, "Implications of
              Oversized IPv6 Header Chains", RFC 7112,
              DOI 10.17487/RFC7112, January 2014,
              <https://www.rfc-editor.org/info/rfc7112>.

Herbert                   Expires 20 June 2024                 [Page 13]
Internet-Draft           Extension Header Limits           December 2023

   [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,
              <https://www.rfc-editor.org/info/rfc7872>.

   [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, <https://www.rfc-editor.org/info/rfc9098>.

Appendix A.  Deriving default limits

   This appendix provides an explanation and justification for the
   recommended default values for limits defined in this specification.
   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

   The default limit for the number of non-padding Hop-by-Hop or
   Destination options is 8.  This matches the default value in
   [RFC8504].  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 adequate for the foreseeable
   future.

A.2.  Limits on length

   The default limit for the IPv6 header chain is 104 bytes.  From this
   value the default length limit for Hop-by-Hop and Destination options
   headers, sixty-four bytes, and the default length limit for a Hop-by-
   Hop or Destination option, sixty bytes, can be deduced.

   The 104 byte limit is derived from an assumed parsing buffer size of
   128 bytes.  A parsing buffer is a memory buffer in many router
   implementations that allows header processing in the high performance
   processing fast path.  The typical sizes for parsing buffers are 64,
   128, 256, or 384 bytes.  When a packet is received by a router, the
   headers of the packet, up to the size of the parsing buffer, are
   loaded into the parsing buffer.  If all the headers that the router
   needs to process fit within the parsing buffer then the packet can be
   processed in the fast path.  If the necessary headers don't fit in
   the parsing buffer then a router may either defer processing to a CPU
   slow path or may just drop the packet.

Herbert                   Expires 20 June 2024                 [Page 14]
Internet-Draft           Extension Header Limits           December 2023

   A de facto requirement of many routers is that they need to process
   transport layer headers in packets.  In particular, a router may
   inspect the port numbers of transport layer header, such as TCP or
   UDP, to perform ECMP or port filtering.  Typically, a router would
   need to read at least the first four bytes of the transport layer
   header which contains the port numbers, so these bytes would need to
   be in the parsing buffer for a packet.

   The default IPv6 header chain limit is derived from the expected size
   of parsing buffers assuming that there is space to accommodate the
   first bytes of the transport layer header in the parsing buffer.  The
   IPv6 header chain limit in this specification assumes a common
   parsing buffer size of 128 bytes.  Recent data [APNIC] and [Cus23a]
   suggests that 128 byte parsing buffers are common and feasible on the
   Internet.  From [APNIC]:

      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 256 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:

Herbert                   Expires 20 June 2024                 [Page 15]
Internet-Draft           Extension Header Limits           December 2023

   *  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)

   This scheme thus establishes a requirement that Internet devices must
   be capable of correctly processing packets with up to sixty-four
   bytes of extension headers, and subsequently it establishes a
   requirement that a host shouldn't send packets with more than sixty-
   four bytes of extension headers unless it known that all the nodes in
   the path can process packets with larger extension headers and a
   larger IPv6 header chain.  Note that this establishes a global
   minimum baseline requirement across the Internet; within a limited
   domain higher limits could freely be applied.

A.3.  Padding limits

   [RFC4942] establishes that the number of consecutive bytes in padding
   options in Hop-by-Hop and Destination Options headers should be
   limited to no more than seven:

      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.

   [RFC8504] established that a receiver MAY limit the number of
   consecutive padding bytes in a received packet to seven.  This
   specification expands on those limits to allow routers and
   intermediate hosts to set a limit.  Additionally, requirements are
   established for sending hosts that they shouldn't set more than seven
   consecutive bytes of padding.

   Note that limit on seven consecutive bytes of padding is "hardcoded"
   and enforced in the Linux networking stack.

   In addition to a limit on the number of consecutive bytes of padding,
   this specification allows a receiver 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 specification also
   recommends that a sender does not send a packet with consecutive
   padding options.

Herbert                   Expires 20 June 2024                 [Page 16]
Internet-Draft           Extension Header Limits           December 2023

Author's Address

   Tom Herbert
   SiPanda
   Santa Clara, CA,
   United States of America
   Email: tom@herbertland.com

Herbert                   Expires 20 June 2024                 [Page 17]