IPv6 Hop-by-Hop Options Processing Procedures
draft-ietf-6man-hbh-processing-20

Network Working Group                                          R. Hinden
Internet-Draft                                      Check Point Software
Updates: 8200 (if approved)                                 G. Fairhurst
Intended status: Standards Track                  University of Aberdeen
Expires: 7 December 2024                                     5 June 2024

             IPv6 Hop-by-Hop Options Processing Procedures
                   draft-ietf-6man-hbh-processing-20

Abstract

   This document specifies procedures for how IPv6 Hop-by-Hop options
   are processed in IPv6 routers and hosts.  It modifies the procedures
   specified in the IPv6 Protocol Specification (RFC 8200) to make
   processing of the IPv6 Hop-by-Hop Options header practical with the
   goal of making IPv6 Hop-by-Hop options useful to deploy and use in
   the Internet.  When published, this document updates RFC 8200.

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 7 December 2024.

Copyright Notice

   Copyright (c) 2024 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Hinden & Fairhurst       Expires 7 December 2024                [Page 1]
Internet-Draft           HBH Options Processing                June 2024

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   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
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   3
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Background  . . . . . . . . . . . . . . . . . . . . . . . . .   4
   5.  Hop-by-Hop Header Processing Procedures . . . . . . . . . . .   7
     5.1.  Processing the Extension Header Carrying Hop-by-Hop
           Options . . . . . . . . . . . . . . . . . . . . . . . . .   8
       5.1.1.  Configuration Enabling Hop-by-Hop Header
               Processing  . . . . . . . . . . . . . . . . . . . . .   8
     5.2.  Hop-by-Hop Options Processing . . . . . . . . . . . . . .   9
       5.2.1.  Router Alert Option . . . . . . . . . . . . . . . . .  11
       5.2.2.  Configuration of Hop-by-Hop Option Processing . . . .  12
   6.  Defining New Hop-by-Hop Options . . . . . . . . . . . . . . .  12
     6.1.  Example of Robust Usage . . . . . . . . . . . . . . . . .  13
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  14
   9.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  16
   10. Change log [RFC Editor: Please remove]  . . . . . . . . . . .  16
   11. Normative References  . . . . . . . . . . . . . . . . . . . .  20
   12. Informative References  . . . . . . . . . . . . . . . . . . .  20
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  22

1.  Introduction

   This document specifies procedures for processing IPv6 Hop-by-Hop
   options in IPv6 routers and hosts.  It modifies the procedures
   specified in the IPv6 Protocol Specification [RFC8200] to make
   processing of IPv6 Hop-by-Hop Options header practical with the goal
   of making IPv6 Hop-by-Hop options useful to deploy and use at IPv6
   routers and hosts.

Hinden & Fairhurst       Expires 7 December 2024                [Page 2]
Internet-Draft           HBH Options Processing                June 2024

   An IPv6 packet includes Hop-by-Hop options by including a Hop-by-Hop
   Options header.  The current list of defined Hop-by-Hop options can
   be found at [IANA-HBH].  The focus for this document is to set the
   minimum requirements for router processing of Hop-by-Hop options.  It
   also discusses how Hop-by-Hop options are used by hosts.  This
   document does not propose a specific bound to the number or size of
   Hop-by-Hop options that ought to be processed.

   When published, this document updates [RFC8200].

2.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

3.  Terminology

   This document uses the following loosely defined terms:

   *  forwarding plane: IPv6 routers exchange user or applications data
      through the forwarding plane.  Routers process fields contained in
      IPv6 packet headers.  However, they do not process information
      contained in packet payloads.

   *  control plane: IPv6 routers exchange control information through
      the control plane.  The control plane processes the management and
      routing information exchanged with other routers.

   *  Fast Path: A path through a router that is optimized for
      forwarding packets.  The Fast Path might be supported by
      Application Specific Integrated Circuits (ASICs), a Network
      Processor (NP), or other special purpose hardware.  This is the
      typical processing path within a router taken by the forwarding
      plane.

   *  Slow Path: A path through a router that is capable of general
      purpose processing and is not optimized for any particular
      function.  This processing path is used for packets that require
      special processing or differ from assumptions made in Fast Path
      heuristics or to process router control protocols used by the
      control plane.

Hinden & Fairhurst       Expires 7 December 2024                [Page 3]
Internet-Draft           HBH Options Processing                June 2024

   *  Full Forwarding Rate: This is the rate that a router can forward
      packets without adversely impacting the aggregate forwarding rate.
      For example, a router could process packets with Hop-by-Hop
      options at a rate that allows it to maintain the full speed on its
      outgoing interfaces, which is sometimes called "wire speed".

   *  source: The node originating the packet.

   NOTE: [RFC6192] is an example of how designs can separate control
   plane and forwarding plane functions.  The separation between
   hardware and software processing described in [RFC6398] does not
   apply to all router architectures.  However, a router that performs
   all or most processing in software might still incur more processing
   cost when providing special processing for Hop-by-Hop options.

