<?xml version="1.0" encoding="UTF-8"?> version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
  ]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?> "rfc2629-xhtml.ent">

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std"
     ipr="trust200902" number="8883" docName="draft-ietf-6man-icmp-limits-08"
     submissionType="IETF" > obsoletes="" updates="" xml:lang="en"
     tocInclude="true" symRefs="true" sortRefs="true" version="3"
     consensus="true">

  <front>
    <title abbrev="ICMPv6 limits">ICMPv6 errors Limits">ICMPv6 Errors for discarding packets due Discarding Packets Due to processing limits</title> Processing Limits</title>
    <seriesInfo name="RFC" value="8883"/>
    <author initials='T.' initials="T." surname="Herbert" fullname='Tom Herbert'> fullname="Tom Herbert">
      <organization>Intel</organization>
      <address>
        <postal>
          <street/>
          <city>Santa Clara, CA</city>
         <region/> Clara</city>
          <region>CA</region>
          <code/>
         <country>USA</country>
          <country>United States of America</country>
        </postal>
        <email>tom@quantonium.net</email>
      </address>
    </author>
  <date/>
    <date month="September" year="2020"/>
<keyword>extension Headers</keyword>
<keyword>destination Options</keyword>
<keyword>Hop-by-Hop Options</keyword>

    <abstract>
      <t>
    Network nodes may discard packets if they are unable to process
    protocol headers of packets due to processing constraints or limits.
    When such packets are dropped, the sender receives no indication indication, so
    it cannot take action to address the cause of discarded packets. This
    specification defines several new ICMPv6 errors that can be sent by a
    node that discards packets because it is unable to process the
    protocol headers. A node that receives such an ICMPv6 error may use
    the information to diagnose packet loss and may modify what it sends
    in future packets to avoid subsequent packet discards.
      </t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>
    This document specifies several new ICMPv6 errors that can be sent
    when a node discards a packet due to it being unable to process the
    necessary protocol headers because of processing constraints or
    limits. New ICMPv6 code points are defined to supplement those defined
    in <xref target="RFC4443" />. format="default"/>.
    Six of the errors are specific to the processing of extension headers;
    another error is used when the aggregate protocol headers in a packet
    exceed the processing limits of a node.
      </t>
      <section title="Extension header limits"> numbered="true" toc="default">
        <name>Extension Header Limits</name>

        <t>
    In IPv6, optional internet-layer information is carried in one or
    more IPv6 Extension Headers extension headers <xref target="RFC8200" />. format="default"/>.
    Extension Headers headers are placed
    between the IPv6 header and the Upper-Layer Header upper-layer header in a packet. The
    term "Header Chain" "header chain" refers collectively to the IPv6 header, Extension
    Headers, extension
    headers, and Upper-Layer Headers upper-layer headers occurring in a packet. Individual
    extension headers may have a maximum length of 2048 octets and must
    fit into a single packet. Destination Options and Hop-by-Hop Options
    contain a list of options in Type-length-value type-length-value (TLV) format. Each
    option includes a length of the data field in octets: the minimum
    size of an option (non-pad type) is two octets octets, and the maximum size
    is 257 octets. The number of options in an extension header is only
    limited by the length of the extension header and the Path MTU from
    the source to the destination. Options may be skipped over by a
    receiver if they are unknown and the Option Type indicates to skip
    (first two high order bits are 00).
  </t><t>
        </t>
        <t>
    Per <xref target="RFC8200" />, format="default"/>, except for Hop by Hop options, Hop-by-Hop Options, extension
    headers are not examined or processed by intermediate nodes. Many However, in
    deployed networks, many intermediate nodes, however, nodes do examine extension headers for various
    purposes. For instance, a node may examine all extension headers to
    locate the transport header of a packet in order to implement transport
    layer transport-layer filtering or to track connections to implement a stateful firewall.
  </t><t>
        </t>
        <t>
    Destination hosts are expected to process all extension headers and
    options in Hop-by-Hop and Destination Options.
  </t><t>
        </t>
        <t>
    Due to the variable lengths, high maximum lengths, or potential for
    Denial of Service a denial-of-service attack of extension headers, many devices impose
    operational limits on extension headers in packets they process.
    <xref target="RFC7045" /> format="default"/> discusses the requirements of intermediate
    nodes that discard packets because of unrecognized extension headers.
    <xref target="RFC8504" /> format="default"/> discusses limits that may be applied to the
    number of options in Hop-by-Hop Options or Destination Options extension
    headers. Both intermediate nodes and end hosts may apply limits to
    extension header processing. When a limit is exceeded, the typical
    behavior is to silently discard the packet.
  </t><t>
        </t>
        <t>
    This specification defines six Parameter Problem codes that may be sent
    by a node that discards a packet due to the processing limits of extension
    headers being exceeded. The information in these ICMPv6 errors may be
    used for diagnostics to determine why packets are being dropped.
    Additionally, a source node that receives these ICMPv6 errors may be
    able to modify its use of extension headers in subsequent packets sent
    to the destination in order to avoid further occurrences of packets being
    discarded.
        </t>
      </section>
      <section title="Aggregate header limits"> numbered="true" toc="default">
        <name>Aggregate Header Limits</name>
        <t>
    Some hardware devices implement a parsing buffer of a fixed size to
    process packets. The parsing buffer is expected to contain all the
    headers (often up to a transport layer transport-layer header for filtering) that a
    device needs to examine. If the aggregate length of headers in a
    packet exceeds the size of the parsing buffer, a device will either
    discard the packet or will defer processing to a software slow path. In
    any case, no indication of a problem is sent back to the sender.
  </t><t>
        </t>
        <t>
    This document defines one code for ICMPv6 Destination Unreachable
    that is sent by a node that is unable to process the headers of a
    packet due to the aggregate size of the packet headers exceeding a
    processing limit. The information in this ICMPv6 error may be used for
    diagnostics to determine why packets are being dropped. Additionally, a
    source node that receives this ICMPv6 error may be able to modify
    the headers used in subsequent packets to try to avoid further
    occurrences of packets being discarded.
        </t>
      </section>
      <section title="Nonconformant packet discard"> numbered="true" toc="default">
        <name>Nonconformant Packet Discard</name>
        <t>
    The ICMP errors defined in this specification may be applicable to
    scenarios for in which a node is dropping packets outside the auspices
    of any standard specification. For instance, an intermediate node
    might send a "Headers too long" code in the a case that where it drops a
    packet because it is unable to parse deep deeply enough to extract transport
    layer the transport-layer information needed for packet filtering. Such behavior might be
    considered nonconformant (with respect to
    <xref target="RFC8200" /> format="default"/>, for instance).
  </t><t>
        </t>
        <t>
    This specification does not advocate behaviors that might be
    considered nonconformant. However, packet discard does occur in real
    deployments
    deployments, and the intent of this specification is to provide
    visibility as to why packets are being discarded. In the spirit that
    providing some reason is better than a silent drop, the sending of ICMP
    errors is RECOMMENDED <bcp14>RECOMMENDED</bcp14> even in cases where a node
    might be discarding packets per a nonconformant behavior.
        </t>
      </section>
      <section title="Terminology" anchor="sec-definitions"> anchor="sec-definitions" numbered="true" toc="default">
        <name>Terminology</name>
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
    NOT", "SHOULD", "SHOULD 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&nbsp;14 <xref target="RFC2119"/>. target="RFC2119"/> <xref target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.
        </t>
      </section>
    </section>
    <section title="ICMPv6 errors numbered="true" toc="default">
      <name>ICMPv6 Errors for extension header limits"> Extension Header Limits</name>
      <t>
    Six new codes are defined for the Parameter Problem type.
      </t>
      <section title="Format"> numbered="true" toc="default">
        <name>Format</name>
        <t>
    The format of the ICMPv6 Parameter Problem message <xref target="RFC4443" /> format="default"/>
    for an extension header limit exceeded error is:

    <figure>
    <artwork>

        </t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |     Code      |          Checksum             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            Pointer                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                    As much of the invoking packet             |
