<?xml version='1.0' encoding='utf-8'?> encoding='UTF-8'?>

<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?> [
 <!ENTITY nbsp    "&#160;">
 <!ENTITY zwsp   "&#8203;">
 <!ENTITY nbhy   "&#8209;">
 <!ENTITY wj     "&#8288;">
]>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ietf-6man-hbh-processing-20" number="9673" ipr="trust200902" updates="8200" obsoletes="" consensus="true" submissionType="IETF" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true"
    version="3"> version="3" xml:lang="en">

  <front>

    <title abbrev="HBH Options Processing">IPv6 Hop-by-Hop Options Processing Procedures</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-6man-hbh-processing-20"/> name="RFC" value="9673"/>
    <author fullname="Robert M. Hinden" initials="R" surname="Hinden">
      <organization>Check Point Software</organization>
      <address>
        <postal>
          <street>959 Skyway Road</street>
          <!-- Reorder these if your country does things differently -->
          <city>San Carlos</city>
          <street>100 Oracle Parkway, Suite 800</street>
          <city>Redwood City</city>
          <region>CA</region>
          <code>94070</code>
          <country>USA</country>
          <code>94065</code>
          <country>United States of America</country>
        </postal>
        <phone/>
        <email>bob.hinden@gmail.com</email>
      </address>
    </author>
    <author fullname="Godred Fairhurst" initials="G" surname="Fairhurst">
      <organization>University of Aberdeen</organization>
      <address>
        <postal>
          <street>School of Engineering</street>
          <street>Fraser Noble Building</street>
          <city>Aberdeen</city>
          <region/>
          <code>AB24 3UE</code>
          <country>UK</country>
          <country>United Kingdom</country>
        </postal>
        <email>gorry@erg.abdn.ac.uk</email>
       </address>
    </author>

<!--
    <date day="" month="" --> month="October" year="2024"/>
    <area>INT</area>
    <workgroup>6man</workgroup>

<abstract>

  <t>This document specifies procedures for how processing 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 at IPv6 routers and hosts.
  This document updates RFC 8200.</t>

</abstract>

</front>

<middle>

<section title=" Introduction" anchor="INTRO">
  <name>Introduction</name>
  <t>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 <xref
  target="RFC8200"/> 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 at IPv6 routers and hosts.</t>

  <t>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 <xref
  target="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.</t>

  <t>When published, this

  <t>This document updates <xref target="RFC8200"/>.</t>

</section>

<section title="Requirements Language">

  <t>The

<section>
  <name>Requirements Language</name>
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
    "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
    "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
    "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and
   "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be
    interpreted as described in
   BCP 14 BCP&nbsp;14 <xref target="RFC2119"/> <xref
    target="RFC8174"/> when, and only when, they appear in all capitals, as
    shown here.</t> here.
        </t>
</section>

<section title="Terminology" anchor="TERM">
  <name>Terminology</name>
  <t>This document uses the following loosely defined
   terms:</t>

   <ul

   <dl spacing="normal">
       <li>forwarding plane: IPv6

       <dt>Forwarding Plane:</dt><dd>IPv6 routers exchange user or applications data through the
       forwarding plane.
       Forwarding Plane.  Routers process fields contained in IPv6 packet
       headers.  However, they do not process information contained in packet
       payloads.</li>

       <li>control plane: IPv6
       payloads.</dd>

       <dt>Control Plane:</dt><dd>IPv6 routers exchange control
       information through the
       control plane.
       Control Plane.  The control plane Control Plane processes the management and routing
       information exchanged with other routers.</li>

       <li>Fast Path: A routers.</dd>

       <dt>Fast Path:</dt><dd>A path through a router that is optimized for
       forwarding packets. The Fast Path
       might be supported by Application Specific 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.</li>

       <li>Slow Path: A Forwarding Plane.</dd>

       <dt>Slow Path:</dt><dd>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 that differ from assumptions made in Fast Path
       heuristics or to process router control protocols used by the control
       plane.</li>

       <li>Full Control
       Plane.</dd>

       <dt>Full Forwarding Rate: This is the Rate:</dt><dd>The rate that at which 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".</li>

       <li>source: The speed".</dd>

       <dt>Source:</dt><dd>The node originating the packet.</li>

   </ul> packet.</dd>
   </dl>

   <t>NOTE: <xref target="RFC6192"/> is an example of how designs can
   separate control plane Control Plane and forwarding plane Forwarding Plane
   functions. The separation between hardware and software processing
   described in <xref target="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.</t>

</section>

<section title="Background" anchor="BACKGROUND">
  <name>Background</name>

    <t>
    In the first early versions of the IPv6 protocol specification
    <xref target="RFC1883"/> and
    <xref target="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: <xref target="RFC7045" sectionFormat="of" section="2.2"/>: "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 reasons behind this includes:</t> include the following:</t>

    <ul spacing="normal">

        <li>Inability

        <li>The inability to process Hop-by-Hop options at the full forwarding
        rate 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. Slow Path.
        This could degrade a router's performance and also its ability to process
        critical control traffic.
        Both traffic, both of which could be exploited as a
        Denial-of-Service (DoS) attack against the router.</li>

        <li>If a subset of packets within a flow includes Hop-by-Hop
	options, this it 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, 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.
        </li>

        <li>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 <xref target="Cus23a"/> show
        that the probability of successful transmission across the
	public Internet is currently
        higher for packets that include Options when it results that result in a short
        total Extension Header (EH) Chain size (i.e., less than 40 bytes).</li>

    </ul>

    <t>
    <xref

    <t><xref target="RFC6564"/> specified specifies a uniform format for new IPv6 Extension Headers.  It updated
    <xref target="RFC2460"/>,
    Headers, and this update was incorporated into Section 4.8 of
    <xref target="RFC8200"/>.
    </t> target="RFC8200" sectionFormat="of" section="4.8"/> (note that
    <xref target="RFC8200"/> obsoleted <xref target="RFC2460"/>).</t>

    <t>When the IPv6 Specification protocol specification was updated and published in
    July 2017 as
    <xref target="RFC8200"/>, the procedures relating to Hop-by-Hop options
    were specified (<xref target="RFC8200"/>, Section 4) (paragraphs 5 and 6 of <xref target="RFC8200" sectionFormat="of" section="4"/>) as follows:</t>

    <ul empty="true">

       <li>The

   <blockquote><t>
       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.</li>

       <li>NOTE: header.</t>
