<?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' ?>
    <!-- try to enforce the ID-nits conventions and DTD validity -->
<?rfc strict="no" ?>    <!-- items used when reviewing the document -->
<?rfc comments="no" ?>  <!-- controls display of <cref> elements -->
<?rfc inline="no" ?>    <!-- when no, put comments at end in comments section,
                                otherwise, put inline -->
<?rfc editing="no" ?>   <!-- when yes, insert editing marks -->

    <!-- create table of contents (set it options).
           Note the table of contents may be omitted
         for very short documents -->

<?rfc toc="yes"?><?rfc tocompact="yes"?>
<?rfc tocdepth="2"?>

    <!-- choose the options for the references. Some like
         symbolic tags in the references (and citations)
         and others prefer numbers. -->
<?rfc symrefs="yes"?><?rfc sortrefs="yes" ?>
    <!-- these two save paper: start new paragraphs from the same page etc. -->
<?rfc compact="yes" ?><?rfc subcompact="no" ?>
<!-- end of list of processing instructions -->
    <!-- Information about the document.
         categories values: std, bcp, info, exp, and historic
         For Internet-Drafts, specify attribute "ipr".
         (ipr values are: full3667, noModification3667, noDerivatives3667),
         Also for Internet-Drafts, can specify values for
         attributes "iprExtract", and "docName".  Note
         that the value for iprExtract is the anchor attribute
         value of a section that can be extracted, and is only
         useful when the value of "ipr" is not "full3667". -->
    <!-- TODO: verify which attributes are specified only
            by the RFC editor.  It appears that attributes
            "number", "obsoletes", "updates", and "seriesNo"
            are specified by the RFC editor (and not by
            the document author). --> [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" number="9288" category="info" ipr="trust200902" docName="draft-ietf-opsec-ipv6-eh-filtering-10" > obsoletes="" updates="" submissionType="IETF" xml:lang="en" consensus="true" tocInclude="true" tocDepth="2" symRefs="true" sortRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.12.10 -->
  <front>
    <title abbrev="Filtering of IPv6 packets Packets with EHs">Recommendations on the Filtering of IPv6 Packets Containing IPv6 Extension Headers at Transit Routers</title>

    <!-- add 'role="editor"' below for the editors if appropriate -->
    <seriesInfo name="RFC" value="9288"/>
    <author fullname="Fernando Gont" initials="F." surname="Gont">
      <organization abbrev="EdgeUno">EdgeUno</organization> abbrev="SI6 Networks">SI6 Networks</organization>
      <address>
        <postal>
          <street>Segurola y Habana 4310, 4310 7mo Piso</street>
          <city>Villa Devoto</city>
          <region>Ciudad piso</street>
          <city>Ciudad Autonoma de Buenos Aires</region> Aires</city>
          <country>Argentina</country>
        </postal>
        <email>fernando.gont@edgeuno.com</email>
        <uri>https://www.edgeuno.com</uri>
        <email>fgont@si6networks.com</email>
        <uri>https://www.si6networks.com</uri>
      </address>
    </author>
    <author fullname="Will (Shucheng) Liu" initials="W." surname="Liu">
      <organization>Huawei Technologies</organization>
      <address>
        <postal>
          <street>Bantian, Longgang District</street>
          <city>Shenzhen</city>
          <code>518129</code>
          <country>P.R. China</country>
          <country>China</country>
        </postal>
        <email>liushucheng@huawei.com</email>
      </address>
    </author>

<!--
    <author fullname="Ronald P. Bonica" initials="R." surname="Bonica">
      <organization>Juniper Networks</organization>

      <address>
        <postal>
          <street>2251 Corporate Park Drive</street>

          <city>Herndon</city>

          <region>VA</region>

          <code>20171</code>

          <country>US</country>
        </postal>

        <phone>571 250 5819</phone>

        <email>rbonica@juniper.net</email>
      </address>
    </author>
-->
<date month="August" year="2022" />
<!-- month="May" is no longer necessary note also, day="30" is optional -->
    <area>Operations and Management (ops)</area>    <!-- WG name at the upperleft corner of the doc,
         IETF fine for individual submissions -->
    <workgroup>opsec</workgroup>

 <keyword>Denial of Service</keyword>
 <keyword>Distributed Denial of Service</keyword>
 <keyword>DoS</keyword>
 <keyword>DDoS</keyword>
 <keyword>ACL</keyword>
 <keyword>filtering policy</keyword>
     <abstract>
      <t>
   This document analyzes the security implications of IPv6 Extension Headers and associated IPv6 options. Additionally, it discusses the operational and
   interoperability implications of discarding packets based on the
   IPv6 Extension Headers and IPv6 options they contain. Finally, it provides advice on the filtering of such IPv6
   packets at transit routers for traffic not directed to them, for those cases where such filtering is deemed as necessary.
</t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction" anchor="intro"> anchor="intro" numbered="true" toc="default">
      <name>Introduction</name>
      <t>IPv6 Extension Headers (EHs) allow for the extension of the IPv6
   protocol,
   protocol and provide support for core functionality functionality, such as IPv6
   fragmentation.  However, common implementation limitations suggest that EHs present a challenge for IPv6 packet routing equipment, particularly when the IPv6 header chain needs to be processed for e.g. for, as an example, enforcing ACLs Access Control Lists (ACLs) or implementing other functions <xref target="RFC9098"/>. target="RFC9098" format="default"/>.
</t>
      <t>Several studies (e.g. (e.g., <xref target="Huston-2022"/>, target="Huston-2022" format="default"/>, <xref target="I-D.vyncke-v6ops-james"/>, target="I-D.vyncke-v6ops-james" format="default"/>, and <xref target="RFC7872"/>) target="RFC7872" format="default"/>) suggest that there is widespread dropping of IPv6 packets that contain IPv6 Extension Headers (EHs). EHs. In some cases, such packet drops occur at transit routers. While some operators are known to intentionally drop packets that contain IPv6 EHs, it is possible that some of the measured packet drops are the result of inappropriate advice in this area.</t>
      <t>This document analyzes both the general security implications of
   IPv6 EHs, as well as the security implications of
   specific EH and Option option types. It also provides advice on the
   filtering of IPv6 packets based on the IPv6 EHs and
   the IPv6 options they contain. Since
   various protocols may use IPv6 EHs (possibly with IPv6
   options), discarding packets based on the IPv6 EHs or
   IPv6 options they contain can have implications on the proper
   functioning of such protocols.  Thus, this document also attempts to
   discuss the operational and interoperability implications of such
   filtering policies.</t>
      <t>The resulting packet filtering policy typically depends on where in the network such policy is enforced: when enforced. When the policy is enforced in a transit network, the policy typically follows a "deny-list" approach, where only packets with clear negative implications are dropped. On the other hand, when the policy is enforced closer to the destination systems, the policy typically follows an "accept-list" approach, where only traffic that is expected to be received is allowed. The advice in this document is aimed only at transit routers that may need to enforce a filtering policy based on the IPv6 EHs and IPv6 options a packet may contain, following a "deny-list" approach, and hence approach; hence, it is likely to be much more permissive than a filtering policy to be employed at e.g. at, for example, the edge of an enterprise network. The advice in this document is meant to improve the current situation of the dropping of packets with IPv6 EHs in the Internet <xref target="RFC7872"/> target="RFC7872" format="default"/> in such cases where packets are being dropped due to inappropriate or missing guidelines.</t>
            <t>This document is similar in nature to
   <xref target="RFC7126"/>, target="RFC7126" format="default"/>, which addresses the same problem for the IPv4 case. However, in IPv6, the problem space is compounded by the fact that IPv6 specifies a number of IPv6 EHs, EHs and a number of IPv6 options which that may be valid only when included in specific EH types.</t>
      <t>This document completes and complements the considerations for protecting the control plane from packets containing IP options that can be found in <xref target="RFC6192"/>.</t> target="RFC6192" format="default"/>.</t>
      <t><xref target="terms"/> target="terms" format="default"/> specifies the terminology and conventions employed throughout this document. <xref target="ipv6-extension-headers-discussion"/> target="ipv6-extension-headers-discussion" format="default"/> discusses IPv6 EHs and provides advice in the area of filtering IPv6 packets that contain such IPv6 EHs. <xref target="ipv6-options-discussion"/> target="ipv6-options-discussion" format="default"/> discusses IPv6 options and provides advice in the area of filtering IPv6 packets that contain such options.  <!-- <xref target="upper-layer"/> specifies the filtering of packets based on the upper-layer protocol. Specifically, it identifies upper-layer protocols that, for different reasons, should not be present in IPv6 packets. -->
      </t>

<!--
<t>While this document is similar in structure and nature to <xref target="RFC7123"/>, we note that this document is aimed at firewall administrators, an hence tends to be more restrictive than what an IPv6-version of <xref target="RFC7123"/> would be.</t>
-->

</section>
    <section title="Terminology anchor="terms" numbered="true" toc="default">
      <name>Terminology and Assumptions Employed in This Document"
    anchor="terms"> Document</name>
      <section title="Terminology"> numbered="true" toc="default">
        <name>Terminology</name>
        <t>The terms "permit" (allow the traffic), "drop" (drop with no notification to sender), and "reject" (drop with appropriate notification to sender) are employed as defined in <xref target="RFC3871"/>. target="RFC3871" format="default"/>. Throughout this document document, we also employ the term "discard" as a generic term to indicate the act of discarding a packet, irrespective of whether the sender is notified of such drops, a drop and irrespective of whether the specific filtering action is logged.
</t>

<t>The
        <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' /> target="RFC2119"/> <xref target='RFC8174' /> target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.
        </t>
      </section>
      <section title="Applicability Statement"> numbered="true" toc="default">
        <name>Applicability Statement</name>
        <t>This document provides advice on the filtering of IPv6 packets with EHs at transit routers for traffic not explicitly destined to them, for cases in which such filtering is deemed as necessary.</t>
      </section>
      <section title="Router numbered="true" toc="default">
        <name>Router Default Behavior and Features"> Features</name>
        <t>This document assumes that nodes comply with the requirements in <xref target="RFC7045"/>. target="RFC7045" format="default"/>. Namely,
<list style="hanging">
<t>"If
	</t>

 <blockquote>If a forwarding node discards a packet containing a standard IPv6
   extension header, it MUST <bcp14>MUST</bcp14> be the result of a configurable policy and
   not just the result of a failure to recognise such a header.  This
   means that the discard policy for each standard type of extension
   header MUST <bcp14>MUST</bcp14> be individually configurable.  The default configuration
   SHOULD
   <bcp14>SHOULD</bcp14> allow all standard extension headers."</t>
</list> headers.</blockquote>
        <t>

	  The advice provided in this document is only meant to guide an operator in configuring forwarding devices, devices and is not to be interpreted as advice regarding default configuration settings for network devices. That is, this document provides advice with respect to operational policies, policies but does not change the implementation defaults required by <xref target="RFC7045"/><!--  and <xref target="draft-gont-6man-ipv6-opt-transmit"/>-->. <!--We note that the advice provided in this document is *not* meant to be employed by transit routers for transit traffic, since such devices should not enforce this type of filtering policy on traffic not directed to them. --> target="RFC7045" format="default"/>.

</t>
        <t>We recommend that configuration options are be made available to govern the processing of each IPv6 EH type and each IPv6 option type. Option Type. Such configuration options should include the following possible settings:
<list style="symbols">
<t>Permit
	</t>
        <ul spacing="normal">
          <li>Permit this IPv6 EH or IPv6 Option type.</t>
<t>Drop Type.</li>
          <li>Drop packets containing this IPv6 EH or option type.</t>
<t>Reject IPv6 Option Type.</li>
          <li>Reject packets containing this IPv6 EH or option type IPv6 Option Type (where the packet drop is signaled with an ICMPv6 error message).</t>
<t>Rate-limit message).</li>
          <li>Rate-limit traffic containing this IPv6 EH or option type.</t>
<t>Ignore IPv6 Option Type.</li>
          <li>Ignore this IPv6 EH or option type IPv6 Option Type (as if it was not present) present), and process the packet according the rules for the remaining headers. We note that if a packet carries forwarding information (e.g., in an IPv6 Routing Header) Header (RH)), this might be an inappropriate or undesirable action.</t>
</list>
</t> action.</li>
        </ul>
        <t>We note that special care needs to be taken when devices log packet drops/rejects. Devices should count the number of packets dropped/rejected, but the logging of drop/reject events should be limited so as to not overburden device resources.</t>
        <t>Finally, we note that when discarding packets, it is generally desirable that the sender be signaled of the packet drop, since this is of use for trouble-shooting purposes. However, throughout this document (when recommending that packets be discarded) discarded), we generically refer to the action as "discard" without specifying whether the sender is signaled of the packet drop.</t>
      </section>
    </section>
    <section title="IPv6 anchor="ipv6-extension-headers-discussion" numbered="true" toc="default">
      <name>IPv6 Extension Headers" anchor="ipv6-extension-headers-discussion"> Headers</name>
      <section title="General Discussion"> numbered="true" toc="default">
        <name>General Discussion</name>
        <t>IPv6 <xref target="RFC8200"/> EHs <xref target="RFC8200" format="default"/> allow for the extension of the IPv6 protocol. Since both IPv6 EHs and upper-layer protocols share the same namespace ("Next Header" registry/namespace), <xref target="RFC7045"/> target="RFC7045" format="default"/> identifies which of the currently assigned Internet Protocol numbers identify IPv6 EHs vs. upper-layer protocols. This document discusses the filtering of packets based on the IPv6 EHs (as specified by <xref target="RFC7045"/>) target="RFC7045" format="default"/>) they contain. <!-- Filtering of IPv6 packets based on the upper-layer protocol is specified in <xref target="upper-layer"/>--></t>

