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

Network Working Group                                         T. Herbert
Internet-Draft                                                   SiPanda
Intended status: Best Current Practice                    4 October 2023
Expires: 6 April 2024

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

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 and 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 6 April 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 6 April 2024                  [Page 1]
Internet-Draft           Extension Header Limits            October 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 and motivation of extension header limits  . . . . .   5
     2.1.  Types of nodes  . . . . . . . . . . . . . . . . . . . . .   5
     2.2.  Types of limits . . . . . . . . . . . . . . . . . . . . .   6
       2.2.1.  Limits on extension header length . . . . . . . . . .   6
       2.2.2.  Limits on option length . . . . . . . . . . . . . . .   6
       2.2.3.  Limits on number of extension headers . . . . . . . .   6
       2.2.4.  Limits on number of options . . . . . . . . . . . . .   6
       2.2.5.  Limits on padding options . . . . . . . . . . . . . .   7
       2.2.6.  Limit on IPv6 header chain length . . . . . . . . . .   8
     2.3.  Actions when limits are exceeded  . . . . . . . . . . . .  10
     2.4.  Design Philosophy . . . . . . . . . . . . . . . . . . . .  11
   3.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . .  13
     3.1.  List of limits  . . . . . . . . . . . . . . . . . . . . .  13
     3.2.  Host requirements . . . . . . . . . . . . . . . . . . . .  13
       3.2.1.  Source host requirements  . . . . . . . . . . . . . .  13
       3.2.2.  Receiving extension headers by destination hosts  . .  15
     3.3.  Router requirements . . . . . . . . . . . . . . . . . . .  17
     3.4.  Intermediate destination requirements . . . . . . . . . .  18
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .  20
   5.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  20
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  21
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .  21
     6.2.  Informative References  . . . . . . . . . . . . . . . . .  21
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  22

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 MTU).  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

Herbert                   Expires 6 April 2024                  [Page 2]
Internet-Draft           Extension Header Limits            October 2023

   use cases those are obviously outside the realm of ever being
   realistic or useful in real world deployment.

   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].  Instead of attempting to
   satisfy the protocol requirements concerning extension headers, some
   router and middlebox vendors have opted to either 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].  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
   1500 byte MTU size packet could legally contain a Hop-by-Hop Options
   header with over seven hundred two byte options.  Currently, there is
   no use case for this other than a Denial of Service attack where an
   attacker simply creates packets with hundreds of small unknown Hop-
   by-Hop 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 per the requirements
   of [RFC2460] could be easily overwhelmed by the processing needed to
   parse these options (this is true for both hardware or software
   implementations).

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

Herbert                   Expires 6 April 2024                  [Page 3]
Internet-Draft           Extension Header Limits            October 2023

      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 host 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 feature is supported, the maximum number
      SHOULD be configurable, and the default value SHOULD be set to 8.

   [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 is 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.

   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

      Router processing routing headers: A router that processes a
      routing header and is addressed by the Destination Address of a
      packet with a Routing header where the Destination Address is not
      the address of the last segment in the Routing header

Herbert                   Expires 6 April 2024                  [Page 4]
Internet-Draft           Extension Header Limits            October 2023

      Router not processing routing headers: A router that forwards
      packets without processing a routing header.  This type of node is
      not explicitly addressed by the Destination Address in a packet
      except in the case that router is performing Network Address
      Translation (NAT) and the Destination Address is translated prior
      to forwarding packets

      Host: any node that is not a router

      Source host: A host that originates and sends an IPv6 packet.
      Only a source host can create the extension headers in a packet.
      In, the absence of NAT, a source host can be identified by the
      Source Address of a packet

      Destination host: A host that is the final destination of a
      forwarded IP packet.  In the absence of NAT, a destination host
      can be identified by the Destination Address when there is no
      Routing header present; or the by address of the last segment in
      when a Routing header is present

      Header chain: The set of consecutive protocol headers in a packet
      that precede the transport payload

      IPv6 header chain: The IPv6 header and the set of following IPv6
      Extension Headers that precede the transport layer in a packet

2.  Overview and motivation of extension header limits

   This specification considers extension header limits in three
   dimensions: 1) The types of nodes that may process extension headers
   and the requirements specific to each type, 2) The types of limits
   that may be applied, 3) The action taken when a limit is exceeded.