4.  Background

   In the first versions of the IPv6 specification [RFC1883] and
   [RFC2460], Hop-by-Hop options were required to be processed by all
   nodes: routers and hosts.  This proved to not be practical in current
   high speed routers, as observed in Section 2.2 of RFC7045: "it is to
   be expected that high-performance routers will either ignore it or
   assign packets containing it to a slow processing path".  The reason
   behind this includes:

   *  Inability to process Hop-by-Hop options at the full forwarding
      rate can result in issues.  In some cases, Hop-by-Hop options
      would be sent to the control/management components that run on the
      slow path.  This could degrade a router's performance and also its
      ability to process critical control traffic.  Both of which could
      be exploited as a Denial-of-Service attack against the router.

   *  If a subset of packets within a flow includes Hop-by-Hop options,
      this could lead to an increased number of reordered packets and
      greater reordering distances for packets delivered to the
      destination.  Such reordering could occur if the Hop-by-Hop
      Options header is included only in some packets, or if a specific
      Hop-by-Hop option results in different processing for some of the
      packets within the flow.  Significant reordering of packets within
      a flow can negatively impact the performance of upper-layer
      protocols and should therefore be avoided.

Hinden & Fairhurst       Expires 7 December 2024                [Page 4]
Internet-Draft           HBH Options Processing                June 2024

   *  Packets could include multiple Hop-by-Hop options.  Too many
      options could make the previous issues worse by increasing the
      resources required to process them.  The total size of the options
      determines the number of header bytes that might need to be
      processed.  Measurements [Cus23a] show that the probability of
      successful transmission across the public Internet is currently
      higher for packets that include Options when it results in a short
      total Extension Header (EH) Chain size (i.e., less than 40 bytes).

   [RFC6564] specified a uniform format for new IPv6 Extension Headers.
   It updated [RFC2460], and this update was incorporated into
   Section 4.8 of [RFC8200].

   When the IPv6 Specification was updated and published in July 2017 as
   [RFC8200], the procedures relating to Hop-by-Hop options were
   specified ([RFC8200], Section 4) as follows:

      The Hop-by-Hop Options header is not inserted or deleted, but may
      be examined or processed by any node along a packet's delivery
      path, until the packet reaches the node (or each of the set of
      nodes, in the case of multicast) identified in the Destination
      Address field of the IPv6 header.  The Hop-by-Hop Options header,
      when present, must immediately follow the IPv6 header.  Its
      presence is indicated by the value zero in the Next Header field
      of the IPv6 header.

      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.

   The changes meant that an implementation complied with the IPv6
   specification even if it did not process Hop-by-Hop options, and that
   it was expected that routers would add configuration information to
   control whether they process the Hop-by-Hop Options header.  In
   practice, routers may include configuration options to control which
   Hop-by-Hop options they will process.

   The text regarding processing of Hop-by-Hop options in [RFC8200] was
   not intended to change the processing of these options.  It
   documented how they were being used in the Internet at the time RFC
   8200 was published (see Appendix B of [RFC8200]).  This was a
   constraint on publishing the IPv6 specification as an IETF Standard.

   The main issues remain:

Hinden & Fairhurst       Expires 7 December 2024                [Page 5]
Internet-Draft           HBH Options Processing                June 2024

   *  Routers can be configured to drop transit packets containing Hop-
      by-Hop Options that would have required processing by a processor
      that implements the control plane.  This could be done to protect
      against a Denial-of-Service attack on the router
      [RFC9098][RFC9288].

   *  IPv6 Packets that include a Hop-by-Hop Options header are dropped
      by some Internet paths.  A survey in 2015 reported a high loss
      rate in transit ASs for packets with Hop-by-Hop options [RFC7872].
      The operational implications of IPv6 Packets that include
      Extension Headers are discussed in [RFC9098].  Measurements in
      2023 confirm this to still be the case for many types of network
      paths [Cus23b].

   *  Allowing multiple Hop-by-Hop options in a single packet in some
      cases consumes more router resources to process these packets.  It
      also adds complexity to the number of permutations that might need
      to be processed/configured.

   *  Including larger or multiple Hop-by-Hop options in a Hop-by-Hop
      Options header increases the number of bytes that need to be
      processed in forwarding, which can in some designs impact the cost
      of processing a packet, and in turn could increase the probability
      of drop [RFC7872].  A larger Extension Header could also reduce
      the probability that a router can locate all the header bytes
      required to successfully process an access control list operating
      on fields after the Hop-by-Hop Options header.

   *  Any option that can be used to force packets into the processor
      that implements the router's control plane can be exploited as a
      Denial-of-Service attack on a transit router by saturating the
      resources needed for router management protocols (routing
      protocols, network management protocols, etc.), that could cause
      adverse router operation.  This is an issue for the Router Alert
      Hop-by-Hop Option [RFC2711], which intentionally forwards packets
      to the control plane, and is discussed in [RFC6398].  This impact
      could be mitigated by limiting the use of control plane resources
      by a specific packet, and/or by the use of per-function rate-
      limiters for packets processed by the control plane.

   Section 3 of RFC 6398 includes a summary of processing the IP Router
   Alert Option:

      "In a nutshell, the IP Router Alert Option does not provide a
      convenient universal mechanism to accurately and reliably
      distinguish between IP Router Alert packets of interest and
      unwanted IP Router Alert packets.  This, in turn, creates a
      security concern when the IP Router Alert option is used, because,