<t>
<list style="hanging">
        </t>
	<t>
NOTE:
<xref target="RFC8200"/> target="RFC8200" format="default"/> specifies that non-fragmented IPv6 datagrams and IPv6 First-Fragments must contain the entire IPv6 header chain <xref target="RFC7112"/>. target="RFC7112" format="default"/>. Therefore, intermediate systems can enforce the filtering policies discussed in this document, document or resort to simply discarding the offending packets when they fail to comply with include the requirements in entire IPv6 header chain <xref target="RFC8200"/>. target="RFC8200" format="default"/>. </t>

<t>
We note that, that in order to implement filtering rules on the fast path, it may be necessary for the filtering device to limit the depth into the packet that can be inspected before giving up. In circumstances where such
      a limitation exists, it is recommended that implementations provide a
      configuration option that specifies whether to discard packets if
      the aforementioned limit is encountered.  Operators may then
      determine
      determine, according to their own circumstances circumstances, how such packets
      will be handled.
</t>
</list>
</t>
<!--
<t>When processing a non-fragmented IPv6 datagram or an IPv6 First-Fragment, the packet must contain the entire IPv6 header chain <xref target="RFC7112"/>. An intermediate system that processes a packet that fails to comply with this requirement should therefore drop the offending packets.
</t>
-->

</section>
      <section title="General anchor="ipv6-eh-general-implications" numbered="true" toc="default">
        <name>General Security Implications" anchor="ipv6-eh-general-implications"> Implications</name>
        <t>In some device architectures, IPv6 packets that contain IPv6 EHs can cause the corresponding packets to be processed on the slow path, and hence path and, hence, may be leveraged for the purpose of Denial of Service Denial-of-Service (DoS) attacks <xref target="RFC9098"/> target="RFC9098" format="default"/> <xref target="Cisco-EH"/> target="Cisco-EH" format="default"/> <xref target="FW-Benchmark"/>. target="FW-Benchmark" format="default"/>.
</t>
        <t>Operators are urged to consider the IPv6 EH and IPv6 options handling capabilities of their devices as they make deployment decisions in the future.</t>
      </section>
      <section title="Rationale anchor="ipv6-ehs-rationale" numbered="true" toc="default">
        <name>Rationale for Our Advice on the Handling of IPv6 Packets with Specific IPv6 Extension Headers" anchor="ipv6-ehs-rationale">
<t>
<list style="symbols">
<t>IPv6 Packets Headers</name>
        <ul spacing="normal">
          <li>IPv6 packets with IPv6 Extension Headers (or options) that are not expected to traverse transit routers should be dropped.</t>

  <t>IPv6 Packets dropped.</li>
          <li>IPv6 packets with IPv6 Extension Headers (or options) that are only
    expected to traverse transit routers when a specific technology is
    employed,
    employed should be permitted (or dropped) based on the knowledge
    regarding the use of such technology in the transit provider in question
    (i.e.
    (i.e., permit the packets if the technology is employed, or drop them)
    </t>

   <t>IPv6 Packets them).
    </li>
          <li>IPv6 packets with IPv6 Extension Headers (or options) that represent
    a concrete attack vector to network infrastructure devices should be dropped.</t>

  <t>IPv6 dropped.</li>
          <li>IPv6 packets with any other IPv6 Extension headers Headers (or options)
    should be permitted. This is an intentional  trade-off made to
    minimize ossification.</t>
</list>

</t> ossification.</li>
        </ul>
      </section>
      <section title="Summary numbered="true" toc="default">
        <name>Summary of Advice on the Handling of IPv6 Packets with Specific IPv6 Extension Headers"> Headers</name>
        <t>This section summarizes the advice provided in <xref target="advice-ehs"/>, target="advice-ehs" format="default"/>, providing references to the specific sections in which a detailed analysis can be found.</t>

    <texttable title="Summary
        <table anchor="eh-table" align="center">
          <name>Summary of Advice on the Handling of IPv6 Packets with Specific IPv6 Extension Headers" style="all" anchor="eh-table">
        <ttcol Headers</name>
          <thead>
            <tr>
              <th align="center">EH type</ttcol>
        <ttcol Type</th>
              <th align="center">Filtering policy</ttcol>
        <ttcol align="center">Reference</ttcol>
<c>IPv6 Hop-by-Hop Policy</th>
              <th align="center">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="center">Hop-by-Hop Options (Proto=0)</c><c>Drop Header (Proto=0)</td>
              <td align="center">Drop or Ignore</c><c><xref target="proto0"/></c>
<c>Routing Ignore</td>
              <td align="center">
                <xref target="proto0" format="default"/></td>
            </tr>
            <tr>
              <td align="center">Routing Header for IPv6 (Proto=43)</c><c>Drop (Proto=43)</td>
              <td align="center">Drop only RHT0 Routing Type 0, Routing Type 1, and RHT1. Routing Type 3. Permit other RH Types</c><c><xref target="proto43"/></c>
<c>Fragment Routing Types</td>
              <td align="center">
                <xref target="proto43" format="default"/></td>
            </tr>
            <tr>
              <td align="center">Fragment Header for IPv6 (Proto=44)</c><c>Permit</c><c><xref target="proto44"/></c>
<c>Encapsulating (Proto=44)</td>
              <td align="center">Permit</td>
              <td align="center">
                <xref target="proto44" format="default"/></td>
            </tr>
            <tr>
              <td align="center">Encapsulating Security Payload (Proto=50)</c><c>Permit</c><c><xref target="proto50"/></c>
<c>Authentication (Proto=50)</td>
              <td align="center">Permit</td>
              <td align="center">
                <xref target="proto50" format="default"/></td>
            </tr>
            <tr>
              <td align="center">Authentication Header (Proto=51)</c><c>Permit</c><c><xref target="proto51"/></c>
<c>Destination (Proto=51)</td>
              <td align="center">Permit</td>
              <td align="center">
                <xref target="proto51" format="default"/></td>
            </tr>
            <tr>
              <td align="center">Destination Options for IPv6 (Proto=60)</c><c>Permit</c><c><xref target="proto60"/></c>
<c>Mobility Header(Proto=60)</td>
              <td align="center">Permit</td>
              <td align="center">
                <xref target="proto60" format="default"/></td>
            </tr>
            <tr>
              <td align="center">Mobility Header (Proto=135)</c><c>Permit</c><c><xref target="proto135"/></c>
<c>Host (Proto=135)</td>
              <td align="center">Permit</td>
              <td align="center">
                <xref target="proto135" format="default"/></td>
            </tr>
            <tr>
              <td align="center">Host Identity Protocol (Proto=139)</c><c>Permit</c><c><xref target="proto139"/></c>
<c>Shim6 (Proto=139)</td>
              <td align="center">Permit</td>
              <td align="center">
                <xref target="proto139" format="default"/></td>
            </tr>
            <tr>
              <td align="center">Shim6 Protocol (Proto=140)</c><c>Permit</c><c><xref target="proto140"/></c>
<c>Use (Proto=140)</td>
              <td align="center">Permit</td>
              <td align="center">
                <xref target="proto140" format="default"/></td>
            </tr>
            <tr>
              <td align="center">Use for experimentation and testing (Proto=253 and
         254)</c><c>Drop</c><c><xref target="proto253254"/></c>
    </texttable>

</section>

<section title="Advice
         254)</td>
              <td align="center">Drop</td>
              <td align="center">
                <xref target="proto253254" format="default"/></td>
            </tr>
          </tbody>
        </table>
      </section>
      <section anchor="advice-ehs" numbered="true" toc="default">
        <name>Advice on the Handling of IPv6 Packets with Specific IPv6 Extension Headers" anchor="advice-ehs"> Headers</name>
        <section title="IPv6 anchor="proto0" numbered="true" toc="default">
          <name>IPv6 Hop-by-Hop Options (Protocol Number=0)" anchor="proto0"> Number=0)</name>
          <section title="Uses"> numbered="true" toc="default">
            <name>Uses</name>
            <t>The Hop-by-Hop (HBH) Options header is used to carry optional information that may be examined by every node along a packet's delivery path. It is expected that nodes will examine the Hop-by-Hop Options header if explicitly configured to do so.</t>
            <aside>
            <t>NOTE: A previous revision of the IPv6 core specification, specification <xref target="RFC2460"/>, target="RFC2460" format="default"/> originally required that all nodes examined to examine and processed process the Hop-by-Hop Options header. However, even before the publication of <xref target="RFC8200"/> target="RFC8200" format="default"/>, a number of implementations already provided the option of ignoring this header unless explicitly configured to examine it.
</t>
</aside>
          </section>
          <section title="Specification"> numbered="true" toc="default">
            <name>Specification</name>
            <t>This EH is specified in <xref target="RFC8200"/>. target="RFC8200" format="default"/>. As of May 2022, the following options have been specified for the Hop-by-Hop Options EH: header:
</t>
<t>
<list style="symbols">
<t>Type
<ul spacing="normal">
              <li>Type 0x00: Pad1 <xref target="RFC8200"/></t>
<t>Type target="RFC8200" format="default"/></li>
              <li>Type 0x01: PadN <xref target="RFC8200"/></t>
<t>Type target="RFC8200" format="default"/></li>
              <li>Type 0x05: Router Alert <xref target="RFC2711"/></t>
<t>Type target="RFC2711" format="default"/></li>
              <li>Type 0x07: CALIPSO <xref target="RFC5570"/></t>
<t>Type target="RFC5570" format="default"/></li>
              <li>Type 0x08: SMF_DPD <xref target="RFC6621"/></t>
<t>Type target="RFC6621" format="default"/></li>
              <li>Type 0x23: RPL Option <xref target="RFC9008"/></t>
<t>Type target="RFC9008" format="default"/></li>
              <li>Type 0x26: Quick-Start <xref target="RFC4782"/></t>
<t>Type target="RFC4782" format="default"/></li>
              <li>Type 0x4D: (Deprecated)</t>
<t>Type (Deprecated)</li>
              <li>Type 0x63: RPL Option <xref target="RFC6553"/></t>
<t>Type target="RFC6553" format="default"/></li>
              <li>Type 0x6D: MPL Option <xref target="RFC7731"/></t>
<!-- [fgont] THis one is deprecated... I guess no need to mention it, right? -->
<t>Type target="RFC7731" format="default"/></li>
	      <li>Type 0x8A: Endpoint Identification (Deprecated) <xref target="draft-ietf-nimrod-eid"/></t>
<t>Type target="NIMROD-EID" format="default"/></li>
              <li>Type 0xC2: Jumbo Payload <xref target="RFC2675"/></t>
<t>Type target="RFC2675" format="default"/></li>
              <li>Type 0xEE: IPv6 DFF Header <xref target="RFC6971"/></t>

<t>Type target="RFC6971" format="default"/></li>
              <li>Type 0x1E: RFC3692-style Experiment <xref target="RFC4727"/></t>
<t>Type target="RFC4727" format="default"/></li>
              <li>Type 0x3E: RFC3692-style Experiment <xref target="RFC4727"/></t>
<t>Type target="RFC4727" format="default"/></li>
              <li>Type 0x5E: RFC3692-style Experiment <xref target="RFC4727"/></t>
<t>Type target="RFC4727" format="default"/></li>
              <li>Type 0x7E: RFC3692-style Experiment <xref target="RFC4727"/></t>
<t>Type target="RFC4727" format="default"/></li>
              <li>Type 0x9E: RFC3692-style Experiment <xref target="RFC4727"/></t>
<t>Type target="RFC4727" format="default"/></li>
              <li>Type 0xBE: RFC3692-style Experiment <xref target="RFC4727"/></t>
<t>Type target="RFC4727" format="default"/></li>
              <li>Type 0xDE: RFC3692-style Experiment <xref target="RFC4727"/></t>
<t>Type target="RFC4727" format="default"/></li>
              <li>Type 0xFE: RFC3692-style Experiment <xref target="RFC4727"/></t>
</list></t> target="RFC4727" format="default"/></li>
            </ul>
          </section>
          <section title="Specific numbered="true" toc="default">
            <name>Specific Security Implications"> Implications</name>
            <t>Legacy nodes that process this extension header might be subject to Denial of Service DoS attacks.</t>
            <aside>
            <t>NOTE: While <xref target="RFC8200"/> target="RFC8200" format="default"/> has removed this requirement, the requirement for all nodes to examine and process the Hop-by-Hop Options header, the deployed base may still reflect the classical legacy <xref target="RFC2460"/> behavior for a while, and hence while; hence, the potential security problems of this EH are still of concern.
