<?xml version="1.0" encoding="US-ASCII"?> encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC0826 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.0826.xml">
<!ENTITY RFC1918 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.1918.xml">
<!ENTITY RFC2119 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2131 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2131.xml">
<!ENTITY RFC2460 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2460.xml">
<!ENTITY RFC2529 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2529.xml">
<!ENTITY RFC2663 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2663.xml">
<!ENTITY RFC2784 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2784.xml">
<!ENTITY RFC2827 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2827.xml">
<!ENTITY RFC2866 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2866.xml">
<!ENTITY RFC3056 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3056.xml">
<!-- RFC 3068 has been obsoleted by RFC 7526 but it is kept here for reference -->
<!ENTITY RFC3068 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3068.xml">
<!-- RFC 3637 has been obsoleted by RFC 6547 but it is kept here for reference -->
<!ENTITY RFC3627 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3627.xml">
<!ENTITY RFC3704 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3704.xml">
<!ENTITY RFC3756 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3756.xml">
<!ENTITY RFC3924 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3924.xml">
<!ENTITY RFC3964 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3964.xml">
<!ENTITY RFC3971 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3971.xml">
<!ENTITY RFC3972 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3972.xml">
<!ENTITY RFC4107 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4107.xml">
<!ENTITY RFC4033 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4033.xml">
<!ENTITY RFC4193 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4193.xml">
<!ENTITY RFC4293 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4293.xml">
<!ENTITY RFC4301 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4301.xml">
<!ENTITY RFC4302 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4302.xml">
<!ENTITY RFC4303 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4303.xml">
<!ENTITY RFC4364 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4364.xml">
<!ENTITY RFC4380 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4380.xml">
<!ENTITY RFC4381 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4381.xml">
<!ENTITY RFC4443 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4443.xml">
<!ENTITY RFC4552 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4552.xml">
<!ENTITY RFC4649 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4649.xml">
<!ENTITY RFC4659 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4659.xml">
<!ENTITY RFC4795 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4795.xml">
<!ENTITY RFC4798 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4798.xml">
<!ENTITY RFC4861 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4861.xml">
<!ENTITY RFC4864 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4864.xml">
<!ENTITY RFC4890 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4890.xml">
<!ENTITY RFC4942 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4942.xml">
<!ENTITY RFC5082 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5082.xml">
<!ENTITY RFC5214 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5214.xml">
<!ENTITY RFC5340 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5340.xml">
<!ENTITY RFC5635 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5635.xml">
<!ENTITY RFC5952 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5952.xml">
<!ENTITY RFC5969 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5969.xml">
<!ENTITY RFC6092 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6092.xml">
<!ENTITY RFC6104 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6104.xml">
<!ENTITY RFC6105 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6105.xml">
<!ENTITY RFC6144 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6144.xml">
<!ENTITY RFC6146 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6146.xml">
<!ENTITY RFC6147 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6147.xml">
<!ENTITY RFC6164 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6164.xml">
<!ENTITY RFC6169 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6169.xml">
<!ENTITY RFC6177 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6177.xml">
<!ENTITY RFC6192 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6192.xml">
<!ENTITY RFC6221 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6221.xml">
<!ENTITY RFC6241 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6241.xml">
<!ENTITY RFC6264 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6264.xml">
<!ENTITY RFC6269 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6269.xml">
<!ENTITY RFC6296 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6296.xml">
<!ENTITY RFC6302 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6302.xml">
<!ENTITY RFC6324 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6324.xml">
<!ENTITY RFC6333 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6333.xml">
<!ENTITY RFC6343 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6343.xml">
<!ENTITY RFC6434 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6434.xml">
<!ENTITY RFC6459 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6459.xml">
<!ENTITY RFC6547 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6547.xml">
<!ENTITY RFC6564 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6564.xml">
<!ENTITY RFC6583 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6583.xml">
<!ENTITY RFC6598 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6598.xml">
<!ENTITY RFC6620 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6620.xml">
<!ENTITY RFC6666 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6666.xml">
<!ENTITY RFC6762 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6762.xml">
<!ENTITY RFC6763 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6763.xml">
<!ENTITY RFC6775 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6775.xml">
<!ENTITY RFC6877 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6877.xml">
<!ENTITY RFC6888 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6888.xml">
<!ENTITY RFC6939 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6939.xml">
<!ENTITY RFC6964 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6964.xml">
<!ENTITY RFC6967 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6967.xml">
<!ENTITY RFC6980 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6980.xml">
<!ENTITY RFC7010 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7010.xml">
<!ENTITY RFC7011 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7011.xml">
<!ENTITY RFC7012 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7012.xml">
<!ENTITY RFC7039 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7039.xml">
<!ENTITY RFC7045 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7045.xml">
<!ENTITY RFC7050 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7050.xml">
<!ENTITY RFC7084 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7084.xml">
<!ENTITY RFC7112 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7112.xml">
<!ENTITY RFC7113 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7113.xml">
<!ENTITY RFC7123 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7123.xml">
<!ENTITY RFC7166 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7166.xml">
<!ENTITY RFC7217 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7217.xml">
<!ENTITY RFC7359 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7359.xml">
<!ENTITY RFC7381 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7381.xml">
<!ENTITY RFC7404 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7404.xml">
<!ENTITY RFC7422 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7422.xml">
<!ENTITY RFC7454 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7454.xml">
<!ENTITY RFC7513 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7513.xml">
<!ENTITY RFC7526 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7526.xml">
<!ENTITY RFC7552 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7552.xml">
<!ENTITY RFC7597 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7597.xml">
<!ENTITY RFC7599 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7599.xml">
<!ENTITY RFC7610 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7610.xml">
<!ENTITY RFC7707 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7707.xml">
<!ENTITY RFC7721 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7721.xml">
<!ENTITY RFC7772 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7772.xml">
<!ENTITY RFC7785 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7785.xml">
<!ENTITY RFC7824 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7824.xml">
<!ENTITY RFC7844 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7844.xml">
<!ENTITY RFC7872 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7872.xml">
<!ENTITY RFC7857 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7857.xml">
<!ENTITY RFC7915 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7915.xml">
<!ENTITY RFC7934 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7934.xml">
<!ENTITY RFC8040 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8040.xml">
<!ENTITY RFC8064 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8064.xml">
<!ENTITY RFC8174 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY RFC8177 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8177.xml">
<!ENTITY RFC8190 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8190.xml">
<!ENTITY RFC8200 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8200.xml">
<!ENTITY RFC8210 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8210.xml">
<!ENTITY RFC8273 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8273.xml">
<!ENTITY RFC8343 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8343.xml">
<!ENTITY RFC8344 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8344.xml">
<!ENTITY RFC8415 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8415.xml">
<!ENTITY RFC8504 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8504.xml">
<!ENTITY RFC8520 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8520.xml">
<!ENTITY RFC8541 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8541.xml">
<!ENTITY RFC8981 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8981.xml">
<!-- active IETF drafts -->
<!ENTITY I-D.ietf-opsec-ipv6-eh-filtering SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-opsec-ipv6-eh-filtering.xml">
]>
<?rfc autobreaks="yes"?>
<?rfc compact="yes"?>
<?rfc strict='yes'?>
<?rfc subcompact="no"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc toc="yes"?>
<?rfc tocindent="yes"?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> "rfc2629-xhtml.ent">