2.1.  Types of nodes

   For the purposes of describing handling of extension headers, this
   specification considers three types of node in an IPv6 network:

   *  Hosts (both a host sending extension headers, an a destination
      host receiving extension headers)

   *  Routers not processing routing headers

   *  Routers processing routing headers

Herbert                   Expires 6 April 2024                  [Page 5]
Internet-Draft           Extension Header Limits            October 2023

2.2.  Types of 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

2.2.1.  Limits on extension header length

   [RFC8504] defines limits that may be defined for the length of an
   extension header.  Those limits are extended to be applicable to
   routers.

2.2.2.  Limits on option length

   A node may establish a limit on the length of individual Hop-by-Hop
   or Destination options.  Conceivably, such a limit could apply to all
   option types, or length limits may be specific to individual options.

2.2.3.  Limits on number of extension headers

   A node may define a limit on the number of extension headers it will
   process.

2.2.4.  Limits on number of options

   Limits may be established for the number of options sent or received;
   these limits are specifically applicable to Hop-by-Hop Options
   headers and Destination Options headers.  The need for this limit
   arises from the fact that [RFC8200] does not specify a limit.
   Requiring nodes to process packets with tens or hundreds of options
   has no foreseeable use cases in deployment except as a denial of
   service attack.  [RFC8504] has proposed such a limit for host
   processing of a Hop-by-Hop Options header or Destination Options
   header with a default of eight options.  This specification extends
   that limit to be applicable to routers.  Specific limits may be
   established for the number of non-padding options or the number of
   all options including padding.

Herbert                   Expires 6 April 2024                  [Page 6]
Internet-Draft           Extension Header Limits            October 2023

   To derive a limit for the total number options in an extension
   header, one can assume that at most one padding option is used
   between two non-padding options (an explicit limit on consecutive
   padding options is described below).  With this assumption, we can
   extrapolate a reasonable limit on the number of all options that
   should be twice the limit of the number of non-padding options.  Per
   [RFC8504], the recommended default limit for the number of non-
   padding options is eight, so this specification establishes a default
   limit of sixteen options including padding options.  The choice of
   sixteen options as a default limit attempts to strike a balance
   between allowing extensibility and maintaining reasonable
   expectations for node processing requirements.

   With regards to extensibility, 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 options.  Current evidence
   suggests that having more than one Destination option or Hop-by-Hop
   option in a extension header is rare, and extrapolating that point
   with the rate of new options being defined, suggests a limit of eight
   non-padding options allows for sufficient extensibility in the
   foreseeable future.

   With regards to processing requirements, TLVs, such as Hop-by-Hop
   options and Destination options, have historically been considered
   difficult to process efficiently due to their serial processing
   requirements and combinatorial nature.  TLV processing has been a
   particularly acute problem for ASIC based hardware devices.
   Recently, there is a strong trend in programmable implementation,
   even in high performance routers, towards using emerging programming
   frameworks such as P4.  Programmable implementations are better
   equipped to handle TLVs, at least for a reasonably small number of
   them.  It might also be pointed out that the need to efficiently
   process TLVs exists in other protocols, for instance processing TCP
   requires processing of TLVs in the form of TCP options which are an
   intrinsic part of the protocol.

2.2.5.  Limits on padding options

   [RFC8200] defines PAD1 and PADN options that respectively provide one
   byte or N bytes of padding in a Hop-by-Hop Options or Destination
   Options header.  The purpose of padding is to properly align the
   following non-padding option to its expected alignment, or to add
   padding after the last Destination or Hop-by-Hop option so that the
   length of the extension header is a multiple of eight bytes as
   required by [RFC8200].  [RFC8504] defines host limits on the number
   of bytes used for consecutive padding where the amount of padding
   between options or at the end of the extension header is no more than

