<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="info" consensus="true" docName="draft-ietf-opsec-ipv6-eh-filtering-10" indexInclude="true" ipr="trust200902" number="9288" prepTime="2022-08-18T16:08:19" scripts="Common,Latin" sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="2" tocInclude="true" xml:lang="en">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-opsec-ipv6-eh-filtering-10" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9288" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="Filtering of IPv6 Packets with EHs">Recommendations on the Filtering of IPv6 Packets Containing IPv6 Extension Headers at Transit Routers</title>
    <seriesInfo name="RFC" value="9288" stream="IETF"/>
    <author fullname="Fernando Gont" initials="F." surname="Gont">
      <organization abbrev="SI6 Networks" showOnFrontPage="true">SI6 Networks</organization>
      <address>
        <postal>
          <street>Segurola y Habana 4310 7mo piso</street>
          <city>Ciudad Autonoma de Buenos Aires</city>
          <country>Argentina</country>
        </postal>
        <email>fgont@si6networks.com</email>
        <uri>https://www.si6networks.com</uri>
      </address>
    </author>
    <author fullname="Will (Shucheng) Liu" initials="W." surname="Liu">
      <organization showOnFrontPage="true">Huawei Technologies</organization>
      <address>
        <postal>
          <street>Bantian, Longgang District</street>
          <city>Shenzhen</city>
          <code>518129</code>
          <country>China</country>
        </postal>
        <email>liushucheng@huawei.com</email>
      </address>
    </author>
    <date month="08" year="2022"/>
    <area>Operations and Management (ops)</area>
    <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 pn="section-abstract">
      <t indent="0" pn="section-abstract-1">
   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>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This document is not an Internet Standards Track specification; it is
            published for informational purposes.  
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by the
            Internet Engineering Steering Group (IESG).  Not all documents
            approved by the IESG are candidates for any level of Internet
            Standard; see Section 2 of RFC 7841. 
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc9288" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2022 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document must include Revised BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Revised BSD License.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-terminology-and-assumptions">Terminology and Assumptions Employed in This Document</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.2.2">
              <li pn="section-toc.1-1.2.2.1">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.2.1.1"><xref derivedContent="2.1" format="counter" sectionFormat="of" target="section-2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-terminology">Terminology</xref></t>
              </li>
              <li pn="section-toc.1-1.2.2.2">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.2.2.1"><xref derivedContent="2.2" format="counter" sectionFormat="of" target="section-2.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-applicability-statement">Applicability Statement</xref></t>
              </li>
              <li pn="section-toc.1-1.2.2.3">
                <t indent="0" pn="section-toc.1-1.2.2.3.1"><xref derivedContent="2.3" format="counter" sectionFormat="of" target="section-2.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-router-default-behavior-and">Router Default Behavior and Features</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-ipv6-extension-headers">IPv6 Extension Headers</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2">
              <li pn="section-toc.1-1.3.2.1">
                <t indent="0" pn="section-toc.1-1.3.2.1.1"><xref derivedContent="3.1" format="counter" sectionFormat="of" target="section-3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-general-discussion">General Discussion</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.2">
                <t indent="0" pn="section-toc.1-1.3.2.2.1"><xref derivedContent="3.2" format="counter" sectionFormat="of" target="section-3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-general-security-implicatio">General Security Implications</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.3">
                <t indent="0" pn="section-toc.1-1.3.2.3.1"><xref derivedContent="3.3" format="counter" sectionFormat="of" target="section-3.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-rationale-for-our-advice-on">Rationale for Our Advice on the Handling of IPv6 Packets with Specific IPv6 Extension Headers</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.4">
                <t indent="0" pn="section-toc.1-1.3.2.4.1"><xref derivedContent="3.4" format="counter" sectionFormat="of" target="section-3.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-summary-of-advice-on-the-ha">Summary of Advice on the Handling of IPv6 Packets with Specific IPv6 Extension Headers</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.5">
                <t indent="0" pn="section-toc.1-1.3.2.5.1"><xref derivedContent="3.5" format="counter" sectionFormat="of" target="section-3.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-advice-on-the-handling-of-i">Advice on the Handling of IPv6 Packets with Specific IPv6 Extension Headers</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.6">
                <t indent="0" pn="section-toc.1-1.3.2.6.1"><xref derivedContent="3.6" format="counter" sectionFormat="of" target="section-3.6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-advice-on-the-handling-of-p">Advice on the Handling of Packets with Unknown IPv6 Extension Headers</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-ipv6-options">IPv6 Options</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2">
              <li pn="section-toc.1-1.4.2.1">
                <t indent="0" pn="section-toc.1-1.4.2.1.1"><xref derivedContent="4.1" format="counter" sectionFormat="of" target="section-4.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-general-discussion-2">General Discussion</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.2">
                <t indent="0" pn="section-toc.1-1.4.2.2.1"><xref derivedContent="4.2" format="counter" sectionFormat="of" target="section-4.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-general-security-implication">General Security Implications of IPv6 Options</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.3">
                <t indent="0" pn="section-toc.1-1.4.2.3.1"><xref derivedContent="4.3" format="counter" sectionFormat="of" target="section-4.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-summary-of-advice-on-the-hand">Summary of Advice on the Handling of IPv6 Packets with Specific IPv6 Options</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.4">
                <t indent="0" pn="section-toc.1-1.4.2.4.1"><xref derivedContent="4.4" format="counter" sectionFormat="of" target="section-4.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-advice-on-the-handling-of-pa">Advice on the Handling of Packets with Specific IPv6 Options</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.5">
                <t indent="0" pn="section-toc.1-1.4.2.5.1"><xref derivedContent="4.5" format="counter" sectionFormat="of" target="section-4.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-advice-on-the-handling-of-pac">Advice on the Handling of Packets with Unknown IPv6 Options</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-privacy-considerations">Privacy Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.8.2">
              <li pn="section-toc.1-1.8.2.1">
                <t indent="0" pn="section-toc.1-1.8.2.1.1"><xref derivedContent="8.1" format="counter" sectionFormat="of" target="section-8.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.8.2.2">
                <t indent="0" pn="section-toc.1-1.8.2.2.1"><xref derivedContent="8.2" format="counter" sectionFormat="of" target="section-8.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgements</xref></t>
          </li>
          <li pn="section-toc.1-1.10">
            <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section anchor="intro" numbered="true" toc="include" removeInRFC="false" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">IPv6 Extension Headers (EHs) allow for the extension of the IPv6
   protocol and provide support for core 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, as an example, enforcing Access Control Lists (ACLs) or implementing other functions <xref target="RFC9098" format="default" sectionFormat="of" derivedContent="RFC9098"/>.
</t>
      <t indent="0" pn="section-1-2">Several studies (e.g., <xref target="Huston-2022" format="default" sectionFormat="of" derivedContent="Huston-2022"/>, <xref target="I-D.vyncke-v6ops-james" format="default" sectionFormat="of" derivedContent="JAMES"/>, and <xref target="RFC7872" format="default" sectionFormat="of" derivedContent="RFC7872"/>) suggest that there is widespread dropping of IPv6 packets that contain IPv6 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 indent="0" pn="section-1-3">This document analyzes both the general security implications of
   IPv6 EHs, as well as the security implications of
   specific EH and 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 indent="0" pn="section-1-4">The resulting packet filtering policy typically depends on where in the network such policy is 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; hence, it is likely to be much more permissive than a filtering policy to be employed 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" format="default" sectionFormat="of" derivedContent="RFC7872"/> in such cases where packets are being dropped due to inappropriate or missing guidelines.</t>
      <t indent="0" pn="section-1-5">This document is similar in nature to
   <xref target="RFC7126" format="default" sectionFormat="of" derivedContent="RFC7126"/>, 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 and a number of IPv6 options that may be valid only when included in specific EH types.</t>
      <t indent="0" pn="section-1-6">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" format="default" sectionFormat="of" derivedContent="RFC6192"/>.</t>
      <t indent="0" pn="section-1-7"><xref target="terms" format="default" sectionFormat="of" derivedContent="Section 2"/> specifies the terminology and conventions employed throughout this document. <xref target="ipv6-extension-headers-discussion" format="default" sectionFormat="of" derivedContent="Section 3"/> discusses IPv6 EHs and provides advice in the area of filtering IPv6 packets that contain such IPv6 EHs. <xref target="ipv6-options-discussion" format="default" sectionFormat="of" derivedContent="Section 4"/> discusses IPv6 options and provides advice in the area of filtering IPv6 packets that contain such options.  
      </t>
    </section>
    <section anchor="terms" numbered="true" toc="include" removeInRFC="false" pn="section-2">
      <name slugifiedName="name-terminology-and-assumptions">Terminology and Assumptions Employed in This Document</name>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-2.1">
        <name slugifiedName="name-terminology">Terminology</name>
        <t indent="0" pn="section-2.1-1">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" format="default" sectionFormat="of" derivedContent="RFC3871"/>. Throughout this 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 a drop and whether the specific filtering action is logged.
</t>
        <t indent="0" pn="section-2.1-2">
    The key words "<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 "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> 
    when, and only when, they appear in all capitals, as shown here.
        </t>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-2.2">
        <name slugifiedName="name-applicability-statement">Applicability Statement</name>
        <t indent="0" pn="section-2.2-1">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 numbered="true" toc="include" removeInRFC="false" pn="section-2.3">
        <name slugifiedName="name-router-default-behavior-and">Router Default Behavior and Features</name>
        <t indent="0" pn="section-2.3-1">This document assumes that nodes comply with the requirements in <xref target="RFC7045" format="default" sectionFormat="of" derivedContent="RFC7045"/>. Namely,
        </t>
        <blockquote pn="section-2.3-2">If a forwarding node discards a packet containing a standard IPv6
   extension header, it <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 <bcp14>MUST</bcp14> be individually configurable.  The default configuration
   <bcp14>SHOULD</bcp14> allow all standard extension headers.</blockquote>
        <t indent="0" pn="section-2.3-3">

	  The advice provided in this document is only meant to guide an operator in configuring forwarding 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 but does not change the implementation defaults required by <xref target="RFC7045" format="default" sectionFormat="of" derivedContent="RFC7045"/>.

        
</t>
        <t indent="0" pn="section-2.3-4">We recommend that configuration options be made available to govern the processing of each IPv6 EH type and each IPv6 Option Type. Such configuration options should include the following possible settings:
        </t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-2.3-5">
          <li pn="section-2.3-5.1">Permit this IPv6 EH or IPv6 Option Type.</li>
          <li pn="section-2.3-5.2">Drop packets containing this IPv6 EH or IPv6 Option Type.</li>
          <li pn="section-2.3-5.3">Reject packets containing this IPv6 EH or IPv6 Option Type (where the packet drop is signaled with an ICMPv6 error message).</li>
          <li pn="section-2.3-5.4">Rate-limit traffic containing this IPv6 EH or IPv6 Option Type.</li>
          <li pn="section-2.3-5.5">Ignore this IPv6 EH or IPv6 Option Type (as if it was not 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 (RH)), this might be an inappropriate or undesirable action.</li>
        </ul>
        <t indent="0" pn="section-2.3-6">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 indent="0" pn="section-2.3-7">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), we generically refer to the action as "discard" without specifying whether the sender is signaled of the packet drop.</t>
      </section>
    </section>
    <section anchor="ipv6-extension-headers-discussion" numbered="true" toc="include" removeInRFC="false" pn="section-3">
      <name slugifiedName="name-ipv6-extension-headers">IPv6 Extension Headers</name>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-3.1">
        <name slugifiedName="name-general-discussion">General Discussion</name>
        <t indent="0" pn="section-3.1-1">IPv6 EHs <xref target="RFC8200" format="default" sectionFormat="of" derivedContent="RFC8200"/> 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" format="default" sectionFormat="of" derivedContent="RFC7045"/> 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" format="default" sectionFormat="of" derivedContent="RFC7045"/>) they contain.
        </t>
        <t indent="0" pn="section-3.1-2">
<xref target="RFC8200" format="default" sectionFormat="of" derivedContent="RFC8200"/> specifies that non-fragmented IPv6 datagrams and IPv6 First-Fragments must contain the entire IPv6 header chain <xref target="RFC7112" format="default" sectionFormat="of" derivedContent="RFC7112"/>. Therefore, intermediate systems can enforce the filtering policies discussed in this document or resort to simply discarding the offending packets when they fail to include the entire IPv6 header chain <xref target="RFC8200" format="default" sectionFormat="of" derivedContent="RFC8200"/>. </t>
        <t indent="0" pn="section-3.1-3">
We note 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, according to their own circumstances, how such packets
      will be handled.
</t>
      </section>
      <section anchor="ipv6-eh-general-implications" numbered="true" toc="include" removeInRFC="false" pn="section-3.2">
        <name slugifiedName="name-general-security-implicatio">General Security Implications</name>
        <t indent="0" pn="section-3.2-1">In some device architectures, IPv6 packets that contain IPv6 EHs can cause the corresponding packets to be processed on the slow path and, hence, may be leveraged for the purpose of Denial-of-Service (DoS) attacks <xref target="RFC9098" format="default" sectionFormat="of" derivedContent="RFC9098"/> <xref target="Cisco-EH" format="default" sectionFormat="of" derivedContent="Cisco-EH"/> <xref target="FW-Benchmark" format="default" sectionFormat="of" derivedContent="FW-Benchmark"/>.
</t>
        <t indent="0" pn="section-3.2-2">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 anchor="ipv6-ehs-rationale" numbered="true" toc="include" removeInRFC="false" pn="section-3.3">
        <name slugifiedName="name-rationale-for-our-advice-on">Rationale for Our Advice on the Handling of IPv6 Packets with Specific IPv6 Extension Headers</name>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3.3-1">
          <li pn="section-3.3-1.1">IPv6 packets with IPv6 Extension Headers (or options) that are not expected to traverse transit routers should be dropped.</li>
          <li pn="section-3.3-1.2">IPv6 packets with IPv6 Extension Headers (or options) that are only
    expected to traverse transit routers when a specific technology is
    employed should be permitted (or dropped) based on the knowledge
    regarding the use of such technology in the transit provider in question
    (i.e., permit the packets if the technology is employed, or drop them).
    </li>
          <li pn="section-3.3-1.3">IPv6 packets with IPv6 Extension Headers (or options) that represent
    a concrete attack vector to network infrastructure devices should be dropped.</li>
          <li pn="section-3.3-1.4">IPv6 packets with any other IPv6 Extension Headers (or options)
    should be permitted. This is an intentional  trade-off made to
    minimize ossification.</li>
        </ul>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-3.4">
        <name slugifiedName="name-summary-of-advice-on-the-ha">Summary of Advice on the Handling of IPv6 Packets with Specific IPv6 Extension Headers</name>
        <t indent="0" pn="section-3.4-1">This section summarizes the advice provided in <xref target="advice-ehs" format="default" sectionFormat="of" derivedContent="Section 3.5"/>, providing references to the specific sections in which a detailed analysis can be found.</t>
        <table anchor="eh-table" align="center" pn="table-1">
          <name slugifiedName="name-summary-of-advice-on-the-han">Summary of Advice on the Handling of IPv6 Packets with Specific IPv6 Extension Headers</name>
          <thead>
            <tr>
              <th align="center" colspan="1" rowspan="1">EH Type</th>
              <th align="center" colspan="1" rowspan="1">Filtering Policy</th>
              <th align="center" colspan="1" rowspan="1">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="center" colspan="1" rowspan="1">Hop-by-Hop Options Header (Proto=0)</td>
              <td align="center" colspan="1" rowspan="1">Drop or Ignore</td>
              <td align="center" colspan="1" rowspan="1">
                <xref target="proto0" format="default" sectionFormat="of" derivedContent="Section 3.5.1"/></td>
            </tr>
            <tr>
              <td align="center" colspan="1" rowspan="1">Routing Header (Proto=43)</td>
              <td align="center" colspan="1" rowspan="1">Drop only Routing Type 0, Routing Type 1, and Routing Type 3. Permit other Routing Types</td>
              <td align="center" colspan="1" rowspan="1">
                <xref target="proto43" format="default" sectionFormat="of" derivedContent="Section 3.5.2"/></td>
            </tr>
            <tr>
              <td align="center" colspan="1" rowspan="1">Fragment Header (Proto=44)</td>
              <td align="center" colspan="1" rowspan="1">Permit</td>
              <td align="center" colspan="1" rowspan="1">
                <xref target="proto44" format="default" sectionFormat="of" derivedContent="Section 3.5.3"/></td>
            </tr>
            <tr>
              <td align="center" colspan="1" rowspan="1">Encapsulating Security Payload (Proto=50)</td>
              <td align="center" colspan="1" rowspan="1">Permit</td>
              <td align="center" colspan="1" rowspan="1">
                <xref target="proto50" format="default" sectionFormat="of" derivedContent="Section 3.5.4"/></td>
            </tr>
            <tr>
              <td align="center" colspan="1" rowspan="1">Authentication Header (Proto=51)</td>
              <td align="center" colspan="1" rowspan="1">Permit</td>
              <td align="center" colspan="1" rowspan="1">
                <xref target="proto51" format="default" sectionFormat="of" derivedContent="Section 3.5.5"/></td>
            </tr>
            <tr>
              <td align="center" colspan="1" rowspan="1">Destination Options Header(Proto=60)</td>
              <td align="center" colspan="1" rowspan="1">Permit</td>
              <td align="center" colspan="1" rowspan="1">
                <xref target="proto60" format="default" sectionFormat="of" derivedContent="Section 3.5.6"/></td>
            </tr>
            <tr>
              <td align="center" colspan="1" rowspan="1">Mobility Header (Proto=135)</td>
              <td align="center" colspan="1" rowspan="1">Permit</td>
              <td align="center" colspan="1" rowspan="1">
                <xref target="proto135" format="default" sectionFormat="of" derivedContent="Section 3.5.7"/></td>
            </tr>
            <tr>
              <td align="center" colspan="1" rowspan="1">Host Identity Protocol (Proto=139)</td>
              <td align="center" colspan="1" rowspan="1">Permit</td>
              <td align="center" colspan="1" rowspan="1">
                <xref target="proto139" format="default" sectionFormat="of" derivedContent="Section 3.5.8"/></td>
            </tr>
            <tr>
              <td align="center" colspan="1" rowspan="1">Shim6 Protocol (Proto=140)</td>
              <td align="center" colspan="1" rowspan="1">Permit</td>
              <td align="center" colspan="1" rowspan="1">
                <xref target="proto140" format="default" sectionFormat="of" derivedContent="Section 3.5.9"/></td>
            </tr>
            <tr>
              <td align="center" colspan="1" rowspan="1">Use for experimentation and testing (Proto=253 and
         254)</td>
              <td align="center" colspan="1" rowspan="1">Drop</td>
              <td align="center" colspan="1" rowspan="1">
                <xref target="proto253254" format="default" sectionFormat="of" derivedContent="Section 3.5.10"/></td>
            </tr>
          </tbody>
        </table>
      </section>
      <section anchor="advice-ehs" numbered="true" toc="include" removeInRFC="false" pn="section-3.5">
        <name slugifiedName="name-advice-on-the-handling-of-i">Advice on the Handling of IPv6 Packets with Specific IPv6 Extension Headers</name>
        <section anchor="proto0" numbered="true" toc="exclude" removeInRFC="false" pn="section-3.5.1">
          <name slugifiedName="name-ipv6-hop-by-hop-options-pro">IPv6 Hop-by-Hop Options (Protocol Number=0)</name>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-3.5.1.1">
            <name slugifiedName="name-uses">Uses</name>
            <t indent="0" pn="section-3.5.1.1-1">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 pn="section-3.5.1.1-2">
              <t indent="0" pn="section-3.5.1.1-2.1">NOTE: A previous revision of the IPv6 core specification <xref target="RFC2460" format="default" sectionFormat="of" derivedContent="RFC2460"/> originally required all nodes to examine and process the Hop-by-Hop Options header. However, even before the publication of <xref target="RFC8200" format="default" sectionFormat="of" derivedContent="RFC8200"/>, a number of implementations already provided the option of ignoring this header unless explicitly configured to examine it.