</t>
</aside>
          </section>
          <section title="Operational numbered="true" toc="default">
            <name>Operational and Interoperability Impact if Blocked"> If Blocked</name>
            <t>Discarding packets containing a Hop-by-Hop Options EH header would break any of the protocols that rely on it for proper functioning. For example, it would break RSVP <xref target="RFC2205"/> target="RFC2205" format="default"/> and multicast deployments, deployments and would cause IPv6 jumbograms to be discarded.</t>
          </section>
          <section title="Advice"> numbered="true" toc="default">
            <name>Advice</name>
            <t>Nodes implementing <xref target="RFC8200"/> target="RFC8200" format="default"/> would already ignore this extension header unless explicitly required to process it. For legacy (<xref target="RFC2460"/>) nodes, nodes <xref target="RFC2460" format="default"/>, the recommended configuration for the processing of these packets depends on the features and capabilities of the underlying platform, the configuration of the platform, and also the deployment environment of the platform. On platforms that allow the forwarding of packets with IPv6 HBH Options headers on the fast path, we recommend that packets with a IPv6 HBH Options EH headers be forwarded as normal. Otherwise, on platforms in which the processing of packets with a IPv6 HBH Options EH headers is carried out in the slow path, path and an option is provided to rate-limit these packets, we recommend that this option be selected. Finally, when packets containing a IPv6 HBH Options EH headers are processed in the slow-path, slow path and the underlying platform does not have any mitigation options available for attacks based on these packets, we recommend that such platforms discard packets containing IPv6 HBH Options EHs.</t> headers.</t>
            <t>Finally, we note that RPL (Routing the Routing Protocol for Low-Power and Lossy Networks) Networks (RPL) routers <xref target="RFC6550"/> target="RFC6550" format="default"/>  must not discard packets based on the presence of an IPv6 Hop-by-Hop Options EH, header, as this would break the RPL.</t>
          </section>
        </section>
        <section title="Routing anchor="proto43" numbered="true" toc="default">
          <name>Routing Header for IPv6 (Protocol Number=43)" anchor="proto43"> Number=43)</name>
          <section title="Uses"> numbered="true" toc="default">
            <name>Uses</name>
            <t>The Routing header Header is used by an IPv6 source to list one or more intermediate nodes to be "visited" on the way to a packet's destination. </t>
          </section>
          <section title="Specification"> numbered="true" toc="default">
            <name>Specification</name>
            <t>This EH is specified in <xref target="RFC8200"/>. <xref target="RFC2460"/> target="RFC8200" format="default"/>. The Routing Type 0 had originally been specified the Routing Header Type 0, which in <xref target="RFC2460" format="default"/> and was later obsoleted by <xref target="RFC5095"/>, and thus target="RFC5095" format="default"/>; thus, it was removed from <xref target="RFC8200"/>.</t>

<t>At target="RFC8200" format="default"/>.</t>
            <t>As of May 2022, the following Routing Types have been specified:

<list style="symbols">
<t>Type specified:</t>
	    <ul spacing="normal">
              <li>Type 0: Source Route (DEPRECATED) <xref target="RFC2460"/> target="RFC2460" format="default"/> <xref target="RFC5095"/></t>
<t>Type target="RFC5095" format="default"/></li>
              <li>Type 1: Nimrod (DEPRECATED)</t>
<t>Type (DEPRECATED)</li>
              <li>Type 2: Type 2 Routing Header <xref target="RFC6275"/></t>
<t>Type target="RFC6275" format="default"/></li>
              <li>Type 3: RPL Source Route Header <xref target="RFC6554"/></t>
<t>Type target="RFC6554" format="default"/></li>
              <li>Type 4: Segment Routing Header (SRH) <xref target="RFC8754"/></t>
<t>Types target="RFC8754" format="default"/></li>
              <li>Types 5-252: Unassigned </t>
<t>Type Unassigned</li>
              <li>Type 253: RFC3692-style Experiment 1 <xref target="RFC4727"/></t>
<t>Type target="RFC4727" format="default"/></li>
              <li>Type 254: RFC3692-style Experiment 2 <xref target="RFC4727"/></t>
<t>Type target="RFC4727" format="default"/></li>
              <li>Type 255: Reserved</t>
</list>
</t> Reserved</li>
            </ul>
          </section>
          <section title="Specific numbered="true" toc="default">
            <name>Specific Security Implications"> Implications</name>
            <t>The security implications of RHT0 Routing Headers of Routing Type 0 have been discussed in detail in <xref target="Biondi2007"/> target="Biondi-2007" format="default"/> and <xref target="RFC5095"/>. RHT1 target="RFC5095" format="default"/>. Routing Type 1 was never widely implemented. The security implications of RHT2, RHT3, Routing Headers of Routing Type 2, Routing Type 3, and RHT4 Routing Type 4 (SRH) are discussed in <xref target="RFC6275"/>, target="RFC6275" format="default"/>,  <xref target="RFC6554"/>, target="RFC6554" format="default"/>, and <xref target="RFC8754"/>, target="RFC8754" format="default"/>, respectively.</t>
          </section>
          <section title="Operational numbered="true" toc="default">
            <name>Operational and Interoperability Impact if Blocked"> If Blocked</name>

            <t>Blocking packets containing a RHT0 Routing Headers of Routing Type 0 or RHT1 Routing Type 1 has no operational implications, since both have been deprecated. Blocking packets with a RHT2 containing Routing Headers of Routing Type 2 would break Mobile IPv6. Packets with a RHT3 containing Routing Headers of Routing Type 3 may be safely blocked at RPL domain boundaries, since RHT3 such headers are employed within a single RPL domain. Blocking packets with a RHT4 containing Routing Headers of Routing Type 4 (SRH) will break Segment Routing (SR) deployments, deployments if the filtering policy is enforced on packets being forwarded within an SR domain.</t>

<!--<t>However, blocking packets employing other routing header types will break the protocols that rely on them.</t> -->
            </section>
          <section title="Advice"> numbered="true" toc="default">
            <name>Advice</name>

            <t>Intermediate systems should discard packets containing a RHT0, RHT1, Routing Headers of Routing Type 0, Routing Type 1, or RHT3. Routing Type 3. Other routing header types Routing Types should be permitted, as required by <xref target="RFC7045"/>.</t> target="RFC7045" format="default"/>.</t>
          </section>
        </section>
        <section title="Fragment anchor="proto44" numbered="true" toc="default">
          <name>Fragment Header for IPv6 (Protocol Number=44)" anchor="proto44"> Number=44)</name>
          <section title="Uses"> numbered="true" toc="default">
            <name>Uses</name>
            <t>This EH provides the fragmentation and reassembly functionality for IPv6.</t>
          </section>
          <section title="Specification"> numbered="true" toc="default">
            <name>Specification</name>
            <t>This EH is specified in <xref target="RFC8200"/>.</t> target="RFC8200" format="default"/>.</t>
          </section>
          <section title="Specific numbered="true" toc="default">
            <name>Specific Security Implications"> Implications</name>
            <t>The security implications of the Fragment Header range from Denial of Service DoS attacks (e.g. (e.g., based on flooding a target with IPv6 fragments) to information leakage attacks <xref target="RFC7739"/>.</t> target="RFC7739" format="default"/>.</t>
          </section>
          <section title="Operational numbered="true" toc="default">
            <name>Operational and Interoperability Impact if Blocked"> If Blocked</name>
            <t>Blocking packets that contain a Fragment Header will break any protocol that may rely on fragmentation (e.g., the DNS <xref target="RFC1034"/>). target="RFC1034" format="default"/>). However, IP fragmentation is known to introduce fragility to Internet communication <xref target="RFC8900"/>.</t> target="RFC8900" format="default"/>.</t>
          </section>
          <section title="Advice"> numbered="true" toc="default">
            <name>Advice</name>
            <t>Intermediate systems should permit packets that contain a Fragment Header.</t>
          </section>
        </section>
        <section title="Encapsulating anchor="proto50" numbered="true" toc="default">
          <name>Encapsulating Security Payload (Protocol Number=50)" anchor="proto50"> Number=50)</name>
          <section title="Uses"> numbered="true" toc="default">
            <name>Uses</name>
            <t>This EH is employed for the IPsec suite <xref target="RFC4303"/>.</t> target="RFC4303" format="default"/>.</t>
          </section>
          <section title="Specification"> numbered="true" toc="default">
            <name>Specification</name>
            <t>This EH is specified in <xref target="RFC4303"/>.</t> target="RFC4303" format="default"/>.</t>
          </section>
          <section title="Specific numbered="true" toc="default">
            <name>Specific Security Implications"> Implications</name>
            <t>Besides the general implications of IPv6 EHs, this EH could be employed to potentially perform a DoS attack at the destination system by wasting CPU resources in validating the contents of the packet.</t>
          </section>
          <section title="Operational numbered="true" toc="default">
            <name>Operational and Interoperability Impact if Blocked"> If Blocked</name>
            <t>Discarding packets that employ this EH would break IPsec deployments.</t>
          </section>
          <section title="Advice"> numbered="true" toc="default">
            <name>Advice</name>
            <t>Intermediate systems should permit packets containing the Encapsulating Security Payload EH.</t>
          </section>
        </section>
        <section title="Authentication anchor="proto51" numbered="true" toc="default">
          <name>Authentication Header (Protocol Number=51)" anchor="proto51"> Number=51)</name>
          <section title="Uses"> numbered="true" toc="default">
            <name>Uses</name>
            <t>The Authentication Header can be employed for to provide authentication services in
   IPv4 and IPv6.</t>
          </section>
          <section title="Specification"> numbered="true" toc="default">
            <name>Specification</name>
            <t>This EH is specified in <xref target="RFC4302"/>.</t> target="RFC4302" format="default"/>.</t>
          </section>
          <section title="Specific numbered="true" toc="default">
            <name>Specific Security Implications"> Implications</name>
            <t>Besides the general implications of IPv6 EHs, this EH could be employed to potentially perform a DoS attack at the destination system by wasting CPU resources in validating the contents of the packet.</t>
          </section>
          <section title="Operational numbered="true" toc="default">
            <name>Operational and Interoperability Impact if Blocked"> If Blocked</name>
            <t>Discarding packets that employ this EH would break IPsec deployments.</t>
          </section>
          <section title="Advice"> numbered="true" toc="default">
            <name>Advice</name>
            <t>Intermediate systems should permit packets containing an Authentication Header.</t>
          </section>
        </section>
        <section title="Destination anchor="proto60" numbered="true" toc="default">
          <name>Destination Options for IPv6 (Protocol Number=60)" anchor="proto60"> Number=60)</name>
          <section title="Uses"> numbered="true" toc="default">
            <name>Uses</name>
            <t>The Destination Options (DO) header is used to carry optional information that needs be examined only by a packet's destination node(s).</t>
          </section>
          <section title="Specification"> numbered="true" toc="default">
            <name>Specification</name>
            <t>This EH is specified in <xref target="RFC8200"/>. target="RFC8200" format="default"/>. As of May 2022, the following options have been specified for this EH:

<list style="symbols">
<t>Type
</t>
<ul spacing="normal">
              <li>Type 0x00: Pad1 <xref target="RFC8200"/></t>
<t>Type target="RFC8200" format="default"/></li>
              <li>Type 0x01: PadN <xref target="RFC8200"/></t>
<t>Type target="RFC8200" format="default"/></li>
              <li>Type 0x04: Tunnel Encapsulation Limit <xref target="RFC2473"/></t>
<t>Type target="RFC2473" format="default"/></li>
              <li>Type 0x0F: IPv6 Performance and Diagnostic Metrics (PDM) <xref target="RFC8250"/></t>
<t>Type target="RFC8250" format="default"/></li>
              <li>Type 0x4D: (Deprecated)</t>

<t>Type (Deprecated)</li>
              <li>Type 0xC9: Home Address <xref target="RFC6275"/></t>
<t>Type target="RFC6275" format="default"/></li>
              <li>Type 0x8A: Endpoint Identification (Deprecated) <xref target="draft-ietf-nimrod-eid"/></t>

<t>Type target="NIMROD-EID" format="default"/></li>
              <li>Type 0x8B: ILNP Nonce <xref target="RFC6744"/></t>
<t>Type target="RFC6744" format="default"/></li>
              <li>Type 0x8C: Line-Identification Option <xref target="RFC6788"/></t>
<t>Type target="RFC6788" format="default"/></li>
              <li>Type 0x1E: RFC3692-style Experiment <xref target="RFC4727"/></t>
<t>Type target="RFC4727" format="default"/></li>
              <li>Type 0x3E: RFC3692-style Experiment <xref target="RFC4727"/></t>
<t>Type target="RFC4727" format="default"/></li>
              <li>Type 0x5E: RFC3692-style Experiment <xref target="RFC4727"/></t>
<t>Type target="RFC4727" format="default"/></li>
              <li>Type 0x7E: RFC3692-style Experiment <xref target="RFC4727"/></t>
<t>Type target="RFC4727" format="default"/></li>
              <li>Type 0x9E: RFC3692-style Experiment <xref target="RFC4727"/></t>
<t>Type target="RFC4727" format="default"/></li>
              <li>Type 0xBE: RFC3692-style Experiment <xref target="RFC4727"/></t>
<t>Type target="RFC4727" format="default"/></li>
              <li>Type 0xDE: RFC3692-style Experiment <xref target="RFC4727"/></t>