Herbert                   Expires 6 April 2024                  [Page 7]
Internet-Draft           Extension Header Limits            October 2023

   seven bytes; this limit is sufficient to align any following data
   after the padding to eight bytes.  These limits are extended by this
   specification to be applicable to routers.

   This specification allows a receiving node to set a requirement that
   consecutive padding options must not present in a packet; which in
   turn requires a sender not to place consecutive padding options in a
   packet.  The rationale for this limit is that a PAD1 or PADN option
   is able to provide one to 257 bytes of padding, so a single padding
   option is sufficient for expected use cases of padding.  When the
   sender creates options, it can compute the amount of padding
   necessary to satisfy the alignment requirements of the following
   data.  If one byte of padding is needed a PAD1 option is used, if
   more than one byte of padding is needed then an appropriate PADN
   option is used.

2.2.6.  Limit on IPv6 header chain length

   Intermediate nodes often perform deep packet inspection (DPI) in
   order to implement various functions in the network.  Routers perform
   DPI when they inspect packets beyond the IPv6 header or beyond the
   Hop-by-Hop Options header if present.  Some router implementations
   must inspect the transport layer headers in order to process and
   forward the packet, and if the transport layer headers are not
   readable then a packet might be discarded.  Even if a transport layer
   header is in plain text within a packet, some devices may not be
   capable of reading it if the header is too deep in the packet.

   Hardware devices often have constraints on how much of the headers in
   a packet can be parsed for DPI.  A typical design is that some
   portion of the beginning of a received packet is loaded for header
   parsing into a specialized memory buffer called the "parsing buffer".
   The size of a parsing buffer is often fixed per device or line cards
   installed in a chassis.

   To derive a size limit for the IPv6 header chain, we need to take
   into account headers in a packet that might be subject to DPI which
   include the link layer header through at least the pertinent fields
   of the transport layer header.  The most common required transport
   layer information is the transport layer port numbers which typically
   occupy the first four bytes of the transport headers (in TCP, UDP,
   SCTP, DCCP, etc.).  Inspection of port numbers may be needed for
   stateless load balancing as well as port filtering.  There are
   middleboxes that may need to inspect more of transport layer headers
   or the transport payload, however those can be considered specialized
   devices that perform work beyond simple packet forwarding and
   filtering and hence should have more capabilities for DPI.

Herbert                   Expires 6 April 2024                  [Page 8]
Internet-Draft           Extension Header Limits            October 2023

   In addition to limits on the length of the IP header chain, it is
   conceivable that there could be a limit on the length of the whole
   header chain in a packet.  The whole header chain would comprise the
   IPv6 header chain as well as any headers that are part of network
   encapsulation that precedes the innermost transport layer.  The
   definition of such a limit is out of scope for this specification,
   however [RFC8883] defines an ICMP Destination Unreachable message
   with code 8 (Headers Too Long) that may be sent when a packet is
   discarded because the aggregate length of the whole header chain
   exceeds a limit.

   This specification specifies that the minimum supported limit for
   IPv6 header chains is 104 bytes.  The value is derived by assuming
   that nodes have the ability to process at least the first 128 bytes
   of a packet (that is they have a parsing buffer that contains at
   least 128 bytes).  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)

   This scheme thus establishes a requirement that all 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.  Note that this establishes a global
   baseline requirement across the Internet; within a limited domain
   higher limits could be applied.

   128 bytes is likely the minimal useful parsing buffer size in
   deployment today.  Devices performing a very narrow DPI could
   conceptually use a smaller parsing buffer, for instance that could be
   as small as sixty-four bytes which accommodates an L2 header, IPv6
   header, and eight bytes of transport header; however, such a device
   would be extremely limited in capabilities and if they do exist they
   are likely legacy devices that will eventually be decommissioned.
   Many routers now have the capability to perform DPI into
   encapsulation headers which implies they already have a larger
   parsing buffer than this baseline minimum.