Hinden & Fairhurst       Expires 7 December 2024                [Page 6]
Internet-Draft           HBH Options Processing                June 2024

      short of appropriate router-implementation-specific mechanisms,
      the router Slow Path is at risk of being flooded by unwanted
      traffic."

   This is an example of the need to limit the resources that can be
   consumed when a particular function is executed and to avoid
   consuming control-plane resources where support for a function has
   not been configured.

   There has been research that has discussed the general problem with
   dropping packets containing IPv6 Extension Headers, including the
   Hop-by-Hop Options header.  For example, [Hendriks] states that
   "dropping all packets with Extension Headers, is a bad practice", and
   that "The share of traffic containing more than one EH however, is
   very small.  For the design of hardware able to handle the dynamic
   nature of Extension Headers we therefore recommend to support at
   least one EH".  Operational aspects of the topics discussed in this
   section are further discussed in [I-D.ietf-v6ops-hbh].

   "Transmission and Processing of IPv6 Extension Headers" [RFC7045]
   clarified how intermediate nodes should process Extension Headers.
   The present document is generally consistent with [RFC7045], and
   addresses an issue that was raised for discussion when [RFC2460] was
   updated and replaced by [RFC8200].  This document updates [RFC8200]
   as described in the next section and consequently clarifies the
   description in Section 2.2 of [RFC7045], using the language of BCP 14
   [RFC2119] [RFC8174].

   This document defines a set of procedures for the Hop-by-Hop Options
   header that are intended to make the processing of Hop-by-Hop options
   practical in modern routers.  The common cases are that some Hop-by-
   Hop options will be processed across the Internet, while others will
   only be processed within a limited domain [RFC8799] (e.g., where a
   specific service is made available in that network segment that
   relies on one or more Hop-by-Hop options).

5.  Hop-by-Hop Header Processing Procedures

   This section describes several changes to [RFC8200].  Section 5.1
   describes processing of the Hop-by-Hop options Extension Header, and
   Section 5.2 describes processing of individual Hop-by-Hop Options.
   These sections updates the text in paragraphs 5 and 6 of Section 4 of
   [RFC8200] and as noted in Section 5.2 modifies Section 4.2 of
   [RFC8200].

Hinden & Fairhurst       Expires 7 December 2024                [Page 7]
Internet-Draft           HBH Options Processing                June 2024

5.1.  Processing the Extension Header Carrying Hop-by-Hop Options

   When a packet includes one or more Extension Headers, the Next Header
   field of the IPv6 Header identifies the type of Extension Header.  It
   does not identify the transport protocol.

   The Extension Header used to carry Hop-by-Hop options is defined in
   Section 4.3 of [RFC8200] and is identified by a Next Header value of
   0 in the IPv6 header.  Section 4.1 of [RFC8200] requires this Hop-by-
   Hop Options header to appear immediately after the IPv6 header.
   [RFC8200] also requires that a Hop-by-Hop Options header only appear
   at most once in a packet.

   The Hop-by-Hop Options Header as defined in [RFC8200] can contain one
   or more Hop-by-Hop options.

   Routers that process the Hop-by-Hop Options header SHOULD do so using
   the method defined in this document.  Exceptions to this "SHOULD"
   include routers that are configured to drop packets with a Hop-by-Hop
   Options header to protect downstream devices that do not comply with
   this specification (see [RFC9288]).

   Even if a router does not process the Hop-by-Hop Options header (for
   example, based on configuration), it MUST forward the packet normally
   based on the remaining Extension Header(s) after the Hop-by-Hop
   Options header.  A router MUST NOT drop a packet solely because it
   contains an Extension Header carrying Hop-by-Hop options.  A
   configuration could control that normal processing skips any or all
   of the Hop-by-Hop options carried in the Hop-by-Hop Options header.

   It is expected that the Hop-by-Hop Options header will be processed
   by the destination(s).  Hosts SHOULD process the Hop-by-Hop Options
   header in received packets.  A constrained host is an example of a
   node that does not process the Hop-by-Hop Options header.  If a
   destination does not process the Hop-by-Hop Options header, it MUST
   process the remainder of the packet normally.

5.1.1.  Configuration Enabling Hop-by-Hop Header Processing

   Section 4 of [RFC8200] allows a router to control its processing of
   IPv6 Hop-by-Hop options by local configuration.  The text is:

      NOTE: While [RFC2460] required that all nodes must examine and
      process the Hop-by-Hop Options header, it is now expected that
      nodes along the path only examine and process the Hop-by-Hop
      Options header if explicitly configured to do so.

Hinden & Fairhurst       Expires 7 December 2024                [Page 8]
Internet-Draft           HBH Options Processing                June 2024

   This document clarifies that a configuration could control whether
   processing skips any specific Hop-by-Hop options carried in the Hop-
   by-Hop Options header.  A router that does not process the contents
   of the Hop-by-Hop Options header does not therefore process the
   option types of individual Option Types to perform any specified
   action.