<t>Type target="RFC4727" format="default"/></li>
              <li>Type 0xFE: RFC3692-style Experiment <xref target="RFC4727"/></t>
</list>
</t> target="RFC4727" format="default"/></li>
            </ul>
          </section>
          <section title="Specific numbered="true" toc="default">
            <name>Specific Security Implications"> Implications</name>
            <t>No security implications are known, other than the general security implications of IPv6 EHs. For a discussion of possible security implications of specific options specified for the DO header, please see the <xref target="opt-filtering"/>.</t> target="opt-filtering" format="default"/>.</t>
          </section>
          <section title="Operational numbered="true" toc="default">
            <name>Operational and Interoperability Impact if Blocked"> If Blocked</name>
            <t>Discarding packets that contain a Destination Options header would break protocols that rely on this EH type for conveying information, including protocols such information (such as ILNP the Identifier-Locator Network Protocol (ILNP) <xref target="RFC6740"/> target="RFC6740" format="default"/> and Mobile IPv6 <xref target="RFC6275"/>, and target="RFC6275" format="default"/>), as well as IPv6 tunnels that employ the Tunnel Encapsulation Limit option.</t> option <xref target="RFC2473"/>.</t>
          </section>
          <section title="Advice"> numbered="true" toc="default">
            <name>Advice</name>
            <t>Intermediate systems should permit packets that contain a Destination Options Header.</t> header.</t>
          </section>
        </section>
        <section title="Mobility anchor="proto135" numbered="true" toc="default">
          <name>Mobility Header (Protocol Number=135)" anchor="proto135"> Number=135)</name>
          <section title="Uses"> numbered="true" toc="default">
            <name>Uses</name>
            <t>The Mobility Header is an EH used by mobile nodes, correspondent nodes, and home agents in all messaging related to the creation and management of bindings in Mobile IPv6.</t>
          </section>
          <section title="Specification"> numbered="true" toc="default">
            <name>Specification</name>
            <t>This EH is specified in <xref target="RFC6275"/>.</t> target="RFC6275" format="default"/>.</t>
          </section>
          <section title="Specific numbered="true" toc="default">
            <name>Specific Security Implications"> Implications</name>
            <t>A thorough security assessment of the security implications of the Mobility Header and related mechanisms can be found in Section 15 of <xref target="RFC6275"/>.</t> target="RFC6275" sectionFormat="of" section="15"/>.</t>
          </section>
          <section title="Operational numbered="true" toc="default">
            <name>Operational and Interoperability Impact if Blocked"> If Blocked</name>
            <t>Discarding packets containing this EH would break Mobile IPv6.</t>
          </section>
          <section title="Advice"> numbered="true" toc="default">
            <name>Advice</name>
            <t>Intermediate systems should permit packets containing this EH.</t> that contain a Mobility Header.</t>
          </section>
        </section>
        <section title="Host anchor="proto139" numbered="true" toc="default">
          <name>Host Identity Protocol (Protocol Number=139)" anchor="proto139"> Number=139)</name>
          <section title="Uses"> numbered="true" toc="default">
            <name>Uses</name>
            <t>This EH is employed with the Host Identity Protocol (HIP), which is a protocol that allows consenting hosts to securely establish and maintain shared IP-layer state, allowing the separation of the identifier and locator roles of IP addresses, thereby enabling continuity of communications across IP address changes.</t>
          </section>
          <section title="Specification"> numbered="true" toc="default">
            <name>Specification</name>
            <t>This EH is specified in <xref target="RFC7401"/>.</t> target="RFC7401" format="default"/>.</t>
          </section>
          <section title="Specific numbered="true" toc="default">
            <name>Specific Security Implications"> Implications</name>
            <t>The security implications of the HIP header are discussed in detail in Section 8 of <xref target="RFC6275"/>.</t> target="RFC7401" sectionFormat="of" section="8"/>.</t>
          </section>
          <section title="Operational numbered="true" toc="default">
            <name>Operational and Interoperability Impact if Blocked"> If Blocked</name>
            <t>Discarding packets that contain the Host Identity Protocol a HIP header would break HIP deployments.</t>
          </section>
          <section title="Advice"> numbered="true" toc="default">
            <name>Advice</name>
            <t>Intermediate systems should permit packets that contain a Host Identity Protocol EH.</t> HIP header.</t>
          </section>
        </section>
        <section title="Shim6 anchor="proto140" numbered="true" toc="default">
          <name>Shim6 Protocol (Protocol Number=140)" anchor="proto140"> Number=140)</name>
          <section title="Uses"> numbered="true" toc="default">
            <name>Uses</name>
            <t>This EH is employed by the Shim6 protocol <xref target="RFC5533"/> Protocol.</t> target="RFC5533" format="default"/>.</t>
          </section>
          <section title="Specification"> numbered="true" toc="default">
            <name>Specification</name>
            <t>This EH is specified in <xref target="RFC5533"/>.</t> target="RFC5533" format="default"/>.</t>
          </section>
          <section title="Specific numbered="true" toc="default">
            <name>Specific Security Implications"> Implications</name>
            <t>The specific security implications are discussed in detail in Section 16 of <xref target="RFC5533"/>.</t> target="RFC5533" sectionFormat="of" section="16"/>.</t>
          </section>
          <section title="Operational numbered="true" toc="default">
            <name>Operational and Interoperability Impact if Blocked"> If Blocked</name>
            <t>Discarding packets that contain this EH will break Shim6.</t>
          </section>
          <section title="Advice"> numbered="true" toc="default">
            <name>Advice</name>
            <t>Intermediate systems should permit packets containing this EH.</t>
          </section>
        </section>
        <section title="Use anchor="proto253254" numbered="true" toc="default">
          <name>Use for experimentation Experimentation and testing Testing (Protocol Numbers=253 and 254)" anchor="proto253254"> 254)</name>
          <section title="Uses"> numbered="true" toc="default">
            <name>Uses</name>
            <t>These IPv6 EHs are employed for performing RFC3692-Style RFC3692-style experiments (see <xref target="RFC3692"/> target="RFC3692" format="default"/> for details).</t>
          </section>
          <section title="Specification"> numbered="true" toc="default">
            <name>Specification</name>
            <t>These EHs are specified in <xref target="RFC3692"/> target="RFC3692" format="default"/> and <xref target="RFC4727"/>.</t> target="RFC4727" format="default"/>.</t>
          </section>
          <section title="Specific numbered="true" toc="default">
            <name>Specific Security Implications"> Implications</name>
            <t>The security implications of these EHs will depend on their specific use.</t>
          </section>
          <section title="Operational numbered="true" toc="default">
            <name>Operational and Interoperability Impact if Blocked"> If Blocked</name>
            <t>For obvious reasons, discarding packets that contain these EHs limits the ability to perform legitimate experiments across IPv6 routers.
</t>
          </section>
          <section title="Advice"> numbered="true" toc="default">
            <name>Advice</name>
            <t>Operators should determine determine, according to their own circumstances circumstances, whether to discard packets containing these EHs.</t>
<!--
<t>Intermediate systems should discard packets containing these EHs. Only in specific scenarios in which RFC3692-Style experiments are to be performed should these EHs be permitted.</t> -->

</section>
        </section>
      </section>
      <section title="Advice anchor="unknown-headers" numbered="true" toc="default">
        <name>Advice on the Handling of Packets with Unknown IPv6 Extension Headers" anchor="unknown-headers"> Headers</name>
        <t>We refer to IPv6 EHs that have not been assigned an Internet Protocol Number number by IANA (and marked as such) in <xref target="IANA-PROTOCOLS"/> target="IANA-PROTOCOLS" format="default"/> as "unknown IPv6 extension headers" Extension Headers" ("unknown IPv6 EHs").
</t>
        <section title="Uses"> numbered="true" toc="default">
          <name>Uses</name>
          <t>New IPv6 EHs may be specified as part of future extensions to the IPv6 protocol.
</t>
          <t>Since IPv6 EHs and Upper-layer upper-layer protocols employ the same namespace, it is impossible to tell whether an unknown "Internet Internet Protocol Number" number is being employed for an IPv6 EH or an Upper-Layer upper-layer protocol.
</t>
        </section>
        <section title="Specification"> numbered="true" toc="default">
          <name>Specification</name>
          <t>The processing of unknown IPv6 EHs is specified in <xref target="RFC7045"/>.</t> target="RFC7045" format="default"/>.</t>
        </section>
        <section title="Specific numbered="true" toc="default">
          <name>Specific Security Implications"> Implications</name>
          <t>For obvious reasons, it is impossible to determine specific security implications of unknown IPv6 EHs.</t>
        </section>
        <section title="Operational numbered="true" toc="default">
          <name>Operational and Interoperability Impact if Blocked"> If Blocked</name>
          <t>As noted in <xref target="RFC7045"/>, target="RFC7045" format="default"/>, discarding unknown IPv6 EHs may slow down the deployment of new IPv6 EHs and transport protocols. The corresponding IANA registry (<xref target="IANA-PROTOCOLS"/>) registry, which is <xref target="IANA-PROTOCOLS" format="default"/>, should be monitored such that filtering rules are updated as new IPv6 EHs are standardized.</t>
          <t>We note that since IPv6 EHs and upper-layer protocols share the same numbering space, discarding unknown IPv6 EHs may result in packets encapsulating unknown upper-layer protocols being discarded.
</t>
        </section>
        <section title="Advice"> numbered="true" toc="default">
          <name>Advice</name>
          <t>Operators should determine determine, according to their own circumstances circumstances, whether to discard packets containing unknown IPv6 EHs.</t>
        </section>
      </section>
    </section>
    <section title="IPv6 Options" anchor="ipv6-options-discussion">
<section title="General Discussion" anchor="ipv6-options-general-discussion"> anchor="ipv6-options-discussion" numbered="true" toc="default">
      <name>IPv6 Options</name>
      <section anchor="ipv6-options-general-discussion" numbered="true" toc="default">
        <name>General Discussion</name>
        <t>The following subsections describe specific security implications of different IPv6 options, options and provide advice regarding filtering packets that contain such options.
</t>
      </section>
      <section title="General anchor="ipv6-options-general-implications" numbered="true" toc="default">
        <name>General Security Implications of IPv6 Options" anchor="ipv6-options-general-implications"> Options</name>
        <t>The general security implications of IPv6 options are closely related to those discussed in <xref target="ipv6-eh-general-implications"/> target="ipv6-eh-general-implications" format="default"/> for IPv6 EHs. Essentially, packets that contain IPv6 options might need to be processed by an IPv6 router's general-purpose CPU,and hence CPU and, hence, could present a DDoS Distributed Denial-of-Service (DDoS) risk to that router's general-purpose CPU (and thus to the router itself). For some architectures, a possible mitigation would be to rate-limit the packets that are to be processed by the general-purpose CPU (see e.g. (see, e.g., <xref target="Cisco-EH"/>).</t> target="Cisco-EH" format="default"/>).</t>
      </section>
      <section title="Summary numbered="true" toc="default">
        <name>Summary of Advice on the Handling of IPv6 Packets with Specific IPv6 Extension Headers"> Options</name>
        <t>This section summarizes the advice provided in <xref target="advice-ehs"/>, providing target="opt-filtering" format="default"/>, and it includes references to the specific sections in which a detailed analysis can be found.</t>

    <texttable title="Summary
        <table anchor="option-table" align="center">
          <name>Summary of Advice on the Handling of IPv6 Packets with Specific IPv6 options" style="all" anchor="option-table">
        <ttcol align="center">Option</ttcol>
        <ttcol Options</name>
          <thead>
            <tr>
              <th align="center">Option</th>
              <th align="center">Filtering policy</ttcol>
        <ttcol align="center">Reference</ttcol>
<c>Pad1 (Type=0x00)</c><c>Permit</c><c><xref target="x00"/></c>
<c>PadN (Type=0x01)</c><c>Permit</c><c><xref target="x01"/></c>
<c>Tunnel Policy</th>
              <th align="center">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="center">Pad1 (Type=0x00)</td>
              <td align="center">Permit</td>
              <td align="center">
                <xref target="x00" format="default"/></td>
            </tr>
            <tr>
              <td align="center">PadN (Type=0x01)</td>
              <td align="center">Permit</td>
              <td align="center">
                <xref target="x01" format="default"/></td>
            </tr>
            <tr>
              <td align="center">Tunnel Encapsulation Limit (Type=0x04)</c><c>Permit</c><c><xref target="x04"/></c>
<c>Router (Type=0x04)</td>
              <td align="center">Permit</td>
              <td align="center">
                <xref target="x04" format="default"/></td>
            </tr>
            <tr>
              <td align="center">Router Alert (Type=0x05)</c><c>Permit (Type=0x05)</td>
              <td align="center">Permit based on needed functionality</c><c><xref target="x05"/></c>
<c>CALIPSO (Type=0x07)</c><c>Permit functionality</td>
              <td align="center">
                <xref target="x05" format="default"/></td>
            </tr>
            <tr>
              <td align="center">CALIPSO (Type=0x07)</td>
              <td align="center">Permit based on needed functionality</c><c><xref target="x07"/></c>