<rfc category="info" xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-opsec-v6-27" ipr="trust200902"> number="9099" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" category="info" consensus="true" xml:lang="en" symRefs="true" sortRefs="true" tocInclude="true" version="3">

  <!-- ***** FRONT MATTER ***** xml2rfc v2v3 conversion 3.7.0 -->

  <front>
    <!-- The abbreviated title is used in the page header - it is only necessary if the
         full title is longer than 39 characters -->
    <title abbrev="OPsec IPv6">Operational Security Considerations for IPv6
    Networks</title>

    <!-- add 'role="editor"' below for the editors if appropriate -->
    <seriesInfo name="RFC" value="9099"/>

    <author fullname="Eric fullname="Éric Vyncke" initials="E" initials="É" surname="Vyncke">
      <organization>Cisco</organization>
      <address>
        <postal>
          <street>De Kleetlaan 6a</street>
          <city>Diegem</city>
          <country>Belgium</country>
          <code>1831</code>
        </postal>
        <phone>+32 2 778 4677</phone>
        <email>evyncke@cisco.com</email>
      </address>
    </author>
    <author fullname="Kiran Kumar" Kumar Chittimaneni" initials="K" surname="Chittimaneni">
      <organization>Square</organization>
      <organization/>
      <address>
        <postal>
          <street>1455 Market Street, Suite 600</street>

          <city>San Francisco</city>

          <country>United States of America</country>

          <code>94103</code>
        </postal>
        <postal/>
        <email>kk.chittimaneni@gmail.com</email>
      </address>
    </author>
    <author fullname="Merike Kaeo" initials="M" surname="Kaeo">
      <organization>Double Shot Security</organization>
      <address>
        <postal>
          <street>3518 Fremont Ave N 363</street>
          <city>Seattle</city>
          <country>United States of America</country>
          <code>98103</code>
        </postal>
        <phone>+12066696394</phone>
        <email>merike@doubleshotsecurity.com</email>
      </address>
    </author>
    <author fullname="Enno Rey" initials="E" surname="Rey">
      <organization>ERNW</organization>
      <address>
        <postal>
          <street>Carl-Bosch-Str. 4</street>

          <city>Heidelberg</city>

          <region>Baden-Wuertemberg</region>
          <city>Heidelberg Baden-Wuertemberg</city>
          <code>69115</code>
          <country>Germany</country>
        </postal>
        <phone>+49 6221 480390</phone>

        <facsimile/>
        <email>erey@ernw.de</email>
        <uri/>
      </address>
    </author>
    <date day="6" month="May" month="August" year="2021"/>

    <!-- Meta-data Declarations -->

    <area>Operations and Management</area>
    <workgroup>OPSEC</workgroup>
    <keyword>IPv6</keyword>
    <keyword>Security</keyword>
    <keyword>Operational Security</keyword>
    <abstract>

      <t>Knowledge and experience on how to operate IPv4 networks securely is
      available:
      available, whether it the operator is an Internet Service Provider (ISP) or an enterprise
      internal network. However, IPv6 presents some new security challenges.
      RFC 4942 describes security issues in the protocol, but network managers
      also need a more practical, operations-minded document to enumerate
      advantages and/or disadvantages of certain choices.</t>
      <t>This document analyzes the operational security issues associated
      with several types of network networks and proposes technical and procedural
      mitigation techniques. This document is only applicable to managed
      networks, such as enterprise networks, service provider networks, or
      managed residential networks.</t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>Running an IPv6 network is new for most operators not only because
      they are not yet used to large-scale IPv6 networks but also because
      there are subtle but critical and important differences between IPv4 and
      IPv6, especially with respect to security. For example, all layer-2 Layer 2 (L2)
      interactions are now done using the Neighbor Discovery Protocol (NDP) <xref
      target="RFC4861"/>
      target="RFC4861" format="default"/> rather than using the Address Resolution
      Protocol <xref
      target="RFC0826"/>. target="RFC0826" format="default"/>. Also, there is no Network
      Address Port Translation
      (NAPT) defined in <xref target="RFC2663"/> target="RFC2663" format="default"/> for IPv6 even if <xref
      target="RFC6296"/>
      target="RFC6296" format="default"/> specifies a an IPv6-to-IPv6 Network Prefix
      Translation for IPv6
      (NPTv6)
      (NPTv6), which is a 1-to-1 mapping of IPv6 addresses. Another important
      difference is that IPv6 is extensible with the use of extension
      headers.</t>
      <t>IPv6 networks are deployed using a variety of techniques, each of
      which have their own specific security concerns.</t>
      <t>This document complements <xref target="RFC4942"/> target="RFC4942" format="default"/> by listing
      security issues when operating a network (including various transition
      technologies).
      It also provides more recent operational deployment
      experiences where warranted.</t>
      <section title="Applicability Statement"> numbered="true" toc="default">
        <name>Applicability Statement</name>
        <t>This document is applicable to managed networks, i.e., when the
        network is operated by the user organization itself. Indeed, many of
        the recommended mitigation techniques must be configured with detailed
        knowledge of the network (which are the default routers, the switch
        trunk ports, etc.). This covers Service Provider (SP), Providers (SPs), enterprise
        networks
        networks, and some knowledgeable-home-user-managed knowledgeable home-user-managed residential
        networks. This applicability statement especially applies to Sections <xref
	target="linklayer" format="counter"/> and <xref
        target="linklayer"/> target="rfilter"
	format="counter"/>.</t>
      </section>
      <section numbered="true" toc="default">
	<name>Requirements Language</name>
	        <t>
    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&nbsp;14 <xref target="RFC2119"/> <xref target="rfilter"/>.</t> target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.
	</t>
      </section>
    </section>
    <section anchor="generic" title="Generic numbered="true" toc="default">
      <name>Generic Security Considerations"> Considerations</name>
      <section anchor="v6addressing" title="Addressing"> numbered="true" toc="default">
        <name>Addressing</name>
        <t>IPv6 address allocations and overall architecture are an important
        part
        parts of securing IPv6. Initial designs, even if intended to be
        temporary, tend to last much longer than expected. Although initially
        IPv6 was initially thought to make renumbering easy, in practice practice, it may be
        extremely difficult to renumber without a proper IP Address Management
        (IPAM) system. <xref target="RFC7010"/> target="RFC7010" format="default"/> introduces the mechanisms that
        could be utilized for IPv6 site renumbering and tries to cover most of
        the explicit issues and requirements associated with IPv6
        renumbering.</t>
        <t>A key task for a successful IPv6 deployment is to prepare an
        addressing plan. Because an abundance of address space is available,
        structuring an address plan around both services and geographic
        locations allows address space to become a basis for more structured
        security policies to permit or deny services between geographic
        regions. <xref target="RFC6177"/> target="RFC6177" format="default"/> documents some operational
        considerations of using different prefix sizes for address assignments
        at end sites.</t>
        <t>A common question is whether companies should use Provider
        Independent Provider-Independent (PI) vs. Provider Allocated or Provider-Aggregated (PA) space <xref
        target="RFC7381"/>, but target="RFC7381" format="default"/>, but, from a security perspective perspective, there is little
        difference. However, one aspect to keep in mind is who has
        administrative ownership of the address space and who is technically
        responsible if/when there is a need to enforce restrictions on
        routability of the space, e.g., due to malicious criminal activity
        originating from it.
	Relying on PA address space may also increase the
        perceived need for address translation techniques techniques, such as NPTv6 and
        thereby augmenting NPTv6;
        thereby, the complexity of the operations operations, including the
        security operations.</t> operations, is augmented.</t>
        <t>In <xref target="RFC7934"/>, target="RFC7934" format="default"/>, it is recommended that IPv6 network
        deployments provide multiple IPv6 addresses from each prefix to
        general-purpose hosts hosts, and it specifically does not recommend limiting
        a host to only one IPv6 address per prefix. It also recommends that
        the network give the host the ability to use new addresses without
        requiring explicit requests (for example example, by using SLAAC). Stateless Address
	Autoconfiguration (SLAAC)). Privacy
        Extensions
        extensions, as of [RFC8981] <xref target="RFC8981" format="default"/>,
	constitute one of the main scenarios where
        hosts are expected to generate multiple addresses from the same prefix prefix,
        and having multiple IPv6 addresses per interface is a major change
        compared to the unique IPv4 address per interface for hosts (secondary
        IPv4 addresses are not common); common), especially for audits (see section
        <xref target="correlation"/>).</t>

        <!--static--> target="correlation" format="default"/>).</t>

        <section anchor="ula" title="Use numbered="true" toc="default">
          <name>Use of ULAs"> ULAs</name>
          <t>Unique Local Addresses (ULAs) <xref target="RFC4193"/> target="RFC4193" format="default"/> are
          intended for scenarios where interfaces are not globally reachable,
          despite being routed within a domain. They formally have global
          scope, but <xref target="RFC4193"/> target="RFC4193" format="default"/> specifies that they must be
          filtered at domain boundaries. ULAs are different from <xref
          target="RFC1918"/> the addresses described in <xref target="RFC1918"
	  format="default"/> and have different use cases. One use
          of ULA ULAs is described in <xref target="RFC4864"/>, target="RFC4864" format="default"/>; another one is
	  for internal communication stability in networks where external
          connectivity may come and go (e.g., some ISPs provide ULAs in home
          networks connected via a cable modem). It should further be kept in
          mind that ULA /48s from the fd00::/8 space (L=1) MUST <bcp14>MUST</bcp14> be generated
          with a pseudo-random pseudorandom algorithm, per <xref target="RFC4193"/> section
          3.2.1.</t> target="RFC4193"
	  sectionFormat="of" section="3.2.1"/>.</t>
        </section>

        <!---->

        <section anchor="p2p" title="Point-to-Point Links"> numbered="true" toc="default">
          <name>Point-to-Point Links</name>
          <t><xref target="RFC6164"/> in section 5.1 target="RFC6164" sectionFormat="of" section="5.1"/> specifies the
	  rationale
          of using /127 for inter-router inter-router, point-to-point links to prevent the
          ping-pong issue between routers not correctly implementing <xref
          target="RFC4443"/>
	  target="RFC4443" format="default"/>, and it also prevents a DoS denial-of-service
	  (DoS) attack on the neighbor
          cache. Neighbor Cache. The previous recommendation of <xref target="RFC3627"/>
	  target="RFC3627" format="default"/> has
          been obsoleted and marked Historic by <xref target="RFC6547"/>).</t> target="RFC6547"
	  format="default"/>.</t>
          <t>Some environments are also using link-local addressing for
          point-to-point links. While this practice could further reduce the
          attack surface of infrastructure devices, the operational
          disadvantages also need to be carefully considered; see also <xref
          target="RFC7404"/>.</t> target="RFC7404"
	  format="default"/>.</t>
        </section>
        <section title="Loopback Addresses"> numbered="true" toc="default">
          <name>Loopback Addresses</name>
          <t>Many operators reserve a /64 block for all loopback addresses in
          their infrastructure and allocate a /128 out of this reserved /64
          prefix for each loopback interface. This practice facilitates
          configuration of Access Control List (ACL) rules to enforce a
          security policy for those loopback addresses.</t>
        </section>
        <section anchor="static" title="Stable Addresses"> numbered="true" toc="default">
          <name>Stable Addresses</name>
          <t>When considering how to assign stable addresses for nodes (either
          by static configuration or by pre-provisioned DHCPv6 lease <xref
          target="dhcp"/>), (<xref target="dhcp"
	  format="default"/>)), it is necessary to take into consideration the
          effectiveness of perimeter security in a given environment.</t>
          <t>There is a trade-off between ease of operation (where some
          portions of the IPv6 address could be easily recognizable for
          operational debugging and troubleshooting) versus the risk of
          trivial scanning used for reconnaissance. <xref target="SCANNING"/> target="SCANNING" format="default"/>
          shows that there are scientifically based mechanisms that make
          scanning for IPv6 reachable IPv6-reachable nodes more feasible than expected; see
          also
          <xref target="RFC7707"/>.</t> target="RFC7707" format="default"/>.</t>
          <t>Stable addresses also allow easy enforcement of a security policy
          at the perimeter based on IPv6 addresses. E.g., For example, <xref
          target="RFC8520">Manufacturer target="RFC8520" format="default">Manufacturer Usage Description (MUD)</xref> is a
          mechanism where the perimeter defense can retrieve the security policy
          template based on the type of internal device and apply the right
          security policy based on the device device's IPv6 address.</t>
          <t>The use of well-known IPv6 addresses (such as ff02::1 for all
          link-local nodes) or the use of commonly repeated addresses could
          make it easy to figure out which devices are name servers, routers,
          or other critical devices; even a simple traceroute will expose most
          of the routers on a path. There are many scanning techniques
          possible and operators should not rely on the 'impossible to find
          because my address is random' paradigm (a.k.a. "security by
          obscurity"),
          obscurity") even if it is common practice to have the stable
          addresses randomly distributed across /64 subnets and to always use
          DNS (as IPv6 addresses are hard for human brains to remember).</t>

          <t>While
          <t>While, in some environments environments, obfuscating addresses could be
          considered an added benefit, it should not preclude enforcement of
          perimeter rules. Stable addresses following some logical allocation
          scheme may ease the operation (as simplicity always helps
          security).</t>
          <t>Typical deployments will have a mix of stable and non-stable
          addresses; the stable addresses being either predictable (e.g., ::25
          for a mail server) or obfuscated (i.e., appearing as a random 64-bit
          number).</t>
        </section>
        <section anchor="priv" title="Temporary numbered="true" toc="default">
          <name>Temporary Addresses for SLAAC"> SLAAC</name>
          <t>Historically, stateless address autoconfiguration Stateless Address Autoconfiguration (SLAAC) makes
          up the globally unique IPv6 address based on an automatically
          generated 64-bit interface identifier (IID) based on the EUI-64 MAC 64-bit Extended Unique Identifier (EUI-64) Media Access Control (MAC)
          address combined with the /64 prefix (received in the Prefix
          Information Option (PIO) of the Router Advertisement (RA)). The
          EUI-64 address is generated from the stable 48-bit MAC address and
          does not change even if the host moves to another network; this is
          of course bad for privacy privacy, as a host can be traced from network
          (home) to network (office or Wi-Fi in hotels). <xref
          target="RFC8064"/> target="RFC8064" format="default"/> recommends against the use of EUI-64 addresses; addresses,
          and it must be noted that most host operating systems do not use
          EUI-64 addresses anymore and rely on either <xref target="RFC8981"/> target="RFC8981" format="default"/>
          or <xref target="RFC8064"/>.</t> target="RFC8064" format="default"/>.</t>
          <t>Randomly generating an interface ID, as described in <xref
          target="RFC8981"/>, target="RFC8981" format="default"/>, is part of SLAAC with so-called privacy
          extension addresses and is used to address some privacy concerns.
          Privacy extension addresses, a.k.a., a.k.a. temporary addresses addresses, may help to
          mitigate the correlation of activities of a node within the same
          network and may also reduce the attack exposure window. But using
          <xref target="RFC8981"/>
           privacy extension addresses as described in  <xref target="RFC8981" format="default"/> might
	  prevent the operator from building host specific host-specific access control lists
          (ACLs). The <xref target="RFC8981"/> These privacy extension addresses
          could also be used to obfuscate some malevolent activities activities, and
          specific user attribution/accountability procedures should be put in
          place
          place, as described in <xref target="log"/>.</t> target="log" format="default"/>.</t>
          <t><xref target="RFC8064"/> target="RFC8064" format="default"/> combined with the address generation
          mechanism of <xref target="RFC7217"/> target="RFC7217" format="default"/> specifies another way to
          generate an address while still keeping the same IID for each
          network prefix; this allows SLAAC nodes to always have the same
          stable IPv6 address on a specific network while having different
          IPv6 addresses on different networks.</t>
          <t>In some specific use cases where user accountability is more
          important than user privacy, network operators may consider
          disabling SLAAC and relying only on DHCPv6; but however, not all operating
          systems support DHCPv6 DHCPv6, so some hosts will not get any IPv6
          connectivity. Disabling SLAAC and privacy extension addresses can be
          done for most operating systems by sending RA messages with a hint
          to get addresses via DHCPv6 by setting the M-bit and disabling SLAAC
          by resetting all A-bits in all prefix information options. PIOs. However,
          attackers could still find ways to bypass this mechanism if it is not
          enforced at the switch/router level.</t>
          <t>However, in scenarios where anonymity is a strong desire
          (protecting user privacy is more important than user attribution),
          privacy extension addresses should be used. When mechanisms
          recommended by <xref target="RFC8064"/> target="RFC8064" format="default"/> are available, the stable
          privacy address is probably a good balance between privacy (among
          different networks) and security/user attribution (within a
          network).</t>
        </section>

        <!---->

        <!---->

        <section anchor="dhcp" title="DHCP Considerations"> numbered="true" toc="default">
          <name>DHCP Considerations</name>
          <t>Some environments use DHCPv6 to provision addresses and other
          parameters in order to ensure auditability and traceability (see
          <xref target="stateful_dhcp"/> target="stateful_dhcp" format="default"/> for the limitations of DHCPv6 for
          auditability).</t>
          <t>A main security concern is the ability to detect and counteract
          rogue DHCP servers (<xref target="snoop"/>). target="snoop" format="default"/>). It must be noted that
	  that, as opposed to DHCPv4, DHCPv6 can lease several IPv6 addresses per
          client. For DHCPv4, the lease is bound to the 'client identifier',
          which may contain a hardware address, address or it may contain another type
          of identifier, such as a DNS name. For DHCPv6, the lease is bound to
          the client DHCP Unique ID Identifier (DUID), which may, may or may not, not be bound to
          the client link-layer L2 address. <xref target="RFC7824"/> target="RFC7824" format="default"/> describes
          the privacy issues associated with the use of DHCPv6 by Internet
          users. The anonymity profiles <xref target="RFC7844"/> target="RFC7844" format="default"/> are designed
          for clients that wish to remain anonymous to the visited network.
          <xref target="RFC7707"/> target="RFC7707" format="default"/> recommends that DHCPv6 servers issue
          addresses randomly from a large pool.</t>
        </section>
        <section anchor="dns" title="DNS Considerations"> numbered="true" toc="default">
          <name>DNS Considerations</name>
          <t>While the security concerns of DNS are not fundamentally
          different between IPv4 and IPv6, there are specific considerations
          in DNS64 <xref target="RFC6147"/> target="RFC6147" format="default"/> environments that need to be
          understood. Specifically, the interactions and the potential of
          interference with DNSSEC (<xref target="RFC4033"/>) <xref target="RFC4033" format="default"/> implementation
          need to be understood - -- these are pointed out in more detail in
          <xref target="nat64"/>.</t> target="nat64" format="default"/>.</t>
        </section>
        <section anchor="sixty4perhost" title="Using numbered="true" toc="default">
          <name>Using a /64 per host"> Host</name>
          <t>An interesting approach is using a /64 per host host, as proposed in
          <xref target="RFC8273"/> target="RFC8273" format="default"/>, especially in a shared environment.
	  This allows for easier user attribution (typically based on the host MAC
          address)
          address), as its /64 prefix is stable stable, even if applications within the
          host can change their IPv6 address within this /64 prefix.</t>
          <t>This can also be useful for the generation of ACLs once
          individual systems (e.g. (e.g., admin workstations) have their own
          prefixes.</t>
        </section>
        <section anchor="privacy" title="Privacy consideration numbered="true" toc="default">
          <name>Privacy Consideration of Addresses">
          <t>Beside Addresses</name>
          <t>In addition to the security aspects of IPv6 addresses, there are also
          privacy considerations: mainly because they are of global scope and
          visible globally. <xref target="RFC7721"/> target="RFC7721" format="default"/> goes into more detail on
          the privacy considerations for IPv6 addresses by comparing the
          manually configured IPv6 address, DHCPv6, and SLAAC.</t>
        </section>
      </section>
      <section anchor="ext_headers" title="Extension Headers"> numbered="true" toc="default">
        <name>Extension Headers</name>
        <t>Extension headers are an important difference between IPv4 and
        IPv6. In IPv4-based packets, it's trivial to find the upper-layer
        protocol type and protocol header, while while, in IPv6 IPv6, it is more complex
        since the extension header chain must be parsed completely (even if
        not processed) in order to find the upper-layer protocol header. IANA
        has closed the existing empty "Next Header Types" registry to new
        entries and is redirecting its users to a new the "IPv6 Extension Header
        Types" registry registry, per <xref target="RFC7045"/>.</t> target="RFC7045" format="default"/>.</t>
        <t>Extension headers have also become a very controversial topic since
        forwarding nodes that discard packets containing extension headers are
        known to cause connectivity failures and deployment problems <xref
        target="RFC7872"/>. target="RFC7872" format="default"/>. Understanding the role of various extension
        headers is important important, and this section enumerates the ones that need
        careful consideration.</t>
        <t>A clarification on how intermediate nodes should handle packets
        with existing or future extension headers is found in <xref
        target="RFC7045"/>. target="RFC7045" format="default"/>. The uniform TLV format to be used for defining
        future extension headers is described in <xref target="RFC6564"/>. target="RFC6564" format="default"/>.
        Sections 5.2 <xref target="RFC8504" sectionFormat="bare" section="5.2"/> and 5.3
	<xref target="RFC8504" sectionFormat="bare" section="5.3"/> of <xref target="RFC8504"/>
	provide more
        information on the processing of extension headers by IPv6 nodes.</t>
        <t>Vendors of filtering solutions and operations personnel responsible
        for implementing packet filtering rules should be aware that the 'Next
        Header' field in an IPv6 header can both point to an IPv6 extension
        header or to an upper layer upper-layer protocol header. This has to be considered
        when designing the user interface of filtering solutions or during the
        creation of filtering rule sets.</t>

        <t>There is IETF work in progress regarding
        <t><xref target="I-D.ietf-opsec-ipv6-eh-filtering" format="default"/> discusses filtering rules for those
        extension headers: <xref target="I-D.ietf-opsec-ipv6-eh-filtering"/>
        for headers at transit routers.</t>
        <section title="Order numbered="true" toc="default">
          <name>Order and Repetition of Extension Headers"> Headers</name>
          <t>While <xref target="RFC8200"/> target="RFC8200" format="default"/> recommends the order and the
          maximum repetition of extension headers, there are still IPv6
          implementations, at the time of writing, which there are still IPv6
          implementations that support a
          non-recommended an
          order of headers that is not recommended (such as ESP Encapsulating Security Payload (ESP)
	  before routing) or an
          illegal repetition of headers (such as multiple routing headers).
          The same applies for options contained in the extension headers (see
          <xref target="I-D.kampanakis-6man-ipv6-eh-parsing"/>). target="I-D.kampanakis-6man-ipv6-eh-parsing" format="default"/>). In some
          cases, it has led to nodes crashing when receiving or forwarding
          wrongly formatted packets.</t>
          <t>A firewall or edge device should be used to enforce the
          recommended order and the maximum occurrences of extension headers
          by dropping non-conforming nonconforming packets.</t>
        </section>
        <section title="Hop-by-Hop numbered="true" toc="default">
          <name>Hop-by-Hop Options Header"> Header</name>
          <t>In the previous IPv6 specification <xref target="RFC2460"/>, target="RFC2460" format="default"/>,
	  the hop-by-hop options header, when present in an IPv6 packet, forced
          all nodes to inspect and possibly process this header. This enabled
          denial-of-service attacks as most, if not all, routers cannot
          process this type of packet in hardware but hardware; they have to process these
          packets in software and hence compete and, hence, this task competes with other software tasks,
          such as handling the control and management plane processing.</t>

          <t>Section 4.3 of
          <t><xref target="RFC8200" sectionFormat="of" section="4.3"/>, the
	  current Internet Standard for IPv6, <xref
          target="RFC8200"/>, has taken this attack vector into account and
          made the processing of hop-by-hop options headers by intermediate
          routers explicitly configurable.</t>
        </section>
        <section anchor="fragments" title="Fragment Header"> numbered="true" toc="default">
          <name>Fragment Header</name>
          <t>The fragment header is used by the source (and only the source)
          when it has to fragment packets. <xref target="RFC7112"/> target="RFC7112" format="default"/> and
          section 4.5 of
          <xref target="RFC8200"/> target="RFC8200" sectionFormat="of" section="4.5"/> explain why it is
	  important
          that:<list>
              <t>Firewall that:</t>
          <ul spacing="normal">
            <li>Firewall and security devices should drop first fragments
              that do not contain the entire IPv6 header chain (including the
              transport-layer header).</t>

              <t>Destination header).</li>
            <li>Destination nodes should discard first fragments that do not
              contain the entire IPv6 header chain (including the
              transport-layer header).</t>
            </list></t> header).</li>
          </ul>
          <t>If those requirements are not met, stateless filtering could be
          bypassed by a hostile party. <xref target="RFC6980"/> target="RFC6980" format="default"/> applies a
          stricter rule to Neighbor Discovery Protocol (NDP) NDP by enforcing the
          drop of fragmented NDP packets (except for "Certification Path
          Advertisement" messages messages, as noted in section <xref
          target="rafiltering"/>). target="rafiltering" format="default"/>). <xref target="RFC7113"/> target="RFC7113" format="default"/> describes how the
          RA-guard
          RA-Guard function described in <xref target="RFC6105"/> target="RFC6105" format="default"/> should
          behave in the presence of fragmented RA packets.</t>
        </section>
        <section title="IP numbered="true" toc="default">
          <name>IP Security Extension Header"> Header</name>
          <t>The <xref target="RFC4301">IPsec</xref> target="RFC4301" format="default">IPsec</xref> extension headers (<xref
          target="RFC4302">AH</xref> target="RFC4302" format="default">Authentication Header (AH)</xref> and <xref target="RFC4303">ESP</xref>) target="RFC4303" format="default">ESP</xref>)
          are required if IPsec is to be utilized for network level network-level security.
          Previously, IPv6 mandated implementation of IPsec IPsec, but <xref
          target="RFC6434"/> target="RFC6434"
	  format="default"/> updated that recommendation by making support of
          the IPsec architecture <xref target="RFC4301"/> target="RFC4301" format="default"/> a SHOULD
	  '<bcp14>SHOULD</bcp14>' for all
          IPv6 nodes which is that are also retained in the latest IPv6 Nodes
          Requirement standard <xref target="RFC8504"/>.</t> target="RFC8504" format="default"/>.</t>
        </section>
      </section>
      <section anchor="linklayer" title="Link-Layer Security"> numbered="true" toc="default">
        <name>Link-Layer Security</name>
        <t>IPv6 relies heavily on NDP <xref target="RFC4861"/> target="RFC4861" format="default"/> to perform a
        variety of link operations operations, such as discovering other nodes on the
        link, resolving their link-layer addresses, and finding routers on the
        link. If not secured, NDP is vulnerable to various attacks, such as
        router/neighbor message spoofing, redirect attacks, Duplicate Address
        Detection (DAD) DoS attacks, etc. Many of these security threats to
        NDP have been documented in IPv6 ND "IPv6 Neighbor Discovery (ND) Trust Models and Threats Threats"
	<xref
        target="RFC3756"/> target="RFC3756" format="default"/> and in "Operational Neighbor Discovery
	Problems" <xref target="RFC6583"/>.</t> target="RFC6583" format="default"/>.</t>
        <t>Most of the issues are only applicable when the attacker is on the
        same link link, but NDP also has security issues when the attacker is
        off-link,
        off link; see the section below <xref target="ratelim"/>.</t> target="ratelim" format="default"/> below.</t>
        <section anchor="ratelim" title="Neighbor numbered="true" toc="default">
          <name>Neighbor Solicitation Rate-Limiting"> Rate-Limiting</name>
          <t>NDP can be vulnerable to remote denial of service (DoS) attacks; DoS attacks,
          for example, when a router is forced to perform address resolution
          for a large number of unassigned addresses, i.e., when a prefix is
          scanned by an attacker in a fast manner. This can keep new devices
          from joining the network or render the last-hop router ineffective
          due to high CPU usage. Easy mitigative steps include rate-limiting rate limiting
          Neighbor Solicitations, restricting the amount of state reserved for
          unresolved solicitations, and clever cache/timer management.</t> cleverly managing the cache/timer.</t>
          <t><xref target="RFC6583"/> target="RFC6583" format="default"/> discusses the potential for off-link DoS
          in detail and suggests implementation improvements and operational
          mitigation techniques that may be used to mitigate or alleviate the
          impact of such attacks. Here are some feasible mitigation options
          that can be employed by network operators today:<list
              style="symbols">
              <t>Ingress today:</t>
          <ul spacing="normal">
            <li>Ingress filtering of unused addresses by ACL. These require
              stable configuration of the addresses; for example, addresses, e.g., allocating
              the addresses out of a /120 and using a specific ACL to only
              allow traffic to this /120 (of course, the actual hosts are
              configured with a /64 prefix for the link).</t>

              <t>Tuning link).</li>
            <li>Tuning of NDP process (where supported), e.g., enforcing
              limits on data structures structures, such as the number of neighbor cache Neighbor Cache
              entries in 'incomplete' state (e.g., 256 incomplete entries per
              interface) or the rate of NA per interface (e.g., 100 NA per
              second).</t>

              <t>Using
              second).</li>
            <li>Using a /127 on a point-to-point link, per <xref
              target="RFC6164"/>.</t>

              <t>Using target="RFC6164" format="default"/>.</li>
            <li>Using only link-local addresses on links where there are only
              routers,
              routers; see <xref target="RFC7404"/></t>
            </list></t> target="RFC7404" format="default"/>.</li>
          </ul>
        </section>

        <!--ratelim-->

        <section anchor="filter"
                 title="Router numbered="true" toc="default">
          <name>Router and Neighbor Advertisements Filtering">
          <t/> Filtering</name>
          <section anchor="rafiltering" title="Router numbered="true" toc="default">
            <name>Router Advertisement Filtering"> Filtering</name>
            <t>Router Advertisement spoofing is a well-known well-known, on-link attack
            vector and has been extensively documented. The presence of rogue
            RAs, either unintentional or malicious, can cause partial or
            complete failure of operation of hosts on an IPv6 link. For
            example, a node can select an incorrect router address address, which can
            then be used for an on-path attack attack, or the node can assume wrong
            prefixes to be used for SLAAC. <xref target="RFC6104"/> target="RFC6104" format="default"/>
	    summarizes
            the scenarios in which rogue RAs may be observed and presents a
            list of possible solutions to the problem. <xref
            target="RFC6105"/> target="RFC6105" format="default"/> (RA-Guard) describes a solution framework for
            the rogue RA problem where network segments are designed around
            switching devices that are capable of identifying invalid RAs and
            blocking them before the attack packets actually reach the target
            nodes.</t>
            <t>However, several evasion techniques that circumvent the
            protection provided by RA-Guard have surfaced. A key challenge to
            this mitigation technique is introduced by IPv6 fragmentation.
            Attackers can conceal their attack by fragmenting their packets
            into multiple fragments such that the switching device that is
            responsible for blocking invalid RAs cannot find all the necessary
            information to perform packet filtering of the same packet. <xref
            target="RFC7113"/> target="RFC7113" format="default"/> describes such evasion techniques and provides
            advice to RA-Guard implementers such that the aforementioned
            evasion vectors can be eliminated.</t>
            <t>Given that the IPv6 Fragmentation Header can be leveraged to
            circumvent some implementations of RA-Guard, <xref
            target="RFC6980"/> target="RFC6980" format="default"/> updates <xref target="RFC4861"/> target="RFC4861" format="default"/> such that use
            of the IPv6 Fragmentation Header is forbidden in all Neighbor
            Discovery messages messages, except "Certification Path Advertisement", thus
            allowing for simple and effective measures to counter fragmented
            NDP attacks.</t>
          </section>
          <section title="Neighbor numbered="true" toc="default">
            <name>Neighbor Advertisement Filtering"> Filtering</name>
            <t>The Source Address Validation Improvements (SAVI) working group (savi) Working Group
            has worked on other ways to mitigate the effects of such attacks.
            <xref target="RFC7513"/> target="RFC7513" format="default"/> helps in creating bindings between a
            DHCPv4 <xref target="RFC2131"/> /DHCPv6 <xref target="RFC8415"/>
            assigned
	    source IP address assigned to
            DHCPv4 <xref target="RFC2131" format="default"/> or DHCPv6 <xref
	    target="RFC8415" format="default"/>
             and a binding anchor <xref
            target="RFC7039"/> target="RFC7039" format="default"/> on a SAVI
	     device. Also, <xref
            target="RFC6620"/> target="RFC6620" format="default"/> describes how to
	     glean similar bindings when
            DHCP is not used. The bindings can be used to filter packets
            generated on the local link with forged source IP addresses.</t>
          </section>
          <section title="Host Isolation"> numbered="true" toc="default">
            <name>Host Isolation</name>
            <t>Isolating hosts for the NDP traffic can be done by using a /64
            per host, refer to <xref target="sixty4perhost"/>, target="sixty4perhost" format="default"/>, as NDP is
	    only relevant within a /64 on-link prefix; 3GPP <xref
            target="threegpp"/> (<xref target="threegpp"
	    format="default"/>) uses a similar mechanism.</t>
            <t>A more drastic technique to prevent all NDP attacks is based on
            isolation of all hosts with specific configurations. In such a
            scenario, hosts (i.e., all nodes that are not routers) are unable
            to send data-link layer frames to other hosts, hosts; therefore, no
            host-to-host attacks can happen. This specific setup can be
            established on some switches or Wi-Fi access points. This is not
            always feasible when hosts need to communicate with other hosts in
            the same subnet, e.g., for access to file shares.</t>
          </section>
          <section title="NDP Recommendations"> numbered="true" toc="default">
            <name>NDP Recommendations</name>
            <t>It is still recommended that RA-Guard and SAVI be employed as a
            first line of defense against common attack vectors vectors, including
            misconfigured hosts. This recommendation also applies when DHCPv6
            is used, as RA messages are used to discover the default router(s)
            and for on-link prefix determination. This line of defense is most
            effective when incomplete fragments are dropped by routers and
            switches
            L2 switches, as described in <xref target="fragments"/>. target="fragments" format="default"/>. The
	    generated log should also be analyzed to identify and act on violations.
            </t> violations.</t>
            <t>Network operators should be aware that RA-Guard and SAVI do not
            work as expected or could even be harmful in specific network
            configurations (notably when there could be multiple routers).</t>
            <t>Enabling RA-Guard by default in managed networks (e.g., Wi-Fi
            networks, enterprise campus networks, etc.) should be strongly
            considered except for specific use cases cases, such as in the presence of
            homenet devices emitting router advertisements.</t>
          </section>
        </section>

        <!--filter-->

        <section anchor="snoop" title="Securing DHCP"> numbered="true" toc="default">
          <name>Securing DHCP</name>
          <t>The Dynamic Host Configuration Protocol for IPv6 (DHCPv6), as
          described in <xref target="RFC8415"/>, target="RFC8415" format="default"/>, enables DHCP servers to pass
          configuration parameters, such as IPv6 network addresses and other
          configuration information, to IPv6 nodes. DHCP plays an important
          role in most large networks by providing robust stateful
          configuration in the context of automated system provisioning.</t>
          <t>The two most common threats to DHCP clients come from malicious
          (a.k.a.,
          (a.k.a. rogue) or unintentionally misconfigured DHCP servers. in In
          these scenarios, a malicious DHCP server is established with the
          intent of providing incorrect configuration information to the
          clients to cause a denial-of-service attack or to mount an on-path
          attack. While unintentional, a misconfigured DHCP server can have
          the same impact. Additional threats against DHCP are discussed in
          the security considerations section of <xref target="RFC8415"/>.</t> target="RFC8415"
	  format="default"/>.</t>
          <t><xref target="RFC7610">DHCPv6-Shield, </xref>, target="RFC7610" format="default">DHCPv6-Shield</xref> specifies a
          mechanism for protecting connected DHCPv6 clients against rogue
          DHCPv6 servers. This mechanism is based on DHCPv6 packet-filtering packet filtering
          at the layer-2 L2 device, i.e., the administrator specifies the
          interfaces connected to DHCPv6 servers. However, extension headers
          could be leveraged to bypass DHCPv6-Shield unless <xref
          target="RFC7112"/> target="RFC7112" format="default"/> is enforced.</t>
          <t>It is recommended to use DHCPv6-Shield and to analyze the
          corresponding log messages.</t>
        </section>
        <section anchor="threegpp" title="3GPP numbered="true" toc="default">
          <name>3GPP Link-Layer Security">
          <!--NEED MORE REWORK: too long, should be more straight to the point MK--> Security</name>
          <t>The 3GPP link is a point-to-point like point-to-point-like link that has no
          link-layer address. This implies there can only be one end host (the
          mobile hand-set) handset) and the first-hop router (i.e., a GPRS Gateway GPRS
          Support Node (GGSN) or a Packet Data Network Gateway (PGW)) on that link. The
          GGSN/PGW never configures a non link-local non-link-local address on the link using
          the advertised /64 prefix on it; see <xref target="sixty4perhost"/>. target="sixty4perhost" format="default"/>.
          The advertised prefix must not be used for on-link determination.
          There is no need for address resolution on the 3GPP link, since
          there are no link-layer addresses. Furthermore, the GGSN/PGW assigns
          a prefix that is unique within each 3GPP link that uses IPv6
          stateless address autoconfiguration.
          Stateless Address Autoconfiguration. This avoids the necessity to
          perform DAD at the network level for every address generated by the
          mobile host. The GGSN/PGW always provides an IID to the cellular
          host for the purpose of configuring the link-local address and
          ensures the uniqueness of the IID on the link (i.e., no collisions
          between its own link-local address and the mobile host's
          address).</t>
          <t>The 3GPP link model itself mitigates most of the known
          NDP-related Denial-of-Service DoS attacks. In practice, the GGSN/PGW
          only needs to route all traffic to the mobile host that falls under
          the prefix assigned to it. As there is also a single host on the
          3GPP link, there is no need to defend that IPv6 address.</t>
          <t>See Section 5 of <xref target="RFC6459"/> target="RFC6459" sectionFormat="of" section="5"/> for a more detailed
          discussion on the 3GPP link model, NDP, and the address
          configuration details. In some mobile networks, DHCPv6 and DHCP-PD DHCP Prefix Delegation
	  (DHCP-PD) are also used.</t>
        </section>
        <section title="Impact numbered="true" toc="default">
          <name>Impact of Multicast Traffic"> Traffic</name>
          <t>IPv6 uses multicast extensively for signaling messages on the
          local link to avoid broadcast messages for on-the-wire
          efficiency.</t>
          <t>The use of multicast has some side effects on wireless networks,
          such as a negative impact on battery life of smartphones and other
          battery-operated devices that are connected to such networks. <xref
          target="RFC7772"/> target="RFC7772" format="default"/> and <xref target="RFC6775"/> target="RFC6775" format="default"/> (for specific
          wireless networks) discuss methods to rate-limit RAs and other ND
          messages on wireless networks in order to address this issue.</t>
          <t>The use of link-layer multicast addresses (e.g., ff02::1 for the
          all nodes link-local multicast address) could also be misused for an
          amplification attack. Imagine, Imagine a hostile node sending an ICMPv6
          ECHO_REQUEST to ff02::1 with a spoofed source address, then, then all
          link-local nodes will reply with ICMPv6 ECHO_REPLY packets to the
          source address. This could be a DoS attack for the address owner.
          This attack is purely local to the layer-2 network L2 network, as packets with a
          link-local destination are never forwarded by an IPv6 router.</t>
          <t>This is the reason why large Wi-Fi network deployments often
          limit the use of link-layer multicast multicast, either from or to the uplink
          of the Wi-Fi access point, i.e., Wi-Fi stations are prevented to
          send link-local multicast to their direct neighboring Wi-Fi
          stations; this policy also blocks service discovery via mDNS (<xref
          target="RFC6762"/>) Multicast DNS (mDNS)
	  <xref target="RFC6762" format="default"/> and LLMNR (<xref target="RFC4795"/>).</t> Link-Local Multicast Name
	  Resolution (LLMNR) <xref target="RFC4795" format="default"/>.</t>
        </section>
        <section anchor="send" title="SeND numbered="true" toc="default">
          <name>SEND and CGA"> CGA</name>
          <t>SEcure Neighbor Discovery (SeND), (SEND), as described in <xref
          target="RFC3971"/>, target="RFC3971" format="default"/>, is a mechanism that was designed to secure ND
          messages. This approach involves the use of new NDP options to carry
          public key-based
          public-key-based signatures. Cryptographically Generated Addresses
          (CGA), as described in <xref target="RFC3972"/>, target="RFC3972" format="default"/>, are used to ensure
          that the sender of a Neighbor Discovery message is the actual
          "owner" of the claimed IPv6 address. A new NDP option, the CGA
          option, was introduced and is used to carry the public key and
          associated parameters. Another NDP option, the RSA Signature option,
          is used to protect all messages relating to neighbor and Router router
          discovery.</t>

          <t>SeND
          <t>SEND protects against: <list style="symbols">
              <t>Neighbor </t>
          <ul spacing="normal">
            <li>Neighbor Solicitation/Advertisement Spoofing</t>

              <t>Neighbor Spoofing</li>
            <li>Neighbor Unreachability Detection Failure</t>

              <t>Duplicate Failure</li>
            <li>Duplicate Address Detection DoS Attack</t>

              <t>Router Attack</li>
            <li>Router Solicitation and Advertisement Attacks</t>

              <t>Replay Attacks</t>

              <t>Neighbor Attacks</li>
            <li>Replay Attacks</li>
            <li>Neighbor Discovery DoS Attacks</t>
            </list></t>

          <t>SeND Attacks</li>
          </ul>
          <t>SEND does NOT: <list style="symbols">
              <t>Protect </t>
          <ul spacing="normal">
            <li>protect statically configured addresses</t>

              <t>Protect addresses</li>
            <li>protect addresses configured using fixed identifiers (i.e.,
              EUI-64)</t>

              <t>Provide
              EUI-64)</li>
            <li>provide confidentiality for NDP communications</t>

              <t>Compensate communications</li>
            <li>compensate for an unsecured link - SeND -- SEND does not require that
              the addresses on the link and Neighbor Advertisements
              correspond.</t>
            </list></t>
              correspond</li>
          </ul>
          <t>However, at this time and over a decade since their original
          specifications, CGA and SeND SEND do not have support from widely
          deployed IPv6 devices; hence, their usefulness is limited and should
          not be relied upon.</t>
        </section>
      </section>
      <section anchor="copp" title="Control numbered="true" toc="default">
        <name>Control Plane Security"> Security</name>
        <t><xref target="RFC6192"/> target="RFC6192" format="default"/> defines the router control plane and
        provides detailed guidance to secure it for IPv4 and IPv6 networks.
        This definition is repeated here for the reader's convenience. Please
        note that the definition is completely protocol-version agnostic (most
        of this section applies to IPv6 in the same way as to IPv4).</t>
	<aside>
        <t>Preamble: IPv6 control plane security is vastly congruent with its
        IPv4 equivalent equivalent, with the exception of OSPFv3 authentication (<xref
        target="control"/>) target="control" format="default"/>) and some packet exceptions (see <xref
        target="exception"/>) target="exception" format="default"/>) that are specific to IPv6.</t>
	</aside>
        <t>Modern router architecture design maintains a strict separation of
        forwarding and router control plane hardware and software. The router
        control plane supports routing and management functions. It is
        generally described as the router architecture hardware and software
        components for handling packets destined to the device itself, itself as well
        as,
        as building and sending packets originated locally on the device. The
        forwarding plane is typically described as the router architecture
        hardware and software components responsible for receiving a packet on
        an incoming interface, performing a lookup to identify the packet's IP
        next hop and best outgoing interface towards the destination, and
        forwarding the packet through the appropriate outgoing interface.</t>
        <t>While the forwarding plane is usually implemented in high-speed
        hardware, the control plane is implemented by a generic processor
        (referred to as the route routing processor (RP)) and cannot process packets
        at a high rate. Hence, this processor can be attacked by flooding its
        input queue with more packets than it can process. The control plane
        processor is then unable to process valid control packets and the
        router can lose IGP or BGP adjacencies adjacencies, which can cause a severe
        network disruption.</t>
        <t><xref target="RFC6192"/> target="RFC6192" format="default"/> provides detailed guidance to protect the
        router control plane in IPv6 networks. The rest of this section
        contains simplified guidance.</t>
        <t>The mitigation techniques are: <list style="symbols">
            <t>To </t>
        <ul spacing="normal">
          <li>to drop non-legit illegitimate or potentially harmful control packets before
            they are queued to the RP (this can be done by a forwarding plane
            ACL) and</t>

            <t>To and</li>
          <li>to rate-limit the remaining packets to a rate that the RP can
            sustain. Protocol-specific protection should also be done (for
            example, a spoofed OSPFv3 packet could trigger the execution of
            the Dijkstra algorithm, algorithm; therefore, the frequency of Dijsktra Dijkstra
            calculations should be also rate-limited).</t>
          </list></t> be rate limited).</li>
        </ul>
        <t>This section will consider several classes of control packets:
        <list style="symbols">
            <t>Control protocols: routing protocols:
        </t>
        <dl newline="true" spacing="normal">
          <dt>Control protocols:</dt>
	  <dd>routing protocols, such as OSPFv3, BGP,
            RIPng, and
            Routing Information Protocol Next Generation (RIPng), and, by extension extension, NDP and ICMP</t>

            <t>Management protocols: SSH,
	  ICMP</dd>
          <dt>Management protocols:</dt>
	  <dd>Secure Shell (SSH), SNMP, NETCONF, Network Configuration Protocol (NETCONF), RESTCONF, IPFIX,
            etc.</t>

            <t>Packet exceptions: normal
	  IP Flow Information Export (IPFIX), etc.</dd>
          <dt>Packet exceptions:</dt>
	  <dd>normal data packets that require a specific
            processing
            processing, such as generating a packet-too-big ICMP message or
            processing the hop-by-hop options header.</t>
          </list></t> header</dd>
        </dl>
        <section anchor="control" title="Control Protocols"> numbered="true" toc="default">
          <name>Control Protocols</name>
          <t>This class includes OSPFv3, BGP, NDP, and ICMP.</t>
          <t>An ingress ACL to be applied on all the router interfaces for
          packets to be processed by the RP should be configured to: <list
              style="symbols">
              <t>drop </t>
          <ul spacing="normal">
            <li>drop OSPFv3 (identified by Next-Header being 89) and RIPng
              (identified by UDP port 521) packets from a non link-local non-link-local
              address (except for OSPFv3 virtual links)</t>

              <t>allow links)</li>
            <li>allow BGP (identified by TCP port 179) packets from all BGP
              neighbors and drop the others</t>

              <t>allow others</li>
            <li>allow all ICMP packets (transit and to the router
              interfaces)</t>
            </list></t>
              interfaces)</li>
          </ul>
	  <aside>
          <t>Note: dropping Dropping OSPFv3 packets which that are authenticated by IPsec
          could be impossible on some routers that are unable to parse the
          IPsec ESP or AH extension headers during ACL classification.</t>
	  </aside>
          <t>Rate-limiting of the valid packets should be done, done; see also <xref
          target="RFC8541"/> target="RFC8541"
	  format="default"/> for a side benefit for OSPv3. The exact
          configuration will depend on the available resources of the router
          (CPU, TCAM, ...).</t> Ternary Content-Addressable Memory (TCAM), etc.).</t>
        </section>

        <!--control-->

        <section anchor="mgmt" title="Management Protocols"> numbered="true" toc="default">
          <name>Management Protocols</name>
          <t>This class includes: includes SSH, SNMP, RESTCONF, NETCONF, gRPC, gRPC Remote Procedure Calls
	  (gRPC), syslog, NTP, etc.</t>
          <t>An ingress ACL to be applied on all the router interfaces (or at
          ingress interfaces of the security perimeter or by using specific
          features of the platform) should be configured for packets destined
          to the RP RP, such as: <list style="symbols">
              <t>Drop </t>
          <ul spacing="normal">
            <li>drop packets destined to the routers routers, except those belonging
              to protocols which that are used (for example, permit TCP 22 and drop
              all others when only SSH is used);</t>

              <t>Drop used) and</li>
            <li>drop packets where the source does not match the security
              policy, for
              policy (for example, if SSH connections should only be
              originated from the Network Operation Center (NOC), then the ACL
              should permit TCP port 22 packets only from the NOC prefix.</t>
            </list></t> prefix).</li>
          </ul>
          <t>Rate-limiting of valid packets should be done. The exact
          configuration will depend on the available router resources.</t>
        </section>

        <!--mgmt-->

        <section anchor="exception" title="Packet Exceptions"> numbered="true" toc="default">
          <name>Packet Exceptions</name>
          <t>This class covers multiple cases where a data plane packet is
          punted to the route processor because it requires specific
          processing: <list style="symbols">
              <t>generation </t>
          <ul spacing="normal">
            <li>generation of an ICMP packet-too-big message when a data
              plane packet cannot be forwarded because it is too large
              (required to discover the Path MTU);</t>

              <t>generation MTU);</li>
            <li>generation of an ICMP hop-limit-expired message when a data
              plane packet cannot be forwarded because its hop-limit field has
              reached 0 (also used by the traceroute utility);</t>

              <t>generation utility);</li>
            <li>generation of an ICMP destination-unreachable message when a
              data plane packet cannot be forwarded for any reason;</t>

              <t>processing reason;</li>
            <li>processing of the hop-by-hop options header, header; new
              implementations follow section 4.3 of <xref target="RFC8200"/> target="RFC8200" sectionFormat="of"
	      section="4.3"/> where this processing is optional;</t>

              <t>or more optional; or</li>
            <li>more specific to some router implementation: implementations, an oversized
              extension header chain which that cannot be processed by the hardware
              and cannot force the packet to be punted to the RP.</t>
            </list></t> RP.</li>
          </ul>
          <t>On some routers, not everything can be done by the specialized
          data plane hardware which that requires some packets to be 'punted' to
          the generic RP. This could include include, for example example, the processing of a
          long extension header chain in order to apply an ACL based on
          layer-4
          Layer 4 information. <xref target="RFC6980"/> target="RFC6980" format="default"/> and more generally
          <xref target="RFC7112"/> target="RFC7112" format="default"/> highlight the security implications of
          oversized extension header chains on routers and updates update the
          original IPv6 specifications, specifications <xref target="RFC2460"/>, target="RFC2460" format="default"/> such that
          the first fragment of a packet is required to contain the entire
          IPv6 header chain. Those changes are incorporated in the IPv6
          standard <xref target="RFC8200"/></t> target="RFC8200" format="default"/>.</t>
          <t>An ingress ACL cannot mitigate a control plane attack using these
          packet exceptions. The only protection for the RP is to rate-limit
          those packet exceptions that are forwarded to the RP, this RP. This means
          that some data plane packets will be dropped without an ICMP message
          sent to the source source, which may delay Path MTU discovery Discovery and cause
          drops.</t>
          <t>In addition to limiting the rate of data plane packets queued to
          the RP, it is also important to rate-limit the generation of ICMP
          messages. This is important both to preserve RP resources and also
          to prevent an amplification attack using the router as a reflector.
          It is worth noting that some platforms implement this rate-limiting
          in hardware. Of course, a consequence of not generating an ICMP
          message will break some IPv6 mechanisms mechanisms, such as Path MTU discovery Discovery
          or a simple traceroute.</t>
        </section>

        <!--exception-->
      </section>

      <!--copp-->

      <section anchor="rsec" title="Routing Security">
        <!-- Note to authors: Markus de Bruen would like to see this section shortened as it does not contain IPv6 specific --> numbered="true" toc="default">
        <name>Routing Security</name>
        <aside>
        <t>Preamble: IPv6 routing security is congruent with IPv4 routing
        security
        security, with the exception of OSPv3 neighbor authentication (see
        <xref target="auth"/>).</t> target="auth" format="default"/>).</t>
	</aside>
        <t>Routing security in general can be broadly divided into three
        sections: <list style="numbers">
            <t>Authenticating neighbors/peers</t>

            <t>Securing </t>
        <ol spacing="normal" type="1">
	  <li>authenticating neighbors/peers</li>
          <li>securing routing updates between peers</t>

            <t>Route filtering</t>
          </list></t> peers</li>
          <li>route filtering</li>
        </ol>
        <t><xref target="RFC5082"/> target="RFC5082" format="default"/> is also applicable to IPv6 and can ensure
        that routing protocol packets are coming from the local network; it
        must also be noted that in IPv6 all interior gateway protocols use
        link-local addresses.</t>
        <t>As for IPv4, it is recommended to enable a routing protocol only on
        interfaces where it is required.</t>
        <section title="BGP Security"> numbered="true" toc="default">
          <name>BGP Security</name>
          <t>As BGP is identical for IPv4 and IPv6 and as <xref
          target="RFC7454"/> target="RFC7454" format="default"/> covers all the security aspects for BGP in
          detail, <xref target="RFC7454"/> target="RFC7454" format="default"/> is also applicable to IPv6.</t>
        </section>
        <section anchor="auth" title="Authenticating numbered="true" toc="default">
          <name>Authenticating OSPFv3 Neighbors"> Neighbors</name>
          <t>OSPFv3 can rely on IPsec to fulfill the authentication function.
          Operators should note that IPsec support is not standard on all
          routing platforms. In some cases, this requires specialized hardware
          that offloads crypto over to dedicated ASICs Application-Specific Integrated Circuits
	  (ASICs) or enhanced software
          images (both of which often come with added financial cost) to
          provide such functionality. An added detail is to determine whether
          OSPFv3 IPsec implementations use AH or ESP-Null ESP-NULL for integrity
          protection. In early implementations, all OSPFv3 IPsec
          configurations relied on AH since the details weren't specified in
          <xref target="RFC5340"/>. target="RFC5340" format="default"/>.
	  However, the document which that specifically
          describes how IPsec should be implemented for OSPFv3 <xref
          target="RFC4552"/> specifically target="RFC4552"
	  format="default"/> states that "ESP-Null MUST "implementations <bcp14>MUST</bcp14> support ESP[-NULL] and AH
          MAY be implemented"
          <bcp14>MAY</bcp14> support AH" since it follows the overall IPsec standards
          wording. OSPFv3 can also use normal ESP to encrypt the OSPFv3
          payload to provide confidentiality for the routing information.</t>
          <t><xref target="RFC7166"/> target="RFC7166" format="default"/> changes OSPFv3 reliance on IPsec by
          appending an authentication trailer to the end of the OSPFv3
          packets; it
          packets. It does not specifically authenticate the specific
          originator of an OSPFv3 packet; rather, it allows a router to
          confirm that the packet has been issued by a router that had access
          to the shared authentication key.</t>
          <t>With all authentication mechanisms, operators should confirm that
          implementations can support re-keying rekeying mechanisms that do not cause
          outages. There have been instances where any re-keying rekeying causes
          outages and
          outages; therefore, the tradeoff trade-off between utilizing this
          functionality needs to be weighed against the protection it
          provides. <xref target="RFC4107"/> target="RFC4107" format="default"/> documents some guidelines for
          crypto keys management.</t>
        </section>

        <!--auth-->

        <section anchor="updates" title="Securing numbered="true" toc="default">
          <name>Securing Routing Updates"> Updates</name>
          <t>IPv6 initially mandated the provisioning of IPsec capability in
          all nodes. However, in the updated IPv6 Nodes Requirement standard
          <xref target="RFC8504"/>, target="RFC8504" format="default"/>, IPsec is a 'SHOULD' '<bcp14>SHOULD</bcp14>' and not a 'MUST'
          implement.
	  '<bcp14>MUST</bcp14>'
          implementation. Theoretically, it is possible that all communication
          between two IPv6 nodes, especially routers exchanging routing
          information, is encrypted using IPsec. In practice however, However, in practice,
          deploying IPsec is not always feasible given hardware and software
          limitations of the various platforms deployed.</t>
          <t>Many routing protocols support the use of cryptography to protect
          the routing updates, updates; the use of this protection is recommended; recommended.
          <xref target="RFC8177"/> target="RFC8177" format="default"/> is a YANG data model for key chains
	  that includes re-keying rekeying functionality.</t>
        </section>

        <!--updates-->

        <section anchor="rfilter" title="Route Filtering"> numbered="true" toc="default">
          <name>Route Filtering</name>
          <t>Route filtering policies will be different depending on whether
          they pertain to edge route filtering vs. or internal route filtering.
          At a minimum, the IPv6 routing policy policy, as it pertains to routing between
          different administrative domains domains, should aim to maintain parity with
          IPv4 from a policy perspective, e.g., <list style="symbols">
              <t>Filter internal-use, non-globally routable for example: </t>
          <ul spacing="normal">
            <li>filter internal-use IPv6 addresses that are not globally routable at
              the perimeter;</t>

              <t>Discard perimeter;</li>
            <li>discard routes
	    for bogon <xref target="CYMRU"/> target="CYMRU" format="default"/> and reserved
              space (see <xref target="RFC8190"/>);</t>

              <t>Configure target="RFC8190" format="default"/>); and</li>
            <li>configure ingress route filters that validate route origin,
              prefix ownership, etc. etc., through the use of various routing
              databases, e.g., <xref target="RADB"/>. target="RADB" format="default"/>. <xref target="RFC8210"/> target="RFC8210" format="default"/>
              formally validates the origin ASs Autonomous Systems (ASes) of BGP announcements. </t>
            </list></t> </li>
          </ul>
          <t>Some good guidance can be found at <xref target="RFC7454"/>.</t> target="RFC7454" format="default"/>.</t>
          <t>A valid routing table can also be used to apply network ingress
          filtering (see <xref target="RFC2827"/>).</t> target="RFC2827" format="default"/>).</t>
        </section>

        <!--rfilter-->
      </section>

      <!--rsec-->

      <section anchor="log" title="Logging/Monitoring"> numbered="true" toc="default">
        <name>Logging/Monitoring</name>
        <t>In order to perform forensic research in the cases of a security
        incident or detecting abnormal behavior, network operators should log
        multiple pieces of information. In some cases, this requires a
        frequent poll of devices via a Network Management Station.</t>
        <t>This logging should include, include but is not limited to: <list
            style="symbols">
            <t>logs </t>
        <ul spacing="normal">
          <li>logs of all applications using the network (including user
            space and kernel space) when available (for example example, web servers
            that the network operator manages);</t>

            <t>data manages);</li>
          <li>data from <xref target="RFC7011">IP target="RFC7011" format="default">IP Flow Information Export
            </xref>
            </xref>, also known as IPFIX;</t>

            <t>data IPFIX;</li>
          <li>data from various SNMP <xref target="RFC4293">MIBs</xref> target="RFC4293" format="default">MIBs</xref> or
            YANG data via RESTCONF <xref target="RFC8040"/> target="RFC8040" format="default">RESTCONF</xref> or NETCONF <xref
            target="RFC6241"/>;</t>

            <t>historical target="RFC6241" format="default">NETCONF</xref>;</li>
          <li>historical data of Neighbor Cache entries;</t>

            <t><xref target="RFC8415">stateful entries;</li>
          <li>
            <xref target="RFC8415" format="default">stateful DHCPv6</xref> lease cache,
            especially when a <xref target="RFC6221">relay target="RFC6221" format="default">relay agent</xref> is
            used;</t>

            <t>Source
            used;</li>
          <li><xref target="RFC7039" format="default">Source Address Validation Improvement (SAVI) <xref
            target="RFC7039"/>
	  (SAVI)</xref> events, especially the binding of an IPv6
            address to a MAC address and a specific switch or router
            interface;</t>

            <t>firewall
            interface;</li>
          <li>firewall ACL log;</t>

            <t>authentication logs;</li>
          <li>authentication server log;</t>

            <t><xref target="RFC2866">RADIUS</xref> logs; and</li>
          <li>
            <xref target="RFC2866" format="default">RADIUS</xref> accounting records.</t>
          </list></t> records.</li>
        </ul>
        <t>Please note that there are privacy issues or regulations related to
        how these logs are collected, stored, used, and safely discarded.
        Operators are urged to check their country legislation (e.g., General
        Data Protection Regulation <xref target="GDPR">GDPR</xref> target="GDPR" format="default"></xref> in the
        European Union).</t>
        <t>All those pieces of information can be used for:<list
            style="symbols">
            <t><xref target="forensic">forensic</xref> investigations such as for:</t>
        <ul spacing="normal">
          <li>
            <xref target="forensic" format="default">forensic</xref> investigations:
            who did what and when?</t>

            <t><xref target="correlation">correlation</xref>: when?</li>
          <li>
            <xref target="correlation" format="default">correlation</xref>: which IP
            addresses were used by a specific node (assuming the use of <xref
            target="RFC8981">privacy target="RFC8981" format="default">privacy extensions addresses </xref>)</t>

            <t><xref target="inventory">inventory</xref>: </xref>)?</li>
          <li>
            <xref target="inventory" format="default">inventory</xref>: which IPv6 nodes
	    are on my network?</t>

            <t><xref target="abnormal_behavior">abnormal network?</li>
          <li>
            <xref target="abnormal_behavior" format="default">abnormal behavior
            detection</xref>: unusual traffic patterns are often the symptoms
            of an abnormal behavior behavior, which is in turn a potential attack
            (denial-of-service,
            (denial of service, network scan, a node being part of a botnet,
            etc.)</t>
          </list></t>
            etc.).</li>
        </ul>
        <section anchor="data_sources" title="Data Sources"> numbered="true" toc="default">
          <name>Data Sources</name>
          <t>This section lists the most important sources of data that are
          useful for operational security.</t>
          <section title="Application Logs"> numbered="true" toc="default">
            <name>Application Logs</name>
            <t>Those logs are usually text files where the remote IPv6 address
            is stored in clear text cleartext (not binary). This can complicate the
            processing since one IPv6 address, for example 2001:db8::1 example, 2001:db8::1, can be
            written in multiple ways, such as:<list style="symbols">
                <t>2001:DB8::1 as:</t>
            <ul spacing="normal">
              <li>2001:DB8::1 (in uppercase)</t>

                <t>2001:0db8::0001 uppercase),</li>
              <li>2001:0db8::0001 (with leading 0)</t>

                <t>and many 0), and</li>
              <li>many other ways ways, including the reverse DNS mapping into
                a FQDN Fully Qualified Domain Name (FQDN) (which should not be trusted).</t>
              </list></t> trusted).</li>
            </ul>
            <t><xref target="RFC5952"/> target="RFC5952" format="default"/> explains this problem in detail and
            recommends the use of a single canonical format. This document
            recommends the use of <xref target="RFC5952">canonical target="RFC5952" format="default">canonical
            format</xref> for IPv6 addresses in all possible cases. If the
            existing application cannot log using the canonical format, then
            it is recommended to use an external post-processing program in
            order to canonicalize all IPv6 addresses.</t>
          </section>
          <section title="IP numbered="true" toc="default">
            <name>IP Flow Information Export by IPv6 Routers"> Routers</name>
            <t><xref target="RFC7012">IPFIX</xref> target="RFC7012" format="default">IPFIX</xref> defines some data elements
            that are useful for security:<list style="symbols">
                <t>nextHeaderIPv6, security:</t>
            <ul spacing="normal">
              <li>nextHeaderIPv6, sourceIPv6Address, and
                destinationIPv6Address;</t>

                <t>sourceMacAddress
                destinationIPv6Address</li>
              <li>sourceMacAddress and destinationMacAddress.</t>
              </list></t> destinationMacAddress</li>
            </ul>
            <t>The IP version is the ipVersion element defined in <xref
            target="IANA-IPFIX"/>.</t> target="IANA-IPFIX" format="default"/>.</t>
            <t>Moreover, IPFIX is very efficient in terms of data handling and
            transport. It can also aggregate flows by a key key, such as
            sourceMacAddress
            sourceMacAddress, in order to have aggregated data associated with
            a specific sourceMacAddress. This memo recommends the use of IPFIX
            and aggregation on nextHeaderIPv6, sourceIPv6Address, and
            sourceMacAddress.</t>
          </section>
          <section anchor="mib"
                   title="SNMP numbered="true" toc="default">
            <name>SNMP MIB and NETCONF/RESTCONF YANG Modules data Data by IPv6 Routers"> Routers</name>
            <t><xref target="RFC4293">RFC 4293</xref> target="RFC4293" format="default"></xref> defines a Management
            Information Base (MIB) for the two address families of IP. This
            memo recommends the use of:<list style="symbols">
                <t>ipIfStatsTable table of:</t>
            <ul spacing="normal">
              <li>ipIfStatsTable table, which collects traffic counters per
                interface;</t>

                <t>ipNetToPhysicalTable table
                interface, and</li>
              <li>ipNetToPhysicalTable table, which is the content of the
                Neighbor cache, Cache, i.e., the mapping between IPv6 and data-link
                layer addresses.</t>
              </list></t> addresses.</li>
            </ul>
            <t>There are also YANG modules relating to the two IP addresses address
            families and that can be used with <xref target="RFC6241"/> target="RFC6241" format="default"/> and <xref
            target="RFC8040"/>. target="RFC8040" format="default"/>. This memo recommends the use of:<list
                style="symbols">
                <t>interfaces-state/interface/statistics of:</t>
            <ul spacing="normal">
              <li>interfaces-state/interface/statistics from <xref
                target="RFC8343">ietf-interfaces@2018-02-20.yang</xref> target="RFC8343" format="default">ietf-interfaces@2018-02-20.yang</xref>, which
                contains counters for interfaces.</t>

                <t>ipv6/neighbor interfaces, and</li>
              <li>ipv6/neighbor from <xref
                target="RFC8344">ietf-ip@2018-02-22.yang</xref> target="RFC8344" format="default">ietf-ip@2018-02-22.yang</xref>, which is the
                content of the Neighbor cache, Cache, i.e., the mapping between IPv6
                and data-link layer addresses.</t>
              </list></t> addresses.</li>
            </ul>
          </section>
          <section anchor="ndp_cache" title="Neighbor numbered="true" toc="default">
            <name>Neighbor Cache of IPv6 Routers"> Routers</name>
            <t>The neighbor cache Neighbor Cache of routers contains all mappings between
            IPv6 addresses and data-link layer addresses. There are multiple
            ways to collect the current entries in the Neighbor Cache, notably notably,
            but not limited to:<list style="symbols">
                <t>the to:</t>
            <ul spacing="normal">
              <li>using the <xref target="mib">SNMP MIB</xref> target="mib" format="default">SNMP MIB</xref>, as
	      explained
                above;</t>

                <t>using above;</li>
              <li>using streaming telemetry or <xref
                target="RFC6241">NETCONF</xref> target="RFC6241"
	      format="default">NETCONF</xref> and <xref
                target="RFC8040">RESTCONF</xref> target="RFC8040"
	      format="default">RESTCONF</xref> to collect the operational
                state of the neighbor cache;</t>

                <t>also, by connecting Neighbor Cache; and</li>
              <li>connecting over a secure management channel (such
                as SSH) and explicitly requesting a neighbor cache Neighbor Cache dump via
                the Command Line Command-Line Interface (CLI) or another monitoring
                mechanism.</t>

                <!-- Mikael Abrahamsson: let's add some text around YANG as there is a model for doing just that -->
              </list></t>
                mechanism.</li>
              </ul>
            <t>The neighbor cache Neighbor Cache is highly dynamic dynamic, as mappings are added when
            a new IPv6 address appears on the network. This could be quite
            frequently with <xref target="RFC8981">privacy target="RFC8981" format="default">privacy extension
            addresses</xref> or when they are removed when the state goes from
            UNREACH to removed (the default time for a removal per <xref
            target="RFC4861">Neighbor target="RFC4861" format="default">Neighbor Unreachability Detection</xref>
            algorithm is 38 seconds for a host using Windows 7). This means
            that the content of the neighbor cache Neighbor Cache must periodically be
            fetched periodically at an interval which that does not exhaust the router resources
            and still provides valuable information (suggested (the suggested value is 30
            seconds
            seconds, but this should be verified in the actual deployment) and
            stored for later use.</t>
            <t>This is an important source of information because it is
            trivial (on a switch not using the <xref
            target="RFC7039">SAVI</xref> target="RFC7039" format="default">SAVI</xref> algorithm) to defeat the mapping
            between data-link layer address and an IPv6 address. Let us rephrase
            the previous statement: Put another way, having access to the current and past
            content of the neighbor cache Neighbor Cache has a paramount value for the
            forensic and audit trail. trails. It should also be noted that that, in certain
            threat models models, this information is also deemed valuable and could
            itself be a target.</t>
            <t>When using one /64 per host (<xref target="sixty4perhost"/>) target="sixty4perhost" format="default"/>)
	    or DHCP-PD, it is sufficient to keep the history of the allocated
            prefixes when combined with strict source address prefix
            enforcement on the routers and layer-2 L2 switches to prevent IPv6
            spoofing.</t>
          </section>
          <section anchor="stateful_dhcp" title="Stateful numbered="true" toc="default">
            <name>Stateful DHCPv6 Lease"> Lease</name>
            <t>In some networks, IPv6 addresses/prefixes are managed by a
            stateful <xref target="RFC8415">DHCPv6 target="RFC8415" format="default">DHCPv6 server</xref> that leases
            IPv6 addresses/prefixes to clients. It is indeed quite similar to
            DHCP for IPv4, so it can be tempting to use this DHCP lease file
            to discover the mapping between IPv6 addresses/prefixes and
            data-link layer addresses addresses, as is commonly used in IPv4
            networking.</t>
            <t>It is not so easy in the IPv6 networks, because not all nodes
            will use DHCPv6 (there are nodes which that can only do stateless
            autoconfiguration) but and also because DHCPv6 clients are identified
            not by their hardware-client address address, as in IPv4 IPv4, but by a DHCP
            Unique ID (DUID), which Identifier (DUID). The DUID can have several formats: some being the
            data-link layer address, some being the data-link layer address
            prepended with time information, or even an opaque number that
            requires correlation with another data source to be usable for
            operational security. Moreover, when the DUID is based on the
            data-link address, this address can be of any client interface
            (such as the wireless interface interface, while the client actually uses its
            wired interface to connect to the network).</t>
            <t>If a <xref target="RFC6221">lightweight target="RFC6221" format="default">lightweight DHCP relay
	    agent</xref>
            is used in a layer-2 L2 switch, then the DHCP servers also receive
            the Interface-ID information interface ID information, which could be saved in order to
            identify the interface on which the switch received a specific
            leased IPv6 address. Also, if a 'normal' (not lightweight) relay
            agent adds the data-link layer address in the option for <xref
            target="RFC4649">Relay Relay Agent Remote-ID</xref> or
	    Remote-ID <xref
            target="RFC6939"/>, target="RFC4649" format="default"></xref> <xref
	    target="RFC6939" format="default"/>, then the DHCPv6 server can keep
	    track of the data-link and leased IPv6 addresses.</t>
            <t>In short, the DHCPv6 lease file is less interesting than lease files for
            IPv4 networks. If possible, it is recommended to use DHCPv6
            servers that keep the relayed data-link layer address in addition
            to the DUID in the lease file file, as those servers have the equivalent
            information to IPv4 DHCP servers.</t>
            <t>The mapping between the data-link layer address and the IPv6
            address can be secured by deploying switches implementing the
            <xref target="RFC7513">SAVI</xref> target="RFC7513" format="default">SAVI</xref> mechanisms. Of course, this
            also requires that the data-link layer address is be protected by
            using a layer-2 mechanism L2 mechanism, such as <xref
            target="IEEE-802.1X"/>.</t> target="IEEE-802.1X" format="default"/>.</t>
          </section>
          <section anchor="radius_accounting" title="RADIUS numbered="true" toc="default">
            <name>RADIUS Accounting Log"> Log</name>
            <t>For interfaces where the user is authenticated via a <xref
            target="RFC2866">RADIUS</xref> target="RFC2866" format="default">RADIUS</xref> server, and if RADIUS accounting is
            enabled, then the RADIUS server receives accounting
            Acct-Status-Type records at the start and at the end of the
            connection
            connection, which include all IPv6 (and IPv4) addresses used by the
            user. This technique can be used notably for Wi-Fi networks with
            Wi-Fi Protected Address Access (WPA) or other <xref
            target="IEEE-802.1X">IEEE target="IEEE-802.1X" format="default">IEEE 802.1X</xref> wired interface interfaces on an
            Ethernet switch.</t>
          </section>
          <section title="Other numbered="true" toc="default">
            <name>Other Data Sources"> Sources</name>
            <t>There are other data sources for log information that must be
            collected (as currently collected in IPv4 networks):<list
                style="symbols">
                <t>historical mapping networks):</t>
            <ul spacing="normal">
              <li>historical mappings of IPv6 addresses to users of remote
                access VPN;</t>

                <t>historical VPN and</li>
              <li>historical mappings of MAC addresses to switch ports in a
                wired network.</t>
              </list></t> network.</li>
            </ul>
          </section>
        </section>
        <section title="Use numbered="true" toc="default">
          <name>Use of Collected Data"> Data</name>
          <t>This section leverages the data collected collected, as described in <xref
	  format="default" target="data_sources">before</xref> target="data_sources"></xref>, in order to
          achieve several security benefits. Section 9.1 of <xref
          target="RFC7934"/> target="RFC7934" sectionFormat="of"
	  section="9.1"/> contains more details about host tracking.</t>
          <section anchor="forensic" title="Forensic numbered="true" toc="default">
            <name>Forensic and User Accountability"> Accountability</name>
            <t>The forensic use case is when the network operator must locate
            an IPv6 address (and the assocated associated port, access point/switch, or
            VPN tunnel) that was present in the network at a certain time or
            is currently in the network.</t>
            <t>To locate an IPv6 address in an enterprise network where the
            operator has control over all resources, the source of information
            can be the neighbor cache, Neighbor Cache, or, if not found, the DHCP lease file.
            Then, the procedure is: <list style="numbers">
                <t>Based </t>
            <ol spacing="normal" type="1">
	      <li>based on the IPv6 prefix of the IPv6 address, address; find the
                router(s) which is(are) one or more
                routers that are used to reach this prefix (assuming
                that anti-spoofing mechanisms are used) used), perhaps based on an
                IPAM.</t>

                <t>Based
                IPAM.</li>
              <li>based on this limited set of routers, on the incident time time,
                and on the IPv6 address, address; retrieve the data-link address from
                the live neighbor cache, Neighbor Cache, from the historical neighbor cache Neighbor Cache
                data, or from SAVI events, or retrieve the data-link address
                from the DHCP lease file (<xref target="stateful_dhcp"/>).</t>

                <t>Based target="stateful_dhcp"
		format="default"/>).</li>
              <li>based on the data-link layer address, look-up address; look up the switch
                interface associated with the data-link layer address. In the
                case of wireless LAN with RADIUS accounting (see <xref
                target="radius_accounting"/>), target="radius_accounting" format="default"/>), the RADIUS log has the mapping
                between the user identification and the MAC address. If a
                Configuration Management Data Base Database (CMDB) is used, then it can
                be used to map the data-link layer address to a switch
                port.</t>
              </list></t>
                port.</li>
            </ol>
            <t>At the end of the process, the interface of the host
            originating,
            originating or the subscriber identity associated with, with the
            activity in question has been determined.</t>
            <t>To identify the subscriber of an IPv6 address in a residential
            Internet Service Provider, the starting point is the DHCP-PD
            leased prefix covering the IPv6 address; this prefix can often be
            linked to a subscriber via the RADIUS log. Alternatively, the
            Forwarding Information Base (FIB) of the Cable Modem Termination
            System (CMTS) or Broadband Network Gateway (BNG) indicates the CPE Customer Premises
	    Equipment (CPE)
            of the subscriber and the RADIUS log can be used to retrieve the
            actual subscriber.</t>
            <t>More generally, a mix of the above techniques can be used in
            most, if not all, networks.</t>
          </section>
          <section anchor="inventory" title="Inventory"> numbered="true" toc="default">
            <name>Inventory</name>
            <t><xref target="RFC7707">RFC 7707</xref> target="RFC7707" format="default"></xref> describes the
            difficulties for an attacker to scan an IPv6 network due to the
            vast number of IPv6 addresses per link (and why in some cases it
            can still be done). While the huge addressing space can sometimes
            be perceived as a 'protection', it also makes the inventory task
            difficult in an IPv6 network while it was trivial to do in an IPv4
            network (a simple enumeration of all IPv4 addresses, followed by a
            ping and a TCP/UDP port scan). Getting an inventory of all
            connected devices is of prime importance for a secure network
            operation.</t>
            <t>There are many ways to do an inventory of an IPv6 network.</t>
            <t>The first technique is to use passive inspection inspection, such as IPFIX.
            Using exported IPFIX information and extracting the list of all
            IPv6 source addresses allows finding all IPv6 nodes that sent
            packets through a router. This is very efficient but, alas, will
            not discover silent nodes that never transmitted packets
            traversing the IPFIX target router. Also, it must be noted that
            link-local addresses will never be discovered by this means. </t>
            <t>The second way is again to use the collected neighbor cache Neighbor Cache
            content to find all IPv6 addresses in the cache. This process will
            also discover all link-local addresses. See <xref
            target="ndp_cache"/>.</t> target="ndp_cache" format="default"/>.</t>
            <t>Another way that works only for a local network, network consists of
            sending a an ICMP ECHO_REQUEST to the link-local multicast address
            ff02::1
            ff02::1, which addresses all IPv6 nodes on the network. All nodes
            should reply to this ECHO_REQUEST ECHO_REQUEST, per <xref
            target="RFC4443"/>.</t> target="RFC4443"
	    format="default"/>.</t>
            <t>Other techniques involve obtaining data from DNS, parsing log
            files, and leveraging service discovery discovery, such as mDNS <xref
            target="RFC6762"/> and target="RFC6762"
	    format="default"/> <xref target="RFC6763"/>.</t> target="RFC6763" format="default"/>.</t>
            <t>Enumerating DNS zones, especially looking at reverse DNS
            records and CNAMES, CNAMEs, is another common method employed by various
            tools. As already mentioned in <xref target="RFC7707"/>, target="RFC7707" format="default"/>, this
            allows an attacker to prune the IPv6 reverse DNS tree, tree and hence
            enumerate it in a feasible time. Furthermore, authoritative
            servers that allow zone transfers (AXFR) (i.e., Authoritative Transfers (AXFRs)) may be a further
            information source. An interesting research paper has analysed analyzed the
            entropy in various IPv6 addresses: see <xref
            target="ENTROPYIP"/>.</t> target="ENTROPYIP" format="default"/>.</t>
          </section>
          <section anchor="correlation" title="Correlation"> numbered="true" toc="default">
            <name>Correlation</name>
            <t>In an IPv4 network, it is easy to correlate multiple logs, for
            example
            example, to find events related to a specific IPv4 address. A
            simple Unix grep command is enough to scan through multiple
            text-based files and extract all lines relevant to a specific IPv4
            address.</t>
            <t>In an IPv6 network, this is slightly more difficult because
            different character strings can express the same IPv6 address.
            Therefore, the simple Unix grep command cannot be used. Moreover,
            an IPv6 node can have multiple IPv6 addresses.</t>
            <t>In order to do correlation in IPv6-related logs, it is advised
            to have all logs in a format with only canonical IPv6 addresses
            <xref target="RFC5952"/>. target="RFC5952" format="default"/>. Then, the neighbor cache current (or
            historical) Neighbor Cache data set must be searched to find the data-link layer
            address of the IPv6 address. Then, Next, the current and historical
            neighbor cache
            Neighbor Cache data sets must be searched for all IPv6 addresses
            associated with this data-link layer address to derive the search
            set. The last step is to search in all log files (containing only
            IPv6 addresses in canonical format) for any IPv6 addresses in the
            search set.</t>
            <t>Moreover, <xref target="RFC7934"/> target="RFC7934" format="default"/> recommends using multiple
            IPv6 addresses per prefix, so, so the correlation must also be done
            among those multiple IPv6 addresses, for example example, by discovering in
            the <xref target="ndp_cache">NDP cache</xref> all IPv6 addresses
            associated with the same MAC address and interface.</t> interface in
            the <xref target="ndp_cache" format="default">NDP cache</xref>.</t>
          </section>
          <section anchor="abnormal_behavior"
                   title="Abnormal numbered="true" toc="default">
            <name>Abnormal Behavior Detection"> Detection</name>
            <t>Abnormal behavior (such as network scanning, spamming,
            denial-of-service)
            DoS) can be detected in the same way as in an IPv4
            network.<list style="symbols">
                <t>Sudden
            network:</t>
            <ul spacing="normal">
              <li>a sudden increase of traffic detected by interface counter
                (SNMP) or by aggregated traffic from <xref
                target="RFC7012">IPFIX records</xref>.</t>

                <t>Rapid target="RFC7012"
		format="default">IPFIX records</xref>,</li>
              <li>rapid growth of ND cache size.</t>

                <t>Change size, or</li>
              <li>change in traffic pattern (number of connections per
                second, number of connections per host...) host, etc.) observed with the
                use of <xref target="RFC7012">IPFIX</xref>.</t>
              </list></t> target="RFC7012" format="default">IPFIX</xref>.</li>
            </ul>
          </section>
        </section>
        <section title="Summary"> numbered="true" toc="default">
          <name>Summary</name>
          <t>While some data sources (IPFIX, MIB, switch CAM Content Addressable Memory (CAM)
	  tables, logs,
          ...) etc.) used in IPv4 are also used in the secure operation of an IPv6
          network, the DHCPv6 lease file is less reliable and the neighbor
          cache Neighbor
          Cache is of prime importance.</t>
          <t>The fact that there are multiple ways to express the same IPv6
          address in a character string renders the use of filters mandatory
          when correlation must be done.</t>
        </section>
      </section>
      <section anchor="coexistence"
               title="Transition/Coexistence Technologies"> numbered="true" toc="default">
        <name>Transition/Coexistence Technologies</name>
        <t>As it is expected that some networks will not run in a pure
        IPv6-only mode, the different transition mechanisms must be deployed
        and operated in a secure way. This section proposes operational
        guidelines for the most known most-known and deployed transition techniques.
        <xref target="RFC4942"/> target="RFC4942" format="default"/> also contains security considerations for
        transition or coexistence scenarios.</t>
        <section anchor="dual" title="Dual Stack"> numbered="true" toc="default">
          <name>Dual Stack</name>
          <t>Dual stack is often the first deployment choice for network
          operators. Dual stacking the network offers some advantages over
          other transition mechanisms. Firstly, the impact on existing IPv4
          operations is reduced. Secondly, in the absence of tunnels or
          address translation, the IPv4 and IPv6 traffic are native (easier to
          observe and secure) and should have the same network processing
          (network path, quality of service, ...). etc.). Dual stack enables a
          gradual termination of the IPv4 operations when the IPv6 network is
          ready for prime time. On the other hand, the operators have to
          manage two network stacks with the added complexities.</t>
          <t>From an operational security perspective, this now means that the
          network operator has twice the exposure. One needs to think about
          protecting both protocols now. At a minimum, the IPv6 portion of a
          dual-stacked network should be consistent with IPv4 from a security
          policy point of view. Typically, the following methods are employed
          to protect IPv4 networks at the edge or security perimeter: <list
              style="symbols">
              <t>ACLs </t>
          <ul spacing="normal">
            <li>ACLs to permit or deny traffic;</t>

              <t>Firewalls traffic,</li>
            <li>firewalls with stateful packet inspection;</t>

              <t>Application inspection, and</li>
            <li>application firewalls inspecting the application flows.</t>
            </list></t> flows.</li>
          </ul>
          <t>It is recommended that these ACLs and/or firewalls be
          additionally configured to protect IPv6 communications. The enforced
          IPv6 security must be congruent with the IPv4 security policy,
          otherwise policy;
          otherwise, the attacker will use the protocol version having that has the more
          relaxed security policy. Maintaining the congruence between security
          policies can be challenging (especially over time); it is
          recommended to use a firewall or an ACL manager that is dual-stack, dual stack,
          i.e., a system that can apply a single ACL entry to a mixed group of
          IPv4 and IPv6 addresses.</t>
          <t>Application firewalls work at the application layer and are
          oblivious to the IP version, i.e., they work as well for IPv6 as for
          IPv4 and the same application security policy will work for both
          protocol versions.</t>
          <t>Also, given the end-to-end connectivity that IPv6 provides, it is
          recommended that hosts be fortified against threats. General device
          hardening guidelines are provided in <xref target="device"/>.</t> target="device" format="default"/>.</t>
          <t>For many years, all host operating systems have IPv6 enabled by
          default, so, so it is possible even in an 'IPv4-only' network to attack
          layer-2 adjacent
          L2-adjacent victims via their IPv6 link-local address or via a
          global IPv6 address when the attacker provides rogue RAs or a rogue
          DHCPv6 service.</t>
          <t><xref target="RFC7123"/> target="RFC7123" format="default"/> discusses the security implications of
          native IPv6 support and IPv6 transition/coexistence technologies on
          "IPv4-only"
          'IPv4-only' networks and describes possible mitigations for the
          aforementioned issues.</t>
        </section>

        <!--dual-->

        <section anchor="transition" title="Encapsulation Mechanisms">
          <!-- Note to authors: Markus de Bruen would like to see this section shortened as it does not contain IPv6 specific --> numbered="true" toc="default">
          <name>Encapsulation Mechanisms</name>
          <t>There are many tunnels used for specific use cases. Except when
          protected by <xref target="RFC4301">IPsec</xref> target="RFC4301" format="default">IPsec</xref> or alternative
          tunnel encryption methods, all those tunnels have a number of
          security issues issues, as described in <xref target="RFC6169">RFC
          6169</xref>;<list style="symbols">
              <t>tunnel injection: a target="RFC6169"
	  format="default"></xref>:</t>
          <dl newline="true" spacing="normal">
            <dt>tunnel injection:</dt>
	    <dd>A malevolent actor knowing a few pieces of
              information (for example example, the tunnel endpoints and the
              encapsulation protocol) can forge a packet which that looks like a
              legitimate and valid encapsulated packet that will gladly be
              accepted by the destination tunnel endpoint. This is a specific
              case of spoofing;</t>

              <t>traffic interception: no spoofing.</dd>
            <dt>traffic interception:</dt>
	    <dd>No confidentiality is provided by the
              tunnel protocols (without the use of IPsec or alternative
              encryption methods), therefore methods); therefore, anybody on the tunnel path can
              intercept the traffic and have access to the clear-text cleartext IPv6
              packet; combined
              packet. Combined with the absence of authentication, an on-path
              attack can also be mounted;</t>

              <t>service theft: as mounted.</dd>
            <dt>service theft:</dt>
	    <dd>As there is no authorization, even a
              non-authorized an
              unauthorized user can use a tunnel relay for free (this is a
              specific case of tunnel injection);</t>

              <t>reflection attack: another injection).</dd>
            <dt>reflection attack:</dt>
	    <dd>Another specific use case of tunnel
              injection where the attacker injects packets with an IPv4
              destination address not matching the IPv6 address causing the
              first tunnel endpoint to re-encapsulate the packet to the
              destination...
              destination. Hence, the final IPv4 destination will not see
              the original IPv4 address but only the IPv4 address of the relay
              router.</t>

              <t>bypassing
              router.</dd>
            <dt>bypassing security policy: if policy:</dt>
	    <dd>If a firewall or an Intrusion
              Prevention System (IPS) is on the path of the tunnel, then it
              may neither inspect nor detect malevolent IPv6 traffic
              transmitted over the tunnel.</t>
            </list></t> tunnel.</dd>
          </dl>
          <t>To mitigate the bypassing of security policies, it is often
          recommended to block all automatic tunnels in default OS
          configuration (if they are not required) by denying IPv4 packets
          matching:<list style="symbols">
              <t>IP
          matching:</t>

          <dl newline="false" spacing="normal">
            <dt>IP protocol 41: this 41:</dt>
	    <dd>This will block <xref
              target="isatap">ISATAP</xref>, <xref
              target="sixtofour">6to4</xref>, <xref target="sixrd">6rd</xref>,
              as well as, <xref target="statictunnel">6in4</xref> tunnels;</t>

              <t>IP Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) (<xref
	    target="isatap" format="default"></xref>), 6to4 (<xref
	    target="sixtofour" format="default"></xref>), 6rd (<xref target="sixrd"
	    format="default"></xref>), and 6in4 (<xref target="statictunnel"
	    format="default"></xref>) tunnels.</dd>
            <dt>IP protocol 47: this 47:</dt>
	    <dd>This will block <xref
              target="statictunnel">GRE</xref> tunnels;</t>

              <t>UDP GRE (<xref target="statictunnel" format="default"></xref>)
	    tunnels.</dd>
            <dt>UDP port 3544: this 3544:</dt>
	    <dd>This will block the default encapsulation of
              <xref target="teredo">Teredo</xref> tunnels.</t>
            </list></t> Teredo
              (<xref target="teredo" format="default"></xref>) tunnels.</dd>
          </dl>
          <t><xref target="RFC2827">Ingress target="RFC2827" format="default">Ingress filtering</xref> should also
	  be applied on all tunnel endpoints endpoints, if applicable applicable, to prevent IPv6
          address spoofing.</t>
          <t>The reflection attack cited above should also be prevented by
          using an IPv6 ACL preventing the hair pinning of the traffic.</t>
          <t>As several of the tunnel techniques share the same encapsulation
          (i.e., IPv4 protocol 41) and embed the IPv4 address in the IPv6
          address, there are a set of well-known looping attacks described in
          <xref target="RFC6324">RFC 6324</xref>. target="RFC6324" format="default"></xref>. This RFC also proposes
          mitigation techniques.</t>
          <section anchor="statictunnel" title="Site-to-Site numbered="true" toc="default">
            <name>Site-to-Site Static Tunnels"> Tunnels</name>
            <t>Site-to-site static tunnels are described in <xref
            target="RFC2529">RFC 2529</xref> target="RFC2529"
	    format="default"></xref> and in <xref
            target="RFC2784">GRE</xref>. target="RFC2784"
	    format="default">GRE</xref>. As the IPv4 endpoints are statically
            configured and are not dynamic, they are slightly more secure
            (bi-directional
            (bidirectional service theft is mostly impossible) impossible), but traffic
            interception and tunnel injection are still possible. Therefore,
            the use of <xref target="RFC4301">IPsec</xref> target="RFC4301" format="default">IPsec</xref> in transport mode
            to protect the encapsulated IPv4 packets is recommended for those
            tunnels. Alternatively, IPsec in tunnel mode can be used to
            transport IPv6 traffic over a non-trusted an untrusted IPv4 network.</t>
          </section>
          <section anchor="isatap" title="ISATAP"> numbered="true" toc="default">
            <name>ISATAP</name>
            <t>ISATAP tunnels <xref target="RFC5214"/> target="RFC5214" format="default"/> are mainly used within
            a single administrative domain and to connect a single IPv6 host
            to the IPv6 network. This often implies that those systems are
            usually managed by a single entity; therefore, audit trail and
            strict anti-spoofing are usually possible possible, and this raises the
            overall security. Even if ISATAP is no more often used, its
            security issues are relevant relevant, per <xref target="KRISTOFF"/>.</t> target="KRISTOFF" format="default"/>.</t>
            <t>Special care must be taken to avoid a looping attack by
            implementing the measures of <xref target="RFC6324"/> target="RFC6324" format="default"/> and <xref
            target="RFC6964"/> target="RFC6964" format="default"/> (especially the section 3.6).</t> in Section <xref target="RFC6964" sectionFormat="bare" section="3.6"/>).</t>
            <t><xref target="RFC4301">IPsec</xref> target="RFC4301" format="default">IPsec</xref> in transport or tunnel mode
            can be used to secure the IPv4 ISATAP traffic to provide IPv6
            traffic confidentiality and prevent service theft.</t>
          </section>
          <section anchor="sixrd" title="6rd"> numbered="true" toc="default">
            <name>6rd</name>
            <t>While 6rd tunnels share the same encapsulation as <xref
            target="sixtofour">6to4 target="sixtofour"
	    format="default">6to4 tunnels</xref>, they are designed to be
            used within a single SP domain, domain; in other words, they are deployed
            in a more constrained environment (e.g., anti-spoofing, protocol
            41 filtering at the edge) than 6to4 tunnels and have few security
            issues other than lack of confidentiality. The security
            considerations (Section 12) of in <xref target="RFC5969"/> target="RFC5969" sectionFormat="of" section="12"/>
	    describes how to secure 6rd tunnels.</t>
            <t><xref target="RFC4301">IPsec</xref> target="RFC4301" format="default">IPsec</xref> for the transported
	    IPv6 traffic can be used if confidentiality is important.</t>
          </section>
          <section anchor="sixpe" title="6PE, numbered="true" toc="default">
            <name>6PE, 6VPE, and LDPv6"> LDPv6</name>
            <t>Organizations using MPLS in their core can also use 6PE IPv6 Provider Edge (6PE) <xref
            target="RFC4798"/> target="RFC4798" format="default"/> and 6VPE IPv6 Virtual Private Extension (6VPE) <xref target="RFC4659"/> target="RFC4659" format="default"/> to enable
            IPv6 access over MPLS. As 6PE and 6VPE are really similar to
            BGP/MPLS IP VPNs described in <xref target="RFC4364"/>, target="RFC4364" format="default"/>, the
            security properties of these networks are also similar to those
            described in <xref target="RFC4381"/> target="RFC4381" format="default"/> (please note that this RFC
            may resemble a published IETF work work, but it is not based on an IETF
            review and the IETF disclaims any knowledge of the fitness of this
            RFC for any purpose). They rely on:<list style="symbols">
                <t>Address on:</t>
            <ul spacing="normal">
              <li>address space, routing, and traffic separation with the
                help of VRFs (only applicable to 6VPE);</t>

                <t>Hiding 6VPE);</li>
              <li>hiding the IPv4 core, hence hence, removing all attacks against
                P-routers;</t>

                <t>Securing
                P-routers; and</li>
              <li>securing the routing protocol between CE Customer Edge (CE) and PE; Provider
	      Edge (PE); in the
                case of 6PE and 6VPE, link-local addresses (see <xref
                target="RFC7404"/>) target="RFC7404" format="default"/>) can be used and used, and, as these addresses cannot
                be reached from outside of the link, the security of 6PE and
                6VPE is even higher than an IPv4 BGP/MPLS IP VPN.</t>
              </list>LDPv6 VPN.</li>
            </ul>
            <t>LDPv6 itself does not induce new risks, risks; see also <xref
            target="RFC7552"/>.</t> target="RFC7552"
	    format="default"/>.</t>
          </section>
          <section anchor="dslite_first" title="DS-Lite">
            <t>DS-lite numbered="true" toc="default">
            <name>DS-Lite</name>
            <t>Dual-Stack Lite (DS-Lite) is also a translation mechanism and is therefore
            analyzed <xref target="dslite">further</xref> target="dslite" format="default">further</xref> in this document document,
	    as it includes IPv4 NAPT.</t>
          </section>

          <!--dslite_first-->

          <section anchor="map_first" title="Mapping numbered="true" toc="default">
            <name>Mapping of Address and Port"> Port</name>
            <t>With the encapsulation and translation versions of mapping Mapping of
            Address and Port (MAP) (<xref target="RFC7597">MAP-E</xref> -- abbreviated MAP-E <xref target="RFC7597" format="default"></xref> and MAP-T <xref target="RFC7599">MAP-T</xref>), target="RFC7599" format="default"></xref> -- the access
	    network is purely
            an IPv6 network network, and MAP protocols are used to provide IPv4 hosts
            on the subscriber network access to IPv4 hosts on the Internet.
            The subscriber router does stateful operations in order to map all
            internal IPv4 addresses and layer-4 Layer 4 ports to the IPv4 address and
            the set of layer-4 Layer 4 ports received through the MAP configuration
            process. The SP equipment always does stateless operations (either
            decapsulation or stateless translation). Therefore, as opposed to
            <xref target="dslite"/>, target="dslite" format="default"/>, there is no state-exhaustion state exhaustion DoS attack
            against the SP equipment because there is no state and there is no
            operation caused by a new layer-4 Layer 4 connection (no logging
            operation).</t>
            <t>The SP MAP equipment should implement all the security
            considerations of <xref target="RFC7597"/>; notably, target="RFC7597" format="default"/>, notably ensuring that
            the mapping of the IPv4 address and port are consistent with the
            configuration. As MAP has a predictable IPv4 address and port
            mapping, the audit logs are easier to use use, as there is a clear
            mapping between the IPv6 address and the IPv4 address and
            ports.</t>
          </section>
          <section anchor="sixtofour" title="6to4"> numbered="true" toc="default">
            <name>6to4</name>
            <t>In <xref target="RFC3056"/>; target="RFC3056" format="default"/>, 6to4 tunnels require
	    a public
            routable public-routable IPv4 address in order to work correctly. They can be used
            to provide either single IPv6 host connectivity to the IPv6
            Internet or multiple IPv6 networks connectivity to the IPv6
            Internet. The 6to4 relay was historically the anycast address
            defined in <xref target="RFC3068"/> target="RFC3068" format="default"/>, which has been
	    deprecated by
            <xref target="RFC7526"/> target="RFC7526" format="default"/> and is no longer used by recent
	    Operating
            Systems. Some security considerations are explained in <xref
            target="RFC3964"/>.</t> target="RFC3964" format="default"/>.</t>
            <t><xref target="RFC6343"/> target="RFC6343" format="default"/> points out that if an operator
            provides well-managed servers and relays for 6to4,
            non-encapsulated
            nonencapsulated IPv6 packets will pass through well-defined
            points (the native IPv6 interfaces of those servers and relays) at
            which security mechanisms may be applied. Client usage of 6to4 by
            default is now discouraged, and significant precautions are needed
            to avoid operational problems.</t>
          </section>
          <section anchor="teredo" title="Teredo"> numbered="true" toc="default">
            <name>Teredo</name>
            <t>Teredo tunnels <xref target="RFC4380"/> target="RFC4380" format="default"/> are mainly used in a
            residential environment because Teredo easily traverses an IPv4
            NAPT device thanks to its UDP encapsulation. Teredo tunnels
            connect a single host to the IPv6 Internet.
	    Teredo shares the same
            issues as other tunnels: no authentication, no confidentiality,
            possible spoofing spoofing, and reflection attacks.</t>
            <t><xref target="RFC4301">IPsec</xref> target="RFC4301" format="default">IPsec</xref> for the transported IPv6
            traffic is recommended.</t>
            <t>The biggest threat to Teredo is probably for an IPv4-only
            network
            network, as Teredo has been designed to easily traverse IPv4 NAT-PT
            devices
            devices, which are quite often co-located with a stateful firewall.
            Therefore, if the stateful IPv4 firewall allows unrestricted UDP
            outbound and accepts the return UDP traffic, then Teredo actually
            punches a hole in this firewall for all IPv6 traffic to the
            Internet
	    and from the Internet. Host policies can be deployed to
            block Teredo in an IPv4-only network in order to avoid this
            firewall bypass. On the IPv4 firewall firewall, all outbound UDP UDPs should be
            blocked except for the commonly used services (e.g., port 53 for
            DNS, port 123 for NTP, port 443 for QUIC, port 500 for IKE, Internet Key Exchange
	    Protocol (IKE), port 3478 for STUN, Session Traversal Utilities for NAT (STUN),
	    etc.).</t>
            <t>Teredo is now hardly ever used and no longer enabled by default
            in most environments, environments so it is less of a threat, threat; however, special
            consideration must be taken made in cases when devices with older or
            non-updated
            operating systems that have not been updated may be present and by default were
            running Teredo.</t>
          </section>
        </section>

        <!--tunnel-->

        <section anchor="xlate" title="Translation Mechanisms"> numbered="true" toc="default">
          <name>Translation Mechanisms</name>
          <t>Translation mechanisms between IPv4 and IPv6 networks are
          alternate coexistence strategies while networks transition to IPv6.
          While a framework is described in <xref target="RFC6144"/>, target="RFC6144" format="default"/>, the
          specific security considerations are documented with each individual
          mechanism. For the most part, they specifically mention interference
          with IPsec or DNSSEC deployments, how to mitigate spoofed traffic,
          and what some effective filtering strategies may be.</t>
          <t>While not really a transition mechanism to IPv6, this section
          also includes the discussion about the use of heavy IPv4-to-IPv4
          network address addresses and port translation to prolong the life of
          IPv4-only networks.</t>
          <section anchor="cgn" title="Carrier-Grade numbered="true" toc="default">
            <name>Carrier-Grade NAT (CGN)"> (CGN)</name>
            <t>Carrier-Grade NAT (CGN), also called NAT444 CGN or Large Scale Large-Scale
            NAT (LSN) or SP NAT NAT, is described in <xref target="RFC6264"/> target="RFC6264"
	    format="default"/> and
            is utilized as an interim measure to extend the use of IPv4 in a
            large service provider network until the provider can deploy an
            effective IPv6 solution. <xref target="RFC6598"/> target="RFC6598" format="default"/> requested a
            specific IANA allocated IANA-allocated /10 IPv4 address block to be used as
            address space shared by all access networks using CGN. This has
            been allocated as 100.64.0.0/10.</t>

            <t>Section 13 of <xref target="RFC6269"/>
            <t><xref target="RFC6269" sectionFormat="of" section="13"/> lists some specific
            security-related issues caused by large scale large-scale address sharing. The
            Security Considerations section of <xref target="RFC6598"/> target="RFC6598" format="default"/> also
            lists some specific mitigation techniques for potential misuse of
            shared address space. Some Law Enforcement Agencies law enforcement agencies have
            identified CGN as impeding their cyber-crime cybercrime investigations (for
            example
            example, see the <xref target="europol-cgn">Europol target="europol-cgn" format="default">Europol press
	    release on
            CGN</xref>). Many translation techniques (NAT64, DS-lite, ...) DS-Lite, etc.)
            have the same security issues as CGN when one part of the
            connection is IPv4-only.</t> IPv4 only.</t>
            <t><xref target="RFC6302"/> target="RFC6302" format="default"/> has recommendations for
            Internet-facing servers to also log the source TCP or UDP ports of
            incoming connections in an attempt to help identify the users
            behind such a CGN.</t>
            <t><xref target="RFC7422"/> target="RFC7422" format="default"/> suggests the use of deterministic
            address mapping in order to reduce logging requirements for CGN.
            The idea is to have a known algorithm for mapping the internal
            subscriber to/from public TCP and UDP ports.</t>
            <t><xref target="RFC6888"/> target="RFC6888" format="default"/> lists common requirements for CGNs.
            <xref target="RFC6967"/> target="RFC6967" format="default"/> analyzes some solutions to enforce
            policies on misbehaving nodes when address sharing is used. <xref
            target="RFC7857"/> target="RFC7857" format="default"/> also updates the NAT behavioral
            requirements.</t>
          </section>

          <!--cgn-->

          <section anchor="nat64" title="NAT64/DNS64 numbered="true" toc="default">
            <name>NAT64/DNS64 and 464XLAT"> 464XLAT</name>
            <t>Stateful NAT64 translation <xref target="RFC6146"/> target="RFC6146" format="default"/> allows
            IPv6-only clients to contact IPv4 servers using unicast UDP, TCP,
            or ICMP. It can be used in conjunction with DNS64 <xref
            target="RFC6147"/>, target="RFC6147"
	    format="default"/>, a mechanism which that synthesizes AAAA records
            from existing A records. There is also a stateless NAT64 <xref
            target="RFC7915"/>,
	    target="RFC7915" format="default"/>, which has similar security aspects but
	    with the added benefit of being stateless, so, stateless and is thereby less prone to a state exhaustion attack.</t>
            <t>The Security Consideration sections of <xref target="RFC6146"/> target="RFC6146" format="default"/>
            and <xref target="RFC6147"/> target="RFC6147" format="default"/> list the comprehensive issues; in
            section 8 of
            <xref target="RFC6147"/> target="RFC6147" sectionFormat="of" section="8"/>, there are some
            considerations on the interaction between NAT64 and DNSSEC. A
            specific issue with the use of NAT64 is that it will interfere
            with most IPsec deployments unless UDP encapsulation is used.</t>
            <t>Another translation mechanism relying on a combination of
            stateful and stateless translation, 464XLAT <xref
            target="RFC6877"/>, target="RFC6877" format="default"/>,
	    can be used to do host local a host-local translation from
            IPv4 to IPv6 and a network provider translation from IPv6 to IPv4,
            i.e., giving IPv4-only application access to an IPv4-only server
            over an IPv6-only network. 464XLAT shares the same security
            considerations as NAT64 and DNS64, however DNS64; however, it can be used without
            DNS64, avoiding the DNSSEC implications.</t>
          </section>

          <!--nat64-->

          <section anchor="dslite" title="DS-Lite"> numbered="true" toc="default">
            <name>DS-Lite</name>
            <t>Dual-Stack Lite (DS-Lite) <xref target="RFC6333"/> target="RFC6333" format="default"/> is a
            transition technique that enables a service provider to share IPv4
            addresses among customers by combining two well-known
            technologies: IP in IP (IPv4-in-IPv6) and IPv4 NAPT.</t>
            <t>Security considerations considerations, with respect to DS-Lite DS-Lite, mainly revolve
            around logging data, preventing DoS attacks from rogue devices (as
            the Address Family Translation Router (AFTR) <xref
            target="RFC6333"/> target="RFC6333"
	    format="default"/> function is stateful) stateful), and restricting service
            offered by the AFTR only to registered customers.</t>

            <t>Section 11 of <xref target="RFC6333"/>
            <t><xref target="RFC6333" sectionFormat="of" section="11"/> and section 2 of <xref
            target="RFC7785"/> target="RFC7785" sectionFormat="of" section="2"/> describe important security issues associated
            with this technology.</t>
          </section>

          <!--dslite-->
        </section>

        <!--xlate-->
      </section>

      <!--coexistence-->

      <section anchor="device" title="General numbered="true" toc="default">
        <name>General Device Hardening"> Hardening</name>
        <t>With almost all devices being IPv6 enabled by default and with many
        end points
        endpoints having IPv6 connectivity to the Internet, it is critical to
        also harden those devices against attacks over IPv6.</t>
        <t>The ame same techniques used to protect devices against attack attacks over IPv4
        should be used for IPv6 and should include, include but are not limited to:<list
            style="symbols">
            <t>Restrict to:</t>
        <ul spacing="normal">
          <li>restricting device access to authorized individuals</t>

            <t>Monitor individuals;</li>
          <li>monitoring and audit auditing access to the device</t>

            <t>Turn device;</li>
          <li>turning off any unused services on the end node</t>

            <t>Understand node</li>
          <li>understanding which IPv6 addresses are being used to source
            traffic and change changing defaults if necessary</t>

            <t>Use necessary;</li>
          <li>using cryptographically protected protocols for device management
            (SCP,
            (Secure Copy Protocol (SCP), SNMPv3, SSH, TLS, etc.)</t>

            <t>Use etc.);</li>
          <li>using host firewall capabilities to control traffic that gets
            processed by upper-layer protocols</t>

            <t>apply protocols;</li>
          <li>applying firmware, OS OS, and application patches/upgrades to the
            devices in a timely manner</t>

            <t>use multi-factor manner;</li>
          <li>using multifactor credentials to authenticate to devices</t>

            <t>Use devices; and</li>
          <li>using virus scanners to detect malicious programs</t>
          </list></t> programs.</li>
        </ul>
      </section>

      <!--device-->
    </section>

    <!--generic-->

    <section anchor="enterprise"
             title="Enterprises Specific numbered="true" toc="default">
      <name>Enterprises-Specific Security Considerations"> Considerations</name>
      <t>Enterprises <xref target="RFC7381"/> target="RFC7381" format="default"/> generally have robust network
      security policies in place to protect existing IPv4 networks. These
      policies have been distilled from years of experiential knowledge of
      securing IPv4 networks. At the very least, it is recommended that
      enterprise networks have parity between their security policies for both
      protocol versions. This section also applies to the enterprise part of
      all SP networks, i.e., the part of the network where the SP employees
      are connected.</t>
      <t>Security considerations in the enterprise can be broadly categorized
      into two groups: External external and Internal.</t> internal.</t>
      <section anchor="external" title="External numbered="true" toc="default">
        <name>External Security Considerations"> Considerations</name>
        <t>The external aspect deals with providing security at the edge or
        perimeter of the enterprise network where it meets the service
        provider's network. This is commonly achieved by enforcing a security
        policy
        policy, either by implementing dedicated firewalls with stateful packet
        inspection or a router with ACLs. A common default IPv4 policy on
        firewalls that could easily be ported to IPv6 is to allow all traffic
        outbound while only allowing specific traffic, such as established
        sessions, inbound (see also <xref target="RFC6092"/>). Section 3.2 of target="RFC6092" format="default"/>).
        <xref target="RFC7381"/> target="RFC7381" sectionFormat="of" section="3.2"/> also provides similar
	recommendations.</t>
        <t>Here are a few more things that could enhance the default policy:
        <list style="symbols">
            <t>Filter
        </t>
        <ul spacing="normal">
          <li>Filter internal-use IPv6 addresses at the perimeter, perimeter; this will
            also mitigate the vulnerabilities listed in <xref
            target="RFC7359"/></t>

            <t>Discard target="RFC7359" format="default"/>.</li>
          <li>Discard packets from and to bogon and reserved space, space; see also
            <xref target="CYMRU"/> target="CYMRU" format="default"/> and <xref target="RFC8190"/></t>

            <t>Accept target="RFC8190" format="default"/>.</li>
          <li>Accept certain ICMPv6 messages to allow proper operation of ND
            and PMTUD, Path MTU Discovery (PMTUD); see also <xref target="RFC4890"/> target="RFC4890" format="default"/> or <xref
            target="REY_PF"/> target="REY_PF" format="default"/> for hosts</t>

            <t>Based hosts.</li>
          <li>Based on the use of the network, filter specific extension
            headers by accepting only the required ones (permit list approach) approach),
            such as ESP, AH, and not forgetting the required transport layers:
            ICMP, TCP, UDP, ... etc. This filtering should be done where applicable
            at the edge and possibly inside the perimeter; see also <xref
            target="I-D.ietf-opsec-ipv6-eh-filtering"/></t>

            <t>Filter target="I-D.ietf-opsec-ipv6-eh-filtering" format="default"/>.</li>
          <li>Filter packets having an illegal IPv6 headers header chain at the
            perimeter (and (and, if possible, inside the network as well), well); see <xref
            target="ext_headers"/></t>

            <t>Filter target="ext_headers" format="default"/>.</li>
          <li>Filter unneeded services at the perimeter</t>

            <t>Implement perimeter.</li>
          <li>Implement ingress and egress anti-spoofing in the forwarding
            and control planes, planes; see <xref target="RFC2827"/> target="RFC2827" format="default"/> and <xref
            target="RFC3704"/></t>

            <t>Implement target="RFC3704" format="default"/>.</li>
          <li>Implement appropriate rate-limiters and control-plane control plane policers
            based on traffic baselines</t>
          </list></t> baselines.</li>
        </ul>
        <t>Having global IPv6 addresses on all the enterprise sites is
        different than in IPv4 IPv4, where <xref target="RFC1918"/> target="RFC1918" format="default"/> addresses are
        often used internally and not routed over the Internet. <xref
        target="RFC7359"/> target="RFC7359" format="default"/> and <xref target="WEBER_VPN"/> target="WEBER_VPN" format="default"/> explain that without
        careful design, there could be IPv6 leakages from layer-3 Layer 3 VPNs.</t>
      </section>

      <!-- external-->

      <section anchor="internal" title="Internal numbered="true" toc="default">
        <name>Internal Security Considerations"> Considerations</name>
        <t>The internal aspect deals with providing security inside the
        perimeter of the network, including end hosts. Internal networks of
        enterprises are often different: different, e.g., University campus, wireless guest
        access, ... etc., so there is no "one size fits all" recommendation.</t>
        <t>The most significant concerns here are related to Neighbor
        Discovery. At the network level, it is recommended that all security
        considerations discussed in <xref target="linklayer"/> target="linklayer" format="default"/> be reviewed
        carefully and the recommendations be considered in-depth as well.
        Section 4.1 of
        <xref target="RFC7381"/> target="RFC7381" sectionFormat="of" section="4.1"/> also provides some
        recommendations.</t>
        <t>As mentioned in <xref target="transition"/>, target="transition" format="default"/>, care must be taken
        when running automated IPv6-in-IPv4 tunnels.</t>
        <t>When site-to-site VPNs are used used, it should be kept in mind that,
        given the global scope of IPv6 global addresses as opposed to the
        common use of IPv4 private address space <xref target="RFC1918"/>, target="RFC1918" format="default"/>,
        sites might be able to communicate with each other over the Internet
        even when the VPN mechanism is not available and hence available. Hence, no traffic
        encryption is performed and traffic could be injected from the
        Internet into the site, site; see <xref target="WEBER_VPN"/>. target="WEBER_VPN" format="default"/>. It is
        recommended to filter at Internet connection(s) packets having a
        source or destination address belonging to the site internal
        prefix(es);
        prefix or prefixes; this should be done for ingress and egress traffic.</t>
        <t>Hosts need to be hardened directly through security policy to
        protect against security threats. The host firewall default
        capabilities have to be clearly understood. In some cases, 3rd party third-party
        firewalls have no IPv6 support support, whereas the native firewall installed
        by default has IPv6 support. General device hardening guidelines are
        provided in <xref target="device"/>.</t> target="device" format="default"/>.</t>
        <t>It should also be noted that many hosts still use IPv4 for
        transporting logs for RADIUS, DIAMETER, TACACS+, SYSLOG, syslog, etc.
        Operators cannot rely on an IPv6-only security policy to secure such
        protocols that are still using IPv4.</t>
      </section>

      <!-- internal-->
    </section>

    <!-- enterprise-->

    <section anchor="sp" title="Service Providers numbered="true" toc="default">
      <name>Service Provider Security Considerations"> Considerations</name>
      <section anchor="bgp" title="BGP"> numbered="true" toc="default">
        <name>BGP</name>
        <t>The threats and mitigation techniques are identical between IPv4
        and IPv6. Broadly speaking speaking, they are: <list style="symbols">
            <t>Authenticating </t>
        <ul spacing="normal">
          <li>authenticating the TCP session;</t>

            <t>TTL session;</li>
          <li>TTL security (which becomes hop-limit security in IPv6) IPv6), as in
            <xref target="RFC5082"/>;</t>

            <t>bogon target="RFC5082" format="default"/>;</li>
          <li>bogon AS filtering, filtering; see <xref target="CYMRU"/>;</t>

            <t>Prefix filtering.</t>
          </list> target="CYMRU" format="default"/>; and</li>
          <li>prefix filtering.</li>
        </ul>
        <t> These are explained in more detail in <xref target="rsec"/>. target="rsec" format="default"/>.
        Also, the recommendations of <xref target="RFC7454"/> target="RFC7454" format="default"/> should be
        considered.</t>
        <section anchor="rtbh"
                 title="Remote numbered="true" toc="default">
          <name>Remote Triggered Black Hole Filtering (RTBH)">
          <t>RTBH Filtering</name>
          <t>A Remote Triggered Black Hole (RTBH) <xref target="RFC5635"/> target="RFC5635" format="default"/> works identically in IPv4 and IPv6.
          IANA has allocated the 100::/64 prefix to be used as the discard
          prefix <xref target="RFC6666"/></t> target="RFC6666" format="default"/>.</t>
        </section>

        <!---->
      </section>

      <!-- BGP-->

      <section anchor="sptrans" title="Transition/Coexistence Mechanism"> numbered="true" toc="default">
        <name>Transition/Coexistence Mechanism</name>
        <t>SPs will typically use transition mechanisms mechanisms, such as 6rd, 6PE, MAP,
        and NAT64 NAT64, which have been analyzed in the transition and coexistence
        <xref target="coexistence"/> section.</t>
        (<xref target="coexistence" format="default"/>).</t>
      </section>

      <!-- sptrans-->

      <section anchor="li" title="Lawful Intercept"> numbered="true" toc="default">
        <name>Lawful Intercept</name>
        <t>The Lawful Intercept lawful intercept requirements are similar for IPv6 and IPv4
        architectures and will be subject to the laws enforced in different
        geographic regions. The local issues with each jurisdiction can make
        this challenging and both corporate legal and privacy personnel should
        be involved in discussions pertaining to what information gets logged
        and with regard to the respective log retention policies for this
        information.</t>

        <t>The target of interception will usually be a residential subscriber
        (e.g., his/her PPP session, physical line, or CPE MAC address). In the
        absence of IPv6 NAT on the CPE, IPv6 has the possibility to allow for
        intercepting the traffic from a single host (i.e., a /128 target)
        rather than the whole set of hosts of a subscriber (which could be a
        /48, /60, or /64).</t>
        <t>In contrast, in mobile environments, since the 3GPP specifications
        allocate a /64 per device, it may be sufficient to intercept traffic
        from the /64 rather than specific /128's /128s (since each time the device
        establishes a data connection connection, it gets a new IID).</t>
      </section>

      <!-- li -->
    </section>

    <!-- SP-->

    <section anchor="residential"
             title="Residential numbered="true" toc="default">
      <name>Residential Users Security Considerations"> Considerations</name>
      <t>The IETF Homenet working group Home Networking (homenet) Working Group is working on standards and
      guidelines
      for IPv6 residential networks; this obviously includes operational
      security considerations; considerations, but this is still a work in progress. <xref
      target="RFC8520"/> target="RFC8520" format="default"/> is an interesting approach on how firewalls could
      retrieve and apply specific security policies to some residential
      devices.</t>
      <t>Some residential users have less experience and knowledge about
      security or networking than experimented operators. As most of the
      recent hosts (e.g., smartphones, smartphones and tablets) have IPv6 enabled by default,
      IPv6 security is important for those users. Even with an IPv4-only ISP,
      those users can get IPv6 Internet access with the help of <xref
      target="teredo">Teredo</xref> target="teredo" format="default">Teredo</xref> tunnels. Several peer-to-peer programs
      support IPv6 IPv6, and those programs can initiate a Teredo tunnel through an
      IPv4 residential gateway, with the consequence of making the internal
      host reachable from any IPv6 host on the Internet. It Therefore, it is therefore
      recommended that all host security products (including personal
      firewalls) are configured with a dual-stack security policy.</t>
      <t>If the residential CPE has IPv6 connectivity, <xref
      target="RFC7084"/> target="RFC7084" format="default"/> defines the requirements of an IPv6 CPE and does not
      take a position on the debate of default IPv6 security policy policy, as defined
      in <xref target="RFC6092"/>:<list style="symbols">
          <t>outbound only: allowing target="RFC6092" format="default"/>:</t>
      <dl newline="true" spacing="normal">
        <dt>outbound only:</dt>
	<dd>Allowing all internally initiated connections and
          block
          blocking all externally initiated ones, which is a common default
          security policy enforced by IPv4 Residential Gateway residential gateway doing NAPT NAPT, but
          it also breaks the end-to-end reachability promise of IPv6. <xref
          target="RFC6092"/>
	  target="RFC6092"
	  format="default"/> lists several recommendations to design such a
          CPE;</t>

          <t>open/transparent: allowing
          CPE.</dd>
        <dt>open/transparent:</dt>
	<dd>Allowing all internally and externally
          initiated connections, therefore therefore, restoring the end-to-end nature of
          the Internet for IPv6 traffic but having a different security policy
          for IPv6 than for IPv4.</t>
        </list></t>

      <t><xref target="RFC6092"/> REC-49 IPv4.</dd>
      </dl>
      <t>REC-49 states that a choice must be given to
      the user to select one of those two policies.</t> policies <xref target="RFC6092" format="default"/>.</t>
    </section>

    <!-- residentialThe -->

    <section title="Further Reading"> numbered="true" toc="default">
      <name>Further Reading</name>
      <t>There are several documents that describe in more detail the security
      of an IPv6 network; these documents are not written by the IETF and some
      of them are dated but are listed here for the reader's convenience:<list
          style="numbers">
          <t><xref target="NIST">Guidelines convenience:</t>
      <ul spacing="normal">
	<li>Guidelines for the Secure Deployment of
          IPv6</xref></t>

          <t><xref target="NAv6TF_Security">North IPv6 <xref target="NIST"
	format="default"></xref></li>
        <li>North American IPv6 Task Force Technology Report - IPv6 Security Technology Paper</xref></t>

          <t><xref target="IPv6_Security_Book">IPv6 Security</xref></t>
        </list></t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>The authors would like to thank the following people for their useful
      comments: Mikael Abrahamsson, Fred Baker, Mustafa Suha Botsali, Mohamed
      Boucadair, Brian Carpenter, Tim Chown, Lorenzo Colitti, Roman Danyliw
      (IESG review), Markus de Bruen, Lars Eggert (IESG review), Tobias
      Fiebig, Fernando Gont, Jeffry Handal, Lee Howard, Benjamin Kaduk (IESG
      review), Panos Kampanakis, Erik Kline, Jouni Korhonen, Warren Kumari
      (IESG review), Ted Lemon, Mark Lentczner, Acee Lindem (and his detailed
      nits), Jen Linkova (and her detailed review), Gyan S. Mishra (the
      document shepherd), Jordi Palet, Alvaro Retana (IESG review),
      Zaheduzzaman Sarker (IESG review), Bob Sleigh, Donald Smith, Tarko
      Tikan, Ole Troan, Bernie Volz (by alphabetical order).</t> Paper
	<xref target="NAv6TF_Security" format="default"></xref></li>
        <li>IPv6 Security <xref target="IPv6_Security_Book" format="default"></xref></li>
      </ul>
    </section>

    <section anchor="Security" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>This memo attempts to give an overview of security considerations of
      operating an IPv6 network both for an IPv6-only network and for networks
      utilizing the most widely deployed IPv4/IPv6 coexistence strategies.</t>
    </section>
    <section anchor="IANA_Considerations" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This document has no IANA actions.</t>
    </section>
  </middle>

  <!--  *****BACK MATTER ***** -->
  <back>
    <references title="Normative References">
      <!-- Here we use entities that we defined at the beginning. -->

      &RFC8200;