5.2.  Hop-by-Hop Options Processing

   A source creating packets with a Hop-by-Hop Options header SHOULD use
   a method that is robust to network nodes selectively processing only
   some of the Hop-by-Hop options that are included in the packet, or
   that forward packets without the option(s) being processed (see
   Section 6.1).  A source MAY, based on local configuration, allow only
   one Hop-by-Hop option to be included in a packet, or could allow more
   than one Hop-by-Hop options, but limit their size to increase the
   likelihood of successful transfer across a network path.  Because
   some routers might only process one or a limited number of options in
   the Hop-by-Hop Option header, sources are motivated to order the
   placement of Hop-by-Hop options within the Hop-by-Hop Options header
   in decreasing order of importance for their processing by nodes on
   the path.

   A router configuration needs to avoid vulnerabilities that arise when
   it cannot process the first Hop-by-Hop option at full forwarding
   rate.  A router SHOULD NOT therefore be configured to process the
   first Hop-by-Hop option if this adversely impacts the aggregate
   forwarding rate.  A router SHOULD process additional Hop-by-Hop
   options, if configured to do so, providing that these also do not
   adversely impact the aggregate forwarding rate.

   If a router is unable to process a specific Hop-by-Hop option (or is
   not configured to do so), it SHOULD behave in the way specified for
   an unrecognized Option Type when the action bits were set to "00" and
   SHOULD skip the remaining options using the "Hdr Ext Len" field in
   the Hop-by-Hop Options header.  This field specifies the length of
   the Options Header in 8-octet units.  After skipping an option, the
   router continues processing the remaining options in the header.
   Skipped options do not need to be verified.

   The Router Alert Option [RFC2711] is an exception to this because it
   is designed to tell a router that the packet needs additional
   processing, usually done in the control plane, see Section 5.2.1.

   Section 4.2 of [RFC8200] defines the Option Type identifiers as
   internally encoded such that their highest-order 2 bits specify the
   action that must be taken if the processing IPv6 node does not
   recognize the Option Type.  The text is:

Hinden & Fairhurst       Expires 7 December 2024                [Page 9]
Internet-Draft           HBH Options Processing                June 2024

      00 - skip over this option and continue processing the header.

      01 - discard the packet.

      10 - discard the packet and, regardless of whether or not the
           packet's Destination Address was a multicast address, send an
           ICMPv6 Parameter Problem, Code 2 [RFC4443], message to the
           packet's Source Address, pointing to the unrecognized Option
           Type.

      11 - discard the packet and, only if the packet's Destination
           Address was not a multicast address, send an ICMPv6 Parameter
           Problem, Code 2, message to the packet's Source Address,
           pointing to the unrecognized Option Type.

   This document modifies this behaviour for the "01", "10", and "11"
   action bits, so that if a router is unable to process a specific Hop-
   by-Hop option (or is not configured to do so), it SHOULD behave in
   the way specified for an unrecognized Option Type when the action
   bits were set to "00".  It also modifies the behaviour for the "10"
   and "11" values for the case when the packet is discarded, the node
   MAY send an ICMP Parameter Problem, Code 2 [RFC4443], message to the
   packet's Source Address, pointing to the unrecognized Option Type.

   The modified text for "01", "10", and "11" values is:

       01 - MAY discard the packet, if so configured. Nodes should not
            rely on routers dropping these unrecognized Option Types.

       10 - MAY discard the packet, if so configured, and, regardless of
            whether or not the packet's Destination Address was a
            multicast address. If the packet was discarded, it MAY send
            an ICMP Parameter Problem, Code 2, message to the packet's
            Source Address, pointing to the unrecognized Option Type.

       11 - MAY discard the packet, if so configured. Only if the
            packet was discarded and the
            packet's Destination Address was not a multicast address,
            it MAY send an ICMP Parameter
            Problem, Code 2, message to the packet's Source Address,
            pointing to the unrecognized Option Type.

   When an ICMP Parameter Problem, Code 2, message is delivered to the
   source, it indicates that at least one node on the path has failed to
   recognize the option [RFC4443].  Generating any ICMP message incurs
   additional router processing.  Reception of this message is not
   guaranteed, routers might be unable to be configured so that they do

Hinden & Fairhurst       Expires 7 December 2024               [Page 10]
Internet-Draft           HBH Options Processing                June 2024

   not generate these messages, and they are not always forwarded to the
   source.  The motivation here is to loosen the requirement to send an
   ICMPv6 Parameter Problem message when a router forwards a packet
   without processing the list of all options.

5.2.1.  Router Alert Option

   The purpose of the Router Alert Option [RFC2711] is to tell a router
   that the packet needs additional processing in the control plane.

   The Router Alert Option includes a two-octet Value field that
   describes the protocol that is carried in the packet.  The current
   specified values can be found in the IANA Router Alert Value registry
   [IANA-RA].

   DISCUSSION

      The function of a Router Alert Option can result in the processing
      that this specification is proposing to eliminate, that is, to
      instruct a router to process the packet in the control plane.
      This results in the concerns discussed in section 4.  One approach
      would be to deprecate this, because current usage beyond the local
      network appears to be limited, and packets containing Hop-by-Hop
      options are frequently dropped.  Deprecation would allow current
      implementations to continue and its use could be phased out over
      time.

      The Router Alert Option could have a potential for use with new
      functions that have to be processed in the control plane.  Keeping
      this as the single exception for processing in the control plane
      with the following restrictions is a reasonable compromise to
      allow future flexibility.  These restrictions are compatible with
      Section 5 of [RFC6398].

   As noted in [RFC6398], "Implementations of the IP Router Alert option
   SHOULD offer the configuration option to simply ignore the presence
   of the IP Router Alert in IPv4 and IPv6 packets."

   A node that is configured to process a Router Alert option MUST
   protect itself from infrastructure attack that could result from
   processing in the control plane.  This might include some combination
   of an access control list to only permit this from trusted nodes,
   rate limiting of processing, or other methods [RFC6398].

   As specified in [RFC2711] the top two bits of Option Type for the
   Router Alert Option are always set to "00" indicating the node should
   skip over this option as if it does not recognize the Option Type and
   continue processing the header.  An implementation that does