Herbert                   Expires 6 April 2024                  [Page 9]
Internet-Draft           Extension Header Limits            October 2023

   Similar to limiting the number of options allowing in a packet,
   setting a limit for the IP header length chain is a tradeoff between
   extensibility and feasible implementation.

   For extensibility, the pertinent extension headers contributing to
   the sixty-four byte limit are mostly the Hop-by-Hop Options header
   and the Destination Options header.  The Routing header is really
   intended for limited domains and not the Internet (for instance, the
   SRv6 Routing header is confined to a Segment Routing Domain), and
   therefore would be subject to a domain specific limit for IP header
   chain length.  The Encryption header may be used on the Internet,
   however encryption obfuscates the encapsulated transport headers such
   that such that routers can't inspect them regardless of their
   position in a packet.  Fragmentation may be used in the Internet,
   however only the first fragment of a fragmented packet contains
   transport layer headers that could be read by an Intermediate node.
   In any case, the Fragment header is only four bytes so that would not
   be a particularly large portion of a sixty-four byte limit.  The
   Authentication header is usable on the Internet and does allow
   transport layer headers to be readable in plain text.  The
   Authentication header is relatively large, typically thirty-two bytes
   or more, so it would contribute significantly to a limit on IP header
   chain length.  However, the use of the Authentication header without
   encryption is likely rare on the Internet.

   Individual Hop-by-Hop or Destination options may also be categorized
   as being intended for use over the Internet or just in limited
   domains.  For instance, the IOAM Hop-by-Hop option is intended for
   use in limited domains.

   Paring this down, the types of extension headers and Destination and
   Hop-by-Hop options that might be used outside of limited domains are
   fairly limited.  Options that are intended for use over the public
   Internet could be defined to be small and compact to promote not
   exceeding a sixty-four byte limit on extension headers, whereas
   options constrained to a limited domain could be larger since larger
   limits might be assumed.

2.3.  Actions when limits are exceeded

   For each limit that is defined, an action is specified for when the
   limit is exceeded.  The appropriate action depends on whether the
   processing node is a host, a router not processing routing headers,
   or a router processing routing headers.  For a host, the typical
   action to take when a limit is exceeded is to discard the packet.
   This is appropriate since a host is required to process all of the
   headers in a packet, and if a limit is exceeded then it cannot
   process the packet so there is no other alternative but to discard.

Herbert                   Expires 6 April 2024                 [Page 10]
Internet-Draft           Extension Header Limits            October 2023

   For routers not processing routing headers, the typical action to
   take when a limit is exceeded is to stop processing headers at the
   point the limit is reached and to forward the packet on.  If a router
   processing routing headers needs to access transport layer
   information it may continue inspecting extension headers, but not
   processing them, after a limit has been reached for the purposes of
   locating the transport layer header.  [RFC8200] and
   [I-D.ietf-6man-hbh-processing] allow that routers may not process the
   Hop-by-Hop Options headers, therefore a router processing routing
   headers may ignore all of the Hop-by-Hop options in a packet.  This
   specification expands on that requirement to allow an to process some
   arbitrary subset of consecutive Hop-by-Hop options in the TLV list
   and to ignore the following ones.  In the case of an egregious
   violation of a limit, for instance an attacker sends three hundred
   options in a packet, the host can decide if the appropriate response
   is to discard (the host must process all options).  Note that this
   provision motivates the sender to place Hop-by-Hop options in the
   extension header so that those considered more important are placed
   first.  It should also be noted that [RFC8504] sets a default limit
   of eight; this specification adds a counterpart for sending hosts
   that they shouldn't send more than eight Hop-by-Hop options by
   default.

   With regards to extension header processing, routers processing
   routing headers have characteristics of both hosts and and routers
   not processing routing headers.  If a limit is exceeded related to
   Hop-by-Hop options then the suggested action in this specification is
   to assume the same processing of limits as routers not processing
   routing headers.  If limits are exceeded that affect the processing
   specific to the destination, such as limits on a Destination Options
   header before the Routing header, then the action should be to
   discard packet as would be done for a destination host processing
   Destination Options.