<t>
       NOTE: While <xref target="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.</li>
    </ul> so.</t>
   </blockquote>

    <t>
    The changes meant that an implementation complied with the IPv6 protocol
    specification even if it did not process Hop-by-Hop options, options and that
    it was expected that
    routers would were expected to 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.</t>

    <t>The text regarding the processing of Hop-by-Hop options in <xref
     target="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 <xref
    target="RFC8200"/>).
    target="RFC8200" sectionFormat="of" section="B"/>).  This was a constraint on
    publishing the IPv6 protocol specification as an IETF Standard.</t>

    <t>The main issues remain:</t>

    <ul spacing="normal">
        <li>Routers can be configured
        to drop transit packets containing Hop-by-Hop Options that would
        have required
        require processing by a processor that implements the control plane. Control Plane.
        This could be done to protect against a Denial-of-Service DoS attack on the
	router <xref target="RFC9098"/><xref target="RFC9098"/> <xref target="RFC9288"/>.</li>

        <li>IPv6 Packets 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 Autonomous Systems (ASes) for packets
        with that include
        Hop-by-Hop options <xref target="RFC7872"/>.
        The operational implications of IPv6 Packets packets that include
        Extension Headers are discussed in <xref target="RFC9098"/>.

        Measurements taken in 2023 confirm this to still be the case for many types of
	network paths <xref target="Cus23b"/>. </li>

        <li>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.</li>

        <li>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 can impact
        the cost of processing a packet, and in turn could increase the probability of
        drop <xref target="RFC7872"/>. A larger Extension Header
        could also reduce the probability that of a router can locate locating all
        the header bytes required to successfully process
        an access control list operating on fields after the Hop-by-Hop
        Options header.</li>

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

    </ul>

    <t> Section 3 of RFC 6398

    <t><xref target="RFC6398" sectionFormat="of" section="3"/> includes a summary of processing the IP Router Alert Option:</t>

    <ul empty="true" spacing="normal">
        <li>"In

    <blockquote>
        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 Option is used, because, short of appropriate
        router-implementation-specific mechanisms, the router Slow Path slow path is at risk
        of being flooded by unwanted traffic."
     </li>
   </ul> traffic.
    </blockquote>

        <t>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
        Control Plane resources
        where support for a function has not been configured.</t>

    <t>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, <xref target="Hendriks"/> states that "dropping "Dropping all
    packets with that contain Extension Headers, Headers is a bad practice", 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 EHs, we therefore
    recommend to support at least one EH".  Operational aspects of the topics
    discussed in this section are further discussed in <xref target="I-D.ietf-v6ops-hbh"/>.</t>

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

    <t>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 <xref
    target="RFC8799"/> (e.g., where a specific service is made available
    in that network segment that relies on one or more Hop-by-Hop
    options).</t>

</section> <!-- BACKGRUND -->

<section anchor="HBH" title="Hop-by-Hop anchor="HBH">
  <name>Hop-by-Hop Header Processing Procedures"> Procedures</name>

    <t>This section describes several changes to <xref
    target="RFC8200"/>. <xref target="FAST"/> describes the processing of
    the Hop-by-Hop options Extension Header, and <xref target="ONE"/> describes
    the processing of individual Hop-by-Hop Options. options.
    These sections updates update the text in paragraphs 5 and paragraph 6 of Section 4 of
   <xref target="RFC8200"/> and target="RFC8200" sectionFormat="of" section="4"/> and, as noted in <xref target="ONE"/> modifies Section 4.2 of target="ONE"/>, modify
   <xref target="RFC8200"/>.</t> target="RFC8200" sectionFormat="of" section="4.2"/>.</t>

    <section anchor="FAST" title="Processing anchor="FAST">
      <name>Processing the Extension Header Carrying Hop-by-Hop Options"> Options</name>

       <t>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.</t>

       <t>The Extension Header used to carry Hop-by-Hop options
       is defined in Section 4.3 of <xref target="RFC8200"/> target="RFC8200" sectionFormat="of" section="4.3"/> and is identified
       by a Next Header value of 0 in the IPv6
        header.  Section 4.1 of  <xref target="RFC8200"/> target="RFC8200" sectionFormat="of" section="4.1"/> requires this Hop-by-Hop
        Options header to appear immediately after the IPv6 header.  <xref
          target="RFC8200"/> also requires that a Hop-by-Hop Options header
        only appear at most once in a packet.</t>

        <t>The Hop-by-Hop Options Header header as defined in
        <xref target="RFC8200"/> can contain
        one or more Hop-by-Hop options.</t>

        <t>Routers that process the Hop-by-Hop Options header SHOULD <bcp14>SHOULD</bcp14> do
        so using the method defined in this document.
	Exceptions to this "SHOULD" <bcp14>SHOULD</bcp14> 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 <xref target="RFC9288"/>).</t>

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

        <t>It is expected that the Hop-by-Hop Options header will be
        processed by the destination(s).
        Hosts SHOULD <bcp14>SHOULD</bcp14> 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 <bcp14>MUST</bcp14> process the remainder of the packet normally.
        <!--
        Additional recommendations for host processing are described in
        <xref target="I-D.ietf-6man-eh-limits"/>.
        -->
        </t>

    <section anchor="CONFIG" title="Configuration anchor="CONFIG">
      <name>Configuration Enabling Hop-by-Hop Header Processing">

        <t> Section 4 of
        <xref target="RFC8200"/> Processing</name>

        <t><xref target="RFC8200" sectionFormat="of" section="4"/> allows a router to control its processing
        of IPv6 Hop-by-Hop options by local configuration.  The text is:</t>

        <ul empty="true">
           <li>NOTE:
        <blockquote>
           NOTE: While <xref target="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.</li>
        </ul>

         <t>This so.
        </blockquote>

         <t>
	 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 process any of the
  option types contained in the Hop-by-Hop Options header.
	 </t>