<c>SMF_DPD (Type=0x08)</c><c>Permit functionality</td>
              <td align="center">
                <xref target="x07" format="default"/></td>
            </tr>
            <tr>
              <td align="center">SMF_DPD (Type=0x08)</td>
              <td align="center">Permit based on needed functionality</c><c><xref target="x08"/></c>
<c>PDM functionality</td>
              <td align="center">
                <xref target="x08" format="default"/></td>
            </tr>
            <tr>
              <td align="center">PDM Option (Type=0x0F)</c><c>Permit</c><c><xref target="x0F"/></c>
<c>RPL (Type=0x0F)</td>
              <td align="center">Permit</td>
              <td align="center">
                <xref target="x0F" format="default"/></td>
            </tr>
            <tr>
              <td align="center">RPL Option (Type=0x23)</c><c>Permit</c><c><xref target="x23"/></c>
<c>Quick-Start (Type=0x26)</c><c>Permit</c><c><xref target="x26"/></c>
<c>Deprecated (Type=0x4D)</c><c>Drop</c><c><xref target="x4D"/></c>
<c>MPL (Type=0x23)</td>
              <td align="center">Permit</td>
              <td align="center">
                <xref target="x23" format="default"/></td>
            </tr>
            <tr>
              <td align="center">Quick-Start (Type=0x26)</td>
              <td align="center">Permit</td>
              <td align="center">
                <xref target="x26" format="default"/></td>
            </tr>
            <tr>
              <td align="center">Deprecated (Type=0x4D)</td>
              <td align="center">Drop</td>
              <td align="center">
                <xref target="x4D" format="default"/></td>
            </tr>
            <tr>
              <td align="center">MPL Option (Type=0x6D)</c><c>Permit</c><c><xref target="x6D"/></c>
<c>Jumbo (Type=0x6D)</td>
              <td align="center">Permit</td>
              <td align="center">
                <xref target="x6D" format="default"/></td>
            </tr>
            <tr>
              <td align="center">Jumbo Payload (Type=0C2)</c><c>Permit (Type=0xC2)</td>
              <td align="center">Permit based on needed functionality</c><c><xref target="xC2"/></c>
<c>RPL functionality</td>
              <td align="center">
                <xref target="xC2" format="default"/></td>
            </tr>
            <tr>
              <td align="center">RPL Option (Type=0x63)</c><c>Drop in non-RPL routers</c><c><xref target="x63"/></c>
<c>Endpoint (Type=0x63)</td>
              <td align="center">Drop</td>
              <td align="center">
                <xref target="x63" format="default"/></td>
            </tr>
            <tr>
              <td align="center">Endpoint Identification (Type=0x8A)</c><c>Drop</c><c><xref target="x8A"/></c>
<c>ILNP (Type=0x8A)</td>
              <td align="center">Drop</td>
              <td align="center">
                <xref target="x8A" format="default"/></td>
            </tr>
            <tr>
              <td align="center">ILNP Nonce (Type=0x8B)</c><c>Permit</c><c><xref target="x8B"/></c>
<c>Line-Identification (Type=0x8B)</td>
              <td align="center">Permit</td>
              <td align="center">
                <xref target="x8B" format="default"/></td>
            </tr>
            <tr>
              <td align="center">Line-Identification Option (Type=0x8C)</c><c>Drop</c><c><xref target="x8C"/></c>
<c>Home (Type=0x8C)</td>
              <td align="center">Drop</td>
              <td align="center">
                <xref target="x8C" format="default"/></td>
            </tr>
            <tr>
              <td align="center">Home Address (Type=0xC9)</c><c>Permit</c><c><xref target="xC9"/></c>
<c>IP_DFF (Type=0xEE)</c><c>Permit (Type=0xC9)</td>
              <td align="center">Permit</td>
              <td align="center">
                <xref target="xC9" format="default"/></td>
            </tr>
            <tr>
              <td align="center">IP_DFF (Type=0xEE)</td>
              <td align="center">Permit based on needed functionality</c><c><xref target="xEE"/></c>
<c>RFC3692-style functionality</td>
              <td align="center">
                <xref target="xEE" format="default"/></td>
            </tr>
            <tr>
              <td align="center">RFC3692-style Experiment (Types = 0x1E, 0x3E, 0x5E, 0x7E, 0x9E, 0xBE, 0xDE, 0xFE)</c><c>Permit 0xFE)</td>
              <td align="center">Permit based on needed functionality</c><c><xref target="x1E"/></c>

    </texttable> functionality</td>
              <td align="center">
                <xref target="x1E" format="default"/></td>
            </tr>
          </tbody>
        </table>
      </section>
      <section title="Advice anchor="opt-filtering" numbered="true" toc="default">
        <name>Advice on the Handling of Packets with Specific IPv6 Options" anchor="opt-filtering"> Options</name>
        <t>The following subsections contain a description of each of the IPv6 options that have so far been specified, a summary of the security implications of each of such options, a discussion of possible
    interoperability implications if packets containing such options are
    discarded, and specific advice regarding whether packets containing these options should be permitted.</t>
        <section title="Pad1 (Type=0x00)"  anchor="x00">
<section title="Uses"> anchor="x00" numbered="true" toc="default">
          <name>Pad1 (Type=0x00)</name>
          <section numbered="true" toc="default">
            <name>Uses</name>
            <t>This option is used when necessary to align subsequent options and to pad out the containing header to a multiple of 8 octets in length.</t>
          </section>
          <section title="Specification"> numbered="true" toc="default">
            <name>Specification</name>
            <t>This option is specified in <xref target="RFC8200"/>.</t> target="RFC8200" format="default"/>.</t>
          </section>
          <section title="Specific numbered="true" toc="default">
            <name>Specific Security Implications"> Implications</name>
            <t>None.</t>
          </section>
          <section title="Operational numbered="true" toc="default">
            <name>Operational and Interoperability Impact if Blocked"> If Blocked</name>
            <t>Discarding packets that contain this option would potentially break any protocol that relies on IPv6 options.</t>
          </section>
          <section title="Advice"> numbered="true" toc="default">
            <name>Advice</name>
            <t>Intermediate systems should not discard packets based on the presence of this option.</t>
          </section>
        </section>
        <section title="PadN (Type=0x01)" anchor="x01">
<section title="Uses"> anchor="x01" numbered="true" toc="default">
          <name>PadN (Type=0x01)</name>
          <section numbered="true" toc="default">
            <name>Uses</name>
            <t>This option is used when necessary to align subsequent options and to pad out the containing header to a multiple of 8 octets in length.</t>
          </section>
          <section title="Specification"> numbered="true" toc="default">
            <name>Specification</name>
            <t>This option is specified in <xref target="RFC8200"/>.</t> target="RFC8200" format="default"/>.</t>
          </section>
          <section title="Specific numbered="true" toc="default">
            <name>Specific Security Implications"> Implications</name>
            <t>Because of the possible size of this option, it could be leveraged as a large-bandwidth covert channel.</t>
          </section>
          <section title="Operational numbered="true" toc="default">
            <name>Operational and Interoperability Impact if Blocked"> If Blocked</name>
            <t>Discarding packets that contain this option would potentially break any protocol that relies on IPv6 options.</t>
          </section>
          <section title="Advice"> numbered="true" toc="default">
            <name>Advice</name>
            <t>Intermediate systems should not discard IPv6 packets based on the presence of this option.</t>
          </section>
        </section>
        <section title="Tunnel anchor="x04" numbered="true" toc="default">
          <name>Tunnel Encapsulation Limit (Type=0x04)"  anchor="x04"> (Type=0x04)</name>
          <section title="Uses"> numbered="true" toc="default">
            <name>Uses</name>
            <t>The Tunnel Encapsulation Limit option can be employed to specify how many further levels of nesting the packet is permitted to undergo.</t>
          </section>
          <section title="Specification"> numbered="true" toc="default">
            <name>Specification</name>
            <t>This option is specified in <xref target="RFC2473"/>.</t> target="RFC2473" format="default"/>.</t>
          </section>
          <section title="Specific numbered="true" toc="default">
            <name>Specific Security Implications">
<t>Those described Implications</name>
            <t>These are discussed in <xref target="RFC2473"/>.</t> target="RFC2473" format="default"/>.</t>
          </section>
          <section title="Operational numbered="true" toc="default">
            <name>Operational and Interoperability Impact if Blocked"> If Blocked</name>
            <t>Discarding packets based on the presence of this option could result in tunnel traffic being discarded.</t>
          </section>
          <section title="Advice"> numbered="true" toc="default">
            <name>Advice</name>
            <t>Intermediate systems should not discard packets based on the presence of this option.</t>
          </section>
        </section>
        <section title="Router anchor="x05" numbered="true" toc="default">
          <name>Router Alert (Type=0x05)" anchor="x05"> (Type=0x05)</name>
          <section title="Uses"> numbered="true" toc="default">
            <name>Uses</name>
            <t>The Router Alert option <xref target="RFC2711"/> target="RFC2711" format="default"/> is employed by a number of protocols, including the Resource reSerVation Protocol (RSVP) <xref target="RFC2205"/>, target="RFC2205" format="default"/>, Multicast Listener Discovery (MLD) <xref target="RFC2710"/> target="RFC2710" format="default"/> <xref target="RFC3810"/>, target="RFC3810" format="default"/>, Multicast Router Discovery (MRD) <xref target="RFC4286"/>, target="RFC4286" format="default"/>, and General Internet Signaling Transport (GIST) <xref target="RFC5971"/>. target="RFC5971" format="default"/>. Its usage is discussed in detail in <xref target="RFC6398"/>. target="RFC6398" format="default"/>.
</t>
          </section>
          <section title="Specification"> numbered="true" toc="default">
            <name>Specification</name>
            <t>This option is specified in <xref target="RFC2711"/>.</t> target="RFC2711" format="default"/>.</t>
          </section>
          <section title="Specific anchor="ra-usage" numbered="true" toc="default">
            <name>Specific Security Implications" anchor="ra-usage"> Implications</name>
            <t>Since this option causes the contents of the packet to be inspected by the handling device, this option could be leveraged for performing DoS attacks. The security implications of the Router Alert option are discussed in detail in <xref target="RFC6398"/>.</t> target="RFC6398" format="default"/>.</t>
          </section>
          <section title="Operational numbered="true" toc="default">
            <name>Operational and Interoperability Impact if Blocked"> If Blocked</name>
            <t>Discarding packets that contain this option would break any protocols that rely on them, such as RSVP and multicast deployments. Please see <xref target="ra-usage"/> target="ra-usage" format="default"/> for further details.</t>
          </section>
          <section title="Advice"> numbered="true" toc="default">
            <name>Advice</name>
            <t>Packets containing this option should be permitted in environments where support for RSVP, multicast routing, or similar protocols is desired.</t> required.</t>
          </section>
        </section>
        <section title="CALIPSO (Type=0x07)"  anchor="x07"> anchor="x07" numbered="true" toc="default">
          <name>CALIPSO (Type=0x07)</name>
          <section title="Uses"> numbered="true" toc="default">
            <name>Uses</name>
            <t>This option is used for encoding explicit packet Sensitivity Labels on IPv6 packets.  It is intended for use only within Multi-Level Secure (MLS) networking environments that are both trusted and trustworthy.</t>
          </section>
          <section title="Specification"> numbered="true" toc="default">
            <name>Specification</name>
            <t>This option is specified in <xref target="RFC5570"/>.</t> target="RFC5570" format="default"/>.</t>
          </section>
          <section title="Specific numbered="true" toc="default">
            <name>Specific Security Implications"> Implications</name>
            <t>Presence of this option in a packet does not by itself create any
          specific new threat. Packets with this option ought not normally be
          seen on the global public Internet.</t>
          </section>
          <section title="Operational numbered="true" toc="default">
            <name>Operational and Interoperability Impact if Blocked"> If Blocked</name>
            <t>If packets with this option are discarded or if the option is
          stripped from the packet during transmission from source to
          destination, then the packet itself is likely to be discarded by the
          receiver because it is not properly labeled. In some cases, the
          receiver might receive the packet but associate an incorrect
          sensitivity label
          Sensitivity Label with the received data from the packet whose CALIPSO Common Architecture Label
	  IPv6 Security Option (CALIPSO)
          was stripped by a middle-box middlebox (such as a packet-scrubber). packet scrubber). Associating an
          incorrect sensitivity label Sensitivity Label can cause the received information
          either
          to be handled either as more sensitive than it really is
          ("upgrading") or as less sensitive than it really is
            ("downgrading"), either of which is problematic. As noted in <xref target="RFC5570"/>, target="RFC5570" format="default"/>, IPsec <xref target="RFC4301"/> target="RFC4301" format="default"/> <xref target="RFC4302"/> target="RFC4302" format="default"/> <xref target="RFC4303"/> target="RFC4303" format="default"/> can be employed to protect the CALIPSO option.</t> CALIPSO.</t>
          </section>
          <section title="Advice"> numbered="true" toc="default">
            <name>Advice</name>
            <t>