<displayreference target="I-D.kampanakis-6man-ipv6-eh-parsing" to="IPV6-EH-PARSING"/>
<displayreference target="I-D.ietf-opsec-ipv6-eh-filtering" to="IPV6-EH-FILTERING"/>

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>

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

    <references title="Informative References">

      &RFC0826;

      &RFC1918;

      &RFC2131;

      &RFC2460;

      &RFC2529;

      &RFC2663;

      &RFC2784;

      &RFC2827;

      &RFC2866;

      &RFC3056;

      &RFC3068;

      &RFC3627;

      &RFC3704;

      &RFC3756;

      &RFC3924;

      &RFC3964;

      &RFC3971;

      &RFC3972;

      &RFC4107;

      &RFC4033;

      &RFC4302;

      &RFC4303;

      &RFC4193;

      &RFC4293;

      &RFC4301;

      &RFC4364;

      &RFC4380;

      &RFC4381;

      &RFC4443;

      &RFC4552;

      &RFC4649;

      &RFC4659;

      &RFC4795;

      &RFC4798;

      &RFC4861;

      &RFC4864;

      &RFC4890;

      &RFC8981;

      &RFC4942;

      &RFC5082;

      &RFC5214;

      &RFC5340;

      &RFC5635;

      &RFC5952;

      &RFC5969;

      &RFC6092;

      &RFC6104;

      &RFC6105;

      &RFC6144;

      &RFC6146;

      &RFC6147;

      &RFC6164;

      &RFC6169;

      &RFC6177;

      &RFC6192;

      &RFC6221;

      &RFC6241;

      &RFC6264;

      &RFC6269;

      &RFC6296;

      &RFC6302;

      &RFC6324;

      &RFC6343;

      &RFC6434;

      &RFC6333;

      &RFC6459;

      &RFC6547;

      &RFC6564;

      &RFC6583;

      &RFC6598;

      &RFC6620;

      &RFC6666;

      &RFC6762;

      &RFC6763;

      &RFC6775;

      &RFC6877;

      &RFC6888;

      &RFC6939;

      &RFC6964;

      &RFC6967;

      &RFC6980;

      &RFC7010;

      &RFC7011;

      &RFC7012;

      &RFC7039;

      &RFC7045;

      &RFC7050;

      &RFC7084;

      &RFC7112;

      &RFC7113;

      &RFC7123;

      &RFC7166;

      &RFC7217;

      &RFC7359;

      &RFC7381;

      &RFC7404;

      &RFC7422;

      &RFC7454;

      &RFC7513;

      &RFC7526;

      &RFC7552;

      &RFC7597;

      &RFC7599;

      &RFC7610;

      &RFC7707;

      &RFC7721;

      &RFC7785;

      &RFC7772;

      &RFC7824;

      &RFC7844;

      &RFC7857;

      &RFC7872;

      &RFC7915;

      &RFC7934;

      &RFC8040;

      &RFC8064;

      &RFC8190;

      &RFC8177;

      &RFC8210;

      &RFC8273;

      &RFC8343;

      &RFC8344;

      &RFC8415;

      &RFC8504;

      &RFC8520;

      &RFC8541;
      <references>
        <name>Informative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.0826.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1918.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2131.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2460.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2529.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2663.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2784.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2827.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2866.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3056.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3068.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3627.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3704.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3756.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3964.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3971.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3972.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4107.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4033.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4302.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4303.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4193.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4293.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4301.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4364.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4380.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4381.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4443.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4552.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4649.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4659.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4795.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4798.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4861.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4864.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4890.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8981.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4942.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5082.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5214.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5340.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5635.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5952.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5969.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6092.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6104.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6105.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6144.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6146.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6147.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6164.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6169.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6177.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6192.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6221.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6241.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6264.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6269.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6296.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6302.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6324.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6343.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6434.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6333.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6459.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6547.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6564.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6583.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6598.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6620.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6666.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6762.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6763.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6775.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6877.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6888.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6939.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6964.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6967.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6980.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7010.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7011.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7012.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7039.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7045.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7084.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7112.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7113.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7123.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7166.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7217.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7359.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7381.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7404.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7422.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7454.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7513.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7526.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7552.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7597.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7599.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7610.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7707.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7721.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7785.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7772.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7824.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7844.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7857.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7872.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7915.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7934.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8040.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8064.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8190.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8177.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8210.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8273.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8343.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8344.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8415.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8504.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8520.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8541.xml"/>

        <reference anchor="IANA-IPFIX" target="http://www.iana.org/assignments/ipfix">
          <front>
            <title>IP Flow Information Export (IPFIX) Entities</title>
            <author>
              <organization>IANA</organization>
            </author>

          <date/>
          </front>
        </reference>