<!--
Original text:
         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.</t>

    </section> <!-- CONFIG
         action.
-->

    </section> <!-- FAST -->
    </section>

    <section anchor="ONE" title="Hop-by-Hop anchor="ONE">
      <name>Hop-by-Hop Options Processing"> Processing</name>

        <t>A source Source creating packets with a Hop-by-Hop Options header SHOULD <bcp14>SHOULD</bcp14> 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, packet or that forward
           packets without the option(s) being processed (see <xref target="HOW"/>).

        A source MAY, Source <bcp14>MAY</bcp14>, based on local configuration,
        allow only one Hop-by-Hop option to be included in a packet,
        or it could allow more than one Hop-by-Hop options,
        <!--
        <xref target="I-D.ietf-6man-eh-limits"/>
        --> option
        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 Options header, sources 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.
	</t>

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

<!--
        <t>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.
        If configured to do so, a router SHOULD process
        additional Hop-by-Hop options providing whether these also do not
        adversely impact the aggregate forwarding rate.</t>
-->

        <t>If a router is unable to process a specific Hop-by-Hop option
        (or is not configured to do so), it
        SHOULD
        <bcp14>SHOULD</bcp14> behave in the same way specified for an unrecognized Option Type when the
        action bits were are set to "00" "00", and
        SHOULD it
        <bcp14>SHOULD</bcp14> 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.</t>

        <t>The Router
        Alert Option <xref target="RFC2711"/> is an exception
        to this because it is designed to tell a router
	that the packet needs additional processing, which is usually done
        in the control plane, Control Plane; see <xref target="RTRALERT"/>.
        </t>

        <t>Section 4.2 of <xref target="RFC8200"/>

        <t><xref target="RFC8200" sectionFormat="of" section="4.2"/>
        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:</t>

<!--NOTE: authors requested that the quoted text below not be in <blockquote>. It should exactly match the formatting in RFC 8200.
-->

<artwork align="left" name="" type="" alt=""><![CDATA[
   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 ICMP Parameter Problem, Code 2 [RFC4443], 2, 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 ICMP Parameter
        Problem, Code 2, message to the packet's Source Address,
        pointing to the unrecognized Option Type.
]]></artwork>

        <t>This document modifies this behaviour behavior for the "01", "10", and
	"11" action bits, 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 <bcp14>SHOULD</bcp14> behave in the same way
	specified for an unrecognized Option Type when the
        action bits were are set to "00".

        It also modifies the behaviour behavior for the values "10" and "11" values for in the case when where
        the packet is discarded, discarded and the
        node MAY <bcp14>MAY</bcp14> send an ICMP Parameter Problem, Code 2 <xref target="RFC4443"/>,
	message to the packet's Source Address, pointing to the unrecognized Option Type.</t>

	<t>The modified text for values "01", "10", and "11" values is:</t>

<artwork align="left" name="" type="" alt=""><![CDATA[
   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 MAY be sent to the
        packet's Source Address, pointing to the unrecognized
        Option Type.

   11 - MAY discard the packet, if so configured. Only if 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 MAY be sent to the packet's Source
        Address, pointing to the unrecognized Option Type.
]]></artwork>

<!--
        <t>When a node sends an ICMP message in response to a packet with
        a multicast destination address, this could be exploited as an
        amplification attack. This is particularly problematic when the
        Source Address is not valid (which can be mitigated to varying
        degrees by using a reverse path forwarding (RPF) check). A node
        SHOULD NOT send ICMP messages in response to a packet with a
        multicast destination address unless this is enabled for the
        specific Source Address and/or the group Destination Address.</t>