Recommendations for handling the CALIPSO option depend on the deployment environment, environment rather than on whether an intermediate system
  happens to be deployed as a transit device (e.g., IPv6 transit router).</t>
            <t>Explicit configuration is the only method via which an intermediate system
 can know whether that particular intermediate system has been
 deployed within a Multi-Level Secure (MLS) an MLS environment.  In many cases,
 ordinary commercial intermediate systems (e.g., IPv6 routers and firewalls)
 are the majority of the deployed intermediate systems inside an MLS
 network environment. </t>
            <t>For Intermediate intermediate systems that DO NOT implement <xref target="RFC5570"/>, target="RFC5570" format="default"/>, there
 should be a configuration option to EITHER either (a) drop packets containing
 the CALIPSO option OR or  (b) to ignore the presence of the CALIPSO option
 and forward the packets normally.  In non-MLS environments, such
 intermediate systems should have this configuration option set to (a)
 above.  In MLS environments, such intermediate systems should
 have this option set to (b) above.  The default setting for this configuration
 option should be set to (a) above, because MLS environments are much
 less common than non-MLS environments.
</t>
            <t>For Intermediate intermediate systems that DO implement <xref target="RFC5570"/>, target="RFC5570" format="default"/>, there should
 be configuration options (a) and (b) from the preceding paragraph and
 also a third configuration option (c) to process packets containing
 a CALIPSO option as per <xref target="RFC5570"/>. target="RFC5570" format="default"/>.  When deployed in non-MLS
 environments, such intermediate systems should have this configuration
 option set to (a) above.  When deployed in MLS environments, such
 intermediate systems should have this configuration option set to (c).  The default setting
 for this configuration option MAY <bcp14>MAY</bcp14> be set to (a) above, because MLS
 environments are much less common than non-MLS environments.
</t>
          </section>
        </section>
        <section title="SMF_DPD (Type=0x08)"  anchor="x08">
<section title="Uses"> anchor="x08" numbered="true" toc="default">
          <name>SMF_DPD (Type=0x08)</name>
          <section numbered="true" toc="default">
            <name>Uses</name>
            <t>This option is employed in the (experimental) Simplified Multicast Forwarding (SMF) for unique packet identification for IPv6 I-DPD, Identification-based DPD (I-DPD) and as a mechanism to guarantee non-collision of hash values for different packets when H-DPD Hash-based DPD (H-DPD) is used.</t>
          </section>
          <section title="Specification"> numbered="true" toc="default">
            <name>Specification</name>
            <t>This option is specified in <xref target="RFC6621"/>.</t> target="RFC6621" format="default"/>.</t>
          </section>
          <section title="Specific numbered="true" toc="default">
            <name>Specific Security Implications"> Implications</name>
            <t>None. The use of transient numeric identifiers is subject to the security and privacy considerations discussed in <xref target="I-D.irtf-pearg-numeric-ids-generation"/>.</t> target="I-D.irtf-pearg-numeric-ids-generation" format="default"/>.</t>
          </section>
          <section title="Operational numbered="true" toc="default">
            <name>Operational and Interoperability Impact if Blocked"> If Blocked</name>
            <t>Dropping packets containing this option within a MANET Mobile Ad Hoc Network (MANET) domain would break SMF. However, dropping such packets at the border of such domain would have no negative impact.</t>
          </section>
          <section title="Advice"> numbered="true" toc="default">
            <name>Advice</name>
            <t>Intermediate systems that are not within a MANET domain should discard packets that contain this option.</t>
          </section>
        </section>
        <section title="PDM (Type=0x0F)"  anchor="x0F">
<section title="Uses"> anchor="x0F" numbered="true" toc="default">
          <name>PDM (Type=0x0F)</name>
          <section numbered="true" toc="default">
            <name>Uses</name>
            <t>This option is employed to convey sequence numbers and timing information in IPv6 packets as a basis for measurements.</t>
          </section>
          <section title="Specification"> numbered="true" toc="default">
            <name>Specification</name>
            <t>This option is specified in <xref target="RFC8250"/>.</t> target="RFC8250" format="default"/>.</t>
          </section>
          <section title="Specific numbered="true" toc="default">
            <name>Specific Security Implications">
<t>Those specified Implications</name>
            <t>These are discussed in <xref target="RFC8250"/>. target="RFC8250" format="default"/>. Additionally, since the options this option employs transient numeric identifiers, implementations may be subject to the issues discussed in <xref target="I-D.irtf-pearg-numeric-ids-generation"/>.</t> target="I-D.irtf-pearg-numeric-ids-generation" format="default"/>.</t>
          </section>
          <section title="Operational numbered="true" toc="default">
            <name>Operational and Interoperability Impact if Blocked"> If Blocked</name>
            <t>Dropping packets containing this option will result in negative interoperaiblity interoperability implications for traffic employing this option as a basis for measurements.</t>
          </section>
          <section title="Advice"> numbered="true" toc="default">
            <name>Advice</name>
            <t>Intermediate systems should not discard packets based on the presence of this option.</t>
          </section>
        </section>
        <section title="RPL anchor="x23" numbered="true" toc="default">
          <name>RPL Option (Type=0x23)" anchor="x23"> (Type=0x23)</name>
          <section title="Uses"> numbered="true" toc="default">
            <name>Uses</name>
            <t>The RPL Option provides a mechanism to include routing information with in each datagram that an a RPL router forwards.</t>
          </section>
          <section title="Specification"> numbered="true" toc="default">
            <name>Specification</name>
            <t>This option is specified in <xref target="RFC9008"/>.</t> target="RFC9008" format="default"/>.</t>
          </section>
          <section title="Specific numbered="true" toc="default">
            <name>Specific Security Implications">
<t>Those described Implications</name>
            <t>These are discussed in <xref target="RFC9008"/>.</t> target="RFC9008" format="default"/>.</t>
          </section>
          <section title="Operational numbered="true" toc="default">
            <name>Operational and Interoperability Impact if Blocked"> If Blocked</name>
            <t>This option can survive outside of an a RPL instance. As a result, discarding packets based on the presence of this option would break some use cases for RPL (see <xref target="RFC9008"/>).</t> target="RFC9008" format="default"/>).</t>
          </section>
          <section title="Advice"> numbered="true" toc="default">
            <name>Advice</name>
            <t>Intermediate systems should not discard IPv6 packets based on the presence of this option.</t>
          </section>
        </section>
        <section title="Quick-Start (Type=0x26)"  anchor="x26">
<section title="Uses"> anchor="x26" numbered="true" toc="default">
          <name>Quick-Start (Type=0x26)</name>
          <section numbered="true" toc="default">
            <name>Uses</name>
            <t>This IP Option option is used in the specification of Quick-Start for
          TCP and IP, which is an experimental mechanism that allows transport
          protocols, in cooperation with routers, to determine an allowed
          sending rate at the start and, at times, in the middle of a data
          transfer (e.g., after an idle period) <xref target="RFC4782"/>.</t> target="RFC4782" format="default"/>.</t>
          </section>
          <section title="Specification"> numbered="true" toc="default">
            <name>Specification</name>
            <t>This option is specified in <xref target="RFC4782"/>, target="RFC4782" format="default"/> on the "Experimental" track.</t>
          </section>
          <section title="Specific numbered="true" toc="default">
            <name>Specific Security Implications">
          <t>Section 9.6 of <xref target="RFC4782"/> Implications</name>
            <t><xref target="RFC4782" sectionFormat="of" section="9.6"/> notes that Quick-Start is
          vulnerable to two kinds of attacks: <list style="symbols">
              <t>attacks </t>
            <ul spacing="normal">
              <li>attacks to increase the routers' processing and state load,
              and,</t>

              <t>attacks load
              and</li>
              <li>attacks with bogus Quick-Start Requests to temporarily tie up
              available Quick-Start bandwidth, preventing routers from
              approving Quick-Start Requests from other connections.</t>
            </list></t> connections</li>
            </ul>
            <t>We note that if routers in a given environment do not implement and enable the Quick-Start mechanism, only the general security
implications of IP options (discussed in <xref target="ipv6-options-general-implications"/>) target="ipv6-options-general-implications" format="default"/>) would apply.</t>
          </section>
          <section title="Operational numbered="true" toc="default">
            <name>Operational and Interoperability Impact if Blocked">
          <t>The Quick-Start functionality would If Blocked</name>
            <t>If packets with IPv6 Quick Start options are blocked, the host trying to establish a TCP
	    connection will fall back to not including the Quick Start option -- this means that the
	    feature will be disabled, and additional delays in TCP's connection establishment (for example) could
	    will be introduced.
          (Please see Section 4.7.2 of introduced (as discussed in <xref target="RFC4782"/>.) target="RFC4782" sectionFormat="of"
	    section="4.7.2"/>). We note,
          however, that Quick-Start has been proposed as a mechanism that could
          be of use in controlled environments, environments and not as a mechanism that
          would be intended or appropriate for ubiquitous deployment in the
          global Internet <xref target="RFC4782"/>.</t> target="RFC4782" format="default"/>.</t>
          </section>
          <section title="Advice"> numbered="true" toc="default">
            <name>Advice</name>
            <t>Intermediate systems should not discard IPv6 packets based on the presence of this option.</t>
          </section>
        </section>
        <section title="Deprecated (Type=0x4D)"  anchor="x4D">
<section title="Uses"> anchor="x4D" numbered="true" toc="default">
          <name>Deprecated (Type=0x4D)</name>
          <section numbered="true" toc="default">
            <name>Uses</name>
            <t>No information has been found about this option type.</t>
          </section>
          <section title="Specification"> numbered="true" toc="default">
            <name>Specification</name>
            <t>No information has been found about this option type.</t>
          </section>
          <section title="Specific numbered="true" toc="default">
            <name>Specific Security Implications"> Implications</name>
            <t>No information has been found about this option type, and hence type; hence, it has been impossible to perform the corresponding security assessment.</t>
          </section>
          <section title="Operational numbered="true" toc="default">
            <name>Operational and Interoperability Impact if Blocked"> If Blocked</name>
            <t>Unknown.</t>
          </section>
          <section title="Advice"> numbered="true" toc="default">
            <name>Advice</name>
            <t>Intermediate systems should discard packets that contain this option.</t>
          </section>
        </section>
        <section title="RPL anchor="x63" numbered="true" toc="default">
          <name>RPL Option (Type=0x63)" anchor="x63"> (Type=0x63)</name>
          <section title="Uses"> numbered="true" toc="default">
            <name>Uses</name>
            <t>The RPL Option provides a mechanism to include routing information with in each datagram that an a RPL router forwards.</t>
          </section>
          <section title="Specification"> numbered="true" toc="default">
            <name>Specification</name>
            <t>This option was originally specified in <xref target="RFC6553"/>. target="RFC6553" format="default"/>. It has been deprecated by <xref target="RFC9008"/>.</t> target="RFC9008" format="default"/>.</t>
          </section>
          <section title="Specific numbered="true" toc="default">
            <name>Specific Security Implications">
<t>Those described Implications</name>
            <t>These are discussed in <xref target="RFC9008"/>.</t> target="RFC6553" sectionFormat="of" section="5"/>.</t>
          </section>
          <section title="Operational numbered="true" toc="default">
            <name>Operational and Interoperability Impact if Blocked"> If Blocked</name>
            <t>This option is meant to be employed within an a RPL instance. As a result, discarding packets based on the presence of this option outside of an a RPL instance will not result in interoperability implications.</t>
          </section>
          <section title="Advice">
<t>Non-RPL routers numbered="true" toc="default">
            <name>Advice</name>
            <t>Intermediate systems should discard packets that contain an a RPL option.</t> Option.</t>
          </section>
        </section>
        <section title="MPL anchor="x6D" numbered="true" toc="default">
          <name>MPL Option (Type=0x6D)"  anchor="x6D"> (Type=0x6D)</name>
          <section title="Uses"> numbered="true" toc="default">
            <name>Uses</name>
            <t>This option is used with the Multicast Protocol for Low power and Lossy Networks (MPL), that which provides IPv6 multicast forwarding in
   constrained networks.</t>
          </section>
          <section title="Specification"> numbered="true" toc="default">
            <name>Specification</name>
            <t>This option is specified in <xref target="RFC7731"/>, target="RFC7731" format="default"/> and is meant to be included only in Hop-by-Hop Option Options headers.</t>
          </section>
          <section title="Specific numbered="true" toc="default">
            <name>Specific Security Implications">