Hinden & Fairhurst       Expires 7 December 2024               [Page 11]
Internet-Draft           HBH Options Processing                June 2024

   recognize the Router Alert Option SHOULD verify that a Router Alert
   Option contains a protocol, as indicated by the Value field in the
   Router Alert Option, that is configured as a protocol of interest to
   that router.  A verified packet SHOULD be sent to the control plane
   for further processing [RFC6398].  Otherwise, the router
   implementation SHOULD forward this packet subject to all normal
   policies and forwarding rules.

5.2.2.  Configuration of Hop-by-Hop Option Processing

   A router can be configured to process a specific Option.  The set of
   enabled options SHOULD be configurable by the operator of the router.

   A possible approach to implementing this is to maintain a lookup
   table based on Option Type of the IPv6 options that can be processed
   at full forwarding rate.  This would allow a router to quickly
   determine if an option is supported and can be processed.  If the
   option is not supported, then the router processes the option as
   described in Section 5.1 of this document.

   The actions of the lookup table should be configurable by the
   operator of the router.

6.  Defining New Hop-by-Hop Options

   This section updates Section 4.8 of [RFC8200].

   Any new IPv6 Hop-by-Hop option designed in the future should be
   designed to be processed at full forwarding rate.  New Hop-by-Hop
   options should have the following characteristics:

   *  New Hop-by-Hop options should be designed to ensure the router can
      process the options at the full forwarding rate.  That is, they
      should be simple to process.

   *  New options should be defined with the Action type (highest-order
      2 bits of the Option Type) set to 00 to skip over this option and
      continue processing the header if a router does not recognize the
      option.

   *  The size of a Hop-by-Hop option should not extend beyond what can
      be expected to be executed at full forwarding rate.  A larger Hop-
      by-Hop Options header can increase the likelihood that that a
      packet will be dropped [Cus23b].

   *  New Hop-by-Hop options should be designed expecting that a router
      might be configured to only process a subset of Hop-by-Hop options
      (e.g., the first option) in the Hop-by-Hop Options header.

Hinden & Fairhurst       Expires 7 December 2024               [Page 12]
Internet-Draft           HBH Options Processing                June 2024

   *  The design of protocols that use new Hop-by-Hop options should
      consider that a router may drop packets containing the new Hop-by-
      Hop option.

   Any new Hop-by-Hop option that is standardized that does not meet
   these criteria must include in the specification a detailed
   explanation why this cannot be accomplished and to show that there is
   a reasonable expectation that the option can be proceed at full
   forwarding rate.  This is consistent with [RFC6564].

   The general issue of robust operation of packets with new Hop-by-Hop
   options is described in Section 6.1 below.

6.1.  Example of Robust Usage

   Recent measurement surveys (e.g., [Cus23a]) show that packets that
   include Extension Headers can cause the packets to be dropped by some
   Internet paths.  In a limited domain, routers can be configured or
   updated to provide support for any required Hop-by-Hop options.

   The primary motivation of this document is to make it more practical
   to use Hop-by-Hop options beyond such a limited domain, with the
   expectation that applications can improve the quality of or add new
   features to their offered service when the path successfully forwards
   packets with the required Hop-by-Hop options and otherwise refrains
   from using these options.  The focus is on incremental deployability.
   A protocol feature (such as using Hop-by-Hop options) is
   incrementally deployable if early adopters gain some benefit on the
   paths being used, even though other paths do not support the protocol
   feature.  A source ought to order the Hop-by-Hop options that are
   carried in the Hop-by-Hop Options header in decreasing order of
   importance for processing by nodes on the path.

   Methods can be developed that do not rely upon all routers to
   implement a specific Hop-by-Hop option (e.g., [RFC9268]), and that
   are robust when the current path drops packets that contain a Hop-by-
   Hop option (e.g., [RFC9098]).

   For example, an application can be designed to first send a test
   packet that includes the required option or combination of options,
   and sends other packets without including the option.  The
   application then does not send additional packets that include this
   option (or set of options) until the test packet(s) is acknowledged.
   The need for potential loss recovery when a path drops these test
   packets can be avoided by choosing packets that do not carry
   application data that needs to be reliably delivered.

Hinden & Fairhurst       Expires 7 December 2024               [Page 13]
Internet-Draft           HBH Options Processing                June 2024

   Since the set of nodes forming a path can change with time, this
   discovery process ought to be repeated from time-to-time.  The
   process of sending packets both with and without a specific header to
   discover whether a path can support a specific header is sometimes
   called "racing".  Transport protocol racing is explained in
   [I-D.ietf-taps-arch], and "A/B protocol feature testing" is described
   in [Tram17].

7.  IANA Considerations

   This document requires no assignment actions by IANA.

   The document updates the processing of Hop-by-Hop options.  IANA is
   requested to add the published RFC as an additional reference for
   "Destination Options and Hop-by-Hop Options" in the Internet Protocol
   Version 6 (IPv6) Parameters Registry.