<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.kampanakis-6man-ipv6-eh-parsing.xml"/>

<reference anchor="I-D.kampanakis-6man-ipv6-eh-parsing"> anchor='I-D.ietf-opsec-ipv6-eh-filtering'>
<front>
          <title>Implementation Guidelines for parsing IPv6 Extension
          Headers</title>

          <author fullname="Panos Kampanakis" initials="P"
                  surname="Kampanakis">
            <organization/>
          </author>

          <date day="5" month="August" year="2014"/>

          <abstract>
            <t>IPv6 is widely used
<title>Recommendations on the internet today and is expected to be
            deployed more as more devices (i.e., home automation) get inter-
            connected. The IPv6 header format allows for the use Filtering of Extension
            Headers (EH). EHs could be chained together with very few existing
            guidelines by the IPv6 protocol on how devices should parse them,
            which open room for security concerns and inconsistencies. This
            document presents guidelines for parsing Packets Containing IPv6 EHs with a goal of
            providing a common and consistent parsing methodology for IPv6
            implementers among the industry.</t>
          </abstract> Extension Headers at Transit Routers</title>
<author initials='F' surname='Gont' fullname='Fernando Gont'>
<organization />
</author>
<author initials='W' surname='Liu' fullname='Will (Shucheng) Liu'>
<organization />
</author>
<date year='2021' month='June' day='3' />
</front>
<seriesInfo name="Internet-Draft"
                    value="draft-kampanakis-6man-ipv6-eh-parsing-01"/> name='Internet-Draft' value='draft-ietf-opsec-ipv6-eh-filtering-08'/>