+               as possible without the ICMPv6 packet           +
|              exceeding the minimum IPv6 MTU [RFC8200]         |
    </artwork>
    </figure>

    <list style="hanging">
      <t hangText="IPv6
]]></artwork>

<dl newline="true" spacing="normal">
          <dt>IPv6 Header Fields:">
        <list style="hanging">
	  <t hangText="Destination Address">
            <vspace /> Fields:</dt>

          <dd>
            <dl newline="true" spacing="normal">
              <dt>Destination Address:</dt>
              <dd>
            Copied from the Source Address field of the invoking packet.
          </t>
        </list>
      </t>
      <t hangText="ICMPv6 Fields:">
        <list style="hanging">
          <t hangText="Type">
            <vspace />
            4 (Parameter
          </dd>
            </dl>
          </dd>

          <dt>ICMPv6 Fields:</dt>

          <dd>
            <dl newline="true" spacing="normal">
              <dt>Type:</dt>
              <dd>
		<dl>
		  <dt>4</dt><dd>(Parameter Problem type)
            <vspace />
          </t>
          <?rfc subcompact="yes"?>
          <t hangText="Code (pertinent type)</dd>
		</dl>
	      </dd>
	    </dl>
            <dl newline="true" spacing="normal">
              <dt>Code:</dt><dd>(pertinent to this specification)">
	    <list style="hanging" hangIndent="8">
              <t hangText="TBA1 -">
                Unrecognized specification)</dd>
	    </dl>

<table align="center">
        <tbody>
          <tr>
            <td align="left">5</td>
            <td align="left">Unrecognized Next Header type encountered
	    by intermediate node
              </t><t hangText="TBA2 -">
                Extension node</td>
          </tr>
          <tr>
            <td align="left">6</td>
            <td align="left">Extension header too big
              </t><t hangText="TBA3 -">
                Extension big</td>
          </tr>
          <tr>
            <td align="left">7</td>
            <td align="left">Extension header chain too long
              </t><t hangText="TBA4 -">
                Too long</td>
          </tr>
          <tr>
            <td align="left">8</td>
            <td align="left">Too many extension headers
              </t><t hangText="TBA5 -">
                Too headers</td>
          </tr>
          <tr>
            <td align="left">9</td>
            <td align="left">Too many options in extension header
              </t><t hangText="TBA6 -">
                Option header</td>
          </tr>
          <tr>
            <td align="left">10</td>
            <td align="left">Option too big
              </t>
            </list>
          </t>
          <?rfc subcompact="no"?>
          <t hangText="Pointer">
            <vspace /> big</td>
          </tr>
        </tbody>