</t>
            </aside>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-3.5.1.2">
            <name slugifiedName="name-specification">Specification</name>
            <t indent="0" pn="section-3.5.1.2-1">This EH is specified in <xref target="RFC8200" format="default" sectionFormat="of" derivedContent="RFC8200"/>. As of May 2022, the following options have been specified for the Hop-by-Hop Options header:
</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3.5.1.2-2">
              <li pn="section-3.5.1.2-2.1">Type 0x00: Pad1 <xref target="RFC8200" format="default" sectionFormat="of" derivedContent="RFC8200"/></li>
              <li pn="section-3.5.1.2-2.2">Type 0x01: PadN <xref target="RFC8200" format="default" sectionFormat="of" derivedContent="RFC8200"/></li>
              <li pn="section-3.5.1.2-2.3">Type 0x05: Router Alert <xref target="RFC2711" format="default" sectionFormat="of" derivedContent="RFC2711"/></li>
              <li pn="section-3.5.1.2-2.4">Type 0x07: CALIPSO <xref target="RFC5570" format="default" sectionFormat="of" derivedContent="RFC5570"/></li>
              <li pn="section-3.5.1.2-2.5">Type 0x08: SMF_DPD <xref target="RFC6621" format="default" sectionFormat="of" derivedContent="RFC6621"/></li>
              <li pn="section-3.5.1.2-2.6">Type 0x23: RPL Option <xref target="RFC9008" format="default" sectionFormat="of" derivedContent="RFC9008"/></li>
              <li pn="section-3.5.1.2-2.7">Type 0x26: Quick-Start <xref target="RFC4782" format="default" sectionFormat="of" derivedContent="RFC4782"/></li>
              <li pn="section-3.5.1.2-2.8">Type 0x4D: (Deprecated)</li>
              <li pn="section-3.5.1.2-2.9">Type 0x63: RPL Option <xref target="RFC6553" format="default" sectionFormat="of" derivedContent="RFC6553"/></li>
              <li pn="section-3.5.1.2-2.10">Type 0x6D: MPL Option <xref target="RFC7731" format="default" sectionFormat="of" derivedContent="RFC7731"/></li>
              <li pn="section-3.5.1.2-2.11">Type 0x8A: Endpoint Identification (Deprecated) <xref target="NIMROD-EID" format="default" sectionFormat="of" derivedContent="NIMROD-EID"/></li>
              <li pn="section-3.5.1.2-2.12">Type 0xC2: Jumbo Payload <xref target="RFC2675" format="default" sectionFormat="of" derivedContent="RFC2675"/></li>
              <li pn="section-3.5.1.2-2.13">Type 0xEE: IPv6 DFF Header <xref target="RFC6971" format="default" sectionFormat="of" derivedContent="RFC6971"/></li>
              <li pn="section-3.5.1.2-2.14">Type 0x1E: RFC3692-style Experiment <xref target="RFC4727" format="default" sectionFormat="of" derivedContent="RFC4727"/></li>
              <li pn="section-3.5.1.2-2.15">Type 0x3E: RFC3692-style Experiment <xref target="RFC4727" format="default" sectionFormat="of" derivedContent="RFC4727"/></li>
              <li pn="section-3.5.1.2-2.16">Type 0x5E: RFC3692-style Experiment <xref target="RFC4727" format="default" sectionFormat="of" derivedContent="RFC4727"/></li>
              <li pn="section-3.5.1.2-2.17">Type 0x7E: RFC3692-style Experiment <xref target="RFC4727" format="default" sectionFormat="of" derivedContent="RFC4727"/></li>
              <li pn="section-3.5.1.2-2.18">Type 0x9E: RFC3692-style Experiment <xref target="RFC4727" format="default" sectionFormat="of" derivedContent="RFC4727"/></li>
              <li pn="section-3.5.1.2-2.19">Type 0xBE: RFC3692-style Experiment <xref target="RFC4727" format="default" sectionFormat="of" derivedContent="RFC4727"/></li>
              <li pn="section-3.5.1.2-2.20">Type 0xDE: RFC3692-style Experiment <xref target="RFC4727" format="default" sectionFormat="of" derivedContent="RFC4727"/></li>
              <li pn="section-3.5.1.2-2.21">Type 0xFE: RFC3692-style Experiment <xref target="RFC4727" format="default" sectionFormat="of" derivedContent="RFC4727"/></li>
            </ul>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-3.5.1.3">
            <name slugifiedName="name-specific-security-implicati">Specific Security Implications</name>
            <t indent="0" pn="section-3.5.1.3-1">Legacy nodes that process this extension header might be subject to DoS attacks.</t>
            <aside pn="section-3.5.1.3-2">
              <t indent="0" pn="section-3.5.1.3-2.1">NOTE: While <xref target="RFC8200" format="default" sectionFormat="of" derivedContent="RFC8200"/> has removed the requirement for all nodes to examine and process the Hop-by-Hop Options header, the deployed base may still reflect the legacy <xref target="RFC2460" format="default" sectionFormat="of" derivedContent="RFC2460"/> behavior for a while; hence, the potential security problems of this EH are still of concern.
</t>
            </aside>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-3.5.1.4">
            <name slugifiedName="name-operational-and-interoperab">Operational and Interoperability Impact If Blocked</name>
            <t indent="0" pn="section-3.5.1.4-1">Discarding packets containing a Hop-by-Hop Options header would break any of the protocols that rely on it for proper functioning. For example, it would break RSVP <xref target="RFC2205" format="default" sectionFormat="of" derivedContent="RFC2205"/> and multicast deployments and would cause IPv6 jumbograms to be discarded.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-3.5.1.5">
            <name slugifiedName="name-advice">Advice</name>
            <t indent="0" pn="section-3.5.1.5-1">Nodes implementing <xref target="RFC8200" format="default" sectionFormat="of" derivedContent="RFC8200"/> would already ignore this extension header unless explicitly required to process it. For legacy nodes <xref target="RFC2460" format="default" sectionFormat="of" derivedContent="RFC2460"/>, 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 IPv6 HBH Options headers be forwarded as normal. Otherwise, on platforms in which the processing of packets with IPv6 HBH Options headers is carried out in the slow path and an option is provided to rate-limit these packets, we recommend that this option be selected. Finally, when packets containing IPv6 HBH Options headers are processed in the 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 headers.</t>
            <t indent="0" pn="section-3.5.1.5-2">Finally, we note that the Routing Protocol for Low-Power and Lossy Networks (RPL) routers <xref target="RFC6550" format="default" sectionFormat="of" derivedContent="RFC6550"/>  must not discard packets based on the presence of an IPv6 Hop-by-Hop Options header, as this would break the RPL.</t>
          </section>
        </section>
        <section anchor="proto43" numbered="true" toc="exclude" removeInRFC="false" pn="section-3.5.2">
          <name slugifiedName="name-routing-header-protocol-num">Routing Header (Protocol Number=43)</name>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-3.5.2.1">
            <name slugifiedName="name-uses-2">Uses</name>
            <t indent="0" pn="section-3.5.2.1-1">The Routing 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 numbered="true" toc="exclude" removeInRFC="false" pn="section-3.5.2.2">
            <name slugifiedName="name-specification-2">Specification</name>
            <t indent="0" pn="section-3.5.2.2-1">This EH is specified in <xref target="RFC8200" format="default" sectionFormat="of" derivedContent="RFC8200"/>. The Routing Type 0 had originally been specified in <xref target="RFC2460" format="default" sectionFormat="of" derivedContent="RFC2460"/> and was later obsoleted by <xref target="RFC5095" format="default" sectionFormat="of" derivedContent="RFC5095"/>; thus, it was removed from <xref target="RFC8200" format="default" sectionFormat="of" derivedContent="RFC8200"/>.</t>
            <t indent="0" pn="section-3.5.2.2-2">As of May 2022, the following Routing Types have been specified:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3.5.2.2-3">
              <li pn="section-3.5.2.2-3.1">Type 0: Source Route (DEPRECATED) <xref target="RFC2460" format="default" sectionFormat="of" derivedContent="RFC2460"/> <xref target="RFC5095" format="default" sectionFormat="of" derivedContent="RFC5095"/></li>
              <li pn="section-3.5.2.2-3.2">Type 1: Nimrod (DEPRECATED)</li>
              <li pn="section-3.5.2.2-3.3">Type 2: Type 2 Routing Header <xref target="RFC6275" format="default" sectionFormat="of" derivedContent="RFC6275"/></li>
              <li pn="section-3.5.2.2-3.4">Type 3: RPL Source Route Header <xref target="RFC6554" format="default" sectionFormat="of" derivedContent="RFC6554"/></li>
              <li pn="section-3.5.2.2-3.5">Type 4: Segment Routing Header (SRH) <xref target="RFC8754" format="default" sectionFormat="of" derivedContent="RFC8754"/></li>
              <li pn="section-3.5.2.2-3.6">Types 5-252: Unassigned</li>
              <li pn="section-3.5.2.2-3.7">Type 253: RFC3692-style Experiment 1 <xref target="RFC4727" format="default" sectionFormat="of" derivedContent="RFC4727"/></li>
              <li pn="section-3.5.2.2-3.8">Type 254: RFC3692-style Experiment 2 <xref target="RFC4727" format="default" sectionFormat="of" derivedContent="RFC4727"/></li>
              <li pn="section-3.5.2.2-3.9">Type 255: Reserved</li>
            </ul>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-3.5.2.3">
            <name slugifiedName="name-specific-security-implicatio">Specific Security Implications</name>
            <t indent="0" pn="section-3.5.2.3-1">The security implications of Routing Headers of Routing Type 0 have been discussed in detail in <xref target="Biondi-2007" format="default" sectionFormat="of" derivedContent="Biondi-2007"/> and <xref target="RFC5095" format="default" sectionFormat="of" derivedContent="RFC5095"/>. Routing Type 1 was never widely implemented. The security implications of Routing Headers of Routing Type 2, Routing Type 3, and Routing Type 4 (SRH) are discussed in <xref target="RFC6275" format="default" sectionFormat="of" derivedContent="RFC6275"/>,  <xref target="RFC6554" format="default" sectionFormat="of" derivedContent="RFC6554"/>, and <xref target="RFC8754" format="default" sectionFormat="of" derivedContent="RFC8754"/>, respectively.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-3.5.2.4">
            <name slugifiedName="name-operational-and-interoperabi">Operational and Interoperability Impact If Blocked</name>
            <t indent="0" pn="section-3.5.2.4-1">Blocking packets containing Routing Headers of Routing Type 0 or Routing Type 1 has no operational implications, since both have been deprecated. Blocking packets containing Routing Headers of Routing Type 2 would break Mobile IPv6. Packets containing Routing Headers of Routing Type 3 may be safely blocked at RPL domain boundaries, since such headers are employed within a single RPL domain. Blocking packets containing Routing Headers of Routing Type 4 (SRH) will break Segment Routing (SR) deployments if the filtering policy is enforced on packets being forwarded within an SR domain.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-3.5.2.5">
            <name slugifiedName="name-advice-2">Advice</name>
            <t indent="0" pn="section-3.5.2.5-1">Intermediate systems should discard packets containing Routing Headers of Routing Type 0, Routing Type 1, or Routing Type 3. Other Routing Types should be permitted, as required by <xref target="RFC7045" format="default" sectionFormat="of" derivedContent="RFC7045"/>.</t>
          </section>
        </section>
        <section anchor="proto44" numbered="true" toc="exclude" removeInRFC="false" pn="section-3.5.3">
          <name slugifiedName="name-fragment-header-protocol-nu">Fragment Header (Protocol Number=44)</name>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-3.5.3.1">
            <name slugifiedName="name-uses-3">Uses</name>
            <t indent="0" pn="section-3.5.3.1-1">This EH provides the fragmentation and reassembly functionality for IPv6.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-3.5.3.2">
            <name slugifiedName="name-specification-3">Specification</name>
            <t indent="0" pn="section-3.5.3.2-1">This EH is specified in <xref target="RFC8200" format="default" sectionFormat="of" derivedContent="RFC8200"/>.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-3.5.3.3">
            <name slugifiedName="name-specific-security-implication">Specific Security Implications</name>
            <t indent="0" pn="section-3.5.3.3-1">The security implications of the Fragment Header range from DoS attacks (e.g., based on flooding a target with IPv6 fragments) to information leakage attacks <xref target="RFC7739" format="default" sectionFormat="of" derivedContent="RFC7739"/>.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-3.5.3.4">
            <name slugifiedName="name-operational-and-interoperabil">Operational and Interoperability Impact If Blocked</name>
            <t indent="0" pn="section-3.5.3.4-1">Blocking packets that contain a Fragment Header will break any protocol that may rely on fragmentation (e.g., the DNS <xref target="RFC1034" format="default" sectionFormat="of" derivedContent="RFC1034"/>). However, IP fragmentation is known to introduce fragility to Internet communication <xref target="RFC8900" format="default" sectionFormat="of" derivedContent="RFC8900"/>.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-3.5.3.5">
            <name slugifiedName="name-advice-3">Advice</name>
            <t indent="0" pn="section-3.5.3.5-1">Intermediate systems should permit packets that contain a Fragment Header.</t>
          </section>
        </section>
        <section anchor="proto50" numbered="true" toc="exclude" removeInRFC="false" pn="section-3.5.4">
          <name slugifiedName="name-encapsulating-security-payl">Encapsulating Security Payload (Protocol Number=50)</name>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-3.5.4.1">
            <name slugifiedName="name-uses-4">Uses</name>
            <t indent="0" pn="section-3.5.4.1-1">This EH is employed for the IPsec suite <xref target="RFC4303" format="default" sectionFormat="of" derivedContent="RFC4303"/>.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-3.5.4.2">
            <name slugifiedName="name-specification-4">Specification</name>
            <t indent="0" pn="section-3.5.4.2-1">This EH is specified in <xref target="RFC4303" format="default" sectionFormat="of" derivedContent="RFC4303"/>.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-3.5.4.3">
            <name slugifiedName="name-specific-security-implications">Specific Security Implications</name>
            <t indent="0" pn="section-3.5.4.3-1">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 numbered="true" toc="exclude" removeInRFC="false" pn="section-3.5.4.4">
            <name slugifiedName="name-operational-and-interoperabili">Operational and Interoperability Impact If Blocked</name>
            <t indent="0" pn="section-3.5.4.4-1">Discarding packets that employ this EH would break IPsec deployments.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-3.5.4.5">
            <name slugifiedName="name-advice-4">Advice</name>
            <t indent="0" pn="section-3.5.4.5-1">Intermediate systems should permit packets containing the Encapsulating Security Payload EH.</t>
          </section>
        </section>
        <section anchor="proto51" numbered="true" toc="exclude" removeInRFC="false" pn="section-3.5.5">
          <name slugifiedName="name-authentication-header-proto">Authentication Header (Protocol Number=51)</name>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-3.5.5.1">
            <name slugifiedName="name-uses-5">Uses</name>
            <t indent="0" pn="section-3.5.5.1-1">The Authentication Header can be employed to provide authentication services in
   IPv4 and IPv6.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-3.5.5.2">
            <name slugifiedName="name-specification-5">Specification</name>
            <t indent="0" pn="section-3.5.5.2-1">This EH is specified in <xref target="RFC4302" format="default" sectionFormat="of" derivedContent="RFC4302"/>.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-3.5.5.3">
            <name slugifiedName="name-specific-security-implications-2">Specific Security Implications</name>
            <t indent="0" pn="section-3.5.5.3-1">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 numbered="true" toc="exclude" removeInRFC="false" pn="section-3.5.5.4">
            <name slugifiedName="name-operational-and-interoperabilit">Operational and Interoperability Impact If Blocked</name>
            <t indent="0" pn="section-3.5.5.4-1">Discarding packets that employ this EH would break IPsec deployments.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-3.5.5.5">
            <name slugifiedName="name-advice-5">Advice</name>
            <t indent="0" pn="section-3.5.5.5-1">Intermediate systems should permit packets containing an Authentication Header.</t>
          </section>
        </section>
        <section anchor="proto60" numbered="true" toc="exclude" removeInRFC="false" pn="section-3.5.6">
          <name slugifiedName="name-destination-options-protoco">Destination Options (Protocol Number=60)</name>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-3.5.6.1">
            <name slugifiedName="name-uses-6">Uses</name>
            <t indent="0" pn="section-3.5.6.1-1">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 numbered="true" toc="exclude" removeInRFC="false" pn="section-3.5.6.2">
            <name slugifiedName="name-specification-6">Specification</name>
            <t indent="0" pn="section-3.5.6.2-1">This EH is specified in <xref target="RFC8200" format="default" sectionFormat="of" derivedContent="RFC8200"/>. As of May 2022, the following options have been specified for this EH:
</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3.5.6.2-2">
              <li pn="section-3.5.6.2-2.1">Type 0x00: Pad1 <xref target="RFC8200" format="default" sectionFormat="of" derivedContent="RFC8200"/></li>
              <li pn="section-3.5.6.2-2.2">Type 0x01: PadN <xref target="RFC8200" format="default" sectionFormat="of" derivedContent="RFC8200"/></li>
              <li pn="section-3.5.6.2-2.3">Type 0x04: Tunnel Encapsulation Limit <xref target="RFC2473" format="default" sectionFormat="of" derivedContent="RFC2473"/></li>
              <li pn="section-3.5.6.2-2.4">Type 0x0F: IPv6 Performance and Diagnostic Metrics (PDM) <xref target="RFC8250" format="default" sectionFormat="of" derivedContent="RFC8250"/></li>
              <li pn="section-3.5.6.2-2.5">Type 0x4D: (Deprecated)</li>
              <li pn="section-3.5.6.2-2.6">Type 0xC9: Home Address <xref target="RFC6275" format="default" sectionFormat="of" derivedContent="RFC6275"/></li>
              <li pn="section-3.5.6.2-2.7">Type 0x8A: Endpoint Identification (Deprecated) <xref target="NIMROD-EID" format="default" sectionFormat="of" derivedContent="NIMROD-EID"/></li>
              <li pn="section-3.5.6.2-2.8">Type 0x8B: ILNP Nonce <xref target="RFC6744" format="default" sectionFormat="of" derivedContent="RFC6744"/></li>
              <li pn="section-3.5.6.2-2.9">Type 0x8C: Line-Identification Option <xref target="RFC6788" format="default" sectionFormat="of" derivedContent="RFC6788"/></li>
              <li pn="section-3.5.6.2-2.10">Type 0x1E: RFC3692-style Experiment <xref target="RFC4727" format="default" sectionFormat="of" derivedContent="RFC4727"/></li>
              <li pn="section-3.5.6.2-2.11">Type 0x3E: RFC3692-style Experiment <xref target="RFC4727" format="default" sectionFormat="of" derivedContent="RFC4727"/></li>
              <li pn="section-3.5.6.2-2.12">Type 0x5E: RFC3692-style Experiment <xref target="RFC4727" format="default" sectionFormat="of" derivedContent="RFC4727"/></li>
              <li pn="section-3.5.6.2-2.13">Type 0x7E: RFC3692-style Experiment <xref target="RFC4727" format="default" sectionFormat="of" derivedContent="RFC4727"/></li>
              <li pn="section-3.5.6.2-2.14">Type 0x9E: RFC3692-style Experiment <xref target="RFC4727" format="default" sectionFormat="of" derivedContent="RFC4727"/></li>
              <li pn="section-3.5.6.2-2.15">Type 0xBE: RFC3692-style Experiment <xref target="RFC4727" format="default" sectionFormat="of" derivedContent="RFC4727"/></li>
              <li pn="section-3.5.6.2-2.16">Type 0xDE: RFC3692-style Experiment <xref target="RFC4727" format="default" sectionFormat="of" derivedContent="RFC4727"/></li>
              <li pn="section-3.5.6.2-2.17">Type 0xFE: RFC3692-style Experiment <xref target="RFC4727" format="default" sectionFormat="of" derivedContent="RFC4727"/></li>
            </ul>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-3.5.6.3">
            <name slugifiedName="name-specific-security-implications-3">Specific Security Implications</name>
            <t indent="0" pn="section-3.5.6.3-1">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 <xref target="opt-filtering" format="default" sectionFormat="of" derivedContent="Section 4.4"/>.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-3.5.6.4">
            <name slugifiedName="name-operational-and-interoperability">Operational and Interoperability Impact If Blocked</name>
            <t indent="0" pn="section-3.5.6.4-1">Discarding packets that contain a Destination Options header would break protocols that rely on this EH type for conveying information (such as the Identifier-Locator Network Protocol (ILNP) <xref target="RFC6740" format="default" sectionFormat="of" derivedContent="RFC6740"/> and Mobile IPv6 <xref target="RFC6275" format="default" sectionFormat="of" derivedContent="RFC6275"/>), as well as IPv6 tunnels that employ the Tunnel Encapsulation Limit option <xref target="RFC2473" format="default" sectionFormat="of" derivedContent="RFC2473"/>.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-3.5.6.5">
            <name slugifiedName="name-advice-6">Advice</name>
            <t indent="0" pn="section-3.5.6.5-1">Intermediate systems should permit packets that contain a Destination Options header.</t>
          </section>
        </section>
        <section anchor="proto135" numbered="true" toc="exclude" removeInRFC="false" pn="section-3.5.7">
          <name slugifiedName="name-mobility-header-protocol-nu">Mobility Header (Protocol Number=135)</name>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-3.5.7.1">
            <name slugifiedName="name-uses-7">Uses</name>
            <t indent="0" pn="section-3.5.7.1-1">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 numbered="true" toc="exclude" removeInRFC="false" pn="section-3.5.7.2">
            <name slugifiedName="name-specification-7">Specification</name>
            <t indent="0" pn="section-3.5.7.2-1">This EH is specified in <xref target="RFC6275" format="default" sectionFormat="of" derivedContent="RFC6275"/>.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-3.5.7.3">
            <name slugifiedName="name-specific-security-implications-4">Specific Security Implications</name>
            <t indent="0" pn="section-3.5.7.3-1">A thorough security assessment of the security implications of the Mobility Header and related mechanisms can be found in <xref target="RFC6275" sectionFormat="of" section="15" format="default" derivedLink="https://rfc-editor.org/rfc/rfc6275#section-15" derivedContent="RFC6275"/>.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-3.5.7.4">
            <name slugifiedName="name-operational-and-interoperability-">Operational and Interoperability Impact If Blocked</name>
            <t indent="0" pn="section-3.5.7.4-1">Discarding packets containing this EH would break Mobile IPv6.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-3.5.7.5">
            <name slugifiedName="name-advice-7">Advice</name>
            <t indent="0" pn="section-3.5.7.5-1">Intermediate systems should permit packets that contain a Mobility Header.</t>
          </section>
        </section>
        <section anchor="proto139" numbered="true" toc="exclude" removeInRFC="false" pn="section-3.5.8">
          <name slugifiedName="name-host-identity-protocol-prot">Host Identity Protocol (Protocol Number=139)</name>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-3.5.8.1">
            <name slugifiedName="name-uses-8">Uses</name>
            <t indent="0" pn="section-3.5.8.1-1">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 numbered="true" toc="exclude" removeInRFC="false" pn="section-3.5.8.2">
            <name slugifiedName="name-specification-8">Specification</name>
            <t indent="0" pn="section-3.5.8.2-1">This EH is specified in <xref target="RFC7401" format="default" sectionFormat="of" derivedContent="RFC7401"/>.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-3.5.8.3">
            <name slugifiedName="name-specific-security-implications-5">Specific Security Implications</name>
            <t indent="0" pn="section-3.5.8.3-1">The security implications of the HIP header are discussed in detail in <xref target="RFC7401" sectionFormat="of" section="8" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7401#section-8" derivedContent="RFC7401"/>.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-3.5.8.4">
            <name slugifiedName="name-operational-and-interoperability-i">Operational and Interoperability Impact If Blocked</name>
            <t indent="0" pn="section-3.5.8.4-1">Discarding packets that contain a HIP header would break HIP deployments.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-3.5.8.5">
            <name slugifiedName="name-advice-8">Advice</name>
            <t indent="0" pn="section-3.5.8.5-1">Intermediate systems should permit packets that contain a HIP header.</t>
          </section>
        </section>
        <section anchor="proto140" numbered="true" toc="exclude" removeInRFC="false" pn="section-3.5.9">
          <name slugifiedName="name-shim6-protocol-protocol-num">Shim6 Protocol (Protocol Number=140)</name>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-3.5.9.1">
            <name slugifiedName="name-uses-9">Uses</name>
            <t indent="0" pn="section-3.5.9.1-1">This EH is employed by the Shim6 protocol <xref target="RFC5533" format="default" sectionFormat="of" derivedContent="RFC5533"/>.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-3.5.9.2">
            <name slugifiedName="name-specification-9">Specification</name>
            <t indent="0" pn="section-3.5.9.2-1">This EH is specified in <xref target="RFC5533" format="default" sectionFormat="of" derivedContent="RFC5533"/>.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-3.5.9.3">
            <name slugifiedName="name-specific-security-implications-6">Specific Security Implications</name>
            <t indent="0" pn="section-3.5.9.3-1">The specific security implications are discussed in detail in <xref target="RFC5533" sectionFormat="of" section="16" format="default" derivedLink="https://rfc-editor.org/rfc/rfc5533#section-16" derivedContent="RFC5533"/>.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-3.5.9.4">
            <name slugifiedName="name-operational-and-interoperability-im">Operational and Interoperability Impact If Blocked</name>
            <t indent="0" pn="section-3.5.9.4-1">Discarding packets that contain this EH will break Shim6.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-3.5.9.5">
            <name slugifiedName="name-advice-9">Advice</name>
            <t indent="0" pn="section-3.5.9.5-1">Intermediate systems should permit packets containing this EH.</t>
          </section>
        </section>
        <section anchor="proto253254" numbered="true" toc="exclude" removeInRFC="false" pn="section-3.5.10">
          <name slugifiedName="name-use-for-experimentation-and">Use for Experimentation and Testing (Protocol Numbers=253 and 254)</name>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-3.5.10.1">
            <name slugifiedName="name-uses-10">Uses</name>
            <t indent="0" pn="section-3.5.10.1-1">These IPv6 EHs are employed for performing RFC3692-style experiments (see <xref target="RFC3692" format="default" sectionFormat="of" derivedContent="RFC3692"/> for details).</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-3.5.10.2">
            <name slugifiedName="name-specification-10">Specification</name>
            <t indent="0" pn="section-3.5.10.2-1">These EHs are specified in <xref target="RFC3692" format="default" sectionFormat="of" derivedContent="RFC3692"/> and <xref target="RFC4727" format="default" sectionFormat="of" derivedContent="RFC4727"/>.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-3.5.10.3">
            <name slugifiedName="name-specific-security-implications-7">Specific Security Implications</name>
            <t indent="0" pn="section-3.5.10.3-1">The security implications of these EHs will depend on their specific use.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-3.5.10.4">
            <name slugifiedName="name-operational-and-interoperability-im-2">Operational and Interoperability Impact If Blocked</name>
            <t indent="0" pn="section-3.5.10.4-1">For obvious reasons, discarding packets that contain these EHs limits the ability to perform legitimate experiments across IPv6 routers.
</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-3.5.10.5">
            <name slugifiedName="name-advice-10">Advice</name>
            <t indent="0" pn="section-3.5.10.5-1">Operators should determine, according to their own circumstances, whether to discard packets containing these EHs.</t>
          </section>
        </section>
      </section>
      <section anchor="unknown-headers" numbered="true" toc="include" removeInRFC="false" pn="section-3.6">
        <name slugifiedName="name-advice-on-the-handling-of-p">Advice on the Handling of Packets with Unknown IPv6 Extension Headers</name>
        <t indent="0" pn="section-3.6-1">We refer to IPv6 EHs that have not been assigned an Internet Protocol number by IANA (and marked as such) in <xref target="IANA-PROTOCOLS" format="default" sectionFormat="of" derivedContent="IANA-PROTOCOLS"/> as "unknown IPv6 Extension Headers" ("unknown IPv6 EHs").
</t>
        <section numbered="true" toc="exclude" removeInRFC="false" pn="section-3.6.1">
          <name slugifiedName="name-uses-11">Uses</name>
          <t indent="0" pn="section-3.6.1-1">New IPv6 EHs may be specified as part of future extensions to the IPv6 protocol.
</t>
          <t indent="0" pn="section-3.6.1-2">Since IPv6 EHs and upper-layer protocols employ the same namespace, it is impossible to tell whether an unknown Internet Protocol number is being employed for an IPv6 EH or an upper-layer protocol.
</t>
        </section>
        <section numbered="true" toc="exclude" removeInRFC="false" pn="section-3.6.2">
          <name slugifiedName="name-specification-11">Specification</name>
          <t indent="0" pn="section-3.6.2-1">The processing of unknown IPv6 EHs is specified in <xref target="RFC7045" format="default" sectionFormat="of" derivedContent="RFC7045"/>.</t>
        </section>
        <section numbered="true" toc="exclude" removeInRFC="false" pn="section-3.6.3">
          <name slugifiedName="name-specific-security-implications-8">Specific Security Implications</name>
          <t indent="0" pn="section-3.6.3-1">For obvious reasons, it is impossible to determine specific security implications of unknown IPv6 EHs.</t>
        </section>
        <section numbered="true" toc="exclude" removeInRFC="false" pn="section-3.6.4">
          <name slugifiedName="name-operational-and-interoperability-im-3">Operational and Interoperability Impact If Blocked</name>
          <t indent="0" pn="section-3.6.4-1">As noted in <xref target="RFC7045" format="default" sectionFormat="of" derivedContent="RFC7045"/>, discarding unknown IPv6 EHs may slow down the deployment of new IPv6 EHs and transport protocols. The corresponding IANA registry, which is <xref target="IANA-PROTOCOLS" format="default" sectionFormat="of" derivedContent="IANA-PROTOCOLS"/>, should be monitored such that filtering rules are updated as new IPv6 EHs are standardized.</t>
          <t indent="0" pn="section-3.6.4-2">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 numbered="true" toc="exclude" removeInRFC="false" pn="section-3.6.5">
          <name slugifiedName="name-advice-11">Advice</name>
          <t indent="0" pn="section-3.6.5-1">Operators should determine, according to their own circumstances, whether to discard packets containing unknown IPv6 EHs.</t>
        </section>
      </section>
    </section>
    <section anchor="ipv6-options-discussion" numbered="true" toc="include" removeInRFC="false" pn="section-4">
      <name slugifiedName="name-ipv6-options">IPv6 Options</name>
      <section anchor="ipv6-options-general-discussion" numbered="true" toc="include" removeInRFC="false" pn="section-4.1">
        <name slugifiedName="name-general-discussion-2">General Discussion</name>
        <t indent="0" pn="section-4.1-1">The following subsections describe specific security implications of different IPv6 options and provide advice regarding filtering packets that contain such options.