<format target="http://www.ietf.org/internet-drafts/draft-kampanakis-6man-ipv6-eh-parsing-01.txt"
                type="TXT"/> type='TXT' target='https://www.ietf.org/internet-drafts/draft-ietf-opsec-ipv6-eh-filtering-08.txt'/>
</reference>

      &I-D.ietf-opsec-ipv6-eh-filtering;

        <reference anchor="IEEE-802.1X">
          <front>
            <title>IEEE Standard for Local and metropolitan area networks -
          Port-Based Metropolitan Area Networks--Port-Based Network Access
	    Control</title>

          <author fullname="IEEE" surname="IEEE"/>
            <author><organization>IEEE</organization></author>
            <date month="February" year="2010"/> year="2020"/>
          </front>
          <seriesInfo name="IEEE Std" value="802.1X-2010"/> value="802.1X-2020"/>
        </reference>

        <reference anchor="SCANNING" target="http://www.caida.org/workshops/isma/1202/slides/aims1202_rbarnes.pdf">
          <front>
            <title>Mapping the Great Void - Smarter scanning for IPv6</title>
            <author fullname="Richard Barnes"/>
            <author fullname="Rick Altmann"/>
            <author fullname="Daniel Kerr"/>
            <date month="February" year="2012"/>
          </front>
        </reference>

        <reference anchor="IPv6_Security_Book">
          <front>
            <title>IPv6 Security</title>
            <author fullname="Scott Hogg" surname="Hogg"/>
            <author fullname="Eric fullname="Éric Vyncke" surname="Vyncke"/>
            <date month="December" year="2008"/>
          </front>
          <seriesInfo name="ISBN" value="1-58705-594-5"/>

        <seriesInfo name="Publisher" value="CiscoPress"/> value="1587055945"/>
          <refcontent>CiscoPress</refcontent>
        </reference>

        <reference anchor="NAv6TF_Security" target="http://www.ipv6forum.com/dl/white/NAv6TF_Security_Report.pdf">
          <front>
            <title>North American IPv6 Task Force (NAv6TF) Technology Report - IPv6 "IPv6
          Security Technology Paper</title>
            <author fullname="Merike Kaeo" surname="Kaeo"/>
            <author fullname="David Green" surname="Green"/>
            <author fullname="Jim Bound" surname="Bound"/>
            <author fullname="Yanick Pouffary" surname="Pouffary"/>
            <date month="July" year="2006"/>
          </front>
        </reference>

        <reference anchor="GDPR" target="https://eur-lex.europa.eu/eli/reg/2016/679/oj">
          <front>
            <title>Regulation (EU) 2016/679 of the European Parliament and of
          the Council of 27 April 2016 on the protection of natural persons
          with regard to the processing of personal data and on the free
          movement of such data, and repealing Directive 95/46/EC (General
          Data Protection Regulation)</title>

          <author fullname="Official Journal of the European Union"/>
            <author><organization>European Union</organization></author>
            <date day="27" month="April" year="2016"/>
          </front>
	  <refcontent>Official Journal of the European Union</refcontent>
        </reference>

        <reference anchor="RADB" target="https://www.radb.net/">
          <front>
          <title>RADb
            <title>RADb: The Internet Routing Registry</title>

          <author fullname="MERIT NETWORK, INC."/>

          <date year="Existing in 2021"/>
            <author><organization>Merit Network, Inc.</organization></author>
          </front>
        </reference>

        <reference anchor="europol-cgn" target="https://www.europol.europa.eu/newsroom/news/are-you-sharing-same-ip-address-criminal-law-enforcement-call-for-end-of-carrier-grade-nat-cgn-to-increase-accountability-online">
          <front>
          <title>ARE YOU SHARING THE SAME
            <title>Are you sharing the same IP ADDRESS AS A CRIMINAL? LAW
          ENFORCEMENT CALL FOR THE END OF CARRIER GRADE NAT address as a criminal? Law enforcement call for the end of Carrier Grade Nat (CGN) TO INCREASE
          ACCOUNTABILITY ONLINE</title>

          <author fullname="Europol"/> to increase accountability online</title>
            <author><organization>Europol</organization></author>
            <date day="17" month="October" year="2017"/>
          </front>
        </reference>

        <reference anchor="NIST" target="http://csrc.nist.gov/publications/nistpubs/800-119/sp800-119.pdf">
          <front>
            <title>Guidelines for the Secure Deployment of IPv6</title>
            <author fullname="Sheila Frankel" surname="Frankel"/>
            <author fullname="Richard Graveman" surname="Graveman"/>
            <author fullname="John Pearce" surname="Pearce"/>
            <author fullname="Mark Rooks " surname="Rooks"/>
            <date month="December" year="2010"/>
          </front>
        </reference>

        <reference anchor="WEBER_VPN" target="https://blog.webernetz.net/wp-content/uploads/2018/03/TR18-Johannes-Weber-Dynamic-IPv6-Prefix-Problems-and-VPNs.pdf">
          <front>
            <title>Dynamic IPv6 Prefix - Problems and VPNs</title>
            <author fullname="Johannes Weber" surname="Weber"/>
            <date month="March" year="2018"/>
          </front>
        </reference>

        <reference anchor="CYMRU" target="https://team-cymru.com/community-services/bogon-reference/">
          <front>
            <title>The Bogon Reference</title>

          <author fullname="Cymru Team"/>

          <date year="Existing in 2021"/>
            <author><organization>Team Cymru</organization></author>
          </front>
        </reference>

        <reference anchor="REY_PF" target="https://labs.ripe.net/Members/enno_rey/local-packet-filtering-with-ipv6">
          <front>
            <title>Local Packet Filtering with IPv6</title>
            <author fullname="Enno Rey" surname="Rey"/>
            <date day="13" month="July" year="2017"/>
          </front>
        </reference>

        <reference anchor="KRISTOFF" target="https://dataplane.org/jtk/publications/kgkp-pam-21.pdf">
          <front>
            <title>Plight at the End of the Tunnel: Legacy IPv6 Transition
          Mechanisms in the Wild</title>
            <author fullname="John Kristoff" surname="Kristoff"/>
            <author fullname="Mohammad Ghasemisharif" surname="Ghasemisharif"/>
            <author fullname="Chris Kanich" surname="Kanich"/>
            <author fullname="Jason Polakis" surname="Polakis"/>
            <date day="30" month="March" year="2021"/>
          </front>
        </reference>

        <reference anchor="ENTROPYIP" target="http://www.entropy-ip.com/">
          <front>
            <title>Entropy/IP: Uncovering Structure in IPv6 Addresses</title>
            <author fullname="P. fullname="Pawel Foremski" surname="Foremski"/>
            <author fullname="D. fullname="Dave Plonka" surname="Plonla"/>
            <author fullname="A. fullname="Arthur Berger" surname="Berger"/>
	  <date /> month="November" year="2016"/>
          </front>
        </reference>

      </references>
    </references>

    <section anchor="Acknowledgements" numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t>The authors would like to thank the following people for their useful
      comments (in alphabetical order): <contact fullname="Mikael Abrahamsson"/>, <contact fullname="Fred Baker"/>,
      <contact fullname="Mustafa Suha Botsali"/>, <contact fullname="Mohamed
      Boucadair"/>, <contact fullname="Brian Carpenter"/>, <contact fullname="Tim Chown"/>,
      <contact fullname="Lorenzo Colitti"/>, <contact fullname="Roman Danyliw"/>
      (IESG Review), <contact fullname="Markus de Bruen"/>, <contact fullname="Lars Eggert"/>
      (IESG review), <contact fullname="Tobias Fiebig"/>, <contact fullname="Fernando Gont"/>,
      <contact fullname="Jeffry Handal"/>, <contact fullname="Lee Howard"/>,
      <contact fullname="Benjamin Kaduk"/> (IESG
      review), <contact fullname="Panos Kampanakis"/>, <contact fullname="Erik Kline"/>,
      <contact fullname="Jouni Korhonen"/>, <contact fullname="Warren Kumari"/>
      (IESG review), <contact fullname="Ted Lemon"/>, <contact fullname="Mark Lentczner"/>,
      <contact fullname="Acee Lindem"/> (and his detailed
      nits), <contact fullname="Jen Linkova"/> (and her detailed review),
      <contact fullname="Gyan S. Mishra"/> (the
      Document Shepherd), <contact fullname="Jordi Palet"/>, <contact fullname="Alvaro Retana"/>
      (IESG review), <contact fullname="Zaheduzzaman Sarker"/> (IESG review),
      <contact fullname="Bob Sleigh"/>, <contact fullname="Donald Smith"/>,
      <contact fullname="Tarko Tikan"/>, <contact fullname="Ole Troan"/>, and
      <contact fullname="Bernie Volz"/>.</t>
    </section>
  </back>
</rfc>