</table>

       <dl newline="true" spacing="normal">
            <dt>Pointer:</dt>
              <dd>
                <t>
            Identifies the octet offset within the invoking packet where
            the problem occurred.
            <vspace blankLines="1" />
                </t>
                <t>
            The pointer will point beyond the end of the Invoking Packet IPv6 packet if
            the field exceeding the limit is beyond what can fit in the
            maximum size of an ICMPv6 error message extension. message. If the
            pointer is used as an offset to read the data in the invoking
            packet
            packet, then a node MUST <bcp14>MUST</bcp14> first validate that the pointer value
            is less than the length of the Invoking Packet invoking packet data.
                </t>
        </list>
      </t>
    </list>
  </t>
              </dd>
   </dl>
       </dd>
       </dl>

      </section>
      <section title="Unrecognized numbered="true" toc="default">
        <name>Unrecognized Next Header type encountered Type Encountered by intermediate node (code TBA1)"> Intermediate Node (Code 5)</name>
        <t>
    This code SHOULD <bcp14>SHOULD</bcp14> be sent by an intermediate node that discards a
    packet because it encounters a Next Header type that is unknown in
    its examination. The ICMPv6 Pointer field is set to the offset of the
    unrecognized next header Next Header value within the original packet.
  </t><t>
        </t>
        <t>
    Note that this code is sent by intermediate nodes, nodes and
    SHOULD NOT
    <bcp14>SHOULD NOT</bcp14> be sent by a final destination. If a final destination
    node observes an unrecognized header header, then it SHOULD <bcp14>SHOULD</bcp14> send an ICMP Parameter
    Problem message with an ICMP Code value of 1 ("unrecognized Next Header
    type encountered") as specified in <xref target="RFC8200" />. format="default"/>.
        </t>
      </section>
      <section title="Extension header too big (code TBA2)"> numbered="true" toc="default">
        <name>Extension Header Too Big (Code 6)</name>
        <t>
    An ICMPv6 Parameter Problem with code for "extension "Extension header too big"
    SHOULD
    <bcp14>SHOULD</bcp14> be sent when a node discards a packet because the size of an
    extension header exceeds its processing limit. The ICMPv6 Pointer
    field is set to the offset of the first octet in the extension header
    that exceeds the limit.
        </t>
      </section>
      <section title="Extension header chain too long (code TBA3)"> numbered="true" toc="default">
        <name>Extension Header Chain Too Long (Code 7)</name>
        <t>
    An ICMPv6 Parameter Problem with code for "extension "Extension header chain too
    long" SHOULD <bcp14>SHOULD</bcp14> be sent when a node discards a packet with an extension
    header chain that exceeds a limit on the total size in octets of the
    header chain. The ICMPv6 Pointer is set to the first octet beyond the
    limit.
        </t>
      </section>
      <section title="Too many extension headers (code TBA4)"> numbered="true" toc="default">
        <name>Too Many Extension Headers (Code 8)</name>
        <t>
    An ICMPv6 Parameter Problem with code for "too "Too many extension headers"
    SHOULD
    <bcp14>SHOULD</bcp14> be sent when a node discards a packet with an extension
    header chain that exceeds a limit on the number of extension headers
    in the chain. The ICMPv6 Pointer is set to the offset of the first octet of
    the first extension header that is beyond the limit.
        </t>
      </section>
      <section title="Too many options numbered="true" toc="default">
        <name>Too Many Options in extension header (code TBA5)"> Extension Header (Code 9)</name>
        <t>
    An ICMPv6 Parameter Problem with code for "too "Too many options in
    extension header" SHOULD <bcp14>SHOULD</bcp14> be sent when a node discards a packet with
    an extension header that has a number of options that exceeds the
    processing limits of the node. This code is applicable for
    Destination options Options and Hop-by-Hop options. Options. The ICMPv6 Pointer field
    is set to the first octet of the first option that exceeds the limit.
        </t>
      </section>
      <section title="Option too big (code TBA6)"> numbered="true" toc="default">
        <name>Option Too Big (Code 10)</name>
        <t>
    An ICMPv6 Parameter Problem with code for "option "Option too big" is sent in
    two different cases: when the length of an individual Hop-by-Hop or
    Destination option Option exceeds a limit, or when the length or number of
    consecutive Hop-by-Hop or Destination padding options exceeds a
    limit. In the a case that where the length of an option exceeds a processing
    limit, the ICMPv6 Pointer field is set to the offset of the first
    octet of the option that exceeds the limit. In the cases that where the
    length or number of padding options exceeds a limit, the ICMPv6
    Pointer field is set to the offset of the first octet of the padding
    option that exceeds the limit.

    <list style="hanging">
      <t hangText="Possible

        </t>
<t>Possible limits related to padding include:">
        <list style="hanging">
          <t hangText="*"> include:</t>
        <ul spacing="normal" empty="false">
<li>
            The number of consecutive PAD1 options in destination
            options Destination
            Options or hop-by-hop options Hop-by-Hop Options is limited to seven octets
            <xref target="RFC8504" />.
          </t><t hangText="*"> format="default"/>.
          </li>
<li>
            The length of PADN options in destination options Destination Options or
            hop-by-hop options
            Hop-by-Hop Options is limited seven octets
            <xref target="RFC8504" />.
          </t><t hangText="*"> format="default"/>.
          </li>
<li>
            The aggregate length of a set of consecutive PAD1 or PADN
            options in destination options Destination Options or hop-by-hop options Hop-by-Hop Options is
            limited to seven octets.
          </t>
        </list>
      </t>
    </list>
  </t>
          </li>
        </ul>
      </section>
    </section>
    <section title="ICMPv6 error numbered="true" toc="default">
      <name>ICMPv6 Error for aggregate header limits"> Aggregate Header Limits</name>
      <t>
    One code is defined for the Destination Unreachable type for aggregate
    header limits.
  </t><t>
      </t>
      <t>
    This ICMP error may be applied to other headers in a packet
    than just the IPv6 header or IPv6 extension headers. Therefore,
    a Destination Unreachable type with a multi-part ICMPv6 message
    format is used in lieu of the Parameter Problem type type, which only
    indicates errors concerning IPv6 headers.
      </t>
      <section title="Format"> numbered="true" toc="default">
        <name>Format</name>
        <t>
     The error for aggregate header limits employs a multi-part ICMPv6
     message format as defined in <xref target="RFC4884" />. format="default"/>.
     The extension object class "Extended Information" is defined to
     contain objects for ancillary information pertaining to an ICMP
     Destination Unreachable error. Within this object class, the sub-type
     "Pointer" is defined defined, which contains a Pointer field with similar
     semantics to the Pointer field in ICMP Parameter Problem errors.
  </t><t>
        </t>
        <t>
     The format of the ICMPv6 message for an aggregate header limit
     exceeded is:

  <figure>
  <artwork>

        </t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\
|     Type      |     Code      |          Checksum             | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I
|    Length     |                  Unused                       | C
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ M
|                           Invoking Packet                                                               | P
~                As much of the invoking packet                 ~
|              as possible without the       ~ |
| ICMPv6 packet            |
|             exceeding the minimum IPv6 MTU [RFC8200]          |/
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/
|Version|       Reserved        |           Checksum            |\
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ E
|             Length            |   Class-Num   |   C-Type      | X
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ T
|                            Pointer                            | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/
  </artwork>
  </figure>

  <list style="hanging">
    <t hangText="IPv6
  ]]></artwork>
        <dl newline="true" spacing="normal">
          <dt>IPv6 Header Fields:">
      <list style="hanging">
        <t hangText="Destination Address">
          <vspace /> Fields:</dt>
          <dd>
            <dl newline="true" spacing="normal">
              <dt>Destination Address:</dt>
              <dd>
          Copied from the Source Address field of the invoking packet.
        </t>
      </list>
    </t>
    <t hangText="ICMPv6 Fields:">
      <list style="hanging">
        <t hangText="Type">
          <vspace />
          1 - Destination Unreachable type
        </t>
        <t hangText="Code
        </dd>
            </dl>
          </dd>
          <dt>ICMPv6 Fields:</dt>
          <dd>
            <dl newline="true" spacing="normal">
              <dt>Type:</dt>
              <dd>
		<dl><dt>1 -</dt><dd>Destination Unreachable</dd>
		</dl>
		</dd>
              <dt>Code: (pertinent to this specification)">
          <vspace />
          TBA7 - Headers specification)</dt>
              <dd>
		<dl>
	      <dt>8 -</dt><dd>Headers too long
        </t>
        <t hangText="Length">
          <vspace />
          Length long</dd></dl></dd>
              <dt>Length:</dt>
              <dd>Length of the padded Invoking Packet invoking packet data measured in 64-bit words.
          The ICMP extension structure immediately follows the padded
          Invoking Packet
        </t>
        <t hangText="Invoking Packet">
          <vspace />
          Contains
          invoking packet data.</dd>
              <dt>Invoking Packet:</dt>
              <dd>Contains as much of the invoking packet as possible without the
          ICMPv6 packet exceeding the minimum IPv6 MTU. The Invoking
          Packet MUST invoking
          packet data <bcp14>MUST</bcp14> be zero padded to the nearest 64-bit boundary
          <xref target="RFC4884" />. format="default"/>.
          If the original invoking packet did not contain 128
          octets, the Invoking Packet MUST invoking packet data <bcp14>MUST</bcp14> be zero padded to 128 octets.
        </t>
      </list>
    </t>
    <t hangText="ICMP octets.</dd>
            </dl>
          </dd>
          <dt>ICMP Extension Fields:">
      <list style="hanging">
        <t hangText="Version">
          <vspace />
          2 - per Fields:</dt>
          <dd>
            <dl newline="true" spacing="normal">
              <dt>Version:</dt>
              <dd>
	      <dl>
		<dt>2 -</dt><dd>per <xref target="RFC4884" />
        </t>
        <t hangText="Reserved">
          <vspace />
          0</t>
        <t hangText="Checksum">
          <vspace />
          The
		format="default"/></dd>
	      </dl></dd>
              <dt>Reserved:</dt>
              <dd>0</dd>
              <dt>Checksum:</dt>
              <dd>The one's complement checksum of the ICMP extension
          <xref target="RFC4884" />
        </t><t hangText="Length">
          <vspace />
          8 - length format="default"/></dd>
              <dt>Length:</dt>
              <dd>
		<dl>
		  <dt>8 -</dt><dd>length of the object header and Pointer field
        </t><t hangText="Class-Num">
          <vspace />
          TBA8 - Extended Information class
        </t><t hangText="C-Type">
          <vspace />
          TBA9 - Pointer sub-type
        </t><t hangText="Pointer">
          <vspace />
          Identifies
		  field</dd>
		</dl></dd>
              <dt>Class-Num:</dt>
              <dd>
	      <dl>
		<dt>4 -</dt><dd>Extended Information</dd>
	      </dl></dd>
              <dt>C-Type:</dt>
              <dd>
	      <dl>
	      <dt>1 -</dt><dd>Pointer</dd>
	      </dl></dd>
              <dt>Pointer:</dt>
              <dd><t>Identifies the octet offset within the invoking packet
          where a limit was exceeded.
          <vspace blankLines="1" />
          The exceeded.</t>
          <t>The pointer will point beyond the end of the Invoking Packet invoking packet data if
          the field exceeding the limit is beyond what can fit in the
          maximum size of an ICMPv6 error message with the ICMP
          extension. If the pointer is used as an offset to read the data
          in the invoking packet packet, then a node MUST <bcp14>MUST</bcp14> first validate
          that the pointer value is less than the length of the Invoking
          Packet data.
        </t>
      </list>
    </t>
  </list>