</t>
      </section>
      <section anchor="ipv6-options-general-implications" numbered="true" toc="include" removeInRFC="false" pn="section-4.2">
        <name slugifiedName="name-general-security-implication">General Security Implications of IPv6 Options</name>
        <t indent="0" pn="section-4.2-1">The general security implications of IPv6 options are closely related to those discussed in <xref target="ipv6-eh-general-implications" format="default" sectionFormat="of" derivedContent="Section 3.2"/> for IPv6 EHs. Essentially, packets that contain IPv6 options might need to be processed by an IPv6 router's general-purpose CPU and, hence, could present a 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., <xref target="Cisco-EH" format="default" sectionFormat="of" derivedContent="Cisco-EH"/>).</t>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-4.3">
        <name slugifiedName="name-summary-of-advice-on-the-hand">Summary of Advice on the Handling of IPv6 Packets with Specific IPv6 Options</name>
        <t indent="0" pn="section-4.3-1">This section summarizes the advice provided in <xref target="opt-filtering" format="default" sectionFormat="of" derivedContent="Section 4.4"/>, and it includes references to the specific sections in which a detailed analysis can be found.</t>
        <table anchor="option-table" align="center" pn="table-2">
          <name slugifiedName="name-summary-of-advice-on-the-handl">Summary of Advice on the Handling of IPv6 Packets with Specific IPv6 Options</name>
          <thead>
            <tr>
              <th align="center" colspan="1" rowspan="1">Option</th>
              <th align="center" colspan="1" rowspan="1">Filtering Policy</th>
              <th align="center" colspan="1" rowspan="1">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="center" colspan="1" rowspan="1">Pad1 (Type=0x00)</td>
              <td align="center" colspan="1" rowspan="1">Permit</td>
              <td align="center" colspan="1" rowspan="1">
                <xref target="x00" format="default" sectionFormat="of" derivedContent="Section 4.4.1"/></td>
            </tr>
            <tr>
              <td align="center" colspan="1" rowspan="1">PadN (Type=0x01)</td>
              <td align="center" colspan="1" rowspan="1">Permit</td>
              <td align="center" colspan="1" rowspan="1">
                <xref target="x01" format="default" sectionFormat="of" derivedContent="Section 4.4.2"/></td>
            </tr>
            <tr>
              <td align="center" colspan="1" rowspan="1">Tunnel Encapsulation Limit (Type=0x04)</td>
              <td align="center" colspan="1" rowspan="1">Permit</td>
              <td align="center" colspan="1" rowspan="1">
                <xref target="x04" format="default" sectionFormat="of" derivedContent="Section 4.4.3"/></td>
            </tr>
            <tr>
              <td align="center" colspan="1" rowspan="1">Router Alert (Type=0x05)</td>
              <td align="center" colspan="1" rowspan="1">Permit based on needed functionality</td>
              <td align="center" colspan="1" rowspan="1">
                <xref target="x05" format="default" sectionFormat="of" derivedContent="Section 4.4.4"/></td>
            </tr>
            <tr>
              <td align="center" colspan="1" rowspan="1">CALIPSO (Type=0x07)</td>
              <td align="center" colspan="1" rowspan="1">Permit based on needed functionality</td>
              <td align="center" colspan="1" rowspan="1">
                <xref target="x07" format="default" sectionFormat="of" derivedContent="Section 4.4.5"/></td>
            </tr>
            <tr>
              <td align="center" colspan="1" rowspan="1">SMF_DPD (Type=0x08)</td>
              <td align="center" colspan="1" rowspan="1">Permit based on needed functionality</td>
              <td align="center" colspan="1" rowspan="1">
                <xref target="x08" format="default" sectionFormat="of" derivedContent="Section 4.4.6"/></td>
            </tr>
            <tr>
              <td align="center" colspan="1" rowspan="1">PDM Option (Type=0x0F)</td>
              <td align="center" colspan="1" rowspan="1">Permit</td>
              <td align="center" colspan="1" rowspan="1">
                <xref target="x0F" format="default" sectionFormat="of" derivedContent="Section 4.4.7"/></td>
            </tr>
            <tr>
              <td align="center" colspan="1" rowspan="1">RPL Option (Type=0x23)</td>
              <td align="center" colspan="1" rowspan="1">Permit</td>
              <td align="center" colspan="1" rowspan="1">
                <xref target="x23" format="default" sectionFormat="of" derivedContent="Section 4.4.8"/></td>
            </tr>
            <tr>
              <td align="center" colspan="1" rowspan="1">Quick-Start (Type=0x26)</td>
              <td align="center" colspan="1" rowspan="1">Permit</td>
              <td align="center" colspan="1" rowspan="1">
                <xref target="x26" format="default" sectionFormat="of" derivedContent="Section 4.4.9"/></td>
            </tr>
            <tr>
              <td align="center" colspan="1" rowspan="1">Deprecated (Type=0x4D)</td>
              <td align="center" colspan="1" rowspan="1">Drop</td>
              <td align="center" colspan="1" rowspan="1">
                <xref target="x4D" format="default" sectionFormat="of" derivedContent="Section 4.4.10"/></td>
            </tr>
            <tr>
              <td align="center" colspan="1" rowspan="1">MPL Option (Type=0x6D)</td>
              <td align="center" colspan="1" rowspan="1">Permit</td>
              <td align="center" colspan="1" rowspan="1">
                <xref target="x6D" format="default" sectionFormat="of" derivedContent="Section 4.4.12"/></td>
            </tr>
            <tr>
              <td align="center" colspan="1" rowspan="1">Jumbo Payload (Type=0xC2)</td>
              <td align="center" colspan="1" rowspan="1">Permit based on needed functionality</td>
              <td align="center" colspan="1" rowspan="1">
                <xref target="xC2" format="default" sectionFormat="of" derivedContent="Section 4.4.16"/></td>
            </tr>
            <tr>
              <td align="center" colspan="1" rowspan="1">RPL Option (Type=0x63)</td>
              <td align="center" colspan="1" rowspan="1">Drop</td>
              <td align="center" colspan="1" rowspan="1">
                <xref target="x63" format="default" sectionFormat="of" derivedContent="Section 4.4.11"/></td>
            </tr>
            <tr>
              <td align="center" colspan="1" rowspan="1">Endpoint Identification (Type=0x8A)</td>
              <td align="center" colspan="1" rowspan="1">Drop</td>
              <td align="center" colspan="1" rowspan="1">
                <xref target="x8A" format="default" sectionFormat="of" derivedContent="Section 4.4.13"/></td>
            </tr>
            <tr>
              <td align="center" colspan="1" rowspan="1">ILNP Nonce (Type=0x8B)</td>
              <td align="center" colspan="1" rowspan="1">Permit</td>
              <td align="center" colspan="1" rowspan="1">
                <xref target="x8B" format="default" sectionFormat="of" derivedContent="Section 4.4.14"/></td>
            </tr>
            <tr>
              <td align="center" colspan="1" rowspan="1">Line-Identification Option (Type=0x8C)</td>
              <td align="center" colspan="1" rowspan="1">Drop</td>
              <td align="center" colspan="1" rowspan="1">
                <xref target="x8C" format="default" sectionFormat="of" derivedContent="Section 4.4.15"/></td>
            </tr>
            <tr>
              <td align="center" colspan="1" rowspan="1">Home Address (Type=0xC9)</td>
              <td align="center" colspan="1" rowspan="1">Permit</td>
              <td align="center" colspan="1" rowspan="1">
                <xref target="xC9" format="default" sectionFormat="of" derivedContent="Section 4.4.17"/></td>
            </tr>
            <tr>
              <td align="center" colspan="1" rowspan="1">IP_DFF (Type=0xEE)</td>
              <td align="center" colspan="1" rowspan="1">Permit based on needed functionality</td>
              <td align="center" colspan="1" rowspan="1">
                <xref target="xEE" format="default" sectionFormat="of" derivedContent="Section 4.4.18"/></td>
            </tr>
            <tr>
              <td align="center" colspan="1" rowspan="1">RFC3692-style Experiment (Types = 0x1E, 0x3E, 0x5E, 0x7E, 0x9E, 0xBE, 0xDE, 0xFE)</td>
              <td align="center" colspan="1" rowspan="1">Permit based on needed functionality</td>
              <td align="center" colspan="1" rowspan="1">
                <xref target="x1E" format="default" sectionFormat="of" derivedContent="Section 4.4.19"/></td>
            </tr>
          </tbody>
        </table>
      </section>
      <section anchor="opt-filtering" numbered="true" toc="include" removeInRFC="false" pn="section-4.4">
        <name slugifiedName="name-advice-on-the-handling-of-pa">Advice on the Handling of Packets with Specific IPv6 Options</name>
        <t indent="0" pn="section-4.4-1">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 anchor="x00" numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.1">
          <name slugifiedName="name-pad1-type0x00">Pad1 (Type=0x00)</name>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.1.1">
            <name slugifiedName="name-uses-12">Uses</name>
            <t indent="0" pn="section-4.4.1.1-1">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 numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.1.2">
            <name slugifiedName="name-specification-12">Specification</name>
            <t indent="0" pn="section-4.4.1.2-1">This option is specified in <xref target="RFC8200" format="default" sectionFormat="of" derivedContent="RFC8200"/>.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.1.3">
            <name slugifiedName="name-specific-security-implications-9">Specific Security Implications</name>
            <t indent="0" pn="section-4.4.1.3-1">None.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.1.4">
            <name slugifiedName="name-operational-and-interoperability-im-4">Operational and Interoperability Impact If Blocked</name>
            <t indent="0" pn="section-4.4.1.4-1">Discarding packets that contain this option would potentially break any protocol that relies on IPv6 options.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.1.5">
            <name slugifiedName="name-advice-12">Advice</name>
            <t indent="0" pn="section-4.4.1.5-1">Intermediate systems should not discard packets based on the presence of this option.</t>
          </section>
        </section>
        <section anchor="x01" numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.2">
          <name slugifiedName="name-padn-type0x01">PadN (Type=0x01)</name>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.2.1">
            <name slugifiedName="name-uses-13">Uses</name>
            <t indent="0" pn="section-4.4.2.1-1">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 numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.2.2">
            <name slugifiedName="name-specification-13">Specification</name>
            <t indent="0" pn="section-4.4.2.2-1">This option is specified in <xref target="RFC8200" format="default" sectionFormat="of" derivedContent="RFC8200"/>.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.2.3">
            <name slugifiedName="name-specific-security-implications-10">Specific Security Implications</name>
            <t indent="0" pn="section-4.4.2.3-1">Because of the possible size of this option, it could be leveraged as a large-bandwidth covert channel.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.2.4">
            <name slugifiedName="name-operational-and-interoperability-im-5">Operational and Interoperability Impact If Blocked</name>
            <t indent="0" pn="section-4.4.2.4-1">Discarding packets that contain this option would potentially break any protocol that relies on IPv6 options.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.2.5">
            <name slugifiedName="name-advice-13">Advice</name>
            <t indent="0" pn="section-4.4.2.5-1">Intermediate systems should not discard IPv6 packets based on the presence of this option.</t>
          </section>
        </section>
        <section anchor="x04" numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.3">
          <name slugifiedName="name-tunnel-encapsulation-limit-">Tunnel Encapsulation Limit (Type=0x04)</name>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.3.1">
            <name slugifiedName="name-uses-14">Uses</name>
            <t indent="0" pn="section-4.4.3.1-1">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 numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.3.2">
            <name slugifiedName="name-specification-14">Specification</name>
            <t indent="0" pn="section-4.4.3.2-1">This option is specified in <xref target="RFC2473" format="default" sectionFormat="of" derivedContent="RFC2473"/>.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.3.3">
            <name slugifiedName="name-specific-security-implications-11">Specific Security Implications</name>
            <t indent="0" pn="section-4.4.3.3-1">These are discussed in <xref target="RFC2473" format="default" sectionFormat="of" derivedContent="RFC2473"/>.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.3.4">
            <name slugifiedName="name-operational-and-interoperability-im-6">Operational and Interoperability Impact If Blocked</name>
            <t indent="0" pn="section-4.4.3.4-1">Discarding packets based on the presence of this option could result in tunnel traffic being discarded.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.3.5">
            <name slugifiedName="name-advice-14">Advice</name>
            <t indent="0" pn="section-4.4.3.5-1">Intermediate systems should not discard packets based on the presence of this option.</t>
          </section>
        </section>
        <section anchor="x05" numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.4">
          <name slugifiedName="name-router-alert-type0x05">Router Alert (Type=0x05)</name>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.4.1">
            <name slugifiedName="name-uses-15">Uses</name>
            <t indent="0" pn="section-4.4.4.1-1">The Router Alert option <xref target="RFC2711" format="default" sectionFormat="of" derivedContent="RFC2711"/> is employed by a number of protocols, including the Resource reSerVation Protocol (RSVP) <xref target="RFC2205" format="default" sectionFormat="of" derivedContent="RFC2205"/>, Multicast Listener Discovery (MLD) <xref target="RFC2710" format="default" sectionFormat="of" derivedContent="RFC2710"/> <xref target="RFC3810" format="default" sectionFormat="of" derivedContent="RFC3810"/>, Multicast Router Discovery (MRD) <xref target="RFC4286" format="default" sectionFormat="of" derivedContent="RFC4286"/>, and General Internet Signaling Transport (GIST) <xref target="RFC5971" format="default" sectionFormat="of" derivedContent="RFC5971"/>. Its usage is discussed in detail in <xref target="RFC6398" format="default" sectionFormat="of" derivedContent="RFC6398"/>.
</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.4.2">
            <name slugifiedName="name-specification-15">Specification</name>
            <t indent="0" pn="section-4.4.4.2-1">This option is specified in <xref target="RFC2711" format="default" sectionFormat="of" derivedContent="RFC2711"/>.</t>
          </section>
          <section anchor="ra-usage" numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.4.3">
            <name slugifiedName="name-specific-security-implications-12">Specific Security Implications</name>
            <t indent="0" pn="section-4.4.4.3-1">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" format="default" sectionFormat="of" derivedContent="RFC6398"/>.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.4.4">
            <name slugifiedName="name-operational-and-interoperability-im-7">Operational and Interoperability Impact If Blocked</name>
            <t indent="0" pn="section-4.4.4.4-1">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" format="default" sectionFormat="of" derivedContent="Section 4.4.4.3"/> for further details.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.4.5">
            <name slugifiedName="name-advice-15">Advice</name>
            <t indent="0" pn="section-4.4.4.5-1">Packets containing this option should be permitted in environments where support for RSVP, multicast routing, or similar protocols is required.</t>
          </section>
        </section>
        <section anchor="x07" numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.5">
          <name slugifiedName="name-calipso-type0x07">CALIPSO (Type=0x07)</name>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.5.1">
            <name slugifiedName="name-uses-16">Uses</name>
            <t indent="0" pn="section-4.4.5.1-1">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 numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.5.2">
            <name slugifiedName="name-specification-16">Specification</name>
            <t indent="0" pn="section-4.4.5.2-1">This option is specified in <xref target="RFC5570" format="default" sectionFormat="of" derivedContent="RFC5570"/>.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.5.3">
            <name slugifiedName="name-specific-security-implications-13">Specific Security Implications</name>
            <t indent="0" pn="section-4.4.5.3-1">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 numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.5.4">
            <name slugifiedName="name-operational-and-interoperability-im-8">Operational and Interoperability Impact If Blocked</name>
            <t indent="0" pn="section-4.4.5.4-1">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 with the received data from the packet whose Common Architecture Label
	  IPv6 Security Option (CALIPSO)
          was stripped by a middlebox (such as a packet scrubber). Associating an
          incorrect Sensitivity Label can cause the received information
          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" format="default" sectionFormat="of" derivedContent="RFC5570"/>, IPsec <xref target="RFC4301" format="default" sectionFormat="of" derivedContent="RFC4301"/> <xref target="RFC4302" format="default" sectionFormat="of" derivedContent="RFC4302"/> <xref target="RFC4303" format="default" sectionFormat="of" derivedContent="RFC4303"/> can be employed to protect the CALIPSO.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.5.5">
            <name slugifiedName="name-advice-16">Advice</name>
            <t indent="0" pn="section-4.4.5.5-1">
Recommendations for handling the CALIPSO depend on the deployment environment rather than on whether an intermediate system 
  happens to be deployed as a transit device (e.g., IPv6 transit router).</t>
            <t indent="0" pn="section-4.4.5.5-2">Explicit configuration is the only method via which an intermediate system
 can know whether that particular intermediate system has been 
 deployed within 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 indent="0" pn="section-4.4.5.5-3">For intermediate systems that DO NOT implement <xref target="RFC5570" format="default" sectionFormat="of" derivedContent="RFC5570"/>, there 
 should be a configuration option to either (a) drop packets containing 
 the CALIPSO or  (b) ignore the presence of the CALIPSO
 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 indent="0" pn="section-4.4.5.5-4">For intermediate systems that DO implement <xref target="RFC5570" format="default" sectionFormat="of" derivedContent="RFC5570"/>, 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 as per <xref target="RFC5570" format="default" sectionFormat="of" derivedContent="RFC5570"/>.  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 <bcp14>MAY</bcp14> be set to (a) above, because MLS 
 environments are much less common than non-MLS environments.