-->

        <t>When an ICMP Parameter Problem, Code 2, message is delivered to the
        source,
        Source, it
	indicates that at least one node on the
        path has failed to recognize the option <xref target="RFC4443"/>.
        Generating any ICMP message
        incurs additional router processing.
        Reception of this message is
        not guaranteed, guaranteed;
        routers might be unable to be configured so that they do not generate
        these messages,
	and they are not always forwarded to the source. 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.</t>

    <section anchor="RTRALERT" title="Router anchor="RTRALERT">
      <name>Router Alert Option"> Option</name>

        <t>The purpose of the Router Alert Option <xref target="RFC2711"/> is to tell
        a router that the packet needs additional processing in the control plane. Control Plane.
        </t>
        <t>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 "IPv6 Router Alert Value Option Values" IANA registry <xref
        target="IANA-RA"/>.</t>

        <t>DISCUSSION</t>

        <ul empty="true" spacing="normal">
        <li> The
        <t indent="3">The function of a Router Alert Option can result in the processing
 that this specification is proposing to eliminate, that is, to instruct
 instructing a router to process the packet in the control plane. Control Plane.
 This results in the concerns processing causes concerns, which are discussed in section 4. <xref target="BACKGROUND"/>.
 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 continue, and its use could be phased out
 over time.</li>

        <li>The time.</t>

        <t indent="3">The Router Alert Option could
        have a potential for use potentially be used with new
 functions that have to be processed in the control plane. Control Plane.  Keeping
 this as the single exception for processing in the control plane Control Plane
 with the following restrictions that follow is a reasonable compromise to
 allow future flexibility.  These restrictions are compatible
 with Section 5 of <xref target="RFC6398"/>.</li>
        </ul> target="RFC6398" sectionFormat="of" section="5"/>.</t>

        <t>
        As noted in <xref target="RFC6398"/>,
        "Implementations of the IP Router Alert option
        SHOULD Option
        <bcp14>SHOULD</bcp14> offer the configuration option to simply ignore the presence
        of the IP 'IP Router Alert Alert' in IPv4 and IPv6 packets."</t>

        <t>A node that is configured to process a Router Alert option
        MUST Option
        <bcp14>MUST</bcp14> protect itself from an infrastructure attack
        that could result from processing in the control plane. Control Plane. This might include
        some combination of an access control list to only permit this access from trusted nodes,
        rate limiting of processing, or other methods <xref target="RFC6398"/>.</t>

        <t>As specified in <xref target="RFC2711"/> target="RFC2711"/>, the top two bits of the Option Type
        for the Router Alert Option are always set to "00" "00", indicating that 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 recognize the Router Alert Option
	SHOULD
	<bcp14>SHOULD</bcp14> verify that a the 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 <bcp14>SHOULD</bcp14> be sent to the control plane Control Plane for further processing
        <xref target="RFC6398"/>.  Otherwise, the router implementation SHOULD <bcp14>SHOULD</bcp14> forward
        this packet subject to all normal policies and forwarding rules.
        </t>

    </section>  <!-- Router Alert option -->

    <section anchor="CONFIG2" title="Configuration anchor="CONFIG2">
      <name>Configuration of Hop-by-Hop Option Processing"> Options Processing</name>

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

      <t>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 <xref target="FAST"/> of this document.</t>

<!--
    <t>A router can be configured to process a specific Option. 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. the 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 <xref target="FAST"/> of this document.</t>
-->

    <t>The actions of the lookup table should be configurable by the operator of
    the router.</t>
    </section> <!-- Config options -->
    </section><!-- Options -->
    </section> <!-- HBH -->

</section>

<section anchor="NEW" title="Defining anchor="NEW">
  <name>Defining New Hop-by-Hop Options"> Options</name>

    <t>This section updates Section 4.8 of <xref target="RFC8200"/>.</t> target="RFC8200" sectionFormat="of" section="4.8"/>.</t>

    <t>Any future new IPv6 Hop-by-Hop option designed in the future options should be designed to
    be processed at full forwarding rate.
    New Hop-by-Hop options the Full Forwarding Rate and should have the following characteristics:</t>

    <ul spacing="normal">

        <li>New Hop-by-Hop options should
        be designed to ensure the router can process the options at the full
        forwarding rate. Full
        Forwarding Rate. That is, they should be simple to process.
        </li>

        <li>New Hop-by-Hop options should be defined with the Action type (highest-order 2
        bits of the Option Type) set to 00 to skip "00", which enables skipping over this option
	and continue continuing with the processing of the header if a router does not recognize
	the option.</li>

        <li>The size of a Hop-by-Hop option options should not extend beyond what can be
        expected to be executed at full forwarding rate. the Full Forwarding Rate.  A larger Hop-by-Hop
        Options header can increase the likelihood that that a packet will be
        dropped <xref target="Cus23b"/>.
        </li>

        <li>New Hop-by-Hop options should be designed expecting with the expectation 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.</li>

        <li>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.
        </li>
    </ul>

    <t>Any

    <t>If a new Hop-by-Hop option that is standardized that does not meet
    these criteria criteria, its specification must include in the specification a detailed
    explanation why this cannot be accomplished that is the case and to show that there
    is a reasonable expectation that the option can be still proceed at full forwarding rate. the Full
    Forwarding Rate.  This is consistent with [RFC6564].
    This is consistent with <xref target="RFC6564"/>.</t>

    <t>The general issue of robust operation of packets with new
    Hop-by-Hop options is described in <xref target="HOW"/> below.</t> target="HOW"/>.</t>

    <section anchor="HOW" title="Example anchor="HOW">
      <name>Example of Robust Usage"> Usage</name>
        <t>Recent measurement
        surveys (e.g., <xref target="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.</t>

        <t>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 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.
	</t>

        <t>Methods can be developed that do not rely upon all routers
        to implement a specific Hop-by-Hop option (e.g., <xref target="RFC9268"/>), target="RFC9268"/>)
        and that are robust when the
        current path drops packets that contain a Hop-by-Hop option (e.g.,
        <xref target="RFC9098"/>).</t>

        <t>For example, an application can be designed to first send
        a test packet that includes the required option or combination
        of options, options and sends then send 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.</t>

        <t>Since the set of nodes forming a path can change with time,
        this discovery process ought to be repeated from time-to-time. 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 <xref target="I-D.ietf-taps-arch"/>,
        and "A/B A/B protocol feature testing" testing is described in <xref target="Tram17"/>.</t>

    </section> <!-- HOW -->