2.4.  Design Philosophy

   The limits defined in this specification are applicable to both
   senders and receivers.  With a few exceptions as described below, the
   limits described herein are optional to configure and enforce.  If a
   limit is configurable then there is a suggested default value.

   A sender of extension headers should generally be conservative in its
   use of extension headers to maximize the chances of packets being
   delivered to their destination.  Default values for sending limits
   are assumed to be useful in arbitrary environment such as the public
   Internet, that is they can be considered "baseline limits".  These
   limits may be relaxed if a sender has a priori information that all
   possible nodes in path will properly handle packets that exceed the

Herbert                   Expires 6 April 2024                 [Page 11]
Internet-Draft           Extension Header Limits            October 2023

   baseline limits.  In particular, if a sender is sending in a limited
   domain, it might be known that all nodes in the limited domain have
   sufficient capabilities to handle packets exceeding the baseline
   limits.

   Specific mechanisms for a host to determine that baseline limits for
   extension headers may be exceeded are out of scope for this
   specification.  Conceivably, this determination could be done by
   configuration, capabilities probing, or applying historical knowledge
   that all routers in the path and the destination node are capable of
   handling packets that exceed the baseline limits.

   Receivers of extension headers should be liberal in accepting packets
   with extension headers, however per this specification they may
   ignore extension headers or options within extension headers (in
   accordance with [RFC8200]).  In particular, the philosophy of this
   specification is that routers should not discard packets with
   extension headers solely on the basis that they don't have sufficient
   capabilities to process all the headers in a packet.  As such,
   routers may define arbitrarily restrictive limits on what they
   process with regards to extension headers as long as the action taken
   when those limits are exceeded is to ignore items beyond the limit.
   Hosts are more constrained in this regard since they generally can't
   correctly process a packet without processing all the headers, so
   when limits are exceeded on a host, packets should be discarded.  It
   should be noted that hosts typically have more processing
   capabilities than routers, so it is expected that they should be able
   to support higher limits for processing extension headers.

   This specification does specify one hard requirement for receiving
   nodes, namely nodes must be able to properly handle packets having an
   IPv6 header chain length up to 104 bytes.  This requirement
   acknowledges that some routers perform deep packet inspection to
   extract information from transport layer headers [RFC9098].  Often a
   node that requires parsing transport layer information will have a
   fixed sized "parsing buffer" to contain packet headers.  If the
   transport layer headers within a packet are beyond the extent of the
   parsing buffer then an implementation might take some detrimental
   action such as arbitrarily discarding packets.  To this end, this
   specification requires that any router that requires access to to
   transport layer header must minimally be able to parse at least 128
   bytes of headers, from which the 104 byte limit for the IP header
   chain is derived.

Herbert                   Expires 6 April 2024                 [Page 12]
Internet-Draft           Extension Header Limits            October 2023

3.  Requirements

   This section lists the normative requirements related to sending and
   processing extension headers.  The requirements in this section
   extends the limits described in section 5.3 of [RFC8504] by making
   them to be applicable to routers as well as hosts.

3.1.  List of limits

   The set of limits that a node may apply when processing extension
   headers include:

   *  Too many non-padding or padding options

   *  Extension header too big

   *  Option too big

   *  Too many consecutive padding options

   *  Too many consecutive bytes of padding

   *  Extension header chain too long

   *  Aggregate header chain too long

   *  Too many extension headers

3.2.  Host requirements