</t>
          </section>
        </section>
        <section anchor="x08" numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.6">
          <name slugifiedName="name-smf_dpd-type0x08">SMF_DPD (Type=0x08)</name>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.6.1">
            <name slugifiedName="name-uses-17">Uses</name>
            <t indent="0" pn="section-4.4.6.1-1">This option is employed in the (experimental) Simplified Multicast Forwarding (SMF) for unique packet identification for IPv6 Identification-based DPD (I-DPD) and as a mechanism to guarantee non-collision of hash values for different packets when Hash-based DPD (H-DPD) is used.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.6.2">
            <name slugifiedName="name-specification-17">Specification</name>
            <t indent="0" pn="section-4.4.6.2-1">This option is specified in <xref target="RFC6621" format="default" sectionFormat="of" derivedContent="RFC6621"/>.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.6.3">
            <name slugifiedName="name-specific-security-implications-14">Specific Security Implications</name>
            <t indent="0" pn="section-4.4.6.3-1">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" format="default" sectionFormat="of" derivedContent="NUMERIC-IDS"/>.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.6.4">
            <name slugifiedName="name-operational-and-interoperability-im-9">Operational and Interoperability Impact If Blocked</name>
            <t indent="0" pn="section-4.4.6.4-1">Dropping packets containing this option within a 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 numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.6.5">
            <name slugifiedName="name-advice-17">Advice</name>
            <t indent="0" pn="section-4.4.6.5-1">Intermediate systems that are not within a MANET domain should discard packets that contain this option.</t>
          </section>
        </section>
        <section anchor="x0F" numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.7">
          <name slugifiedName="name-pdm-type0x0f">PDM (Type=0x0F)</name>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.7.1">
            <name slugifiedName="name-uses-18">Uses</name>
            <t indent="0" pn="section-4.4.7.1-1">This option is employed to convey sequence numbers and timing information in IPv6 packets as a basis for measurements.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.7.2">
            <name slugifiedName="name-specification-18">Specification</name>
            <t indent="0" pn="section-4.4.7.2-1">This option is specified in <xref target="RFC8250" format="default" sectionFormat="of" derivedContent="RFC8250"/>.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.7.3">
            <name slugifiedName="name-specific-security-implications-15">Specific Security Implications</name>
            <t indent="0" pn="section-4.4.7.3-1">These are discussed in <xref target="RFC8250" format="default" sectionFormat="of" derivedContent="RFC8250"/>. Additionally, since this option employs transient numeric identifiers, implementations may be subject to the issues discussed in <xref target="I-D.irtf-pearg-numeric-ids-generation" format="default" sectionFormat="of" derivedContent="NUMERIC-IDS"/>.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.7.4">
            <name slugifiedName="name-operational-and-interoperability-im-10">Operational and Interoperability Impact If Blocked</name>
            <t indent="0" pn="section-4.4.7.4-1">Dropping packets containing this option will result in negative interoperability implications for traffic employing this option as a basis for measurements.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.7.5">
            <name slugifiedName="name-advice-18">Advice</name>
            <t indent="0" pn="section-4.4.7.5-1">Intermediate systems should not discard packets based on the presence of this option.</t>
          </section>
        </section>
        <section anchor="x23" numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.8">
          <name slugifiedName="name-rpl-option-type0x23">RPL Option (Type=0x23)</name>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.8.1">
            <name slugifiedName="name-uses-19">Uses</name>
            <t indent="0" pn="section-4.4.8.1-1">The RPL Option provides a mechanism to include routing information in each datagram that a RPL router forwards.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.8.2">
            <name slugifiedName="name-specification-19">Specification</name>
            <t indent="0" pn="section-4.4.8.2-1">This option is specified in <xref target="RFC9008" format="default" sectionFormat="of" derivedContent="RFC9008"/>.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.8.3">
            <name slugifiedName="name-specific-security-implications-16">Specific Security Implications</name>
            <t indent="0" pn="section-4.4.8.3-1">These are discussed in <xref target="RFC9008" format="default" sectionFormat="of" derivedContent="RFC9008"/>.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.8.4">
            <name slugifiedName="name-operational-and-interoperability-im-11">Operational and Interoperability Impact If Blocked</name>
            <t indent="0" pn="section-4.4.8.4-1">This option can survive outside of 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" format="default" sectionFormat="of" derivedContent="RFC9008"/>).</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.8.5">
            <name slugifiedName="name-advice-19">Advice</name>
            <t indent="0" pn="section-4.4.8.5-1">Intermediate systems should not discard IPv6 packets based on the presence of this option.</t>
          </section>
        </section>
        <section anchor="x26" numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.9">
          <name slugifiedName="name-quick-start-type0x26">Quick-Start (Type=0x26)</name>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.9.1">
            <name slugifiedName="name-uses-20">Uses</name>
            <t indent="0" pn="section-4.4.9.1-1">This IP 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" format="default" sectionFormat="of" derivedContent="RFC4782"/>.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.9.2">
            <name slugifiedName="name-specification-20">Specification</name>
            <t indent="0" pn="section-4.4.9.2-1">This option is specified in <xref target="RFC4782" format="default" sectionFormat="of" derivedContent="RFC4782"/> on the "Experimental" track.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.9.3">
            <name slugifiedName="name-specific-security-implications-17">Specific Security Implications</name>
            <t indent="0" pn="section-4.4.9.3-1"><xref target="RFC4782" sectionFormat="of" section="9.6" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4782#section-9.6" derivedContent="RFC4782"/> notes that Quick-Start is
          vulnerable to two kinds of attacks: </t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.4.9.3-2">
              <li pn="section-4.4.9.3-2.1">attacks to increase the routers' processing and state load
              and</li>
              <li pn="section-4.4.9.3-2.2">attacks with bogus Quick-Start Requests to temporarily tie up
              available Quick-Start bandwidth, preventing routers from
              approving Quick-Start Requests from other connections</li>
            </ul>
            <t indent="0" pn="section-4.4.9.3-3">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" format="default" sectionFormat="of" derivedContent="Section 4.2"/>) would apply.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.9.4">
            <name slugifiedName="name-operational-and-interoperability-im-12">Operational and Interoperability Impact If Blocked</name>
            <t indent="0" pn="section-4.4.9.4-1">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 connection establishment
	    will be introduced (as discussed in <xref target="RFC4782" sectionFormat="of" section="4.7.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4782#section-4.7.2" derivedContent="RFC4782"/>). We note,
          however, that Quick-Start has been proposed as a mechanism that could
          be of use in controlled environments and not as a mechanism that
          would be intended or appropriate for ubiquitous deployment in the
          global Internet <xref target="RFC4782" format="default" sectionFormat="of" derivedContent="RFC4782"/>.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.9.5">
            <name slugifiedName="name-advice-20">Advice</name>
            <t indent="0" pn="section-4.4.9.5-1">Intermediate systems should not discard IPv6 packets based on the presence of this option.</t>
          </section>
        </section>
        <section anchor="x4D" numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.10">
          <name slugifiedName="name-deprecated-type0x4d">Deprecated (Type=0x4D)</name>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.10.1">
            <name slugifiedName="name-uses-21">Uses</name>
            <t indent="0" pn="section-4.4.10.1-1">No information has been found about this option type.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.10.2">
            <name slugifiedName="name-specification-21">Specification</name>
            <t indent="0" pn="section-4.4.10.2-1">No information has been found about this option type.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.10.3">
            <name slugifiedName="name-specific-security-implications-18">Specific Security Implications</name>
            <t indent="0" pn="section-4.4.10.3-1">No information has been found about this option type; hence, it has been impossible to perform the corresponding security assessment.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.10.4">
            <name slugifiedName="name-operational-and-interoperability-im-13">Operational and Interoperability Impact If Blocked</name>
            <t indent="0" pn="section-4.4.10.4-1">Unknown.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.10.5">
            <name slugifiedName="name-advice-21">Advice</name>
            <t indent="0" pn="section-4.4.10.5-1">Intermediate systems should discard packets that contain this option.</t>
          </section>
        </section>
        <section anchor="x63" numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.11">
          <name slugifiedName="name-rpl-option-type0x63">RPL Option (Type=0x63)</name>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.11.1">
            <name slugifiedName="name-uses-22">Uses</name>
            <t indent="0" pn="section-4.4.11.1-1">The RPL Option provides a mechanism to include routing information in each datagram that a RPL router forwards.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.11.2">
            <name slugifiedName="name-specification-22">Specification</name>
            <t indent="0" pn="section-4.4.11.2-1">This option was originally specified in <xref target="RFC6553" format="default" sectionFormat="of" derivedContent="RFC6553"/>. It has been deprecated by <xref target="RFC9008" format="default" sectionFormat="of" derivedContent="RFC9008"/>.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.11.3">
            <name slugifiedName="name-specific-security-implications-19">Specific Security Implications</name>
            <t indent="0" pn="section-4.4.11.3-1">These are discussed in <xref target="RFC6553" sectionFormat="of" section="5" format="default" derivedLink="https://rfc-editor.org/rfc/rfc6553#section-5" derivedContent="RFC6553"/>.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.11.4">
            <name slugifiedName="name-operational-and-interoperability-im-14">Operational and Interoperability Impact If Blocked</name>
            <t indent="0" pn="section-4.4.11.4-1">This option is meant to be employed within a RPL instance. As a result, discarding packets based on the presence of this option outside of a RPL instance will not result in interoperability implications.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.11.5">
            <name slugifiedName="name-advice-22">Advice</name>
            <t indent="0" pn="section-4.4.11.5-1">Intermediate systems should discard packets that contain a RPL Option.</t>
          </section>
        </section>
        <section anchor="x6D" numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.12">
          <name slugifiedName="name-mpl-option-type0x6d">MPL Option (Type=0x6D)</name>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.12.1">
            <name slugifiedName="name-uses-23">Uses</name>
            <t indent="0" pn="section-4.4.12.1-1">This option is used with the Multicast Protocol for Low power and Lossy Networks (MPL), which provides IPv6 multicast forwarding in
   constrained networks.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.12.2">
            <name slugifiedName="name-specification-23">Specification</name>
            <t indent="0" pn="section-4.4.12.2-1">This option is specified in <xref target="RFC7731" format="default" sectionFormat="of" derivedContent="RFC7731"/> and is meant to be included only in Hop-by-Hop Options headers.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.12.3">
            <name slugifiedName="name-specific-security-implications-20">Specific Security Implications</name>
            <t indent="0" pn="section-4.4.12.3-1">These are discussed in <xref target="RFC7731" format="default" sectionFormat="of" derivedContent="RFC7731"/>.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.12.4">
            <name slugifiedName="name-operational-and-interoperability-im-15">Operational and Interoperability Impact If Blocked</name>
            <t indent="0" pn="section-4.4.12.4-1">Dropping packets that contain an MPL Option within an MPL network would break the MPL. However, dropping such packets at the border of such networks will have no negative impact.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.12.5">
            <name slugifiedName="name-advice-23">Advice</name>
            <t indent="0" pn="section-4.4.12.5-1">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 header, such systems should consider the discussion in <xref target="proto0" format="default" sectionFormat="of" derivedContent="Section 3.5.1"/>.</t>
          </section>
        </section>
        <section anchor="x8A" numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.13">
          <name slugifiedName="name-endpoint-identification-typ">Endpoint Identification (Type=0x8A)</name>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.13.1">
            <name slugifiedName="name-uses-24">Uses</name>
            <t indent="0" pn="section-4.4.13.1-1">The Endpoint Identification option was meant to be used with the Nimrod routing architecture <xref target="NIMROD-DOC" format="default" sectionFormat="of" derivedContent="NIMROD-DOC"/> but has never seen widespread deployment.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.13.2">
            <name slugifiedName="name-specification-24">Specification</name>
            <t indent="0" pn="section-4.4.13.2-1">This option is specified in <xref target="NIMROD-DOC" format="default" sectionFormat="of" derivedContent="NIMROD-DOC"/>.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.13.3">
            <name slugifiedName="name-specific-security-implications-21">Specific Security Implications</name>
            <t indent="0" pn="section-4.4.13.3-1">Undetermined.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.13.4">
            <name slugifiedName="name-operational-and-interoperability-im-16">Operational and Interoperability Impact If Blocked</name>
            <t indent="0" pn="section-4.4.13.4-1">None.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.13.5">
            <name slugifiedName="name-advice-24">Advice</name>
            <t indent="0" pn="section-4.4.13.5-1">Intermediate systems should discard packets that contain this option.</t>
          </section>
        </section>
        <section anchor="x8B" numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.14">
          <name slugifiedName="name-ilnp-nonce-type0x8b">ILNP Nonce (Type=0x8B)</name>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.14.1">
            <name slugifiedName="name-uses-25">Uses</name>
            <t indent="0" pn="section-4.4.14.1-1">This option is employed by the Identifier-Locator Network Protocol for IPv6 (ILNPv6) to provide protection against off-path attacks for packets when ILNPv6 is in 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 numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.14.2">
            <name slugifiedName="name-specification-25">Specification</name>
            <t indent="0" pn="section-4.4.14.2-1">This option is specified in <xref target="RFC6744" format="default" sectionFormat="of" derivedContent="RFC6744"/>.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.14.3">
            <name slugifiedName="name-specific-security-implications-22">Specific Security Implications</name>
            <t indent="0" pn="section-4.4.14.3-1">These are discussed in <xref target="RFC6744" format="default" sectionFormat="of" derivedContent="RFC6744"/>.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.14.4">
            <name slugifiedName="name-operational-and-interoperability-im-17">Operational and Interoperability Impact If Blocked</name>
            <t indent="0" pn="section-4.4.14.4-1">Discarding packets that contain this option will break ILNPv6 deployments.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.14.5">
            <name slugifiedName="name-advice-25">Advice</name>
            <t indent="0" pn="section-4.4.14.5-1">Intermediate systems should not discard packets based on the presence of this option.</t>
          </section>
        </section>
        <section anchor="x8C" numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.15">
          <name slugifiedName="name-line-identification-option-">Line-Identification Option (Type=0x8C)</name>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.15.1">
            <name slugifiedName="name-uses-26">Uses</name>
            <t indent="0" pn="section-4.4.15.1-1">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>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.15.2">
            <name slugifiedName="name-specification-26">Specification</name>
            <t indent="0" pn="section-4.4.15.2-1">This option is specified in <xref target="RFC6788" format="default" sectionFormat="of" derivedContent="RFC6788"/>.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.15.3">
            <name slugifiedName="name-specific-security-implications-23">Specific Security Implications</name>
            <t indent="0" pn="section-4.4.15.3-1">These are discussed in <xref target="RFC6788" format="default" sectionFormat="of" derivedContent="RFC6788"/>.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.15.4">
            <name slugifiedName="name-operational-and-interoperability-im-18">Operational and Interoperability Impact If Blocked</name>
            <t indent="0" pn="section-4.4.15.4-1">Since this option is meant to be used when tunneling Neighbor Discovery messages in 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 numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.15.5">
            <name slugifiedName="name-advice-26">Advice</name>
            <t indent="0" pn="section-4.4.15.5-1">Intermediate systems should discard packets that contain this option.</t>
          </section>
        </section>
        <section anchor="xC2" numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.16">
          <name slugifiedName="name-jumbo-payload-type0xc2">Jumbo Payload (Type=0XC2)</name>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.16.1">
            <name slugifiedName="name-uses-27">Uses</name>
            <t indent="0" pn="section-4.4.16.1-1">The Jumbo Payload option provides the means for supporting payloads larger than 65535 bytes.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.16.2">
            <name slugifiedName="name-specification-27">Specification</name>
            <t indent="0" pn="section-4.4.16.2-1">This option is specified in <xref target="RFC2675" format="default" sectionFormat="of" derivedContent="RFC2675"/>.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.16.3">
            <name slugifiedName="name-specific-security-implications-24">Specific Security Implications</name>
            <t indent="0" pn="section-4.4.16.3-1">There are no specific issues arising from this option, except for improper validity checks of the option and associated packet lengths.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.16.4">
            <name slugifiedName="name-operational-and-interoperability-im-19">Operational and Interoperability Impact If Blocked</name>
            <t indent="0" pn="section-4.4.16.4-1">Discarding packets based on the presence of this option will cause IPv6 jumbograms to be discarded.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.16.5">
            <name slugifiedName="name-advice-27">Advice</name>
            <t indent="0" pn="section-4.4.16.5-1">An operator should permit this option only in specific scenarios in which support for IPv6 jumbograms is required.
</t>
          </section>
        </section>
        <section anchor="xC9" numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.17">
          <name slugifiedName="name-home-address-type0xc9">Home Address (Type=0xC9)</name>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.17.1">
            <name slugifiedName="name-uses-28">Uses</name>
            <t indent="0" pn="section-4.4.17.1-1">The Home Address option is used by a Mobile IPv6 node while away from home to inform the recipient of the mobile node's home address.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.17.2">
            <name slugifiedName="name-specification-28">Specification</name>
            <t indent="0" pn="section-4.4.17.2-1">This option is specified in <xref target="RFC6275" format="default" sectionFormat="of" derivedContent="RFC6275"/>.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.17.3">
            <name slugifiedName="name-specific-security-implications-25">Specific Security Implications</name>
            <t indent="0" pn="section-4.4.17.3-1">There are no (known) additional security implications, other than those discussed in <xref target="RFC6275" format="default" sectionFormat="of" derivedContent="RFC6275"/>.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.17.4">
            <name slugifiedName="name-operational-and-interoperability-im-20">Operational and Interoperability Impact If Blocked</name>
            <t indent="0" pn="section-4.4.17.4-1">Discarding IPv6 packets based on the presence of this option will break Mobile IPv6.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.17.5">
            <name slugifiedName="name-advice-28">Advice</name>
            <t indent="0" pn="section-4.4.17.5-1">Intermediate systems should not discard IPv6 packets based on the presence of this option.</t>
          </section>
        </section>
        <section anchor="xEE" numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.18">
          <name slugifiedName="name-ip_dff-type0xee">IP_DFF (Type=0xEE)</name>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.18.1">
            <name slugifiedName="name-uses-29">Uses</name>
            <t indent="0" pn="section-4.4.18.1-1">This option is employed with the (experimental) Depth-First Forwarding (DFF) in unreliable networks.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.18.2">
            <name slugifiedName="name-specification-29">Specification</name>
            <t indent="0" pn="section-4.4.18.2-1">This option is specified in <xref target="RFC6971" format="default" sectionFormat="of" derivedContent="RFC6971"/>.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.18.3">
            <name slugifiedName="name-specific-security-implications-26">Specific Security Implications</name>
            <t indent="0" pn="section-4.4.18.3-1">These are specified in <xref target="RFC6971" format="default" sectionFormat="of" derivedContent="RFC6971"/>.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.18.4">
            <name slugifiedName="name-operational-and-interoperability-im-21">Operational and Interoperability Impact If Blocked</name>
            <t indent="0" pn="section-4.4.18.4-1">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 operational or interoperability implications.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.18.5">
            <name slugifiedName="name-advice-29">Advice</name>
            <t indent="0" pn="section-4.4.18.5-1">Intermediate systems that do not operate within a routing domain that is running DFF should discard packets containing this option.</t>
          </section>
        </section>
        <section anchor="x1E" numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.19">
          <name slugifiedName="name-rfc3692-style-experiment-ty">RFC3692-Style Experiment (Types = 0x1E, 0x3E, 0x5E, 0x7E, 0x9E, 0xBE, 0xDE, 0xFE)</name>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.19.1">
            <name slugifiedName="name-uses-30">Uses</name>
            <t indent="0" pn="section-4.4.19.1-1">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 numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.19.2">
            <name slugifiedName="name-specification-30">Specification</name>
            <t indent="0" pn="section-4.4.19.2-1">These options are specified in <xref target="RFC4727" format="default" sectionFormat="of" derivedContent="RFC4727"/> in the context of
          RFC3692-style experiments.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.19.3">
            <name slugifiedName="name-specific-security-implications-27">Specific Security Implications</name>
            <t indent="0" pn="section-4.4.19.3-1">The specific security implications will depend on the specific use of these options.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.19.4">
            <name slugifiedName="name-operational-and-interoperability-im-22">Operational and Interoperability Impact If Blocked</name>
            <t indent="0" pn="section-4.4.19.4-1">For obvious reasons, discarding packets that contain these options limits the ability to perform legitimate experiments across IPv6 routers.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-4.4.19.5">
            <name slugifiedName="name-advice-30">Advice</name>
            <t indent="0" pn="section-4.4.19.5-1">Operators should determine, according to their own circumstances, whether to discard packets containing these IPv6 options.</t>
          </section>
        </section>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-4.5">
        <name slugifiedName="name-advice-on-the-handling-of-pac">Advice on the Handling of Packets with Unknown IPv6 Options</name>
        <t indent="0" pn="section-4.5-1">We refer to IPv6 options that have not been assigned an IPv6 Option Type in the corresponding registry, which is <xref target="IANA-IPV6-PARAM" format="default" sectionFormat="of" derivedContent="IANA-IPV6-PARAM"/>, as "unknown IPv6 options".</t>
        <section numbered="true" toc="exclude" removeInRFC="false" pn="section-4.5.1">
          <name slugifiedName="name-uses-31">Uses</name>
          <t indent="0" pn="section-4.5.1-1">New IPv6 options may be specified as part of future protocol work.</t>
        </section>
        <section numbered="true" toc="exclude" removeInRFC="false" pn="section-4.5.2">
          <name slugifiedName="name-specification-31">Specification</name>
          <t indent="0" pn="section-4.5.2-1">The processing of unknown IPv6 options is specified in <xref target="RFC8200" format="default" sectionFormat="of" derivedContent="RFC8200"/>.</t>
        </section>
        <section numbered="true" toc="exclude" removeInRFC="false" pn="section-4.5.3">
          <name slugifiedName="name-specific-security-implications-28">Specific Security Implications</name>
          <t indent="0" pn="section-4.5.3-1">For obvious reasons, it is impossible to determine specific security implications of unknown IPv6 options.</t>
        </section>
        <section numbered="true" toc="exclude" removeInRFC="false" pn="section-4.5.4">
          <name slugifiedName="name-operational-and-interoperability-im-23">Operational and Interoperability Impact If Blocked</name>
          <t indent="0" pn="section-4.5.4-1">Discarding unknown IPv6 options may slow down the deployment of new IPv6 options. As noted in <xref target="I-D.gont-6man-ipv6-opt-transmit" format="default" sectionFormat="of" derivedContent="IPv6-OPTIONS"/>, the corresponding IANA registry, which is <xref target="IANA-IPV6-PARAM" format="default" sectionFormat="of" derivedContent="IANA-IPV6-PARAM"/>, should be monitored such that IPv6 option filtering rules are updated as new IPv6 options are standardized.</t>
        </section>
        <section numbered="true" toc="exclude" removeInRFC="false" pn="section-4.5.5">
          <name slugifiedName="name-advice-31">Advice</name>
          <t indent="0" pn="section-4.5.5-1">Operators should determine, according to their own circumstances, whether to discard packets containing unknown IPv6 options.</t>
        </section>
      </section>
    </section>
    <section anchor="IANA" numbered="true" toc="include" removeInRFC="false" pn="section-5">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-5-1">This document has no IANA actions.</t>
    </section>
    <section anchor="Privacy" numbered="true" toc="include" removeInRFC="false" pn="section-6">
      <name slugifiedName="name-privacy-considerations">Privacy Considerations</name>
      <t indent="0" pn="section-6-1">