</t> invoking
          packet data.</t>
              </dd>
            </dl>
          </dd>
        </dl>
      </section>
      <section title="Usage"> numbered="true" toc="default">
        <name>Usage</name>
        <t>
    An ICMPv6 Destination Unreachable error with code for "headers "Headers
    too long" SHOULD <bcp14>SHOULD</bcp14> be sent when a node discards a packet because
    the aggregate length of the headers in the packet exceeds the
    processing limits of the node. The Pointer in the extended
    ICMPv6 structure is set to the offset of the first octet that
    exceeds the limit.
  </t><t>
        </t>
        <t>
    This error is sent in response to a node dropping a packet
    because the aggregate header chain exceeds the processing
    limits of a node. The aggregate header chain may be composed of
    protocol headers other than an IPv6 header and IPv6 extension
    headers. For instance, in the case of a node parsing a UDP
    encapsulation protocol, the encapsulating UDP header would be
    considered to be in the aggregate header chain.
  </t><t>
        </t>
        <t>
    As noted in section 4.1, <xref target="priority"/>, the ICMPv6 Destination Unreachable
    error with code for "headers "Headers too long" has the lowest
    precedence of the ICMP errors discussed in this specification.
    If a packet contains an error corresponding to a Parameter
    Problem code code, then a node SHOULD <bcp14>SHOULD</bcp14> send the Parameter Problem
    error instead of sending the ICMPv6 Destination Unreachable
    error with code for "headers "Headers too long".