<t>Those described Implications</name>
            <t>These are discussed in <xref target="RFC7731"/>.</t> target="RFC7731" format="default"/>.</t>
          </section>
          <section title="Operational numbered="true" toc="default">
            <name>Operational and Interoperability Impact if Blocked"> If Blocked</name>
            <t>Dropping packets that contain an MPL option Option within an MPL network would break the Multicast Protocol for Low power and Lossy Networks (MPL). MPL. However, dropping such packets at the border of such networks will have no negative impact.</t>
          </section>
          <section title="Advice"> numbered="true" toc="default">
            <name>Advice</name>
            <t>Intermediate systems should not discard packets based on the presence of this option. However, since this option has been specified for the Hop-by-Hop Options, Options header, such systems should consider the discussion in <xref target="proto0"/>.</t> target="proto0" format="default"/>.</t>
          </section>
        </section>
        <section title="Endpoint anchor="x8A" numbered="true" toc="default">
          <name>Endpoint Identification (Type=0x8A)" anchor="x8A"> (Type=0x8A)</name>
          <section title="Uses"> numbered="true" toc="default">
            <name>Uses</name>
            <t>The Endpoint Identification option was meant to be used with the Nimrod routing architecture <xref target="NIMROD-DOC"/>, target="NIMROD-DOC" format="default"/> but has never seen widespread deployment.</t>
          </section>
          <section title="Specification"> numbered="true" toc="default">
            <name>Specification</name>
            <t>This option is specified in <xref target="NIMROD-DOC"/>.</t> target="NIMROD-DOC" format="default"/>.</t>
          </section>
          <section title="Specific numbered="true" toc="default">
            <name>Specific Security Implications"> Implications</name>
            <t>Undetermined.</t>
          </section>
          <section title="Operational numbered="true" toc="default">
            <name>Operational and Interoperability Impact if Blocked"> If Blocked</name>
            <t>None.</t>
          </section>
          <section title="Advice"> numbered="true" toc="default">
            <name>Advice</name>
            <t>Intermediate systems should discard packets that contain this option.</t>
          </section>
        </section>
        <section title="ILNP anchor="x8B" numbered="true" toc="default">
          <name>ILNP Nonce (Type=0x8B)" anchor="x8B"> (Type=0x8B)</name>
          <section title="Uses"> numbered="true" toc="default">
            <name>Uses</name>
            <t>This option is employed by the Identifier-Locator Network Protocol for IPv6 (ILNPv6) for providing to provide protection against off-path attacks for packets when ILNPv6 is in use, use and as a signal during initial network-layer session creation that ILNPv6 is proposed for use with this network-layer session, rather than classic IPv6.</t>
          </section>
          <section title="Specification"> numbered="true" toc="default">
            <name>Specification</name>
            <t>This option is specified in <xref target="RFC6744"/>.</t> target="RFC6744" format="default"/>.</t>
          </section>
          <section title="Specific numbered="true" toc="default">
            <name>Specific Security Implications">
<t>Those described Implications</name>
            <t>These are discussed in <xref target="RFC6744"/>.</t> target="RFC6744" format="default"/>.</t>
          </section>
          <section title="Operational numbered="true" toc="default">
            <name>Operational and Interoperability Impact if Blocked"> If Blocked</name>
            <t>Discarding packets that contain this option will break INLPv6 ILNPv6 deployments.</t>
          </section>
          <section title="Advice"> numbered="true" toc="default">
            <name>Advice</name>
            <t>Intermediate systems should not discard packets based on the presence of this option.</t>
          </section>
        </section>
        <section title="Line-Identification anchor="x8C" numbered="true" toc="default">
          <name>Line-Identification Option (Type=0x8C)" anchor="x8C"> (Type=0x8C)</name>
          <section title="Uses"> numbered="true" toc="default">
            <name>Uses</name>
            <t>This option is used by an Edge Router to identify the subscriber premises in scenarios where several subscriber premises may be logically connected to the same interface of an Edge Router.</t>

<!--
   The Line-Identification Option (LIO) is a destination option that can
   be included in IPv6 datagrams that tunnel Router Solicitation and
   Router Advertisement messages.  The use of the Line-ID option in any
   other IPv6 datagrams is not defined by this document.  Multiple Line-
   ID destination options MUST NOT be present in the same IPv6 datagram.
   The LIO has no alignment requirement.
-->

</section>
          <section title="Specification"> numbered="true" toc="default">
            <name>Specification</name>
            <t>This option is specified in <xref target="RFC6788"/>.</t> target="RFC6788" format="default"/>.</t>
          </section>
          <section title="Specific numbered="true" toc="default">
            <name>Specific Security Implications">
<t>Those described Implications</name>
            <t>These are discussed in <xref target="RFC6788"/>.</t> target="RFC6788" format="default"/>.</t>
          </section>
          <section title="Operational numbered="true" toc="default">
            <name>Operational and Interoperability Impact if Blocked"> If Blocked</name>
            <t>Since this option is meant to be employed used when tunneling Neighbor Discovery messages in Router Solicitation messages, some broadband network deployment scenarios, discarding packets based on the presence of this option at intermediate systems will result in no interoperability implications.</t>
          </section>
          <section title="Advice"> numbered="true" toc="default">
            <name>Advice</name>
            <t>Intermediate devices systems should discard packets that contain this option.</t>
          </section>
        </section>
        <section title="Jumbo anchor="xC2" numbered="true" toc="default">
          <name>Jumbo Payload (Type=0XC2)"  anchor="xC2"> (Type=0XC2)</name>
          <section title="Uses"> numbered="true" toc="default">
            <name>Uses</name>
            <t>The Jumbo payload Payload option provides the means of specifying for supporting payloads larger than 65535 bytes.</t>
          </section>
          <section title="Specification"> numbered="true" toc="default">
            <name>Specification</name>
            <t>This option is specified in <xref target="RFC2675"/>.</t> target="RFC2675" format="default"/>.</t>
          </section>
          <section title="Specific numbered="true" toc="default">
            <name>Specific Security Implications"> Implications</name>
            <t>There are no specific issues arising from this option, except for improper validity checks of the option and associated packet lengths.</t>
          </section>
          <section title="Operational numbered="true" toc="default">
            <name>Operational and Interoperability Impact if Blocked"> If Blocked</name>
            <t>Discarding packets based on the presence of this option will cause IPv6 jumbograms to be discarded.</t>
          </section>
          <section title="Advice"> numbered="true" toc="default">
            <name>Advice</name>
            <t>An operator should permit this option only in specific scenarios in which support for IPv6 jumbograms is desired. required.
</t>
          </section>
        </section>
        <section title="Home anchor="xC9" numbered="true" toc="default">
          <name>Home Address (Type=0xC9)" anchor="xC9"> (Type=0xC9)</name>
          <section title="Uses"> numbered="true" toc="default">
            <name>Uses</name>
            <t>The Home Address option is used by a Mobile IPv6 node while away from home, home to inform the recipient of the mobile node's home address.</t>
          </section>
          <section title="Specification"> numbered="true" toc="default">
            <name>Specification</name>
            <t>This option is specified in <xref target="RFC6275"/>.</t> target="RFC6275" format="default"/>.</t>
          </section>
          <section title="Specific numbered="true" toc="default">
            <name>Specific Security Implications">
<t>No Implications</name>
            <t>There are no (known) additional security implications implications, other than those described discussed in <xref target="RFC6275"/>.</t> target="RFC6275" format="default"/>.</t>
          </section>
          <section title="Operational numbered="true" toc="default">
            <name>Operational and Interoperability Impact if Blocked"> If Blocked</name>
            <t>Discarding IPv6 packets based on the presence of this option will break Mobile IPv6.</t>
          </section>
          <section title="Advice"> numbered="true" toc="default">
            <name>Advice</name>
            <t>Intermediate systems should not discard IPv6 packets based on the presence of this option.</t>
          </section>
        </section>
        <section title="IP_DFF (Type=0xEE)"  anchor="xEE">
<section title="Uses"> anchor="xEE" numbered="true" toc="default">
          <name>IP_DFF (Type=0xEE)</name>
          <section numbered="true" toc="default">
            <name>Uses</name>
            <t>This option is employed with the (Experimental) (experimental) Depth-First Forwarding (DFF) in Unreliable Networks.</t> unreliable networks.</t>
          </section>
          <section title="Specification"> numbered="true" toc="default">
            <name>Specification</name>
            <t>This option is specified in <xref target="RFC6971"/>.</t> target="RFC6971" format="default"/>.</t>
          </section>
          <section title="Specific numbered="true" toc="default">
            <name>Specific Security Implications">
<t>Those Implications</name>
            <t>These are specified in <xref target="RFC6971"/>.</t> target="RFC6971" format="default"/>.</t>
          </section>
          <section title="Operational numbered="true" toc="default">
            <name>Operational and Interoperability Impact if Blocked"> If Blocked</name>
            <t>Dropping packets containing this option within a routing domain that is running DFF would break DFF. However, dropping such packets at the border of such domains will have no security operational or interoperability implications.</t>
          </section>
          <section title="Advice"> numbered="true" toc="default">
            <name>Advice</name>
            <t>Intermediate systems that do not operate within a routing domain that is running DFF should discard packets containing this option.</t>
          </section>
        </section>
        <section title="RFC3692-style anchor="x1E" numbered="true" toc="default">
          <name>RFC3692-Style Experiment (Types = 0x1E, 0x3E, 0x5E, 0x7E, 0x9E, 0xBE, 0xDE, 0xFE)" anchor="x1E"> 0xFE)</name>
          <section title="Uses"> numbered="true" toc="default">
            <name>Uses</name>
            <t>These options can be employed for performing RFC3692-style experiments. It is only appropriate to use these values in
          explicitly configured experiments; they must not be shipped as defaults in implementations.</t>
          </section>
          <section title="Specification">
         <t>Specified numbered="true" toc="default">
            <name>Specification</name>
            <t>These options are specified in RFC 4727 <xref target="RFC4727"/> target="RFC4727" format="default"/> in the context of
          RFC3692-style experiments.</t>
          </section>
          <section title="Specific numbered="true" toc="default">
            <name>Specific Security Implications"> Implications</name>
            <t>The specific security implications will depend on the specific use of these options.</t>
          </section>
          <section title="Operational numbered="true" toc="default">
            <name>Operational and Interoperability Impact if Blocked"> If Blocked</name>
            <t>For obvious reasons, discarding packets that contain these options limits the ability to perform legitimate experiments across IPv6 routers.</t>
          </section>
          <section title="Advice"> numbered="true" toc="default">
            <name>Advice</name>
            <t>Operators should determine determine, according to their own circumstances circumstances, whether to discard packets containing these IPv6 options.</t>
<!--
<t>Intermediate systems should discard packets that contain these options. Only in specific environments where RFC3692-style experiments are meant to be performed should these options be permitted.</t> -->