There are no privacy considerations associated with this document.
</t>
    </section>
    <section anchor="Security" numbered="true" toc="include" removeInRFC="false" pn="section-7">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-7-1">
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 or inappropriate advice in this area.
</t>
      <t indent="0" pn="section-7-2">
   As discussed in <xref target="ipv6-ehs-rationale" format="default" sectionFormat="of" derivedContent="Section 3.3"/>, one of the
   underlying principles for the advice provided in this document is
   that IPv6 packets with specific EHs or options 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" format="default" sectionFormat="of" derivedContent="RFC9098"/>. 
</t>
      <t indent="0" pn="section-7-3">We also note that depending on the router architecture, attempts to filter packets based on the presence of IPv6 EHs or options might itself represent an attack vector to network infrastructure devices <xref target="RFC9098" format="default" sectionFormat="of" derivedContent="RFC9098"/>.</t>
    </section>
  </middle>
  <back>
    <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 pn="section-8">
      <name slugifiedName="name-references">References</name>
      <references pn="section-8.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="RFC1034" target="https://www.rfc-editor.org/info/rfc1034" quoteTitle="true" derivedAnchor="RFC1034">
          <front>
            <title>Domain names - concepts and facilities</title>
            <author initials="P." surname="Mockapetris" fullname="P. Mockapetris">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="1987" month="November"/>
            <abstract>
              <t indent="0">This RFC is the revised basic definition of The Domain Name System.  It obsoletes RFC-882.  This memo describes the domain style names and their used for host address look up and electronic mail forwarding.  It discusses the clients and servers in the domain name system and the protocol used between them.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="13"/>
          <seriesInfo name="RFC" value="1034"/>
          <seriesInfo name="DOI" value="10.17487/RFC1034"/>
        </reference>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S" surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t indent="0">In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized.  This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC2205" target="https://www.rfc-editor.org/info/rfc2205" quoteTitle="true" derivedAnchor="RFC2205">
          <front>
            <title>Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification</title>
            <author fullname="R. Braden" initials="R" role="editor" surname="Braden"/>
            <author fullname="L. Zhang" initials="L" surname="Zhang"/>
            <author fullname="S. Berson" initials="S" surname="Berson"/>
            <author fullname="S. Herzog" initials="S" surname="Herzog"/>
            <author fullname="S. Jamin" initials="S" surname="Jamin"/>
            <date month="September" year="1997"/>
            <abstract>
              <t indent="0">This memo describes version 1 of RSVP, a resource reservation setup protocol designed for an integrated services Internet.  RSVP provides receiver-initiated setup of resource reservations for multicast or unicast data flows, with good scaling and robustness properties. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2205"/>
          <seriesInfo name="DOI" value="10.17487/RFC2205"/>
        </reference>
        <reference anchor="RFC2473" target="https://www.rfc-editor.org/info/rfc2473" quoteTitle="true" derivedAnchor="RFC2473">
          <front>
            <title>Generic Packet Tunneling in IPv6 Specification</title>
            <author fullname="A. Conta" initials="A" surname="Conta"/>
            <author fullname="S. Deering" initials="S" surname="Deering"/>
            <date month="December" year="1998"/>
            <abstract>
              <t indent="0">This document defines the model and generic mechanisms for IPv6 encapsulation of Internet packets, such as IPv6 and IPv4. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2473"/>
          <seriesInfo name="DOI" value="10.17487/RFC2473"/>
        </reference>
        <reference anchor="RFC2675" target="https://www.rfc-editor.org/info/rfc2675" quoteTitle="true" derivedAnchor="RFC2675">
          <front>
            <title>IPv6 Jumbograms</title>
            <author fullname="D. Borman" initials="D" surname="Borman"/>
            <author fullname="S. Deering" initials="S" surname="Deering"/>
            <author fullname="R. Hinden" initials="R" surname="Hinden"/>
            <date month="August" year="1999"/>
            <abstract>
              <t indent="0">This document describes the IPv6 Jumbo Payload option, which provides the means of specifying such large payload lengths.  It also describes the changes needed to TCP and UDP to make use of jumbograms. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2675"/>
          <seriesInfo name="DOI" value="10.17487/RFC2675"/>
        </reference>
        <reference anchor="RFC2710" target="https://www.rfc-editor.org/info/rfc2710" quoteTitle="true" derivedAnchor="RFC2710">
          <front>
            <title>Multicast Listener Discovery (MLD) for IPv6</title>
            <author fullname="S. Deering" initials="S" surname="Deering"/>
            <author fullname="W. Fenner" initials="W" surname="Fenner"/>
            <author fullname="B. Haberman" initials="B" surname="Haberman"/>
            <date month="October" year="1999"/>
            <abstract>
              <t indent="0">This document specifies the protocol used by an IPv6 router to discover the presence of multicast listeners (that is, nodes wishing to receive multicast packets) on its directly attached links, and to discover specifically which multicast addresses are of interest to those neighboring nodes. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2710"/>
          <seriesInfo name="DOI" value="10.17487/RFC2710"/>
        </reference>
        <reference anchor="RFC2711" target="https://www.rfc-editor.org/info/rfc2711" quoteTitle="true" derivedAnchor="RFC2711">
          <front>
            <title>IPv6 Router Alert Option</title>
            <author fullname="C. Partridge" initials="C" surname="Partridge"/>
            <author fullname="A. Jackson" initials="A" surname="Jackson"/>
            <date month="October" year="1999"/>
            <abstract>
              <t indent="0">This memo describes a new IPv6 Hop-by-Hop Option type that alerts transit routers to more closely examine the contents of an IP datagram. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2711"/>
          <seriesInfo name="DOI" value="10.17487/RFC2711"/>
        </reference>
        <reference anchor="RFC3692" target="https://www.rfc-editor.org/info/rfc3692" quoteTitle="true" derivedAnchor="RFC3692">
          <front>
            <title>Assigning Experimental and Testing Numbers Considered Useful</title>
            <author fullname="T. Narten" initials="T" surname="Narten"/>
            <date month="January" year="2004"/>
            <abstract>
              <t indent="0">When experimenting with or extending protocols, it is often necessary to use some sort of protocol number or constant in order to actually test or experiment with the new function, even when testing in a closed environment.  For example, to test a new DHCP option, one needs an option number to identify the new function.  This document recommends that when writing IANA Considerations sections, authors should consider assigning a small range of numbers for experimentation purposes that implementers can use when testing protocol extensions or other new features.  This document reserves some ranges of numbers for experimentation purposes in specific protocols where the need to support experimentation has been identified.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="82"/>
          <seriesInfo name="RFC" value="3692"/>
          <seriesInfo name="DOI" value="10.17487/RFC3692"/>
        </reference>
        <reference anchor="RFC3810" target="https://www.rfc-editor.org/info/rfc3810" quoteTitle="true" derivedAnchor="RFC3810">
          <front>
            <title>Multicast Listener Discovery Version 2 (MLDv2) for IPv6</title>
            <author fullname="R. Vida" initials="R" role="editor" surname="Vida"/>
            <author fullname="L. Costa" initials="L" role="editor" surname="Costa"/>
            <date month="June" year="2004"/>
            <abstract>
              <t indent="0">This document updates RFC 2710, and it specifies Version 2 of the ulticast Listener Discovery Protocol (MLDv2).  MLD is used by an IPv6 router to discover the presence of multicast listeners on directly attached links, and to discover which multicast addresses are of interest to those neighboring nodes.  MLDv2 is designed to be interoperable with MLDv1.  MLDv2 adds the ability for a node to report interest in listening to packets with a particular multicast address only from specific source addresses or from all sources except for specific source addresses. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3810"/>
          <seriesInfo name="DOI" value="10.17487/RFC3810"/>
        </reference>
        <reference anchor="RFC4286" target="https://www.rfc-editor.org/info/rfc4286" quoteTitle="true" derivedAnchor="RFC4286">
          <front>
            <title>Multicast Router Discovery</title>
            <author fullname="B. Haberman" initials="B" surname="Haberman"/>
            <author fullname="J. Martin" initials="J" surname="Martin"/>
            <date month="December" year="2005"/>
            <abstract>
              <t indent="0">The concept of Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) snooping requires the ability to identify the location of multicast routers. Since snooping is not standardized, there are many mechanisms in use to identify the multicast routers. However, this can lead to interoperability issues between multicast routers and snooping switches from different vendors.</t>
              <t indent="0">This document introduces a general mechanism that allows for the discovery of multicast routers. This new mechanism, Multicast Router Discovery (MRD), introduces a standardized means of identifying multicast routers without a dependency on particular multicast routing protocols. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4286"/>
          <seriesInfo name="DOI" value="10.17487/RFC4286"/>
        </reference>
        <reference anchor="RFC4301" target="https://www.rfc-editor.org/info/rfc4301" quoteTitle="true" derivedAnchor="RFC4301">
          <front>
            <title>Security Architecture for the Internet Protocol</title>
            <author fullname="S. Kent" initials="S" surname="Kent"/>
            <author fullname="K. Seo" initials="K" surname="Seo"/>
            <date month="December" year="2005"/>
            <abstract>
              <t indent="0">This document describes an updated version of the "Security Architecture for IP", which is designed to provide security services for traffic at the IP layer.  This document obsoletes RFC 2401 (November 1998). [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4301"/>
          <seriesInfo name="DOI" value="10.17487/RFC4301"/>
        </reference>
        <reference anchor="RFC4302" target="https://www.rfc-editor.org/info/rfc4302" quoteTitle="true" derivedAnchor="RFC4302">
          <front>
            <title>IP Authentication Header</title>
            <author fullname="S. Kent" initials="S" surname="Kent"/>
            <date month="December" year="2005"/>
            <abstract>
              <t indent="0">This document describes an updated version of the IP Authentication Header (AH), which is designed to provide authentication services in IPv4 and IPv6.  This document obsoletes RFC 2402 (November 1998). [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4302"/>
          <seriesInfo name="DOI" value="10.17487/RFC4302"/>
        </reference>
        <reference anchor="RFC4303" target="https://www.rfc-editor.org/info/rfc4303" quoteTitle="true" derivedAnchor="RFC4303">
          <front>
            <title>IP Encapsulating Security Payload (ESP)</title>
            <author fullname="S. Kent" initials="S" surname="Kent"/>
            <date month="December" year="2005"/>
            <abstract>
              <t indent="0">This document describes an updated version of the Encapsulating Security Payload (ESP) protocol, which is designed to provide a mix of security services in IPv4 and IPv6.  ESP is used to provide confidentiality, data origin authentication, connectionless integrity, an anti-replay service (a form of partial sequence integrity), and limited traffic flow confidentiality.  This document obsoletes RFC 2406 (November 1998). [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4303"/>
          <seriesInfo name="DOI" value="10.17487/RFC4303"/>
        </reference>
        <reference anchor="RFC4727" target="https://www.rfc-editor.org/info/rfc4727" quoteTitle="true" derivedAnchor="RFC4727">
          <front>
            <title>Experimental Values In IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers</title>
            <author fullname="B. Fenner" initials="B" surname="Fenner"/>
            <date month="November" year="2006"/>
            <abstract>
              <t indent="0">When experimenting with or extending protocols, it is often necessary to use some sort of protocol number or constant in order to actually test or experiment with the new function, even when testing in a closed environment.  This document reserves some ranges of numbers for experimentation purposes in specific protocols where the need to support experimentation has been identified, and it describes the numbers that have already been reserved by other documents. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4727"/>
          <seriesInfo name="DOI" value="10.17487/RFC4727"/>
        </reference>
        <reference anchor="RFC4782" target="https://www.rfc-editor.org/info/rfc4782" quoteTitle="true" derivedAnchor="RFC4782">
          <front>
            <title>Quick-Start for TCP and IP</title>
            <author fullname="S. Floyd" initials="S" surname="Floyd"/>
            <author fullname="M. Allman" initials="M" surname="Allman"/>
            <author fullname="A. Jain" initials="A" surname="Jain"/>
            <author fullname="P. Sarolahti" initials="P" surname="Sarolahti"/>
            <date month="January" year="2007"/>
            <abstract>
              <t indent="0">This document specifies an optional Quick-Start mechanism for 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). While Quick-Start is designed to be used by a range of transport protocols, in this document we only specify its use with TCP. Quick-Start is designed to allow connections to use higher sending rates when there is significant unused bandwidth along the path, and the sender and all of the routers along the path approve the Quick-Start Request.</t>
              <t indent="0">This document describes many paths where Quick-Start Requests would not be approved. These paths include all paths containing routers, IP tunnels, MPLS paths, and the like that do not support Quick- Start. These paths also include paths with routers or middleboxes that drop packets containing IP options. Quick-Start Requests could be difficult to approve over paths that include multi-access layer- two networks. This document also describes environments where the Quick-Start process could fail with false positives, with the sender incorrectly assuming that the Quick-Start Request had been approved by all of the routers along the path. As a result of these concerns, and as a result of the difficulties and seeming absence of motivation for routers, such as core routers to deploy Quick-Start, Quick-Start is being proposed as a mechanism that could be of use in controlled environments, and not as a mechanism that would be intended or appropriate for ubiquitous deployment in the global Internet. This memo defines an Experimental Protocol for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4782"/>
          <seriesInfo name="DOI" value="10.17487/RFC4782"/>
        </reference>
        <reference anchor="RFC5095" target="https://www.rfc-editor.org/info/rfc5095" quoteTitle="true" derivedAnchor="RFC5095">
          <front>
            <title>Deprecation of Type 0 Routing Headers in IPv6</title>
            <author fullname="J. Abley" initials="J" surname="Abley"/>
            <author fullname="P. Savola" initials="P" surname="Savola"/>
            <author fullname="G. Neville-Neil" initials="G" surname="Neville-Neil"/>
            <date month="December" year="2007"/>
            <abstract>
              <t indent="0">The functionality provided by IPv6's Type 0 Routing Header can be exploited in order to achieve traffic amplification over a remote path for the purposes of generating denial-of-service traffic.  This document updates the IPv6 specification to deprecate the use of IPv6 Type 0 Routing Headers, in light of this security concern. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5095"/>
          <seriesInfo name="DOI" value="10.17487/RFC5095"/>
        </reference>
        <reference anchor="RFC5533" target="https://www.rfc-editor.org/info/rfc5533" quoteTitle="true" derivedAnchor="RFC5533">
          <front>
            <title>Shim6: Level 3 Multihoming Shim Protocol for IPv6</title>
            <author fullname="E. Nordmark" initials="E" surname="Nordmark"/>
            <author fullname="M. Bagnulo" initials="M" surname="Bagnulo"/>
            <date month="June" year="2009"/>
            <abstract>
              <t indent="0">This document defines the Shim6 protocol, a layer 3 shim for providing locator agility below the transport protocols, so that multihoming can be provided for IPv6 with failover and load-sharing properties, without assuming that a multihomed site will have a provider-independent IPv6 address prefix announced in the global IPv6 routing table.  The hosts in a site that has multiple provider- allocated IPv6 address prefixes will use the Shim6 protocol specified in this document to set up state with peer hosts so that the state can later be used to failover to a different locator pair, should the original one stop working. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5533"/>
          <seriesInfo name="DOI" value="10.17487/RFC5533"/>
        </reference>
        <reference anchor="RFC5570" target="https://www.rfc-editor.org/info/rfc5570" quoteTitle="true" derivedAnchor="RFC5570">
          <front>
            <title>Common Architecture Label IPv6 Security Option (CALIPSO)</title>
            <author fullname="M. StJohns" initials="M" surname="StJohns"/>
            <author fullname="R. Atkinson" initials="R" surname="Atkinson"/>
            <author fullname="G. Thomas" initials="G" surname="Thomas"/>
            <date month="July" year="2009"/>
            <abstract>
              <t indent="0">This document describes an optional method 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.  This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5570"/>
          <seriesInfo name="DOI" value="10.17487/RFC5570"/>
        </reference>
        <reference anchor="RFC5971" target="https://www.rfc-editor.org/info/rfc5971" quoteTitle="true" derivedAnchor="RFC5971">
          <front>
            <title>GIST: General Internet Signalling Transport</title>
            <author fullname="H. Schulzrinne" initials="H" surname="Schulzrinne"/>
            <author fullname="R. Hancock" initials="R" surname="Hancock"/>
            <date month="October" year="2010"/>
            <abstract>
              <t indent="0">This document specifies protocol stacks for the routing and transport of per-flow signalling messages along the path taken by that flow through the network.  The design uses existing transport and security protocols under a common messaging layer, the General Internet Signalling Transport (GIST), which provides a common service for diverse signalling applications.  GIST does not handle signalling application state itself, but manages its own internal state and the configuration of the underlying transport and security protocols to enable the transfer of messages in both directions along the flow path.  The combination of GIST and the lower layer transport and security protocols provides a solution for the base protocol component of the "Next Steps in Signalling" (NSIS) framework.  This document defines an Experimental Protocol for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5971"/>
          <seriesInfo name="DOI" value="10.17487/RFC5971"/>
        </reference>
        <reference anchor="RFC6275" target="https://www.rfc-editor.org/info/rfc6275" quoteTitle="true" derivedAnchor="RFC6275">
          <front>
            <title>Mobility Support in IPv6</title>
            <author fullname="C. Perkins" initials="C" role="editor" surname="Perkins"/>
            <author fullname="D. Johnson" initials="D" surname="Johnson"/>
            <author fullname="J. Arkko" initials="J" surname="Arkko"/>
            <date month="July" year="2011"/>
            <abstract>
              <t indent="0">This document specifies Mobile IPv6, a protocol that allows nodes to remain reachable while moving around in the IPv6 Internet.  Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet.  While situated away from its home, a mobile node is also associated with a care-of address, which provides information about the mobile node's current location.  IPv6 packets addressed to a mobile node's home address are transparently routed to its care-of address.  The protocol enables IPv6 nodes to cache the binding of a mobile node's home address with its care-of address, and to then send any packets destined for the mobile node directly to it at this care-of address.  To support this operation, Mobile IPv6 defines a new IPv6 protocol and a new destination option.  All IPv6 nodes, whether mobile or stationary, can communicate with mobile nodes.  This document obsoletes RFC 3775. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6275"/>
          <seriesInfo name="DOI" value="10.17487/RFC6275"/>
        </reference>
        <reference anchor="RFC6398" target="https://www.rfc-editor.org/info/rfc6398" quoteTitle="true" derivedAnchor="RFC6398">
          <front>
            <title>IP Router Alert Considerations and Usage</title>
            <author fullname="F. Le Faucheur" initials="F" role="editor" surname="Le Faucheur"/>
            <date month="October" year="2011"/>
            <abstract>
              <t indent="0">The IP Router Alert Option is an IP option that alerts transit routers to more closely examine the contents of an IP packet.  The Resource reSerVation Protocol (RSVP), Pragmatic General Multicast (PGM), the Internet Group Management Protocol (IGMP), Multicast Listener Discovery (MLD), Multicast Router Discovery (MRD), and General Internet Signaling Transport (GIST) are some of the protocols that make use of the IP Router Alert Option.  This document discusses security aspects and usage guidelines around the use of the current IP Router Alert Option, thereby updating RFC 2113 and RFC 2711.  Specifically, it provides recommendations against using the Router Alert in the end-to-end open Internet and identifies controlled environments where protocols depending on Router Alert can be used safely.  It also provides recommendations about protection approaches for service providers.  Finally, it provides brief guidelines for Router Alert implementation on routers.  This memo documents an Internet Best Current Practice.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="168"/>
          <seriesInfo name="RFC" value="6398"/>
          <seriesInfo name="DOI" value="10.17487/RFC6398"/>
        </reference>
        <reference anchor="RFC6550" target="https://www.rfc-editor.org/info/rfc6550" quoteTitle="true" derivedAnchor="RFC6550">
          <front>
            <title>RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks</title>
            <author fullname="T. Winter" initials="T" role="editor" surname="Winter"/>
            <author fullname="P. Thubert" initials="P" role="editor" surname="Thubert"/>
            <author fullname="A. Brandt" initials="A" surname="Brandt"/>
            <author fullname="J. Hui" initials="J" surname="Hui"/>
            <author fullname="R. Kelsey" initials="R" surname="Kelsey"/>
            <author fullname="P. Levis" initials="P" surname="Levis"/>
            <author fullname="K. Pister" initials="K" surname="Pister"/>
            <author fullname="R. Struik" initials="R" surname="Struik"/>
            <author fullname="JP. Vasseur" initials="JP" surname="Vasseur"/>
            <author fullname="R. Alexander" initials="R" surname="Alexander"/>
            <date month="March" year="2012"/>
            <abstract>
              <t indent="0">Low-Power and Lossy Networks (LLNs) are a class of network in which both the routers and their interconnect are constrained.  LLN routers typically operate with constraints on processing power, memory, and energy (battery power).  Their interconnects are characterized by high loss rates, low data rates, and instability.  LLNs are comprised of anything from a few dozen to thousands of routers.  Supported traffic flows include point-to-point (between devices inside the LLN), point-to-multipoint (from a central control point to a subset of devices inside the LLN), and multipoint-to-point (from devices inside the LLN towards a central control point).  This document specifies the IPv6 Routing Protocol for Low-Power and Lossy Networks (RPL), which provides a mechanism whereby multipoint-to-point traffic from devices inside the LLN towards a central control point as well as point-to-multipoint traffic from the central control point to the devices inside the LLN are supported.  Support for point-to-point traffic is also available. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6550"/>
          <seriesInfo name="DOI" value="10.17487/RFC6550"/>
        </reference>
        <reference anchor="RFC6553" target="https://www.rfc-editor.org/info/rfc6553" quoteTitle="true" derivedAnchor="RFC6553">
          <front>
            <title>The Routing Protocol for Low-Power and Lossy Networks (RPL) Option for Carrying RPL Information in Data-Plane Datagrams</title>
            <author fullname="J. Hui" initials="J" surname="Hui"/>
            <author fullname="JP. Vasseur" initials="JP" surname="Vasseur"/>
            <date month="March" year="2012"/>
            <abstract>
              <t indent="0">The Routing Protocol for Low-Power and Lossy Networks (RPL) includes routing information in data-plane datagrams to quickly identify inconsistencies in the routing topology.  This document describes the RPL Option for use among RPL routers to include such routing information. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6553"/>
          <seriesInfo name="DOI" value="10.17487/RFC6553"/>
        </reference>
        <reference anchor="RFC6554" target="https://www.rfc-editor.org/info/rfc6554" quoteTitle="true" derivedAnchor="RFC6554">
          <front>
            <title>An IPv6 Routing Header for Source Routes with the Routing Protocol for Low-Power and Lossy Networks (RPL)</title>
            <author fullname="J. Hui" initials="J" surname="Hui"/>
            <author fullname="JP. Vasseur" initials="JP" surname="Vasseur"/>
            <author fullname="D. Culler" initials="D" surname="Culler"/>
            <author fullname="V. Manral" initials="V" surname="Manral"/>
            <date month="March" year="2012"/>
            <abstract>
              <t indent="0">In Low-Power and Lossy Networks (LLNs), memory constraints on routers may limit them to maintaining, at most, a few routes.  In some configurations, it is necessary to use these memory-constrained routers to deliver datagrams to nodes within the LLN.  The Routing Protocol for Low-Power and Lossy Networks (RPL) can be used in some deployments to store most, if not all, routes on one (e.g., the Directed Acyclic Graph (DAG) root) or a few routers and forward the IPv6 datagram using a source routing technique to avoid large routing tables on memory-constrained routers.  This document specifies a new IPv6 Routing header type for delivering datagrams within a RPL routing domain. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6554"/>
          <seriesInfo name="DOI" value="10.17487/RFC6554"/>
        </reference>
        <reference anchor="RFC6621" target="https://www.rfc-editor.org/info/rfc6621" quoteTitle="true" derivedAnchor="RFC6621">
          <front>
            <title>Simplified Multicast Forwarding</title>
            <author fullname="J. Macker" initials="J" role="editor" surname="Macker"/>
            <date month="May" year="2012"/>
            <abstract>
              <t indent="0">This document describes a Simplified Multicast Forwarding (SMF) mechanism that provides basic Internet Protocol (IP) multicast forwarding suitable for limited wireless mesh and mobile ad hoc network (MANET) use.  It is mainly applicable in situations where efficient flooding represents an acceptable engineering design trade-off.  It defines techniques for multicast duplicate packet detection (DPD), to be applied in the forwarding process, for both IPv4 and IPv6 protocol use.  This document also specifies optional mechanisms for using reduced relay sets to achieve more efficient multicast data distribution within a mesh topology as compared to Classic Flooding.  Interactions with other protocols, such as use of information provided by concurrently running unicast routing protocols or interaction with other multicast protocols, as well as multiple deployment approaches are also described.  Distributed algorithms for selecting reduced relay sets and related discussion are provided in the appendices.  Basic issues relating to the operation of multicast MANET border routers are discussed, but ongoing work remains in this area and is beyond the scope of this document.  This document defines an Experimental Protocol for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6621"/>
          <seriesInfo name="DOI" value="10.17487/RFC6621"/>
        </reference>
        <reference anchor="RFC6740" target="https://www.rfc-editor.org/info/rfc6740" quoteTitle="true" derivedAnchor="RFC6740">
          <front>
            <title>Identifier-Locator Network Protocol (ILNP) Architectural Description</title>
            <author fullname="RJ Atkinson" initials="RJ" surname="Atkinson"/>
            <author fullname="SN Bhatti" initials="SN" surname="Bhatti"/>
            <date month="November" year="2012"/>
            <abstract>
              <t indent="0">This document provides an architectural description and the concept of operations for the Identifier-Locator Network Protocol (ILNP), which is an experimental, evolutionary enhancement to IP.  This is a product of the IRTF Routing Research Group.  This document defines an Experimental Protocol for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6740"/>
          <seriesInfo name="DOI" value="10.17487/RFC6740"/>
        </reference>
        <reference anchor="RFC6744" target="https://www.rfc-editor.org/info/rfc6744" quoteTitle="true" derivedAnchor="RFC6744">
          <front>
            <title>IPv6 Nonce Destination Option for the Identifier-Locator Network Protocol for IPv6 (ILNPv6)</title>
            <author fullname="RJ Atkinson" initials="RJ" surname="Atkinson"/>
            <author fullname="SN Bhatti" initials="SN" surname="Bhatti"/>
            <date month="November" year="2012"/>
            <abstract>
              <t indent="0">The Identifier-Locator Network Protocol (ILNP) is an experimental, evolutionary enhancement to IP.  ILNP has multiple instantiations.  This document describes an experimental Nonce Destination Option used only with ILNP for IPv6 (ILNPv6).  This document is a product of the IRTF Routing Research Group.  This document defines an Experimental Protocol for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6744"/>
          <seriesInfo name="DOI" value="10.17487/RFC6744"/>
        </reference>
        <reference anchor="RFC6788" target="https://www.rfc-editor.org/info/rfc6788" quoteTitle="true" derivedAnchor="RFC6788">
          <front>
            <title>The Line-Identification Option</title>
            <author fullname="S. Krishnan" initials="S" surname="Krishnan"/>
            <author fullname="A. Kavanagh" initials="A" surname="Kavanagh"/>
            <author fullname="B. Varga" initials="B" surname="Varga"/>
            <author fullname="S. Ooghe" initials="S" surname="Ooghe"/>
            <author fullname="E. Nordmark" initials="E" surname="Nordmark"/>
            <date month="November" year="2012"/>
            <abstract>
              <t indent="0">In Ethernet-based aggregation networks, several subscriber premises may be logically connected to the same interface of an Edge Router.  This document proposes a method for the Edge Router to identify the subscriber premises using the contents of the received Router Solicitation messages.  The applicability is limited to broadband network deployment scenarios in which multiple user ports are mapped to the same virtual interface on the Edge Router. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6788"/>
          <seriesInfo name="DOI" value="10.17487/RFC6788"/>
        </reference>
        <reference anchor="RFC6971" target="https://www.rfc-editor.org/info/rfc6971" quoteTitle="true" derivedAnchor="RFC6971">
          <front>
            <title>Depth-First Forwarding (DFF) in Unreliable Networks</title>
            <author fullname="U. Herberg" initials="U" role="editor" surname="Herberg"/>
            <author fullname="A. Cardenas" initials="A" surname="Cardenas"/>
            <author fullname="T. Iwao" initials="T" surname="Iwao"/>
            <author fullname="M. Dow" initials="M" surname="Dow"/>
            <author fullname="S. Cespedes" initials="S" surname="Cespedes"/>
            <date month="June" year="2013"/>
            <abstract>
              <t indent="0">This document specifies the Depth-First Forwarding (DFF) protocol for IPv6 networks, a data-forwarding mechanism that can increase reliability of data delivery in networks with dynamic topology and/or lossy links.  The protocol operates entirely on the forwarding plane but may interact with the routing plane.  DFF forwards data packets using a mechanism similar to a "depth-first search" for the destination of a packet.  The routing plane may be informed of failures to deliver a packet or loops.  This document specifies the DFF mechanism both for IPv6 networks (as specified in RFC 2460) and for "mesh-under" Low-Power Wireless Personal Area Networks (LoWPANs), as specified in RFC 4944.  The design of DFF assumes that the underlying link layer provides means to detect if a packet has been successfully delivered to the Next Hop or not.  It is applicable for networks with little traffic and is used for unicast transmissions only.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6971"/>
          <seriesInfo name="DOI" value="10.17487/RFC6971"/>
        </reference>
        <reference anchor="RFC7045" target="https://www.rfc-editor.org/info/rfc7045" quoteTitle="true" derivedAnchor="RFC7045">
          <front>
            <title>Transmission and Processing of IPv6 Extension Headers</title>
            <author fullname="B. Carpenter" initials="B" surname="Carpenter"/>
            <author fullname="S. Jiang" initials="S" surname="Jiang"/>
            <date month="December" year="2013"/>
            <abstract>
              <t indent="0">Various IPv6 extension headers have been standardised since the IPv6 standard was first published.  This document updates RFC 2460 to clarify how intermediate nodes should deal with such extension headers and with any that are defined in the future.  It also specifies how extension headers should be registered by IANA, with a corresponding minor update to RFC 2780.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7045"/>
          <seriesInfo name="DOI" value="10.17487/RFC7045"/>
        </reference>
        <reference anchor="RFC7112" target="https://www.rfc-editor.org/info/rfc7112" quoteTitle="true" derivedAnchor="RFC7112">
          <front>
            <title>Implications of Oversized IPv6 Header Chains</title>
            <author fullname="F. Gont" initials="F" surname="Gont"/>
            <author fullname="V. Manral" initials="V" surname="Manral"/>
            <author fullname="R. Bonica" initials="R" surname="Bonica"/>
            <date month="January" year="2014"/>
            <abstract>
              <t indent="0">The IPv6 specification allows IPv6 Header Chains of an arbitrary size.  The specification also allows options that can, in turn, extend each of the headers.  In those scenarios in which the IPv6 Header Chain or options are unusually long and packets are fragmented, or scenarios in which the fragment size is very small, the First Fragment of a packet may fail to include the entire IPv6 Header Chain.  This document discusses the interoperability and security problems of such traffic, and updates RFC 2460 such that the First Fragment of a packet is required to contain the entire IPv6 Header Chain.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7112"/>
          <seriesInfo name="DOI" value="10.17487/RFC7112"/>
        </reference>
        <reference anchor="RFC7401" target="https://www.rfc-editor.org/info/rfc7401" quoteTitle="true" derivedAnchor="RFC7401">
          <front>
            <title>Host Identity Protocol Version 2 (HIPv2)</title>
            <author fullname="R. Moskowitz" initials="R" role="editor" surname="Moskowitz"/>
            <author fullname="T. Heer" initials="T" surname="Heer"/>
            <author fullname="P. Jokela" initials="P" surname="Jokela"/>
            <author fullname="T. Henderson" initials="T" surname="Henderson"/>
            <date month="April" year="2015"/>
            <abstract>
              <t indent="0">This document specifies the details of the Host Identity Protocol (HIP). HIP allows consenting hosts to securely establish and maintain shared IP-layer state, allowing separation of the identifier and locator roles of IP addresses, thereby enabling continuity of communications across IP address changes. HIP is based on a Diffie-Hellman key exchange, using public key identifiers from a new Host Identity namespace for mutual peer authentication. The protocol is designed to be resistant to denial-of-service (DoS) and man-in-the-middle (MitM) attacks. When used together with another suitable security protocol, such as the Encapsulating Security Payload (ESP), it provides integrity protection and optional encryption for upper-layer protocols, such as TCP and UDP.</t>
              <t indent="0">This document obsoletes RFC 5201 and addresses the concerns raised by the IESG, particularly that of crypto agility. It also incorporates lessons learned from the implementations of RFC 5201.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7401"/>
          <seriesInfo name="DOI" value="10.17487/RFC7401"/>
        </reference>
        <reference anchor="RFC7731" target="https://www.rfc-editor.org/info/rfc7731" quoteTitle="true" derivedAnchor="RFC7731">
          <front>
            <title>Multicast Protocol for Low-Power and Lossy Networks (MPL)</title>
            <author fullname="J. Hui" initials="J" surname="Hui"/>
            <author fullname="R. Kelsey" initials="R" surname="Kelsey"/>
            <date month="February" year="2016"/>
            <abstract>
              <t indent="0">This document specifies the Multicast Protocol for Low-Power and Lossy Networks (MPL), which provides IPv6 multicast forwarding in constrained networks. MPL avoids the need to construct or maintain any multicast forwarding topology, disseminating messages to all MPL Forwarders in an MPL Domain.</t>
              <t indent="0">MPL has two modes of operation. One mode uses the Trickle algorithm to manage control-plane and data-plane message transmissions and is applicable for deployments with few multicast sources. The other mode uses classic flooding. By providing both modes and parameterization of the Trickle algorithm, an MPL implementation can be used in a variety of multicast deployments and can trade between dissemination latency and transmission efficiency.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7731"/>
          <seriesInfo name="DOI" value="10.17487/RFC7731"/>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B" surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t indent="0">RFC 2119 specifies common key words that may be used in protocol specifications.  This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="RFC8200" target="https://www.rfc-editor.org/info/rfc8200" quoteTitle="true" derivedAnchor="RFC8200">
          <front>
            <title>Internet Protocol, Version 6 (IPv6) Specification</title>
            <author fullname="S. Deering" initials="S" surname="Deering"/>
            <author fullname="R. Hinden" initials="R" surname="Hinden"/>
            <date month="July" year="2017"/>
            <abstract>
              <t indent="0">This document specifies version 6 of the Internet Protocol (IPv6).  It obsoletes RFC 2460.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="86"/>
          <seriesInfo name="RFC" value="8200"/>
          <seriesInfo name="DOI" value="10.17487/RFC8200"/>
        </reference>
        <reference anchor="RFC8250" target="https://www.rfc-editor.org/info/rfc8250" quoteTitle="true" derivedAnchor="RFC8250">
          <front>
            <title>IPv6 Performance and Diagnostic Metrics (PDM) Destination Option</title>
            <author fullname="N. Elkins" initials="N" surname="Elkins"/>
            <author fullname="R. Hamilton" initials="R" surname="Hamilton"/>
            <author fullname="M. Ackermann" initials="M" surname="Ackermann"/>
            <date month="September" year="2017"/>
            <abstract>
              <t indent="0">To assess performance problems, this document describes optional headers embedded in each packet that provide sequence numbers and timing information as a basis for measurements.  Such measurements may be interpreted in real time or after the fact.  This document specifies the Performance and Diagnostic Metrics (PDM) Destination Options header.  The field limits, calculations, and usage in measurement of PDM are included in this document.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8250"/>
          <seriesInfo name="DOI" value="10.17487/RFC8250"/>
        </reference>
        <reference anchor="RFC8754" target="https://www.rfc-editor.org/info/rfc8754" quoteTitle="true" derivedAnchor="RFC8754">
          <front>
            <title>IPv6 Segment Routing Header (SRH)</title>
            <author fullname="C. Filsfils" initials="C" role="editor" surname="Filsfils"/>
            <author fullname="D. Dukes" initials="D" role="editor" surname="Dukes"/>
            <author fullname="S. Previdi" initials="S" surname="Previdi"/>
            <author fullname="J. Leddy" initials="J" surname="Leddy"/>
            <author fullname="S. Matsushima" initials="S" surname="Matsushima"/>
            <author fullname="D. Voyer" initials="D" surname="Voyer"/>
            <date month="March" year="2020"/>
            <abstract>
              <t indent="0">Segment Routing can be applied to the IPv6 data plane using a new type of Routing Extension Header called the Segment Routing Header (SRH).  This document describes the SRH and how it is used by nodes that are Segment Routing (SR) capable.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8754"/>
          <seriesInfo name="DOI" value="10.17487/RFC8754"/>
        </reference>
        <reference anchor="RFC8900" target="https://www.rfc-editor.org/info/rfc8900" quoteTitle="true" derivedAnchor="RFC8900">
          <front>
            <title>IP Fragmentation Considered Fragile</title>
            <author fullname="R. Bonica" initials="R" surname="Bonica"/>
            <author fullname="F. Baker" initials="F" surname="Baker"/>
            <author fullname="G. Huston" initials="G" surname="Huston"/>
            <author fullname="R. Hinden" initials="R" surname="Hinden"/>
            <author fullname="O. Troan" initials="O" surname="Troan"/>
            <author fullname="F. Gont" initials="F" surname="Gont"/>
            <date month="September" year="2020"/>
            <abstract>
              <t indent="0">This document describes IP fragmentation and explains how it introduces fragility to Internet communication.</t>
              <t indent="0">This document also proposes alternatives to IP fragmentation and provides recommendations for developers and network operators.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="230"/>
          <seriesInfo name="RFC" value="8900"/>
          <seriesInfo name="DOI" value="10.17487/RFC8900"/>
        </reference>
        <reference anchor="RFC9008" target="https://www.rfc-editor.org/info/rfc9008" quoteTitle="true" derivedAnchor="RFC9008">
          <front>
            <title>Using RPI Option Type, Routing Header for Source Routes, and IPv6-in-IPv6 Encapsulation in the RPL Data Plane</title>
            <author initials="M.I." surname="Robles" fullname="M.I. Robles">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Richardson" fullname="M. Richardson">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="P." surname="Thubert" fullname="P. Thubert">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2021" month="April"/>
            <abstract>
              <t indent="0">This document looks at different data flows through Low-Power and Lossy Networks (LLN) where RPL (IPv6 Routing Protocol for Low-Power and Lossy Networks) is used to establish routing. The document enumerates the cases where RPL Packet Information (RPI) Option Type (RFC 6553), RPL Source Route Header (RFC 6554), and IPv6-in-IPv6 encapsulation are required in the data plane. This analysis provides the basis upon which to design efficient compression of these headers. This document updates RFC 6553 by adding a change to the RPI Option Type. Additionally, this document updates RFC 6550 by defining a flag in the DODAG Information Object (DIO) Configuration option to indicate this change and updates RFC 8138 as well to consider the new Option Type when the RPL Option is decompressed.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9008"/>
          <seriesInfo name="DOI" value="10.17487/RFC9008"/>
        </reference>
      </references>
      <references pn="section-8.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="Biondi-2007" target="http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf" quoteTitle="true" derivedAnchor="Biondi-2007">
          <front>
            <title>IPv6 Routing Header Security</title>
            <author fullname="P. Biondi" initials="P." surname="Biondi">
              <organization showOnFrontPage="true"/>
            </author>
            <author fullname="A. Ebalard" initials="A." surname="Ebalard">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="April" year="2007"/>
          </front>
          <refcontent>CanSecWest Security Conference</refcontent>
        </reference>
        <reference anchor="Cisco-EH" target="https://www.cisco.com/en/US/technologies/tk648/tk872/technologies_white_paper0900aecd8054d37d.pdf" quoteTitle="true" derivedAnchor="Cisco-EH">
          <front>
            <title abbrev="Cisco IPv6 EH">IPv6 Extension Headers Review and Considerations</title>
            <author initials="" surname="" fullname="">
              <organization showOnFrontPage="true">Cisco Systems</organization>
            </author>
            <date month="October" year="2006"/>
          </front>
          <refcontent>Whitepaper</refcontent>
        </reference>
        <reference anchor="FW-Benchmark" target="https://www.ipv6hackers.org/files/meetings/ipv6-hackers-1/zack-ipv6hackers1-firewall-security-assessment-and-benchmarking.pdf" quoteTitle="true" derivedAnchor="FW-Benchmark">
          <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 month="June" year="2013"/>
          </front>
          <refcontent>IPv6 Hackers Meeting #1, Berlin, Germany</refcontent>
        </reference>
        <reference anchor="Huston-2022" target="https://iepg.org/2022-03-20-ietf113/huston-v6frag.pdf" quoteTitle="true" derivedAnchor="Huston-2022">
          <front>
            <title>IPv6 Fragmentation and EH Behaviours</title>
            <author fullname="Geoff Huston" initials="G." surname="Huston">
              <organization abbrev="APNIC" showOnFrontPage="true"/>
              <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" showOnFrontPage="true"/>
            </author>
            <date month="March" year="2022"/>
          </front>
          <refcontent>IEPG Meeting at IETF 113"</refcontent>
        </reference>
        <reference anchor="IANA-IPV6-PARAM" target="https://www.iana.org/assignments/ipv6-parameters" quoteTitle="true" derivedAnchor="IANA-IPV6-PARAM">
          <front>
            <title>Internet Protocol Version 6 (IPv6) Parameters</title>
            <author>
              <organization showOnFrontPage="true">IANA</organization>
            </author>
          </front>
        </reference>
        <reference anchor="IANA-PROTOCOLS" target="https://www.iana.org/assignments/protocol-numbers" quoteTitle="true" derivedAnchor="IANA-PROTOCOLS">
          <front>
            <title>Protocol Numbers</title>
            <author>
              <organization showOnFrontPage="true">IANA</organization>
            </author>
          </front>
        </reference>
        <reference anchor="I-D.gont-6man-ipv6-opt-transmit" quoteTitle="true" target="https://datatracker.ietf.org/doc/html/draft-gont-6man-ipv6-opt-transmit-02" derivedAnchor="IPv6-OPTIONS">
          <front>
            <title>Transmission and Processing of IPv6 Options</title>
            <author fullname="Fernando Gont">
	 </author>
            <author fullname="Will(Shucheng) Liu">
	 </author>
            <author fullname="Ronald P. Bonica">
	 </author>
            <date month="August" day="21" year="2015"/>
            <abstract>
              <t indent="0">   Various IPv6 options have been standardized since the core IPv6
   standard was first published.  This document updates RFC 2460 to
   clarify how nodes should deal with such IPv6 options and with any
   options that are defined in the future.  It complements [RFC7045],
   which offers a similar clarification regarding IPv6 Extension
   Headers.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-gont-6man-ipv6-opt-transmit-02"/>
          <format type="TXT" target="https://www.ietf.org/archive/id/draft-gont-6man-ipv6-opt-transmit-02.txt"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="I-D.vyncke-v6ops-james" quoteTitle="true" target="https://datatracker.ietf.org/doc/html/draft-vyncke-v6ops-james-02" derivedAnchor="JAMES">
          <front>
            <title>Just Another Measurement of Extension header Survivability (JAMES)</title>
            <author fullname="Justin Iurman">
	 </author>
            <date month="July" day="11" year="2022"/>
            <abstract>
              <t indent="0">   In 2016, RFC7872 has measured the drop of packets with IPv6 extension
   headers.  This document presents a slightly different methodology
   with more recent results.  It is still work in progress.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-vyncke-v6ops-james-02"/>
          <format type="TXT" target="https://www.ietf.org/archive/id/draft-vyncke-v6ops-james-02.txt"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="NIMROD-DOC" target="http://ana-3.lcs.mit.edu/~jnc/nimrod" quoteTitle="true" derivedAnchor="NIMROD-DOC">
          <front>
            <title>Nimrod Documentation</title>
            <author/>
          </front>
        </reference>
        <reference anchor="NIMROD-EID" quoteTitle="true" target="https://datatracker.ietf.org/doc/html/draft-ietf-nimrod-eid-00" derivedAnchor="NIMROD-EID">
          <front>
            <title>Endpoint Identifier Destination Option</title>
            <author initials="C." surname="Lynn" fullname="Dr. Charles W. Lynn Jr.">
         </author>
            <date month="March" day="2" year="1996"/>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-nimrod-eid-00"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="I-D.irtf-pearg-numeric-ids-generation" quoteTitle="true" target="https://datatracker.ietf.org/doc/html/draft-irtf-pearg-numeric-ids-generation-11" derivedAnchor="NUMERIC-IDS">
          <front>
            <title>On the Generation of Transient Numeric Identifiers</title>
            <author fullname="Fernando Gont">
              <organization showOnFrontPage="true">SI6 Networks</organization>
            </author>
            <author fullname="Ivan Arce">
              <organization showOnFrontPage="true">Quarkslab</organization>
            </author>
            <date month="July" day="11" year="2022"/>
            <abstract>
              <t indent="0">   This document performs an analysis of the security and privacy
   implications of different types of "transient numeric identifiers"
   used in IETF protocols, and tries to categorize them based on their
   interoperability requirements and their associated failure severity
   when such requirements are not met.  Subsequently, it provides advice
   on possible algorithms that could be employed to satisfy the
   interoperability requirements of each identifier category, while
   minimizing the negative security and privacy implications, thus
   providing guidance to protocol designers and protocol implementers.
   Finally, it describes a number of algorithms that have been employed
   in real implementations to generate transient numeric identifiers,
   and analyzes their security and privacy properties.  This document is
   a product of the Privacy Enhancement and Assessment Research Group
   (PEARG) in the IRTF.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-irtf-pearg-numeric-ids-generation-11"/>
          <format type="TXT" target="https://www.ietf.org/archive/id/draft-irtf-pearg-numeric-ids-generation-11.txt"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="RFC2460" target="https://www.rfc-editor.org/info/rfc2460" quoteTitle="true" derivedAnchor="RFC2460">
          <front>
            <title>Internet Protocol, Version 6 (IPv6) Specification</title>
            <author fullname="S. Deering" initials="S" surname="Deering"/>
            <author fullname="R. Hinden" initials="R" surname="Hinden"/>
            <date month="December" year="1998"/>
            <abstract>
              <t indent="0">This document specifies version 6 of the Internet Protocol (IPv6), also sometimes referred to as IP Next Generation or IPng. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2460"/>
          <seriesInfo name="DOI" value="10.17487/RFC2460"/>
        </reference>
        <reference anchor="RFC3871" target="https://www.rfc-editor.org/info/rfc3871" quoteTitle="true" derivedAnchor="RFC3871">
          <front>
            <title>Operational Security Requirements for Large Internet Service Provider (ISP) IP Network Infrastructure</title>
            <author fullname="G. Jones" initials="G" role="editor" surname="Jones"/>
            <date month="September" year="2004"/>
            <abstract>
              <t indent="0">This document defines a list of operational security requirements for the infrastructure of large Internet Service Provider (ISP) IP networks (routers and switches).  A framework is defined for specifying "profiles", which are collections of requirements applicable to certain network topology contexts (all, core-only, edge-only...).  The goal is to provide network operators a clear, concise way of communicating their security requirements to vendors.  This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3871"/>
          <seriesInfo name="DOI" value="10.17487/RFC3871"/>
        </reference>
        <reference anchor="RFC6192" target="https://www.rfc-editor.org/info/rfc6192" quoteTitle="true" derivedAnchor="RFC6192">
          <front>
            <title>Protecting the Router Control Plane</title>
            <author fullname="D. Dugal" initials="D" surname="Dugal"/>
            <author fullname="C. Pignataro" initials="C" surname="Pignataro"/>
            <author fullname="R. Dunn" initials="R" surname="Dunn"/>
            <date month="March" year="2011"/>
            <abstract>
              <t indent="0">This memo provides a method for protecting a router's control plane from undesired or malicious traffic. In this approach, all legitimate router control plane traffic is identified. Once legitimate traffic has been identified, a filter is deployed in the router's forwarding plane. That filter prevents traffic not specifically identified as legitimate from reaching the router's control plane, or rate-limits such traffic to an acceptable level.</t>
              <t indent="0">Note that the filters described in this memo are applied only to traffic that is destined for the router, and not to all traffic that is passing through the router. This document is not an Internet Standards Track specification; it is published for informational purposes.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6192"/>
          <seriesInfo name="DOI" value="10.17487/RFC6192"/>
        </reference>
        <reference anchor="RFC7126" target="https://www.rfc-editor.org/info/rfc7126" quoteTitle="true" derivedAnchor="RFC7126">
          <front>
            <title>Recommendations on Filtering of IPv4 Packets Containing IPv4 Options</title>
            <author fullname="F. Gont" initials="F" surname="Gont"/>
            <author fullname="R. Atkinson" initials="R" surname="Atkinson"/>
            <author fullname="C. Pignataro" initials="C" surname="Pignataro"/>
            <date month="February" year="2014"/>
            <abstract>
              <t indent="0">This document provides advice on the filtering of IPv4 packets based on the IPv4 options they contain.  Additionally, it discusses the operational and interoperability implications of dropping packets based on the IP options they contain.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="186"/>
          <seriesInfo name="RFC" value="7126"/>
          <seriesInfo name="DOI" value="10.17487/RFC7126"/>
        </reference>
        <reference anchor="RFC7739" target="https://www.rfc-editor.org/info/rfc7739" quoteTitle="true" derivedAnchor="RFC7739">
          <front>
            <title>Security Implications of Predictable Fragment Identification Values</title>
            <author fullname="F. Gont" initials="F" surname="Gont"/>
            <date month="February" year="2016"/>
            <abstract>
              <t indent="0">IPv6 specifies the Fragment Header, which is employed for the fragmentation and reassembly mechanisms.  The Fragment Header contains an "Identification" field that, together with the IPv6 Source Address and the IPv6 Destination Address of a packet, identifies fragments that correspond to the same original datagram, such that they can be reassembled together by the receiving host.  The only requirement for setting the Identification field is that the corresponding value must be different than that employed for any other fragmented datagram sent recently with the same Source Address and Destination Address.  Some implementations use a simple global counter for setting the Identification field, thus leading to predictable Identification values.  This document analyzes the security implications of predictable Identification values, and provides implementation guidance for setting the Identification field of the Fragment Header, such that the aforementioned security implications are mitigated.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7739"/>
          <seriesInfo name="DOI" value="10.17487/RFC7739"/>
        </reference>
        <reference anchor="RFC7872" target="https://www.rfc-editor.org/info/rfc7872" quoteTitle="true" derivedAnchor="RFC7872">
          <front>
            <title>Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World</title>
            <author fullname="F. Gont" initials="F" surname="Gont"/>
            <author fullname="J. Linkova" initials="J" surname="Linkova"/>
            <author fullname="T. Chown" initials="T" surname="Chown"/>
            <author fullname="W. Liu" initials="W" surname="Liu"/>
            <date month="June" year="2016"/>
            <abstract>
              <t indent="0">This document presents real-world data regarding the extent to which packets with IPv6 Extension Headers (EHs) are dropped in the Internet (as originally measured in August 2014 and later in June 2015, with similar results) and where in the network such dropping occurs.  The aforementioned results serve as a problem statement that is expected to trigger operational advice on the filtering of IPv6 packets carrying IPv6 EHs so that the situation improves over time.  This document also explains how the results were obtained, such that the corresponding measurements can be reproduced by other members of the community and repeated over time to observe changes in the handling of packets with IPv6 EHs.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7872"/>
          <seriesInfo name="DOI" value="10.17487/RFC7872"/>
        </reference>
        <reference anchor="RFC9098" target="https://www.rfc-editor.org/info/rfc9098" quoteTitle="true" derivedAnchor="RFC9098">
          <front>
            <title>Operational Implications of IPv6 Packets with Extension Headers</title>
            <author fullname="F. Gont" initials="F" surname="Gont"/>
            <author fullname="N. Hilliard" initials="N" surname="Hilliard"/>
            <author fullname="G. Doering" initials="G" surname="Doering"/>
            <author fullname="W. Kumari" initials="W" surname="Kumari"/>
            <author fullname="G. Huston" initials="G" surname="Huston"/>
            <author fullname="W. Liu" initials="W" surname="Liu"/>
            <date month="September" year="2021"/>
            <abstract>
              <t indent="0">This document summarizes the operational implications of IPv6 extension headers specified in the IPv6 protocol specification (RFC 8200) and attempts to analyze reasons why packets with IPv6 extension headers are often dropped in the public Internet.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9098"/>
          <seriesInfo name="DOI" value="10.17487/RFC9098"/>
        </reference>
      </references>
    </references>
    <section numbered="false" toc="include" removeInRFC="false" pn="section-appendix.a">
      <name slugifiedName="name-acknowledgements">Acknowledgements</name>
      <t indent="0" pn="section-appendix.a-1">The authors would like to thank <contact fullname="Ron Bonica"/> for his work on earlier draft versions of this document.</t>
      <t indent="0" pn="section-appendix.a-2">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 indent="0" pn="section-appendix.a-3">This document borrows some text and analysis from <xref target="RFC7126" format="default" sectionFormat="of" derivedContent="RFC7126"/>, which is authored by <contact fullname="Fernando Gont"/>, <contact fullname="Randall Atkinson"/>, and <contact fullname="Carlos Pignataro"/>.</t>
      <t indent="0" pn="section-appendix.a-4">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 indent="0" pn="section-appendix.a-5">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 (including the present document).</t>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.b">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author fullname="Fernando Gont" initials="F." surname="Gont">
        <organization abbrev="SI6 Networks" showOnFrontPage="true">SI6 Networks</organization>
        <address>
          <postal>
            <street>Segurola y Habana 4310 7mo piso</street>
            <city>Ciudad Autonoma de Buenos Aires</city>
            <country>Argentina</country>
          </postal>
          <email>fgont@si6networks.com</email>
          <uri>https://www.si6networks.com</uri>
        </address>
      </author>
      <author fullname="Will (Shucheng) Liu" initials="W." surname="Liu">
        <organization showOnFrontPage="true">Huawei Technologies</organization>
        <address>
          <postal>
            <street>Bantian, Longgang District</street>
            <city>Shenzhen</city>
            <code>518129</code>
            <country>China</country>
          </postal>
          <email>liushucheng@huawei.com</email>
        </address>
      </author>
    </section>
  </back>
</rfc>