</t>
      </section>
    </section>
    <section title="Operation"> numbered="true" toc="default">
      <name>Operation</name>
      <t>
    Nodes that send or receive ICMPv6 errors due to header
    processing limits MUST <bcp14>MUST</bcp14> comply with ICMPv6 processing as
    specified in <xref target="RFC4443" />. format="default"/>.
      </t>
      <section title="Priority anchor="priority" numbered="true" toc="default">
        <name>Priority of reporting"> Reporting</name>
        <t>
    More than one ICMPv6 error may be applicable to report for a
    packet. For instance, the number of extension headers in a
    packet might exceed a limit limit, and the aggregate length of
    protocol headers might also exceed a limit. Only one ICMPv6
    error SHOULD <bcp14>SHOULD</bcp14> be sent for a packet, so a priority is defined to
    determine which error to report.

    <list style="hanging">
      <t hangText="The RECOMMENDED

        </t>
<t>The <bcp14>RECOMMENDED</bcp14> reporting priority of ICMPv6 errors for
processing limits is listed from highest to lowest priority:">
        <list style="hanging">
          <t hangText="1)"> priority:</t>
            <ol spacing="normal">
<li>
            Existing ICMP errors defined in <xref target="RFC4443" />
          </t><t hangText="2)"> format="default"/>.
              </li>
<li>
            "Unrecognized Next Header type encountered by intermediate node"
          </t><t hangText="3)">
          </li>