8.  Security Considerations

   Security issues with including IPv6 Hop-by-Hop options are well known
   and have been documented in several places, including [RFC6398],
   [RFC6192], [RFC7045] and [RFC9098].  The main issue, as noted in
   Section 4, is that any mechanism that can be used to force packets
   into the router's control plane or slow path can be exploited as a
   Denial-of-Service attack on a router by saturating the resources
   needed for router management (routing protocols, network management
   protocols, etc.) and cause the router to fail or perform sub-
   optimally.

   While Hop-by-Hop options are not required to be processed in the
   control plane, the Router Alert Option is the one exception that is
   designed to be processed in the control plane.

   Some IPv6 nodes implement features that access more of the protocol
   information than a typical IPv6 router (e.g., [RFC9098]).  Examples
   are nodes that provide Denial-of-Service mitigation, firewall/access
   control, traffic engineering, or traffic normalization.  These nodes
   could be configured to drop packets when they are unable to access
   and process all Extension Headers or are unable to locate and process
   the higher-layer packet information.  This document provides guidance
   on the requirements concerning Hop-by-Hop options.

   Finally, the document notes that Internet protocol processing needs
   to be robust to malformed/malicious protocol fields.  For example, a
   packet with an excessive number of options could consume significant
   resources; inclusion of a large extension header could potentially
   cause an on-path router to be unable to utilise hardware
   optimisations to process later headers (e.g., to perform equal cost

Hinden & Fairhurst       Expires 7 December 2024               [Page 14]
Internet-Draft           HBH Options Processing                June 2024

   multipath forwarding or port filtering).  This requirement is not
   specific to Hop-by-Hop options.  It is important that implementations
   fail gracefully when a malformed or malicious Hop-by-Hop option is
   encountered.

   This document changes the way the Hop-by-Hop Options header is
   processed in several ways that significantly reduce the attack
   surface.  These changes include:

   *  A router configuration needs to avoid vulnerabilities that arise
      when it cannot process a Hop-by-Hop option at full forwarding rate
      and SHOULD NOT therefore be configured to process the a Hop-by-Hop
      option if this adversely impacts the aggregate forwarding rate,
      instead it SHOULD behave in the way specified for an unrecognized
      Option Type when the action bits were set to "00", as specified in
      Section 5.2.

   *  It adds criteria for the Router Alert Option in Section 5.2.1 to
      allow control over how the Router Alert Option is processed and
      that a node configured to support these options must protect
      itself from attacks using the Router Alert Option.

   *  The document sets an expectation that if a packet includes a Hop-
      by-Hop Options header that the packet will be forwarded across the
      network path.

   *  A source MAY include, based on local configuration, a single Hop-
      by-Hop option or may be configured to include more Hop-by-Hop
      options.  The configuration of intermediate nodes determines
      whether a node processes any of these options, and, if so, which
      and how many.

   *  The present document adds guidance for the design of any future
      new Hop-by-Hop option that reduce their computational requirements
      and encourage a limit to their size.

   The intent of this document is that these changes significantly
   reduce the security issues relating to processing the IPv6 Hop-by-Hop
   Options header and to enable Hop-by-Hop options to be safely used in
   the Internet.

Hinden & Fairhurst       Expires 7 December 2024               [Page 15]
Internet-Draft           HBH Options Processing                June 2024

9.  Acknowledgments

   Helpful comments were received from Brian Carpenter, Ron Bonica, Ole
   Troan, Mike Heard, Tom Herbert, Cheng Li, Eric Vyncke, Greg Mirksy,
   Xiao Min, Fernando Gont, Darren Dukes, Peng Shuping, Dave Thaler, Ana
   Custura, Tim Winters, Jingrong Xie, Lorenzo Colitti, Toerless Eckert,
   Suresh Krishnan, Mikael Abrahamsson, Adrian Farrel, Jie Dong, Jen
   Linkova, Erik Kline, and other members of the 6MAN working group.

10.  Change log [RFC Editor: Please remove]

   draft-ietf-6man-hbh-processing-20, 2024-June 5

   *  Changes based on John Scudder's AD review.
   *  Changes based on Deb Cooley's AD review.
   *  Changes based on Jim Guichard's AD review.
   *  Changes based on Roman Danyliw's AD review.
   *  Changes based on Jim Guichard's AD review.
   *  Editorial Changes.

   draft-ietf-6man-hbh-processing-19, 2024-June 4

   *  Changes based on Warren Kumari's AD review.

   draft-ietf-6man-hbh-processing-18, 2024-May 29:

   *  Changes based on Éric Vyncke's AD review.
   *  Changes based on Roman Danyliw's AD review.

   draft-ietf-6man-hbh-processing-17, 2024-May 16:

   *  Editorial changes and request to IANA, based on Bernie Volz's
      INTDIR review.

   draft-ietf-6man-hbh-processing-16, 2024-April 30:

   *  Clarifications and editorial changes based on Peter Yee's SECDIR
      review.
   *  Editorial changes based on Behcet Sarikaya's GENART review.
   *  Clarifications based on Brian Trammell's TSVART review.

   draft-ietf-6man-hbh-processing-15, 2024-April 13:

   *  Clarifications based on AD review by Erik Kline.
   *  Editorial Changes.

   draft-ietf-6man-hbh-processing-14, 2024-February-25:

Hinden & Fairhurst       Expires 7 December 2024               [Page 16]
Internet-Draft           HBH Options Processing                June 2024

   *  Clarifications based on comment from Jen Linkova
   *  Editorial Changes.

   draft-ietf-6man-hbh-processing-13, 2024-February-18:

   *  Correction based on comment by Jie Dong
   *  Clarifications based on comments from Tom Herbert
   *  Clarifications based on comments from Ole Troan
   *  Editorial Changes.

   draft-ietf-6man-hbh-processing-12, 2023-November-21:

   *  Clarifications and text improvements based on review by Fernando
      Gont.
   *  Editorial Changes.

   draft-ietf-6man-hbh-processing-11, 2023-November-5:

   *  Clarifications and text improvements based on review by Adrian
      Farrel.
   *  Editorial Changes.

   draft-ietf-6man-hbh-processing-10, 2023-September-26:

   *  Clarifying changes based on comments received during the IPv6 w.g.
      session at IETF117 from Lorenzo Colitti, Toerless Eckert, and
      others.
   *  Clarifying changes based on comments received after the first w.g.
      last call.
   *  Editorial Changes.

   draft-ietf-6man-hbh-processing-09, 2023-July-4:

   *  Revised text in Section 3 relating to fast/slow path and
      processing
   *  Restructured Section 5 to separate Hop-by-Hop Options header and
      Hop-by-Hop options processing and configuration.
   *  Revised MUST/SHOULD language in Section 5.2.
   *  Revised text to use consistant names for Hop-by-Hop Options header
      and Hop-by-Hop options.
   *  Revised Section 5.2 regarding the modified behaviour of the action
      bits "01", "10", and "11" to be a MAY to be consistant with text
      earlier in that section.
   *  Added to Section 6 that new Hop-by-Hop options SHOULD be designed
      expecting that routers may drop packets with the new option.
   *  Added new Section 6.1 on "Example of Robust Usage".
   *  Other editorial changes to improve readability and clarity.

Hinden & Fairhurst       Expires 7 December 2024               [Page 17]
Internet-Draft           HBH Options Processing                June 2024

   draft-ietf-6man-hbh-processing-08, 2023-April-30:

   *  Changed document that is no longer updates [RFC7045], it now
      clarifies it using the language of BCP 14.
   *  Added additional clarification to Section 4.
   *  Editorial changes

   draft-ietf-6man-hbh-processing-07, 2023-April-6:

   *  Changed text to clarify how hosts and routers process the Hop-by-
      Hop Options header based on comments at 6MAN session at IETF 116.
   *  Editorial changes

   draft-ietf-6man-hbh-processing-06, 2023-March-11:

   *  Added reference to RFC6564.
   *  Editorial changes

   draft-ietf-6man-hbh-processing-05, 2023-February-23:

   *  Clarified text in Section 6 about processing complexity and time
      to process.
   *  Added a definition to Section 3 for "Full Forwarding Rate".
   *  Added text to Section 5.1 about nodes that do not process the Hop-
      by-Hop Options header.
   *  Added text to Section 4 about slow path processing can cause
      packets to be deliver out of order to the destination.
   *  Editorial changes

   draft-ietf-6man-hbh-processing-04, 2022-October-21:

   *  Add a paragraph to Section 4 that describes the relationship to
      [RFC7045] "Transmission and Processing of IPv6 Extension Headers".
   *  Change that this draft updates section 2.2 of [RFC7045].

   draft-ietf-6man-hbh-processing-03, 2022-October-12:

   *  Changed in Section 5.1 to have router skip over options if can't
      process at full forwarding rate.
   *  Added to Section 6 that new options should be defined with action
      type set to 00.

   draft-ietf-6man-hbh-processing-02, 2022-August-23:

   *  Several clarification and editorial changes suggested by a review
      by Peng Shuping.
   *  Editorial changes.
   *  Revised text relating to fast/slow path and processing rates.

Hinden & Fairhurst       Expires 7 December 2024               [Page 18]
Internet-Draft           HBH Options Processing                June 2024

   *  Revised the third paragraph in Section 5.1.1 to be clearer.
   *  Revised text in Security section based on comments from Fernando
      Gont.

   draft-ietf-6man-hbh-processing-01, 2022-June-15:

   *  Fixed typo in last paragraph of Section 5.1
   *  Revised text in Section 4 to reflect constraints on publishing RFC
      8200.
   *  Changed text in Section 6 that new options SHOULD NOT (from MUST
      NOT) be defined that require that are not expected to be excepted
      at full forwarding rates.
   *  Added reference to RFC7872 in Section 4.
   *  Added text to Section 1 that the focus of this document is to set
      a minimum bound on the number of Hop-by-Hop options a node should
      process.
   *  Added text to Section 4 that the authors some Hop-by-Hop options
      will be supported Internet wide, and others only in limited
      domains.
   *  Editorial changes.

   draft-ietf-6man-hbh-processing-00, 2022-January-29:

   *  6MAN Working Group Draft
   *  Reworked text to talk about processing Hop-by-Hop options at full
      forwarding rates, instead of "fast path"
   *  Revised Section 6 "New Hop-by-Hop options" to allow variable sized
      Hop-by-Hop options, remove specific length requirements, and other
      clarifications.
   *  Editorial changes.

   draft-hinden-6man-hbh-processing-01, 2021-June-2:

   *  Expanded terminology section to include forwarding plane and
      control plane.
   *  Changed draft that only one Hop-by-Hop option MUST be processed
      and additional Hop-by-Hop options MAY be processed based on local
      configuration.
   *  Clarified that all Hop-by-Hop options (with one exception) must be
      processed on the Fast Path.
   *  Kept the Router Alert Option as the single exception for Slow Path
      processing.
   *  Rewrote and expanded section on New Hop-by-Hop options.
   *  Removed requirement for Hop-by-Hop option size and alignment.
   *  Removed sections evaluating currently defined Hop-by-Hop options.
   *  Added content to the Security Considerations section.
   *  Added people to the acknowledgements section.
   *  Numerous editorial changes