</section>
        </section>
      </section>
      <section title="Advice numbered="true" toc="default">
        <name>Advice on the handling Handling of Packets with Unknown IPv6 Options"> Options</name>
        <t>We refer to IPv6 options that have not been assigned an IPv6 option type Option Type in the corresponding registry (<xref target="IANA-IPV6-PARAM"/>) registry, which is <xref target="IANA-IPV6-PARAM" format="default"/>, as "unknown IPv6 options".</t>
        <section title="Uses"> numbered="true" toc="default">
          <name>Uses</name>
          <t>New IPv6 options may be specified as part of future protocol work.</t>
        </section>
        <section title="Specification"> numbered="true" toc="default">
          <name>Specification</name>
          <t>The processing of unknown IPv6 options is specified in <xref target="RFC8200"/>.</t> target="RFC8200" format="default"/>.</t>
        </section>
        <section title="Specific numbered="true" toc="default">
          <name>Specific Security Implications"> Implications</name>
          <t>For obvious reasons, it is impossible to determine specific security implications of unknown IPv6 options.</t>
        </section>
        <section title="Operational numbered="true" toc="default">
          <name>Operational and Interoperability Impact if Blocked"> If Blocked</name>
          <t>Discarding unknown IPv6 options may slow down the deployment of new IPv6 options. As noted in <xref target="draft-gont-6man-ipv6-opt-transmit"/>, target="I-D.gont-6man-ipv6-opt-transmit" format="default"/>, the corresponding IANA registry (<xref target="IANA-IPV6-PARAM"/> registry, which is <xref target="IANA-IPV6-PARAM" format="default"/>, should be monitored such that IPv6 option filtering rules are updated as new IPv6 options are standardized.</t>
        </section>
        <section title="Advice"> numbered="true" toc="default">
          <name>Advice</name>
          <t>Operators should determine determine, according to their own circumstances circumstances, whether to discard packets containing unknown IPv6 options.</t>
        </section>
      </section>
    </section>
    <section anchor="IANA" title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This document has no actions for IANA.</t> IANA actions.</t>
    </section>
    <section title="Privacy Considerations" anchor="Privacy" > numbered="true" toc="default">
      <name>Privacy Considerations</name>
      <t>
There are no privacy considerations associated with this document.
</t>
    </section>
    <section title="Security Considerations" anchor="Security" > numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>
This document provides advice on the filtering of IPv6 packets that contain IPv6 EHs (and possibly IPv6 options) at IPv6 transit routers. It is meant to improve the current situation of widespread dropping of such IPv6 packets in those cases where the drops result from improper configuration defaults, defaults or inappropriate advice in this area.
</t>
      <t>
   As discussed in Section <xref target="ipv6-ehs-rationale"/> of this document, target="ipv6-ehs-rationale" format="default"/>, one of the
   underlying principles for the advice provided in this document is
   that IPv6 packets with specific EHs or options which that may represent an
   attack vector for infrastructure devices should be dropped. While
   this policy helps mitigate some specific attack vectors, the
   recommendations in this document will not help to mitigate
   vulnerabilities based on implementation errors <xref target="RFC9098"/>. target="RFC9098" format="default"/>.
</t>
      <t>We also note that depending on the router architecture, attempts to filter packets ased based on the presence of IPv6 EHs or options might itself represent an attack vector to network infrastructure devices <xref target="RFC9098"/>.</t>
</section>

<section title="Acknowledgements">
<t>The authors would like to thank Ron Bonica for his work on earlier versions of this document.</t>
<t>The authors of this document would like to thank (in alphabetical order) Mikael Abrahamsson, Brian Carpenter, Tim Chown, Roman Danyliw, Darren Dukes, Lars Eggert, David Farmer, Mike Heard, Bob Hinden, Christian Huitema, Benjamin Kaduk, Erik Kline, Murray Kucherawy, Jen Linkova, Carlos Pignataro, Alvaro Retana, Maria Ines Robles, Zaheduzzaman Sarker, Donald Smith, Pascal Thubert, Ole Troan, Gunter Van De Velde, Eric Vyncke, and Robert Wilton, for providing valuable comments on earlier versions of this document.</t>
<t>This document borrows some text and analysis from <xref target="RFC7126"/>, authored by Fernando Gont, Randall Atkinson, and Carlos Pignataro.</t>

<t>The authors would like to thank Warren Kumari and Eric Vyncke for their guidance during the publication process of this document.</t>

<t>Fernando would also like to thank Brian Carpenter and Ran Atkinson who, over the years, have answered many questions and provided valuable comments that have benefited his protocol-related work (including the present document).</t> target="RFC9098" format="default"/>.</t>
    </section>

  </middle>
  <back>
<references title="Normative References">
    <?rfc include="reference.RFC.1034" ?>
    <?rfc include="reference.RFC.5570" ?>
    <?rfc include="reference.RFC.2119" ?>
    <?rfc include="reference.RFC.8174" ?>

    <?rfc include="reference.RFC.2205" ?>

    <?rfc include="reference.RFC.2675" ?>
    <?rfc include="reference.RFC.4301" ?>
    <?rfc include="reference.RFC.4302" ?>
    <?rfc include="reference.RFC.4303" ?>

    <?rfc include="reference.RFC.6275" ?>
    <?rfc include="reference.RFC.7401" ?>
    <?rfc include="reference.RFC.5533" ?>
    <?rfc include="reference.RFC.3692" ?>
    <?rfc include="reference.RFC.4727" ?>
    <?rfc include="reference.RFC.2710" ?>
    <?rfc include="reference.RFC.3810" ?>
    <?rfc include="reference.RFC.4286" ?>
    <?rfc include="reference.RFC.5971" ?>
    <?rfc include="reference.RFC.2711" ?>
    <?rfc include="reference.RFC.5095" ?>
    <?rfc include="reference.RFC.6550" ?>
    <?rfc include="reference.RFC.6621" ?>
    <?rfc include="reference.RFC.6971" ?>
    <?rfc include="reference.RFC.7045" ?>
    <?rfc include="reference.RFC.7112" ?>
    <?rfc include="reference.RFC.4782" ?>
    <?rfc include="reference.RFC.6788" ?>
    <?rfc include="reference.RFC.6740" ?>
    <?rfc include="reference.RFC.6744" ?>
    <?rfc include="reference.RFC.2473" ?>
    <?rfc include="reference.RFC.6553" ?>
    <?rfc include="reference.RFC.6554" ?>
    <?rfc include="reference.RFC.6398" ?>
    <?rfc include="reference.RFC.8754" ?>

    <?rfc include="reference.RFC.9008" ?>

    <?rfc include="reference.RFC.7731" ?>
    <?rfc include="reference.RFC.8200" ?>
    <?rfc include="reference.RFC.8250" ?>
    <?rfc include="reference.RFC.8900" ?>
<displayreference target="I-D.irtf-pearg-numeric-ids-generation" to="NUMERIC-IDS"/>
<displayreference target="I-D.vyncke-v6ops-james" to="JAMES"/>
<displayreference target="I-D.gont-6man-ipv6-opt-transmit" to="IPv6-OPTIONS"/>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1034.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5570.xml"/>
        <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.2205.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2675.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4301.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4302.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4303.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6275.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7401.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5533.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3692.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4727.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2710.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3810.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4286.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5971.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2711.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5095.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6550.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6621.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6971.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.7112.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4782.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6788.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6740.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6744.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2473.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6553.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6554.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6398.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8754.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9008.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7731.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.8250.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8900.xml"/>
      </references>

<references title="Informative References">
    <?rfc include="reference.RFC.2460" ?>
    <?rfc include="reference.RFC.3871" ?>
    <?rfc include="reference.RFC.6192" ?>
    <?rfc include="reference.RFC.7126" ?>
    <?rfc include="reference.RFC.7739" ?>

    <?rfc include="reference.I-D.irtf-pearg-numeric-ids-generation" ?>

    <?rfc include="reference.RFC.9098" ?>

    <?rfc include="reference.RFC.7872" ?>

    <?rfc include="reference.I-D.vyncke-v6ops-james" ?>
      <references>
        <name>Informative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2460.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3871.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6192.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7126.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7739.xml"/>
        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.irtf-pearg-numeric-ids-generation.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9098.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7872.xml"/>
 <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.vyncke-v6ops-james.xml"/>

        <reference anchor="Huston-2022" target="https://iepg.org/2022-03-20-ietf113/huston-v6frag.pdf">
          <front>
            <title>IPv6 Fragmentation and EH Behaviours</title>
            <author fullname="Geoff Huston" initials="G." surname="Huston">
              <organization abbrev="APNIC"/>
              <address>
                <email>gih@apnic.net</email>
                <uri>https://www.apnic.net</uri>
              </address>
            </author>
            <author fullname="Joao Damas" initials="J." surname="Damas">
              <organization abbrev="APNIC"/>
            </author>
            <date month="March" year="2022"/>
          </front>

        <seriesInfo name=""
                    value="IEPG Meeting - March 2022 @ IETF 113"/>
      </reference>

<!--
      <reference anchor="Vyncke-2022" target="https://iepg.org/2022-03-20-ietf113/james-IEPG.pdf">
        <front>
          <title>Just Another Measurement of Extension Header Survivability (JAMES)</title>

    <author fullname="Eric Vyncke" initials="E." surname="Vyncke">

    </author>

    <author fullname="Raphael Leas" initials="R." surname="Leas">
      <organization/>
    </author>

    <author fullname="Justin Iurman" initials="J." surname="Iurman">
      <organization/>
    </author>

          <date month="March" year="2022"/>
        </front>

        <seriesInfo name=""
                    value="IEPG
          <refcontent>IEPG Meeting - March 2022 @ at IETF 113"/> 113"</refcontent>
        </reference>
-->

<reference anchor="draft-ietf-nimrod-eid"> anchor="NIMROD-EID">
   <front>
      <title>Endpoint Identifier Destination Option</title>
      <author fullname="Charles Lynn" initials="C.L." surname="Lynn">
            <organization>BBN Systems and Technologies</organization> initials="C." surname="Lynn" fullname="Dr. Charles W. Lynn Jr.">
         </author>
      <date month="November" year="1995"/> month="March" day="2" year="1996" />
   </front>
   <seriesInfo name=""
                    value="IETF Internet Draft, draft-ietf-nimrod-eid-00.txt"/> name="Internet-Draft" value="draft-ietf-nimrod-eid-00" />
</reference>

        <reference anchor="NIMROD-DOC"> anchor="NIMROD-DOC" target="http://ana-3.lcs.mit.edu/~jnc/nimrod">
          <front>
			<title>http://ana-3.lcs.mit.edu/~jnc/nimrod/</title>
			<author initials="" surname="Nimrod Documentation Page" fullname="Nimrod Documentation Page">
				<organization></organization>
			</author>
			<date year=""/>
            <title>Nimrod Documentation</title>
	    <author/>
	  </front>
        </reference>

        <reference anchor="Biondi2007" anchor="Biondi-2007" target="http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf">
          <front>
            <title>IPv6 Routing Header Security</title>
            <author fullname="P. Biondi" initials="P." surname="Biondi">
              <organization/>
            </author>
            <author fullname="A. Ebalard" initials="A." surname="Ebalard">
              <organization/>
            </author>
            <date month="April" year="2007"/>
          </front>

        <seriesInfo name="CanSecWest 2007"
                    value="Security Conference"/>
          <refcontent>CanSecWest Security Conference</refcontent>
        </reference>

        <reference anchor="IANA-PROTOCOLS"
                 target="https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml"> target="https://www.iana.org/assignments/protocol-numbers">
          <front>
            <title>Protocol Numbers</title>

          <author fullname="">
            <organization>Internet Assigned Numbers Authority</organization>
	    <author>
              <organization>IANA</organization>
            </author>

          <date year="2014"/>
          </front>

        <format target="https://www.iana.org/assignments/protocol-numbers/protocol-numbers.txt"
                type="TXT"/>
        </reference>

        <reference anchor="IANA-IPV6-PARAM"
                 target="https://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml"> target="https://www.iana.org/assignments/ipv6-parameters">
          <front>
            <title>Internet Protocol Version 6 (IPv6) Parameters</title>

          <author fullname="">
            <organization>Internet Assigned Numbers Authority</organization>
            <author>
              <organization>IANA</organization>
            </author>

          <date month="December" year="2013"/>
          </front>
        </reference>

        <reference anchor="FW-Benchmark" target="https://www.ipv6hackers.org/files/meetings/ipv6-hackers-1/zack-ipv6hackers1-firewall-security-assessment-and-benchmarking.pdf">
          <front>
            <title abbrev="Firewall Benchmarking">Firewall Security Assessment and Benchmarking IPv6 Firewall Load Tests</title>
            <author initials="E." surname="Zack" fullname="Eldad Zack">
  </author>
            <date year=""/> month="June" year="2013"/>
          </front>
		<seriesInfo name="" value="IPv6
          <refcontent>IPv6 Hackers Meeting #1, Berlin, Germany. June 30, 2013"/>
<!-- July 27 - August 1 --> Germany</refcontent>
  </reference>

        <reference anchor="Cisco-EH" target="https://www.cisco.com/en/US/technologies/tk648/tk872/technologies_white_paper0900aecd8054d37d.pdf">
          <front>
            <title abbrev="Cisco IPv6 EH">IPv6 Extension Headers Review and Considerations</title>
            <author initials="" surname="Cisco Systems" fullname="Cisco Systems"> surname="" fullname="">
	      <organization>Cisco Systems</organization>
  </author>
            <date year=""/> month="October" year="2006"/>
          </front>
		<seriesInfo name="" value="Whitepaper. October 2006"/>
<!-- July 27 - August 1 -->
          <refcontent>Whitepaper</refcontent>
	</reference>

      <reference anchor="draft-gont-6man-ipv6-opt-transmit">
        <front>
          <title>Transmission and Processing
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.gont-6man-ipv6-opt-transmit.xml"/>
      </references>
</references>
    <section numbered="false" toc="default">
      <name>Acknowledgements</name>

      <t>The authors would like to thank <contact fullname="Ron Bonica"/> for his work on earlier draft versions of IPv6 Options</title>

          <author this document.</t>
      <t>The authors of this document would like to thank (in alphabetical order) <contact fullname="Mikael Abrahamsson"/>, <contact fullname="Brian Carpenter"/>, <contact fullname="Tim Chown"/>, <contact fullname="Roman Danyliw"/>, <contact fullname="Darren Dukes"/>, <contact fullname="Lars Eggert"/>, <contact fullname="David Farmer"/>, <contact fullname="Mike Heard"/>, <contact fullname="Bob Hinden"/>, <contact fullname="Christian Huitema"/>, <contact fullname="Benjamin Kaduk"/>, <contact fullname="Erik Kline"/>, <contact fullname="Murray Kucherawy"/>, <contact fullname="Jen Linkova"/>, <contact fullname="Carlos Pignataro"/>, <contact fullname="Alvaro Retana"/>, <contact fullname="Maria Ines Robles"/>, <contact fullname="Zaheduzzaman Sarker"/>, <contact fullname="Donald Smith"/>, <contact fullname="Pascal Thubert"/>, <contact fullname="Ole Troan"/>, <contact fullname="Gunter Van de Velde"/>, <contact fullname="Éric Vyncke"/>, and <contact fullname="Robert Wilton"/> for providing valuable comments on earlier draft versions of this document.</t>
      <t>This document borrows some text and analysis from <xref target="RFC7126" format="default"/>, which is authored by <contact fullname="Fernando Gont" initials="F." surname="Gont">
            <organization>SI6 Networks / UTN-FRH</organization>
          </author>
          <author fullname="Will Liu" initials="W." surname="Liu">
            <organization></organization>
          </author>
          <author fullname="Ron Bonica" initials="R." surname="Bonica">
            <organization></organization>
          </author>
          <date month="August" year="2014"/>
        </front>

        <seriesInfo name=""
                    value="IETF Internet Draft, Gont"/>, <contact fullname="Randall Atkinson"/>, and <contact fullname="Carlos Pignataro"/>.</t>
      <t>The authors would like to thank <contact fullname="Warren Kumari"/> and <contact fullname="Éric Vyncke"/> for their guidance during the publication process for this document.</t>
      <t>Fernando would also like to thank <contact fullname="Brian Carpenter"/> and <contact fullname="Ran Atkinson"/> who, over the years, have answered many questions and provided valuable comments that have benefited his protocol-related work in progress"/>
      </reference>

</references> (including the present document).</t>
    </section>
  </back>
</rfc>