<li>
            "Extension header too big"
          </t><t hangText="4)">
          </li>
<li>
            "Option too big" for length or number of consecutive padding
            options exceeding a limit
          </t><t hangText="5)"> limit.
          </li>
<li>
            "Option too big" for the length of an option exceeding a limit
          </t><t hangText="6)"> limit.
          </li>
<li>
            "Too many options in an extension header"
          </t><t hangText="7)">
          </li>
<li>
            "Extension header chain too long"
            headers exceeding a limit
          </t><t hangText="8)"> limit.
          </li>
<li>
            "Too many extension headers"
          </t><t hangText="9)">
          </li>
<li>
            "Headers too long"
          </t>
	</list>
      </t>
    </list>
  </t>
          </li>
            </ol>
      </section>
      <section title="Host response"> numbered="true" toc="default">
        <name>Host Response</name>
        <t>
    When a source host receives an ICMPv6 error for a processing limit
    being exceeded, it SHOULD <bcp14>SHOULD</bcp14> verify the ICMPv6 error is valid and take
    appropriate action as suggested below.
  </t><t>
        </t>
        <t>
    The general validations for ICMP as described in
    <xref target="RFC4443" /> format="default"/> are applicable. The packet in the ICMP data
    SHOULD
    <bcp14>SHOULD</bcp14> be validated to match the upper layer upper-layer process or connection that
    generated the original packet. Other validation checks that are specific
    to the upper layers may be performed and are out of the scope of this
    specification.
  </t><t>
        </t>
        <t>
    The ICMPv6 error SHOULD <bcp14>SHOULD</bcp14> be logged with sufficient detail for
    debugging packet loss. The details of the error, including the
    addresses and the offending extension header or data, should be
    retained. This, for instance, would be useful for debugging when a
    node is mis-configured misconfigured and unexpectedly discarding packets, packets or when a
    new extension header is being deployed.
  </t><t>
        </t>
        <t>
    A host MAY <bcp14>MAY</bcp14> modify its usage of protocol headers in subsequent packets
    to avoid repeated occurrences of the same error.

    <list style="hanging">
      <t hangText="For

        </t>
          <t>For ICMPv6 errors caused by extension header limits being exceeded:">
        <list style="hanging">
          <t hangText="*"> exceeded:</t>
            <ul empty="false" spacing="normal">
              <li>
            An error SHOULD <bcp14>SHOULD</bcp14> be reported to an application if
	    the application enabled extension headers for its traffic. In
	    response, the application may terminate communications if extension headers
            are required, stop using extension headers in packets to the
            destination indicated by the ICMPv6 error, or attempt to modify
            its use of extension headers or extension headers to avoid further packet
            discards.
          </t>
          <t hangText="*">
          </li>
<li>
            A host system SHOULD <bcp14>SHOULD</bcp14> take appropriate action if it is creating
            packets with extension headers on behalf of the application. If
            the offending extension header is not required for
            communication, the host may either stop sending it or otherwise
            modify its use in subsequent packets sent to the destination
            indicated in the ICMPv6 error.
          </t>
	</list>
      </t>
    </list>
  </t>
          </li>
        </ul>
      </section>
    </section>
    <section title="Applicability numbered="true" toc="default">
      <name>Applicability and use cases"> Use Cases</name>
      <section title="Reliability numbered="true" toc="default">
        <name>Reliability of ICMP"> ICMP</name>
        <t>
    ICMP is fundamentally an unreliable protocol and and, in real deployment deployment,
    it may consistently fail over some paths. As with any other use of
    ICMP, it is assumed that the errors defined in this document are only
    the best effort to be delivered. No protocol should be implemented that
    relies on reliable delivery of ICMP messages. If necessary,
    alternative or additional mechanisms may used be employed to augment the
    processes used to deduce the reason that packets are being
    discarded. For instance, ICMP error messages may be correlated with
    information attained through Packetization Layer Path MTU Discovery
    (PLMTUD)
    (PLPMTUD) <xref target="RFC4821" /> format="default"/> or Happy Eyeballs for IPv6
    <xref target="RFC8305" />. format="default"/>. Details of the
    interaction with alternative mechanisms are out of scope of this
    specification.
        </t>
      </section>
      <section title="Processing limits"> numbered="true" toc="default">
        <name>Processing Limits</name>
        <t>
    This section discusses the trends and motivations of processing
    limits that warrant ICMP errors.
        </t>
        <section title="Long headers numbered="true" toc="default">
          <name>Long Headers and header chains">
  <t>
    <list style="hanging">
      <t hangText="The Header Chains</name>
            <t>The trend towards longer and more complex headers and header chains needing to be processed by end nodes, as well as intermediate nodes, is driven by:">
        <list style="hanging">
          <t hangText="*"> by:</t>
              <ul empty="false" spacing="normal">