Hinden & Fairhurst       Expires 7 December 2024               [Page 19]
Internet-Draft           HBH Options Processing                June 2024

   draft-hinden-6man-hbh-processing-00, 2020-Nov-29:

   *  Initial draft.

11.  Normative References

   [IANA-HBH] "Destination Options and Hop-by-Hop Options",
              <https://www.iana.org/assignments/ipv6-parameters/
              ipv6-parameters.xhtml#ipv6-parameters-2>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

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

12.  Informative References

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

   [Hendriks] Hendriks, L., Velan, P., Schmidt, RO., Boer, P., and A.
              Aiko, "Threats and Surprises behind IPv6 Extension
              Headers",  , August 2017,
              <http://dl.ifip.org/db/conf/tma/tma2017/
              tma2017_paper22.pdf>.

Hinden & Fairhurst       Expires 7 December 2024               [Page 20]
Internet-Draft           HBH Options Processing                June 2024

   [I-D.ietf-taps-arch]
              Pauly, T., Trammell, B., Brunstrom, A., Fairhurst, G., and
              C. Perkins, "Architecture and Requirements for Transport
              Services", Work in Progress, Internet-Draft, draft-ietf-
              taps-arch-19, 9 November 2023,
              <https://datatracker.ietf.org/doc/html/draft-ietf-taps-
              arch-19>.

   [I-D.ietf-v6ops-hbh]
              Peng, S., Li, Z., Xie, C., Qin, Z., and G. S. Mishra,
              "Operational Issues with Processing of the Hop-by-Hop
              Options Header", Work in Progress, Internet-Draft, draft-
              ietf-v6ops-hbh-10, 16 February 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-
              hbh-10>.

   [IANA-RA]  "IPv6 Router Alert Option Values",
              <https://www.iana.org/assignments/ipv6-routeralert-values/
              ipv6-routeralert-values>.

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

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

   [RFC2711]  Partridge, C. and A. Jackson, "IPv6 Router Alert Option",
              RFC 2711, DOI 10.17487/RFC2711, October 1999,
              <https://www.rfc-editor.org/info/rfc2711>.

   [RFC4443]  Conta, A., Deering, S., and M. Gupta, Ed., "Internet
              Control Message Protocol (ICMPv6) for the Internet
              Protocol Version 6 (IPv6) Specification", STD 89,
              RFC 4443, DOI 10.17487/RFC4443, March 2006,
              <https://www.rfc-editor.org/info/rfc4443>.

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

Hinden & Fairhurst       Expires 7 December 2024               [Page 21]
Internet-Draft           HBH Options Processing                June 2024

   [RFC6564]  Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and
              M. Bhatia, "A Uniform Format for IPv6 Extension Headers",
              RFC 6564, DOI 10.17487/RFC6564, April 2012,
              <https://www.rfc-editor.org/info/rfc6564>.

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

   [RFC8799]  Carpenter, B. and B. Liu, "Limited Domains and Internet
              Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020,
              <https://www.rfc-editor.org/info/rfc8799>.

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

   [RFC9268]  Hinden, R. and G. Fairhurst, "IPv6 Minimum Path MTU Hop-
              by-Hop Option", RFC 9268, DOI 10.17487/RFC9268, August
              2022, <https://www.rfc-editor.org/info/rfc9268>.

   [RFC9288]  Gont, F. and W. Liu, "Recommendations on the Filtering of
              IPv6 Packets Containing IPv6 Extension Headers at Transit
              Routers", RFC 9288, DOI 10.17487/RFC9288, August 2022,
              <https://www.rfc-editor.org/info/rfc9288>.

   [Tram17]   Trammell, B., Kuehlewind, M., De Vaere, P., Learmonth,
              IR., and G. Fairhurst, "Tracking Transport-Layer Evolution
              with PATH Spider", ANRW , July 2017,
              <https://irtf.org/anrw/2017/anrw17-final16.pdf>.

Authors' Addresses

   Robert M. Hinden
   Check Point Software
   959 Skyway Road
   San Carlos, CA 94070
   United States of America
   Email: bob.hinden@gmail.com

Hinden & Fairhurst       Expires 7 December 2024               [Page 22]
Internet-Draft           HBH Options Processing                June 2024

   Godred Fairhurst
   University of Aberdeen
   School of Engineering
   Fraser Noble Building
   Aberdeen
   AB24 3UE
   United Kingdom
   Email: gorry@erg.abdn.ac.uk

Hinden & Fairhurst       Expires 7 December 2024               [Page 23]