3.2.1.  Source host requirements

   The requirements 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 routers processing routing headers in
      the case of a Destination Options header before the routing header
      in the path, are able to process a greater number of options.

   *  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
      the destination host is able to process a greater number of
      options.

Herbert                   Expires 6 April 2024                 [Page 13]
Internet-Draft           Extension Header Limits            October 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 in the path are able to process a greater
      number of options or will ignore options that exceeds their limit.

   *  A source host SHOULD NOT send a packet with a Hop-by-Hop Options
      header or a Destination Options header larger than 64 bytes unless
      it has explicit knowledge that all nodes that might process the
      extension headers are capable of processing a larger header.

   *  A source host SHOULD NOT send a packet with a Destination option
      in a Destination Option header or Hop-by-Hop option in a Hop-by-
      Hop Option header with Data Length greater than 60 bytes unless it
      has explicit knowledge that all nodes that might process the
      option are capable of processing options with a larger Data
      Length.

   *  A source host SHOULD NOT send a packet with an IPv6 header chain
      larger than 104 bytes unless the IPv6 header chain contains an
      IPsec header that obfuscates the transport layer header, the
      packet doesn't contain a transport layer header, or the source
      host has explicit knowledge that all nodes in the path that might
      need to parse the transport layer of packets are capable of
      properly handling packets with larger header chains.  This
      requirement is equivalently stated as a host SHOULD NOT send a
      packet with more than 64 bytes of aggregate extension headers, or
      a host SHOULD not send a packet where the offset of the plain text
      transport layer is greater than 108 bytes in the packet.

   *  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 PadN option in a Hop-by-Hop
      Options header or Destination Options header with total length of
      more than seven bytes.

   *  A source host SHOULD NOT send more than 16 (padding or non-
      padding) options in a Destination Options header unless it has
      explicit knowledge that the destination host and all routers
      processing routing headers in the path in the case of a
      Destination Options header before the routing header, are able to
      process a greater number of options.  Note that if the above
      requirements on a host sending non-padding Destination options and
      requirements on option padding are met, then this requirement is
      implicitly satisfied.

Herbert                   Expires 6 April 2024                 [Page 14]
Internet-Draft           Extension Header Limits            October 2023

   *  A source host node SHOULD NOT send more than 16 options (padding
      or non-padding) in a Hop-by-Hop Options header unless it has
      explicit knowledge that the destination host is able to process a
      greater number of options.  Note that if the above requirements on
      a host sending non-padding Hop-by-Hop options and requirements on
      padding are met, then this requirement is implicitly satisfied.

3.2.2.  Receiving extension headers by destination hosts

   Per [RFC8200], a destination host that receives a packet with
   extension headers must process all the extension headers in the
   packet before accepting the payload and processing the payload.

   As described in [RFC8504] a destination host may establish limits on
   the processing of extension headers.  This specification reiterates
   and updates those requirements to allow for a host to send an RFC8883
   error if a limit has been exceeded.

   *  Per [RFC8504], a destination host 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 default value SHOULD be set
      to 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 destination host 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 destination host MAY set a limit on the maximum number of
      options (padding or non-padding) allowed in a Destination Options
      header or Hop-by-Hop Options header.  If this limit is supported
      then the maximum number SHOULD be configurable and the limit
      SHOULD be greater than or equal to 16.  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
      destination host 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.

   *  Per [RFC8504], a destination host 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 different extension headers MAY be separately