<li>
            Increasing prevalence of deep packet inspection in middleboxes.
            In particular, many intermediate nodes now parse network layer network-layer
            encapsulation protocols or transport layer transport-layer protocols.
          </t><t hangText="*">
          </li>

              <li>
            Deployment of routing headers. For instance,
            <xref target="I-D.ietf-6man-segment-routing-header" /> target="RFC8754" format="default"/> defines an
            extension header format that includes a list of IPv6 addresses
            which may consume a considerable number of bytes.
          </t><t hangText="*">
          </li>
                <li>
            Development of In-situ in situ OAM headers that allow a rich set of
            measurements to be gathered in the data path at the cost of
            additional header overhead overhead, which may be significant <xref target="I-D.ioametal-ippm-6man-ioam-ipv6-options" />.
          </t><t hangText="*"> target="I-D.ietf-ippm-ioam-ipv6-options" format="default"/>.
          </li>
                <li>
            Other emerging use cases of Hop-by-Hop and Destination options.
          </t>
	</list>
      </t>
    </list>
  </t> Options.
          </li>
          </ul>
        </section>
        <section title="At end hosts"> numbered="true" toc="default">
          <name>At End Hosts</name>
          <t>
    End hosts may implement limits on processing extension headers as
    described in <xref target="RFC8504" />. format="default"/>. Host implementations are usually
    software stacks that typically don't have inherent processing limitations.
    Limits imposed by a software stack are more likely to be for denial
    of service denial-of-service mitigation or performance.
          </t>
        </section>
        <section title="At intermediate nodes"> numbered="true" toc="default">
          <name>At Intermediate Nodes</name>
          <t>
    Hardware devices that process packet headers may have limits as to
    how many headers or bytes of headers they can process. For instance,
    a middlebox hardware implementation might have a parsing buffer that
    contains some number of bytes of packet headers to process. Parsing
    buffers typically have a fixed size such as sixty-four, 64, 128, or 256
    bytes. In addition, hardware implementations (and some software
    implementations) often don't have loop constructs. Processing of a
    TLV list might be implemented as an unrolled loop so that the number
    of TLVs that can be processed is limited.
          </t>
        </section>
      </section>
    </section>
    <section title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>
    The security considerations for ICMPv6 described in
    <xref target="RFC4443" /> format="default"/> are applicable. The ICMP errors described
    in this document MAY <bcp14>MAY</bcp14> be filtered by firewalls in accordance with
    <xref target="RFC4890" />.
  </t><t> format="default"/>.
      </t>
      <t>
    In some circumstances, the sending of ICMP errors might conceptually
    be exploited as a means to covertly deduce the processing capabilities of
    nodes. Accordingly, an implementation SHOULD <bcp14>SHOULD</bcp14> allow a configurable policy to
    withhold sending of the ICMP errors described in this specification in
    environments where the security of ICMP errors is a concern.
      </t>
    </section>
    <section title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <section title="Parameter numbered="true" toc="default">
        <name>Parameter Problem codes">
  <t>
    <list style="hanging">
      <t hangText="IANA is requested to assign Codes</name>
          <t>IANA has assigned the following codes for ICMPv6 type in the "Type 4 &quot;Parameter Problem&quot; [IANA-PARAMPROB]:">
        <list style="hanging">
          <t hangText="*">Unrecognized - Parameter
	  Problem" registry within the ICMPv6 Parameters registry <xref target="IANA-ICMP"/>:</t>

<table anchor="param-prob">
  <thead>
    <tr>
      <th>Code</th>
      <th>Name</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>5</td>
      <td>Unrecognized Next Header type encountered by intermediate node (value TBA1)</t>
          <t hangText="*">Extension node</td>
    </tr>
    <tr>
      <td>6</td>
      <td>Extension header too big (value TBA2)</t>
	  <t hangText="*">Extension big</td>
    </tr>
    <tr>
      <td>7</td>
      <td>Extension header chain too long (value TBA3)</t>
          <t hangText="*">Too long</td>
    </tr>
    <tr>
      <td>8</td>
      <td>Too many extension headers (value TBA4)</t>
	  <t hangText="*">Too headers</td>
    </tr>
    <tr>
      <td>9</td>
      <td>Too many options in extension header (value TBA5)</t>
	  <t hangText="*">Option header</td>
    </tr>
    <tr>
      <td>10</td>
      <td>Option too big (value TBA6)</t>
        </list>
      </t>
    </list>
  </t> big</td>
    </tr>
  </tbody>
</table>
      </section>
      <section title="Destination numbered="true" toc="default">
        <name>Destination Unreachable codes">
  <t>
    <list style="hanging">
      <t hangText="IANA is requested to assign Codes</name>
          <t>IANA has assigned the following code for ICMPv6 type in the "Type 1 &quot;Destination Unreachable&quot; [IANA-DESTUNREACH]:">
        <list style="hanging">
          <t hangText="*">Headers - Destination
	  Unreachable" registry within the ICMPv6 Parameters registry <xref target="IANA-ICMP"/>:</t>

<table anchor="dest-unreach">
  <thead>
    <tr>
      <th>Code</th>
      <th>Name</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>8</td>
      <td>Headers too long (value TBA7)</t>
	</list>
      </t>
    </list>
  </t> long</td>
    </tr>
  </tbody>