</section> <!-- NEW -->

<section anchor="IANA" title="IANA Considerations"> anchor="IANA">
  <name>IANA Considerations</name>

    <t>This document requires no assignment actions by IANA.</t>

    <t>The document updates the processing of
        Hop-by-Hop options.
        IANA is requested to add the published RFC has added this document as an
        additional reference for the "Destination Options and Hop-by-Hop Options" registry
        in the Internet "Internet Protocol Version 6 (IPv6) Parameters Registry. </t> Parameters" registry group <xref target="IANA-HBH"/>.</t>
</section>

<section title="Security Considerations" anchor="Security">
  <name>Security Considerations</name>
    <t>Security issues with caused by including IPv6 Hop-by-Hop options are well known and have
    been documented in several places, including
    <xref target="RFC6398"/>,
    <xref target="RFC6192"/>, <xref target="RFC7045"/> target="RFC7045"/>, and
    <xref target="RFC9098"/>.
    The main issue, as noted in <xref target="BACKGROUND"/>, is that
    any mechanism that can be used to force packets into the
    router's control plane Control Plane or slow path Slow Path can be exploited as a Denial-of-Service DoS attack on a
    router by saturating the resources needed for router management
    (routing protocols, network management protocols, etc.) etc.), and this can
    cause the router to fail or perform sub-optimally. suboptimally. </t>

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

    <t>Some IPv6 nodes implement features that access more of the protocol
    information than a typical IPv6 router (e.g., <xref target="RFC9098"/>).
    Examples are nodes that provide
    Denial-of-Service
    DoS 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.</t>

    <t> Finally, the this document notes that Internet protocol processing needs to be robust to for
    malformed/malicious protocol fields.

    For example, a packet with an
    excessive number of options could consume significant resources;
    inclusion of a large extension header Extension Header could potentially cause an
    on-path router to be unable to utilise utilize hardware optimisations optimizations
    to process later headers (e.g., to perform equal cost 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.</t>

    <t>This document changes the way how the Hop-by-Hop Options header is processed in
    several ways that processed,
    which significantly reduce reduces the attack surface.  These changes include: include the following:
    </t>

    <ul spacing="normal">

        <li>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 the Full
            Forwarding Rate; therefore, it <bcp14>SHOULD NOT</bcp14> be configured to
            process the a Hop-by-Hop option if this it adversely impacts the
            aggregate forwarding rate, instead rate. Instead, it
            SHOULD
            <bcp14>SHOULD</bcp14> behave in the same way specified for an unrecognized Option Type when the
            action bits were are set to "00", as specified in <xref target="ONE"/>.</li>

        <li>It

        <li>This document adds criteria for the Router Alert Option in <xref target="RTRALERT"/> (<xref target="RTRALERT"/>)
        to allow control over how the Router Alert Option it is
        processed and that describes how a node configured to support these options must
        protect itself from attacks by using the Router Alert Option.</li>

        <li>The

        <li>This document sets an the expectation that if a packet
        includes a Hop-by-Hop Options header that header, the packet will be forwarded across the network path.
        </li>

        <li>A source MAY include, based on local configuration, Source <bcp14>MAY</bcp14> include a single Hop-by-Hop option (based on
        local configuration) or may <bcp14>MAY</bcp14> be configured to include more
        Hop-by-Hop options. The configuration of intermediate nodes determines
    whether a node processes any of these options, and, and if so, which ones and how many.</li>

        <li>The present

        <li>This document adds guidance for the design of
        any future new Hop-by-Hop option that reduce their reduces the
        computational requirements and encourage encourages a
        limit to their size.</li>

    </ul>

    <t>The intent of this document is to highlight 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.</t>

</section>

<section title="Acknowledgments" anchor="Ack">

    <t>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.</t>

</section>

 <section anchor="changes" title="Change log [RFC Editor: Please remove]">

     <t>draft-ietf-6man-hbh-processing-20, 2024-June 5</t>
       <ul spacing="compact">
	 <li>Changes based on John Scudder's AD review.</li>
         <li>Changes based on Deb Cooley's AD review.</li>
         <li>Changes based on Jim Guichard's AD review.</li>
         <li>Changes based on Roman Danyliw's AD review.</li>
         <li>Changes based on Jim Guichard's AD review.</li>
	 <li>Editorial Changes.</li>
       </ul>

         <t>draft-ietf-6man-hbh-processing-19, 2024-June 4</t>
       <ul spacing="compact">
	 <li>Changes based on Warren Kumari's AD review.</li>
       </ul>

     <t>draft-ietf-6man-hbh-processing-18, 2024-May 29:</t>
       <ul spacing="compact">
	 <li>Changes based on Éric Vyncke's AD review.</li>
	 <li>Changes based on Roman Danyliw's AD review.</li>
       </ul>

     <t>draft-ietf-6man-hbh-processing-17, 2024-May 16:</t>
       <ul spacing="compact">
     <li>Editorial changes and request to IANA, based on Bernie Volz's INTDIR review.</li>
       </ul>

     <t>draft-ietf-6man-hbh-processing-16, 2024-April 30:</t>
       <ul spacing="compact">
	 <li>Clarifications and editorial changes based on Peter Yee's SECDIR review.</li>
         <li>Editorial changes based on Behcet Sarikaya's GENART review.</li>
         <li>Clarifications based on Brian Trammell's TSVART review.</li>
       </ul>

     <t>draft-ietf-6man-hbh-processing-15, 2024-April 13:</t>
       <ul spacing="compact">
	 <li>Clarifications based on AD review by Erik Kline.</li>
	 <li>Editorial Changes.</li>
       </ul>

     <t>draft-ietf-6man-hbh-processing-14, 2024-February-25:</t>
       <ul spacing="compact">
	 <li>Clarifications based on comment from Jen Linkova</li>
	 <li>Editorial Changes.</li>
       </ul>

     <t>draft-ietf-6man-hbh-processing-13, 2024-February-18:</t>
       <ul spacing="compact">
         <li>Correction based on comment by Jie Dong</li>
	 <li>Clarifications based on comments from Tom Herbert</li>
	 <li>Clarifications based on comments from Ole Troan</li>
	 <li>Editorial Changes.</li>
       </ul>

     <t>draft-ietf-6man-hbh-processing-12, 2023-November-21:</t>
       <ul spacing="compact">
         <li>Clarifications and text improvements based on review by
	 Fernando Gont.</li>
	 <li>Editorial Changes.</li>
       </ul>

      <t>draft-ietf-6man-hbh-processing-11, 2023-November-5:</t>
       <ul spacing="compact">
         <li>Clarifications and text improvements based on review by Adrian Farrel.</li>
	 <li>Editorial Changes.</li>
       </ul>

     <t>draft-ietf-6man-hbh-processing-10, 2023-September-26:</t>
       <ul spacing="compact">
         <li>Clarifying changes based on comments received during the
	 IPv6 w.g. session at IETF117 from Lorenzo Colitti, Toerless Eckert, and others.</li>
         <li>Clarifying changes based on comments received after the
	 first w.g. last call.</li>
	 <li>Editorial Changes.</li>
       </ul>

     <t>draft-ietf-6man-hbh-processing-09, 2023-July-4:</t>
       <ul spacing="compact">
         <li>Revised text in <xref target="TERM"/> relating to fast/slow path and processing</li>
	 <li>Restructured <xref target="HBH"/> to separate Hop-by-Hop
	 Options header and Hop-by-Hop options processing and configuration.</li>
         <li>Revised MUST/SHOULD language in <xref target="ONE"/>.</li>
         <li>Revised text to use consistant names for Hop-by-Hop Options
	 header and Hop-by-Hop options.</li>
	 <li>Revised <xref target="ONE"/> 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.</li>
	 <li>Added to <xref target="NEW"/> that new Hop-by-Hop options
	 SHOULD be designed expecting that routers may drop packets with
	 the new option.</li>
	 <li>Added new <xref target="HOW"/> on "Example of Robust Usage".</li>
         <li>Other editorial changes to improve readability and clarity.</li>
        </ul>

  <t>draft-ietf-6man-hbh-processing-08, 2023-April-30:</t>
  <ul spacing="compact">
      <li>Changed document that is no longer updates <xref
      target="RFC7045"/>, it now clarifies it using the language of BCP 14.
      </li>
      <li>Added additional clarification to  <xref target="BACKGROUND"/>.</li>
      <li>Editorial changes</li>
    </ul>

  <t>draft-ietf-6man-hbh-processing-07, 2023-April-6:</t>
  <ul spacing="compact">
      <li>Changed text to clarify how hosts and routers process the
      Hop-by-Hop Options header based on comments at 6MAN session at IETF 116.
      </li>
      <li>Editorial changes</li>
    </ul>

  <t>draft-ietf-6man-hbh-processing-06, 2023-March-11:</t>
  <ul spacing="compact">
      <li>Added reference to RFC6564.</li>
      <li>Editorial changes</li>
    </ul>

  <t>draft-ietf-6man-hbh-processing-05, 2023-February-23:</t>
  <ul spacing="compact">
      <li>Clarified text in <xref target="NEW"/> about processing
      complexity and time to process.</li>
      <li>Added a definition to <xref target="TERM"/> for "Full
      Forwarding Rate".</li>
      <li>Added text to <xref target="FAST"/> about nodes that do not
      process the Hop-by-Hop Options header.</li>
      <li>Added text to <xref target="BACKGROUND"/> about slow path processing
      can cause packets to be deliver out of order to the destination.</li>
      <li>Editorial changes</li>
    </ul>

  <t>draft-ietf-6man-hbh-processing-04, 2022-October-21:</t>
    <ul spacing="compact">
      <li>Add a paragraph to  <xref target="BACKGROUND"/> that describes the
      relationship to  <xref target="RFC7045"/> "Transmission and Processing of IPv6
      Extension Headers".</li>
      <li>Change that this draft updates section 2.2 of <xref target="RFC7045"/>.
      </li>
    </ul>

  <t>draft-ietf-6man-hbh-processing-03, 2022-October-12:</t>
    <ul spacing="compact">
      <li>Changed in <xref target="FAST"/> to have router skip over options if can't
      process at full forwarding rate.</li>
      <li>Added to <xref target="NEW"/> that new options should be
      defined with action type set to 00.</li>
    </ul>

  <t>draft-ietf-6man-hbh-processing-02, 2022-August-23:</t>
    <ul spacing="compact">
      <li>Several clarification and editorial changes suggested by a review
      by Peng Shuping.</li>
      <li>Editorial changes.</li>
      <li>Revised text relating to fast/slow path and processing
      rates.</li>
      <li>Revised the third paragraph in <xref target="CONFIG"/> to be clearer.</li>
      <li>Revised text in Security section based on comments from Fernando Gont.</li>
    </ul>

  <t>draft-ietf-6man-hbh-processing-01, 2022-June-15:</t>

    <ul spacing="compact">
      <li>Fixed typo in last paragraph of <xref target="FAST"/> </li>
      <li>Revised text in <xref target="BACKGROUND"/> to reflect
      constraints on publishing RFC 8200. </li>
      <li>Changed text in  <xref target="NEW"/> that new options
      SHOULD NOT (from MUST NOT) be defined that require that are not
      expected to be excepted at full forwarding rates.</li>
      <li>Added reference to RFC7872 in <xref target="BACKGROUND"/>.</li>
      <li>Added text to <xref target="INTRO"/> that the focus of this
      document is to set a minimum bound on the number of Hop-by-Hop
      options a node should process.</li>
      <li>Added text to  <xref target="BACKGROUND"/> that the authors
      some Hop-by-Hop options will be supported Internet wide, and
      others only in limited domains.</li>

      <li>Editorial changes.</li>
</ul>

  <t>draft-ietf-6man-hbh-processing-00, 2022-January-29:</t>

    <ul spacing="compact">
      <li>6MAN Working Group Draft</li>
      <li>Reworked text to talk about processing Hop-by-Hop options at full
      forwarding rates, instead of "fast path"</li>
      <li>Revised <xref target="NEW"/> "New Hop-by-Hop options" to allow variable sized Hop-by-Hop
      options, remove specific length requirements, and other clarifications.
      </li>
      <li>Editorial changes.</li>
    </ul>

  <t>draft-hinden-6man-hbh-processing-01, 2021-June-2:</t>

    <ul spacing="compact">
    <li>Expanded terminology section to include forwarding plane and
        control plane.</li>
    <li>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.</li>
    <li>Clarified that all Hop-by-Hop options (with one exception) must be
        processed on the Fast Path.</li>
    <li>Kept the Router Alert Option as the single exception for Slow
    Path processing.</li>
    <li>Rewrote and expanded section on New Hop-by-Hop options.</li>
    <li>Removed requirement for Hop-by-Hop option size and alignment.</li>
    <li>Removed sections evaluating currently defined Hop-by-Hop options.</li>
    <li>Added content to the Security Considerations section.</li>
    <li>Added people to the acknowledgements section.</li>
    <li>Numerous editorial changes</li>
    </ul>

   <t>draft-hinden-6man-hbh-processing-00, 2020-Nov-29:</t>

   <ul spacing="compact">
      <li>Initial draft.</li>
   </ul>

 </section>

</middle>

<back>
  <displayreference target="I-D.ietf-v6ops-hbh" to="HBH"/>
  <displayreference target="I-D.ietf-taps-arch" to="TAPS-ARCH"/>
  <references>
      <name>Normative References</name>

      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8200.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8200.xml"/>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
      <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>

      <reference anchor="IANA-HBH"
       target="https://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#ipv6-parameters-2">
       target="https://www.iana.org/assignments/ipv6-parameters/">
          <front>
            <title>Destination Options and Hop-by-Hop Options</title>
            <author/>
            <author>
              <organization>IANA</organization>
            </author>
            <date/>
          </front>
        </reference>

    </references>

  <references>
     <name>Informative References</name>

     <reference anchor="IANA-RA"
       target="https://www.iana.org/assignments/ipv6-routeralert-values/ipv6-routeralert-values">
       target="https://www.iana.org/assignments/ipv6-routeralert-values/">
          <front>
            <title>IPv6 Router Alert Option Values</title>
            <author/>
            <author>
              <organization>IANA</organization>
            </author>
            <date/>
          </front>
        </reference>

    <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.1883.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1883.xml"/>
    <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2460.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2460.xml"/>
    <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2711.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2711.xml"/>
    <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4443.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4443.xml"/>
    <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6398.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6398.xml"/>
    <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6192.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6192.xml"/>
    <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6564.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6564.xml"/>
    <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7045.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7045.xml"/>
    <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7872.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7872.xml"/>
    <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8799.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8799.xml"/>
    <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.9098.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9098.xml"/>
    <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.9268.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9268.xml"/>
    <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.9288.xml"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9288.xml"/>

<!-- [I-D.ietf-v6ops-hbh] IESG state: Expired as of 09/30/24-->
    <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-6man-eh-limits.xml"/> href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-v6ops-hbh.xml"/>

<!-- [I-D.ietf-taps-arch] IESG state: RFC Ed Queue (EDIT) as of 09/30/24 (C508 document). Missing editors. -->
    <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-v6ops-hbh.xml"/>
    <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-taps-arch.xml"/>

<reference anchor="I-D.ietf-taps-arch" target="https://datatracker.ietf.org/doc/html/draft-ietf-taps-arch-19">
<front>
<title>
Architecture and Requirements for Transport Services
</title>
<author initials="T." surname="Pauly" fullname="Tommy Pauly" role="editor">
<organization>Apple Inc.</organization>
</author>
<author initials="B." surname="Trammell" fullname="Brian Trammell" role="editor">
<organization>Google Switzerland GmbH</organization>
</author>
<author initials="A." surname="Brunstrom" fullname="Anna Brunstrom">
<organization>Karlstad University</organization>
</author>
<author initials="G." surname="Fairhurst" fullname="Gorry Fairhurst">
<organization>University of Aberdeen</organization>
</author>
<author initials="C." surname="Perkins" fullname="Colin Perkins">
<organization>University of Glasgow</organization>
</author>
<date month="November" day="9" year="2023"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-taps-arch-19"/>
</reference>

    <reference anchor="Hendriks" target="http://dl.ifip.org/db/conf/tma/tma2017/tma2017_paper22.pdf">
       <front>
          <title>Threats and Surprises behind IPv6 Extension Headers</title>
          <author initials="L" surname="Hendriks" fullname="Luuk Hendriks">
           <organization>University of Twente</organization>
            </author>
          <author initials="P" surname="Velan" fullname="Petr Velan">
           <organization>University of Twente</organization>
            </author>
          <author initials="RO" surname="Schmidt" fullname="Ricardo de O. Schmidt">
           <organization>University of Twente</organization>
            </author>
          <author initials="P" surname="Boer" fullname="Pieter-Tjerk de Boer">
           <organization>University of Twente</organization>
            </author>
          <author initials="A" surname="Aiko" fullname="Aiko Pras">
           <organization>University of Twente</organization>
            </author>
            <date month="August" year="2017" />
        </front>
        <seriesInfo name="" value="" name="DOI" value="10.23919/TMA.2017.8002912" />
        <refcontent></refcontent>
        <refcontent>2017 Network Traffic Measurement and Analysis Conference (TMA)</refcontent>
   </reference>

   <reference anchor="Tram17" target="https://irtf.org/anrw/2017/anrw17-final16.pdf">
       <front>
          <title>Tracking Transport-Layer Evolution with PATH Spider</title> PATHspider</title>
          <author initials="B" surname="Trammell" fullname="Brian Trammell">
          </author>
          <author initials="M" surname="Kuehlewind" surname="Kühlewind" fullname="Mirja Kuehlewind"> Kühlewind">
          </author>
          <author initials="P" surname="De Vaere" fullname="Piet De Vaere">
          </author>
          <author initials="IR" initials="I" surname="Learmonth" fullname="Iain Learmonth ">
          </author>
          <author initials="G" surname="Fairhurst" fullname="Gorry Fairhurst">
          </author>
            <date month="July" year="2017" />
        </front>
        <seriesInfo name="ANRW" value="" name="DOI" value="10.1145/3106328.3106336" />
        <refcontent></refcontent>
        <refcontent>ANRW '17: Proceedings of the 2017 Applied Networking Research Workshop</refcontent>
   </reference>

   <reference anchor="Cus23a" target="http://www.iepg.org/2023-03-26-ietf116/eh.pdf">
       <front>
          <title>Internet Measurements: IPv6 Extension Header Edition</title>
          <author initials="A" surname="Custura" fullname="Ana Custura ">
          </author>
          <author initials="G" surname="Fairhurst" fullname="Gorry Fairhurst">
          </author>
            <date month="March" year="2023" />
        </front>
        <seriesInfo name="IEPG, IETF-116" value="" />
        <refcontent></refcontent>
        <refcontent>IEPG Meeting: IETF 116</refcontent>
   </reference>

  <reference anchor="Cus23b" target="https://www.sciencedirect.com/science/article/pii/S0140366423003705">
   <front>
    <title>Is it possible to extend IPv6?</title>
    <author initials="A." surname="Custura" fullname="A. Custura"></author>
    <author initials="R." surname="Secchi" fullname="R. Secchi"></author>
    <author initials="E." surname="Boswell" fullname="E. Boswell"></author>
    <author initials="G." surname="Fairhurst" fullname="G. Fairhurst"></author>
    <date year="2023" month="Oct"/>
    <abstract>
      <t>The IPv6 Hop-by-Hop Options and Destination Options Extension
      Headers have historically faced challenges in deployment due to a
      lack of router support coupled with concerns around potential for
      denial-of-service attacks. However, there has been a renewed
      interest within the standards community both in simplifying their
      processing, and in using these extension headers for new
      applications. Through a wide-scale measurement campaign, we show
      that many autonomous systems in both access networks and the core
      of the Internet do permit the traversal of packets that include
      options, and that the path traversal currently depends on the type
      of network, size of the option and the transport protocol used, but
      does not usually depend on the type of included option. This is an
      encouraging result when considering the extensibility of IPv6. We
      show that packets that include an extension header can also impact
      the function of load balancing network devices, and present
      evidence of equipment mis-configuration, noting that a different
      path to the same destination can result in a different traversal
      result. Finally, we outline the current deployment challenges and
      provide recommendations for how extension headers can utilise
      options to extend IPv6.</t>
    </abstract> year="2024" month="Jan"/>
  </front>
  <refcontent>Computer Communications, vol. 214, pp. 90-99</refcontent>
  <seriesInfo name="Computer Communications" value="X"/> name="DOI" value="10.1016/j.comcom.2023.10.006"/>
</reference>

</references>
<section anchor="Ack" numbered="false">
  <name>Acknowledgments</name>
    <t>Helpful comments were received from <contact fullname="Brian
    Carpenter"/>, <contact fullname="Ron Bonica"/>, <contact fullname="Ole
    Troan"/>, <contact fullname="Mike Heard"/>, <contact fullname="Tom
    Herbert"/>, <contact fullname="Cheng Li"/>, <contact fullname="Éric
    Vyncke"/>, <contact fullname="Greg Mirsky"/>, <contact fullname="Xiao
    Min"/>, <contact fullname="Fernando Gont"/>, <contact fullname="Darren
    Dukes"/>, <contact fullname="Peng Shuping"/>, <contact fullname="Dave
    Thaler"/>, <contact fullname="Ana Custura"/>, <contact fullname="Tim
    Winters"/>, <contact fullname="Jingrong Xie"/>, <contact fullname="Lorenzo
    Colitti"/>, <contact fullname="Toerless Eckert"/>, <contact
    fullname="Suresh Krishnan"/>, <contact fullname="Mikael Abrahamsson"/>,
    <contact fullname="Adrian Farrel"/>, <contact fullname="Jie Dong"/>,
    <contact fullname="Jen Linkova"/>, <contact fullname="Erik Kline"/>, and
    other members of the 6MAN Working Group.</t>

</section>
</back>
</rfc>