Herbert                   Expires 6 April 2024                 [Page 15]
Internet-Draft           Extension Header Limits            October 2023

      configurable.  If a packet is received and the length of an
      extension header exceeds the limit, then the destination host
      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 destination host node MAY set a limit on the Data Length of a
      Hop-by-Hop or Destination option.  If this limit is supported then
      the limit SHOULD be configurable, and the limit SHOULD be greater
      than or equal to 60 bytes.  The limits for Destination options and
      Hop-by-Hop options MAY be separately configurable.  If a packet is
      received and a Hop-by-Hop or Destination option has a length that
      exceeds the limit, then the host SHOULD discard the packet and MAY
      send an ICMP Parameter Problem message with code 10 (Option Too
      Big) [RFC8883] to the packet's source address.

   *  Per [RFC8504], a destination host MAY limit the number of
      consecutive PAD1 options in a Destination Options header or Hop-
      by-Hop Options header to 7.  If a packet is received and there are
      more than 7 consecutive PAD1 options present, then the destination
      host 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.

   *  Per [RFC8504], a destination host MAY limit the number of bytes in
      a PADN option to be less than 8.  If a packet is received an a
      PADN option is present that has a length greater than 7, then the
      destination host SHOULD discard the packet and MAY send an ICMP
      Parameter Problem message with code 10 (Option Too Big) [RFC8883]
      to the packet's source address.

   *  A destination host MAY set a limit on the maximum length of a
      Destination Options header or Hop-by-Hop Options header.  This
      value SHOULD be configurable, and if the limit is set then the
      limit SHOULD be greater than or equal to 64 bytes.  If a packet is
      received and the length of the Destination Options header or Hop-
      by-Hop Options header exceeds the length limit, then the
      destination host 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 destination host 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 used 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

Herbert                   Expires 6 April 2024                 [Page 16]
Internet-Draft           Extension Header Limits            October 2023

      exceeds the limit, then the destination host 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 destination host MAY disallow consecutive padding options,
      either PAD1 or PADN, to be present in a packet.  If packet is
      received with consecutive padding options that are disallowed by
      the host, then the host 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.

3.3.  Router requirements

   The following common requirements are established for routers
   including both routers not processing routing headers and routers not
   processing routing headers.  The limits described in this section
   should all be configurable and there are no default values specified
   if the limits are set.

   *  If a router needs to parse the transport layer 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 an router MUST be able to process a packet with an
      aggregate length of extension headers less than or equal to 64
      bytes, or equivalently the router must be able to parse the port
      numbers of a transport layer header in plaintext when the offset
      of the transport layer header in the packet is equal to or less
      than 120 bytes.

   *  Per [RFC8200] a router MAY be configured not to process Hop-by-Hop
      Options headers.  If a router is configured as such and a packet
      with a Hop-by-Hop Options header is received, the extension header
      MUST be be skipped and the packet MUST otherwise be properly
      processed and forwarded.

   *  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 6 April 2024                 [Page 17]
Internet-Draft           Extension Header Limits            October 2023

   *  A router MAY limit the number of Hop-by-Hop options (padding or
      non-padding) that it processes.  If a packet is received with a
      Hop-by-Hop Options header having a number of non-padding and
      padding options that exceeds the limit, then the router SHOULD
      stop processing the Hop-by-Hop Options 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.

   *  If a router encounters an unknown Hop-by-Hop option and the two
      high order bits are not 00 then the router SHOULD immediately stop
      processing the Hop-by-Hop Options header and ignore any Hop-by-Hop
      options beyond the unknown option.  A router node MAY either elect
      to discard the packet per the requirements of [RFC8200] and
      [I-D.ietf-6man-hbh-processing], or the router MAY forward the
      packet and effectively disregard the high order two bits in the
      option type.  The motivation for this requirement is to simplify
      processing at routers.  Note, that if the high order two bits are
      non-zero for an option that is unknown to the destination host
      then the packet will be discarded since the destination host is
      required to process all Hop-by-Hop options in a packet or to
      discard a packet if its limit for maximum number of options to
      process is exceeded.  If a router elects to discard the packet and
      the high two order bits of the option type are 10 or are 11 and
      the packet's Destination Address was not a multicast address, then
      the router MAY send an ICMP Parameter Problem message with code 2
      (Unrecognized Option Type) [RFC8200] 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 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 6 (Extension Header Too Big) [RFC8883]
      to the packet's source address.