</table>
      </section>
      <section title="ICMP numbered="true" toc="default">
        <name>ICMP Extension Object Classes and Class Sub-types">
  <t>
    <list style="hanging">
      <t hangText="IANA is requested to assign Sub-types</name>
          <t>IANA has assigned the following Class value in
	  the &quot;ICMP "ICMP Extension Object Classes and Class Sub-types&quot; Sub-types"
	  registry [IANA-ICMPEXT]:">
        <list style="hanging">
          <t hangText="*">Extended information (value TBA8)</t>
        </list>
      </t>
    </list>
  </t><t> within the ICMP Parameters registry <xref target="IANA-ICMPEXT"/>:</t>
<table anchor="class-sub-types">
  <thead>
    <tr>
      <th>Class Value</th>
      <th>Class Name</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>4</td>
      <td>Extended Information</td>
    </tr>
  </tbody>
</table>
        <t>
    IANA is requested to create has created a Sub-type sub-type registry for the "Extended
    information"
    Information" ICMP extension object class. The registration procedure for
    this registry shall be is "Standards Action". The Sub-type sub-type value of 0
    shall be reserved,
    is reserved; values greater than zero may be assigned.
        </t>
  <t>
    <list style="hanging">
      <t hangText="IANA is requested to assign
          <t>IANA has assigned the following Sub-type sub-type within the "Sub-types —
	  Class 4 — Extended Information" registry within the &quot;Extended information&quot; ICMP extension object class:">
        <list style="hanging">
          <t hangText="*">Pointer (value TBA9)</t>
        </list>
      </t>
    </list>
  </t>
</section> Parameters registry:</t>

<table anchor="extended-info">
  <thead>
    <tr>
      <th>Value</th>
      <th>Description</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>1</td>
      <td>Pointer</td>
    </tr>
  </tbody>
</table>

      </section>
<section title="Acknowledgments">
<t>
The author would like to thank Ron Bonica, Bob Hinden, Nick Hilliard,
Michael Richardson, Mark Smith, Suresh Krishnan, and Ole Tran for
their comments and suggestions that improved this document.
</t>
    </section>
  </middle>

<?rfc needLines="20"?>
  <back>
<references title="Normative References">
  <?rfc include="reference.RFC.2119"?>
  <?rfc include="reference.RFC.4443"?>
  <?rfc include="reference.RFC.8200"?>
  <?rfc include="reference.RFC.7045"?>
  <?rfc include="reference.RFC.4884"?>

    <displayreference target="I-D.ietf-ippm-ioam-ipv6-options" to="OAM-IPV6"/>

 <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include
	    href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4443.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8200.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7045.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4884.xml"/>
        <reference anchor="IANA-PARAMPROB" target="https://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml#icmpv6-parameters-codes-5"> anchor="IANA-ICMP" target="https://www.iana.org/assignments/icmpv6-parameters/">
          <front>
            <title>Internet Control Message Protocol version 6 (ICMPv6) Parameters, Type 4 - Parameter Problem</title>
      <author/>
      <date/> Parameters</title>
            <author><organization>IANA</organization></author>
          </front>
        </reference>
        <reference anchor="IANA-DESTUNREACH" target="https://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml#icmpv6-parameters-codes-2"> anchor="IANA-ICMPEXT" target="https://www.iana.org/assignments/icmp-parameters/">
          <front>
            <title>Internet Control Message Protocol version 6 (ICMPv6) Parameters, Type 1 - Destination Unreachable</title>
      <author/>
      <date/>
    </front>
  </reference>
  <reference anchor="IANA-ICMPEXT" target="https://www.iana.org/assignments/icmp-parameters/icmp-parameters.xhtml#icmp-parameters-ext-classes">
    <front>
      <title>ICMP Extension Object Classes and Class Sub-types</title>
      <author/>
      <date/> (ICMP) Parameters</title>
            <author><organization>IANA</organization></author>
          </front>
        </reference>
      </references>

<references title="Informative References">
  <?rfc include="reference.RFC.8504"?>
  <?rfc include="reference.RFC.4890"?>
  <?rfc include="reference.RFC.4821"?>
  <?rfc include="reference.RFC.8305"?>
  <?rfc include="reference.I-D.draft-ietf-6man-segment-routing-header-26.xml"?>
  <?rfc include="reference.I-D.draft-ioametal-ippm-6man-ioam-ipv6-options-02.xml"?>
      <references>
        <name>Informative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8504.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4890.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4821.xml"/>
        <xi:include
	    href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8305.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8754.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-ippm-ioam-ipv6-options.xml"/>

      </references>
    </references>
    <section numbered="false" toc="default">
      <name>Acknowledgments</name>
      <t>
The author would like to thank <contact fullname="Ron Bonica"/>,
<contact fullname="Bob Hinden"/>, <contact fullname="Nick Hilliard"/>,
<contact fullname="Michael Richardson"/>, <contact fullname="Mark Smith"/>,
  <contact fullname="Suresh Krishnan"/>, and <contact fullname="Ole Tran"/> for
their comments and suggestions that improved this document.
</t>
    </section>
  </back>
</rfc>

<!-- Local Variables: -->
<!-- fill-column:72 -->
<!-- End: -->