3.4.  Intermediate destination requirements

   The following are requirements specific to routers processing routing
   headers pertaining to the processing of a Destination Options header
   before the Routing header.

Herbert                   Expires 6 April 2024                 [Page 18]
Internet-Draft           Extension Header Limits            October 2023

   *  A router processing routing headers MAY limit the maximum length
      of a Destination Options header before the Routing header.  This
      value SHOULD be configurable, and the default is to accept options
      of any length.  If a limit is defined, it MUST be at least 64
      bytes.  If packet is received with a Destination Options header
      before the Routing header having a length that exceeds the limit,
      then the router processing routing headers 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.

   *  An router processing routing headers MAY limit the number of non-
      padding options in a Destination Options header before the Routing
      header.  If this limit is supported then the maximum number SHOULD
      be configurable and the limit MUST be greater than or equal to 8.
      If packet is received with a Destination Options header before the
      Routing header that contains more non-padding options than the
      limit, then the router processing routing headers 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.

   *  An router processing routing headers node MAY limit the number of
      options (padding or non-padding) in a Destination Options header
      before the Routing header.  If this limit is supported then the
      maximum number SHOULD be configurable and the limit MUST be
      greater than or equal to 16.  If packet is received with a
      Destination Options header before the Routing header that contains
      more non-padding options than the limit, then the router
      processing routing headers 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.

   *  An router processing routing headers MAY limit the total number
      bytes in consecutive PAD1 options in a Destination Options header
      before the Routing header to 7.  If packet is received with a
      Destination Options header before the Routing header that contains
      more than seven consecutive PAD1 options and the limit is enabled,
      then the router processing routing headers 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.

   *  An router processing routing headers MAY limit the number of bytes
      in a PADN option in a Destination Option header before the Routing
      header to be less than 8.  If packet is received with a
      Destination Options header before the Routing header that more
      contains a PADN option with more than seven bytes, then the router

Herbert                   Expires 6 April 2024                 [Page 19]
Internet-Draft           Extension Header Limits            October 2023

      processing routing headers SHOULD discard the packet and MAY send
      an ICMP Parameter Problem message with code 10 (Option Too Big)
      [RFC8883] to the packet's source address.

   *  An router processing routing headers MAY set a limit for the
      maximum length of a Destination Options header before the Routing
      header.  If this limit is supported then the limit SHOULD be
      configurable and the limit MUST be greater than or equal to 64
      bytes.  If packet is received with a Destination Options header
      before the Routing header with a length that exceeds the limit,
      then the router processing routing headers SHOULD discard the
      packet and MAY send an ICMP Parameter Problem message with code 10
      (Option Too Big) [RFC8883] to the packet's source address.

4.  Security Considerations

   Security issues with IPv6 Hop-by-Hop options are well known and have
   been documented in several places, including [RFC6398], [RFC6192],
   [RFC7045] and [RFC9098].

   Of particular concern is a Distributed Denial-of-Service attack
   (DDOS) 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 that will be unknown to the receiver 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 hard to do efficiently (in either hardware or software).

   This specification addresses the DDOS concern of extension headers
   and options in extension headers by allowing receivers to configure
   limits the number of extension headers or options that they process.
   Such limits cap the amount of processing needed for extension headers
   and hence mitigate the DDOS concerns of extension headers.

   This specification does not otherwise introduce any new security
   concerns.

5.  Acknowledgments

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

Herbert                   Expires 6 April 2024                 [Page 20]
Internet-Draft           Extension Header Limits            October 2023

6.  References

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

6.2.  Informative References

   [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-10, 26 September 2023,
              <https://datatracker.ietf.org/doc/html/draft-ietf-6man-
              hbh-processing-10>.

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

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

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

Herbert                   Expires 6 April 2024                 [Page 21]
Internet-Draft           Extension Header Limits            October 2023

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

Author's Address

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

Herbert                   Expires 6 April 2024                 [Page 22]