rfc9099xml2.original.xml   rfc9099.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<!ENTITY RFC0826 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.0826.xml">
<!ENTITY RFC1918 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.1918.xml">
<!ENTITY RFC2119 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.2119.xml">
<!ENTITY RFC2131 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.2131.xml">
<!ENTITY RFC2460 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.2460.xml">
<!ENTITY RFC2529 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.2529.xml">
<!ENTITY RFC2663 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.2663.xml">
<!ENTITY RFC2784 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.2784.xml">
<!ENTITY RFC2827 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.2827.xml">
<!ENTITY RFC2866 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.2866.xml">
<!ENTITY RFC3056 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.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/referen
ce.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/referen
ce.RFC.3627.xml">
<!ENTITY RFC3704 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.3704.xml">
<!ENTITY RFC3756 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.3756.xml">
<!ENTITY RFC3924 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.3924.xml">
<!ENTITY RFC3964 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.3964.xml">
<!ENTITY RFC3971 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.3971.xml">
<!ENTITY RFC3972 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.3972.xml">
<!ENTITY RFC4107 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.4107.xml">
<!ENTITY RFC4033 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.4033.xml">
<!ENTITY RFC4193 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.4193.xml">
<!ENTITY RFC4293 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.4293.xml">
<!ENTITY RFC4301 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.4301.xml">
<!ENTITY RFC4302 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.4302.xml">
<!ENTITY RFC4303 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.4303.xml">
<!ENTITY RFC4364 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.4364.xml">
<!ENTITY RFC4380 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.4380.xml">
<!ENTITY RFC4381 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.4381.xml">
<!ENTITY RFC4443 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.4443.xml">
<!ENTITY RFC4552 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.4552.xml">
<!ENTITY RFC4649 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.4649.xml">
<!ENTITY RFC4659 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.4659.xml">
<!ENTITY RFC4795 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.4795.xml">
<!ENTITY RFC4798 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.4798.xml">
<!ENTITY RFC4861 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.4861.xml">
<!ENTITY RFC4864 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.4864.xml">
<!ENTITY RFC4890 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.4890.xml">
<!ENTITY RFC4942 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.4942.xml">
<!ENTITY RFC5082 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.5082.xml">
<!ENTITY RFC5214 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.5214.xml">
<!ENTITY RFC5340 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.5340.xml">
<!ENTITY RFC5635 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.5635.xml">
<!ENTITY RFC5952 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.5952.xml">
<!ENTITY RFC5969 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.5969.xml">
<!ENTITY RFC6092 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.6092.xml">
<!ENTITY RFC6104 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.6104.xml">
<!ENTITY RFC6105 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.6105.xml">
<!ENTITY RFC6144 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.6144.xml">
<!ENTITY RFC6146 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.6146.xml">
<!ENTITY RFC6147 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.6147.xml">
<!ENTITY RFC6164 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.6164.xml">
<!ENTITY RFC6169 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.6169.xml">
<!ENTITY RFC6177 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.6177.xml">
<!ENTITY RFC6192 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.6192.xml">
<!ENTITY RFC6221 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.6221.xml">
<!ENTITY RFC6241 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.6241.xml">
<!ENTITY RFC6264 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.6264.xml">
<!ENTITY RFC6269 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.6269.xml">
<!ENTITY RFC6296 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.6296.xml">
<!ENTITY RFC6302 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.6302.xml">
<!ENTITY RFC6324 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.6324.xml">
<!ENTITY RFC6333 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.6333.xml">
<!ENTITY RFC6343 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.6343.xml">
<!ENTITY RFC6434 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.6434.xml">
<!ENTITY RFC6459 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.6459.xml">
<!ENTITY RFC6547 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.6547.xml">
<!ENTITY RFC6564 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.6564.xml">
<!ENTITY RFC6583 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.6583.xml">
<!ENTITY RFC6598 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.6598.xml">
<!ENTITY RFC6620 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.6620.xml">
<!ENTITY RFC6666 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.6666.xml">
<!ENTITY RFC6762 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.6762.xml">
<!ENTITY RFC6763 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.6763.xml">
<!ENTITY RFC6775 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.6775.xml">
<!ENTITY RFC6877 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.6877.xml">
<!ENTITY RFC6888 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.6888.xml">
<!ENTITY RFC6939 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.6939.xml">
<!ENTITY RFC6964 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.6964.xml">
<!ENTITY RFC6967 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.6967.xml">
<!ENTITY RFC6980 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.6980.xml">
<!ENTITY RFC7010 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.7010.xml">
<!ENTITY RFC7011 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.7011.xml">
<!ENTITY RFC7012 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.7012.xml">
<!ENTITY RFC7039 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.7039.xml">
<!ENTITY RFC7045 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.7045.xml">
<!ENTITY RFC7050 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.7050.xml">
<!ENTITY RFC7084 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.7084.xml">
<!ENTITY RFC7112 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.7112.xml">
<!ENTITY RFC7113 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.7113.xml">
<!ENTITY RFC7123 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.7123.xml">
<!ENTITY RFC7166 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.7166.xml">
<!ENTITY RFC7217 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.7217.xml">
<!ENTITY RFC7359 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.7359.xml">
<!ENTITY RFC7381 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.7381.xml">
<!ENTITY RFC7404 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.7404.xml">
<!ENTITY RFC7422 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.7422.xml">
<!ENTITY RFC7454 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.7454.xml">
<!ENTITY RFC7513 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.7513.xml">
<!ENTITY RFC7526 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.7526.xml">
<!ENTITY RFC7552 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.7552.xml">
<!ENTITY RFC7597 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.7597.xml">
<!ENTITY RFC7599 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.7599.xml">
<!ENTITY RFC7610 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.7610.xml">
<!ENTITY RFC7707 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.7707.xml">
<!ENTITY RFC7721 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.7721.xml">
<!ENTITY RFC7772 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.7772.xml">
<!ENTITY RFC7785 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.7785.xml">
<!ENTITY RFC7824 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.7824.xml">
<!ENTITY RFC7844 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.7844.xml">
<!ENTITY RFC7872 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.7872.xml">
<!ENTITY RFC7857 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.7857.xml">
<!ENTITY RFC7915 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.7915.xml">
<!ENTITY RFC7934 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.7934.xml">
<!ENTITY RFC8040 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8040.xml">
<!ENTITY RFC8064 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8064.xml">
<!ENTITY RFC8174 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8174.xml">
<!ENTITY RFC8177 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8177.xml">
<!ENTITY RFC8190 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8190.xml">
<!ENTITY RFC8200 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8200.xml">
<!ENTITY RFC8210 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8210.xml">
<!ENTITY RFC8273 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8273.xml">
<!ENTITY RFC8343 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8343.xml">
<!ENTITY RFC8344 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8344.xml">
<!ENTITY RFC8415 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8415.xml">
<!ENTITY RFC8504 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8504.xml">
<!ENTITY RFC8520 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8520.xml">
<!ENTITY RFC8541 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8541.xml">
<!ENTITY RFC8981 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.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' ?>
<rfc category="info" docName="draft-ietf-opsec-v6-27" ipr="trust200902">
<!-- ***** FRONT MATTER ***** -->
<front> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-opsec-v6-27"
<!-- The abbreviated title is used in the page header - it is only necessary number="9099" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" c
if the ategory="info" consensus="true" xml:lang="en" symRefs="true" sortRefs="true" toc
full title is longer than 39 characters --> Include="true" version="3">
<!-- xml2rfc v2v3 conversion 3.7.0 -->
<front>
<title abbrev="OPsec IPv6">Operational Security Considerations for IPv6 <title abbrev="OPsec IPv6">Operational Security Considerations for IPv6
Networks</title> Networks</title>
<seriesInfo name="RFC" value="9099"/>
<!-- add 'role="editor"' below for the editors if appropriate --> <author fullname="Éric Vyncke" initials="É" surname="Vyncke">
<author fullname="Eric Vyncke" initials="E" surname="Vyncke">
<organization>Cisco</organization> <organization>Cisco</organization>
<address> <address>
<postal> <postal>
<street>De Kleetlaan 6a</street> <street>De Kleetlaan 6a</street>
<city>Diegem</city> <city>Diegem</city>
<country>Belgium</country> <country>Belgium</country>
<code>1831</code> <code>1831</code>
</postal> </postal>
<phone>+32 2 778 4677</phone> <phone>+32 2 778 4677</phone>
<email>evyncke@cisco.com</email> <email>evyncke@cisco.com</email>
</address> </address>
</author> </author>
<author fullname="Kiran Kumar Chittimaneni" initials="K" surname="Chittimane
<author fullname="Kiran Kumar" initials="K" surname="Chittimaneni"> ni">
<organization>Square</organization> <organization/>
<address> <address>
<postal> <postal/>
<street>1455 Market Street, Suite 600</street>
<city>San Francisco</city>
<country>United States of America</country>
<code>94103</code>
</postal>
<email>kk.chittimaneni@gmail.com</email> <email>kk.chittimaneni@gmail.com</email>
</address> </address>
</author> </author>
<author fullname="Merike Kaeo" initials="M" surname="Kaeo"> <author fullname="Merike Kaeo" initials="M" surname="Kaeo">
<organization>Double Shot Security</organization> <organization>Double Shot Security</organization>
<address> <address>
<postal> <postal>
<street>3518 Fremont Ave N 363</street> <street>3518 Fremont Ave N 363</street>
<city>Seattle</city> <city>Seattle</city>
<country>United States of America</country> <country>United States of America</country>
<code>98103</code> <code>98103</code>
</postal> </postal>
<phone>+12066696394</phone> <phone>+12066696394</phone>
<email>merike@doubleshotsecurity.com</email> <email>merike@doubleshotsecurity.com</email>
</address> </address>
</author> </author>
<author fullname="Enno Rey" initials="E" surname="Rey"> <author fullname="Enno Rey" initials="E" surname="Rey">
<organization>ERNW</organization> <organization>ERNW</organization>
<address> <address>
<postal> <postal>
<street>Carl-Bosch-Str. 4</street> <street>Carl-Bosch-Str. 4</street>
<city>Heidelberg Baden-Wuertemberg</city>
<city>Heidelberg</city>
<region>Baden-Wuertemberg</region>
<code>69115</code> <code>69115</code>
<country>Germany</country> <country>Germany</country>
</postal> </postal>
<phone>+49 6221 480390</phone> <phone>+49 6221 480390</phone>
<facsimile/>
<email>erey@ernw.de</email> <email>erey@ernw.de</email>
<uri/> <uri/>
</address> </address>
</author> </author>
<date month="August" year="2021"/>
<date day="6" month="May" year="2021"/>
<!-- Meta-data Declarations -->
<area>Operations and Management</area> <area>Operations and Management</area>
<workgroup>OPSEC</workgroup> <workgroup>OPSEC</workgroup>
<keyword>IPv6</keyword> <keyword>IPv6</keyword>
<keyword>Security</keyword> <keyword>Security</keyword>
<keyword>Operational Security</keyword> <keyword>Operational Security</keyword>
<abstract> <abstract>
<t>Knowledge and experience on how to operate IPv4 networks securely is <t>Knowledge and experience on how to operate IPv4 networks securely is
available: whether it is an Internet Service Provider or an enterprise available, whether the operator is an Internet Service Provider (ISP) or a n enterprise
internal network. However, IPv6 presents some new security challenges. internal network. However, IPv6 presents some new security challenges.
RFC 4942 describes security issues in the protocol, but network managers RFC 4942 describes security issues in the protocol, but network managers
also need a more practical, operations-minded document to enumerate also need a more practical, operations-minded document to enumerate
advantages and/or disadvantages of certain choices.</t> advantages and/or disadvantages of certain choices.</t>
<t>This document analyzes the operational security issues associated <t>This document analyzes the operational security issues associated
with several types of network and proposes technical and procedural with several types of networks and proposes technical and procedural
mitigation techniques. This document is only applicable to managed mitigation techniques. This document is only applicable to managed
networks, such as enterprise networks, service provider networks, or networks, such as enterprise networks, service provider networks, or
managed residential networks.</t> managed residential networks.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section title="Introduction"> <section numbered="true" toc="default">
<name>Introduction</name>
<t>Running an IPv6 network is new for most operators not only because <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 they are not yet used to large-scale IPv6 networks but also because
there are subtle but critical and important differences between IPv4 and there are subtle but critical and important differences between IPv4 and
IPv6, especially with respect to security. For example, all layer-2 IPv6, especially with respect to security. For example, all Layer 2 (L2)
interactions are now done using Neighbor Discovery Protocol <xref interactions are now done using the Neighbor Discovery Protocol (NDP) <xre
target="RFC4861"/> rather than using Address Resolution Protocol <xref f
target="RFC0826"/>. Also, there is no Network Address Port Translation target="RFC4861" format="default"/> rather than the Address Resolution
(NAPT) defined in <xref target="RFC2663"/> for IPv6 even if <xref Protocol <xref target="RFC0826" format="default"/>. Also, there is no Netw
target="RFC6296"/> specifies a Network Prefix Translation for IPv6 ork
(NPTv6) which is a 1-to-1 mapping of IPv6 addresses. Another important Address Port Translation
(NAPT) defined in <xref target="RFC2663" format="default"/> for IPv6 even
if <xref
target="RFC6296" format="default"/> specifies an IPv6-to-IPv6 Network Pref
ix
Translation
(NPTv6), which is a 1-to-1 mapping of IPv6 addresses. Another important
difference is that IPv6 is extensible with the use of extension difference is that IPv6 is extensible with the use of extension
headers.</t> headers.</t>
<t>IPv6 networks are deployed using a variety of techniques, each of <t>IPv6 networks are deployed using a variety of techniques, each of
which have their own specific security concerns.</t> which have their own specific security concerns.</t>
<t>This document complements <xref target="RFC4942" format="default"/> by
<t>This document complements <xref target="RFC4942"/> by listing listing
security issues when operating a network (including various transition security issues when operating a network (including various transition
technologies). It also provides more recent operational deployment technologies).
It also provides operational deployment
experiences where warranted.</t> experiences where warranted.</t>
<section numbered="true" toc="default">
<section title="Applicability Statement"> <name>Applicability Statement</name>
<t>This document is applicable to managed networks, i.e., when the <t>This document is applicable to managed networks, i.e., when the
network is operated by the user organization itself. Indeed, many of network is operated by the user organization itself. Indeed, many of
the recommended mitigation techniques must be configured with detailed the recommended mitigation techniques must be configured with detailed
knowledge of the network (which are the default routers, the switch knowledge of the network (which are the default routers, the switch
trunk ports, etc.). This covers Service Provider (SP), enterprise trunk ports, etc.). This covers Service Providers (SPs), enterprise
networks and some knowledgeable-home-user-managed residential networks, and some knowledgeable home-user-managed residential
networks. This applicability statement especially applies to <xref networks. This applicability statement especially applies to Sections <x
target="linklayer"/> and <xref target="rfilter"/>.</t> ref
target="linklayer" format="counter"/> and <xref 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>REQU
IRED</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="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
</section> </section>
</section> </section>
<section anchor="generic" numbered="true" toc="default">
<section anchor="generic" title="Generic Security Considerations"> <name>Generic Security Considerations</name>
<section anchor="v6addressing" title="Addressing"> <section anchor="v6addressing" numbered="true" toc="default">
<t>IPv6 address allocations and overall architecture are an important <name>Addressing</name>
part of securing IPv6. Initial designs, even if intended to be <t>IPv6 address allocations and overall architecture are important
temporary, tend to last much longer than expected. Although initially parts of securing IPv6. Initial designs, even if intended to be
IPv6 was thought to make renumbering easy, in practice it may be temporary, tend to last much longer than expected. Although
IPv6 was initially thought to make renumbering easy, in practice, it may
be
extremely difficult to renumber without a proper IP Address Management extremely difficult to renumber without a proper IP Address Management
(IPAM) system. <xref target="RFC7010"/> introduces the mechanisms that (IPAM) system. <xref target="RFC7010" format="default"/> introduces the mechanisms that
could be utilized for IPv6 site renumbering and tries to cover most of could be utilized for IPv6 site renumbering and tries to cover most of
the explicit issues and requirements associated with IPv6 the explicit issues and requirements associated with IPv6
renumbering.</t> renumbering.</t>
<t>A key task for a successful IPv6 deployment is to prepare an <t>A key task for a successful IPv6 deployment is to prepare an
addressing plan. Because an abundance of address space is available, addressing plan. Because an abundance of address space is available,
structuring an address plan around both services and geographic structuring an address plan around both services and geographic
locations allows address space to become a basis for more structured locations allows address space to become a basis for more structured
security policies to permit or deny services between geographic security policies to permit or deny services between geographic
regions. <xref target="RFC6177"/> documents some operational regions. <xref target="RFC6177" format="default"/> documents some operat ional
considerations of using different prefix sizes for address assignments considerations of using different prefix sizes for address assignments
at end sites.</t> at end sites.</t>
<t>A common question is whether companies should use Provider-Independen
<t>A common question is whether companies should use Provider t (PI) or Provider-Aggregated (PA) space <xref target="RFC7381" format="default"
Independent (PI) vs. Provider Allocated (PA) space <xref />, but, from a security perspective, there is little
target="RFC7381"/>, but from a security perspective there is little
difference. However, one aspect to keep in mind is who has difference. However, one aspect to keep in mind is who has
administrative ownership of the address space and who is technically administrative ownership of the address space and who is technically
responsible if/when there is a need to enforce restrictions on responsible if/when there is a need to enforce restrictions on
routability of the space, e.g., due to malicious criminal activity routability of the space, e.g., due to malicious criminal activity
originating from it. Relying on PA address space may also increase the originating from it.
perceived need for address translation techniques such as NPTv6 and Relying on PA address space may also increase the
thereby augmenting the complexity of the operations including the perceived need for address translation techniques, such as NPTv6;
security operations.</t> thereby, the complexity of the operations, including the
security operations, is augmented.</t>
<t>In <xref target="RFC7934"/>, it is recommended that IPv6 network <t>In <xref target="RFC7934" format="default"/>, it is recommended that
IPv6 network
deployments provide multiple IPv6 addresses from each prefix to deployments provide multiple IPv6 addresses from each prefix to
general-purpose hosts and it specifically does not recommend limiting general-purpose hosts, and it specifically does not recommend limiting
a host to only one IPv6 address per prefix. It also recommends that 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 the network give the host the ability to use new addresses without
requiring explicit requests (for example by using SLAAC). Privacy requiring explicit requests (for example, by using Stateless Address
Extensions as of [RFC8981] constitute one of the main scenarios where Autoconfiguration (SLAAC)). Privacy
hosts are expected to generate multiple addresses from the same prefix extensions, as of <xref target="RFC8981" format="default"/>,
constitute one of the main scenarios where
hosts are expected to generate multiple addresses from the same prefix,
and having multiple IPv6 addresses per interface is a major change and having multiple IPv6 addresses per interface is a major change
compared to the unique IPv4 address per interface for hosts (secondary compared to the unique IPv4 address per interface for hosts (secondary
IPv4 addresses are not common); especially for audits (see section IPv4 addresses are not common), especially for audits (see
<xref target="correlation"/>).</t> <xref target="correlation" format="default"/>).</t>
<!--static-->
<section anchor="ula" title="Use of ULAs"> <section anchor="ula" numbered="true" toc="default">
<t>Unique Local Addresses (ULAs) <xref target="RFC4193"/> are <name>Use of ULAs</name>
<t>Unique Local Addresses (ULAs) <xref target="RFC4193" format="defaul
t"/> are
intended for scenarios where interfaces are not globally reachable, intended for scenarios where interfaces are not globally reachable,
despite being routed within a domain. They formally have global despite being routed within a domain. They formally have global
scope, but <xref target="RFC4193"/> specifies that they must be scope, but <xref target="RFC4193" format="default"/> specifies that th
filtered at domain boundaries. ULAs are different from <xref ey must be
target="RFC1918"/> addresses and have different use cases. One use filtered at domain boundaries. ULAs are different from the addresses d
of ULA is described in <xref target="RFC4864"/>, another one is for escribed in <xref target="RFC1918"
internal communication stability in networks where external format="default"/> and have different use cases. One use
of ULAs is described in <xref target="RFC4864" format="default"/>; ano
ther one is
for internal communication stability in networks where external
connectivity may come and go (e.g., some ISPs provide ULAs in home 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 networks connected via a cable modem). It should further be kept in
mind that ULA /48s from the fd00::/8 space (L=1) MUST be generated mind that ULA /48s from the fd00::/8 space (L=1) <bcp14>MUST</bcp14> b
with a pseudo-random algorithm, per <xref target="RFC4193"/> section e generated
3.2.1.</t> with a pseudorandom algorithm, per <xref target="RFC4193"
sectionFormat="of" section="3.2.1"/>.</t>
</section> </section>
<!----> <section anchor="p2p" numbered="true" toc="default">
<name>Point-to-Point Links</name>
<section anchor="p2p" title="Point-to-Point Links"> <t><xref target="RFC6164" sectionFormat="of" section="5.1"/> specifies
<t><xref target="RFC6164"/> in section 5.1 specifies the rationale the
of using /127 for inter-router point-to-point links to prevent the rationale
of using /127 for inter-router, point-to-point links to prevent the
ping-pong issue between routers not correctly implementing <xref ping-pong issue between routers not correctly implementing <xref
target="RFC4443"/> and also prevents a DoS attack on the neighbor target="RFC4443" format="default"/>, and it also prevents a denial-of-s
cache. The previous recommendation of <xref target="RFC3627"/> has ervice
been obsoleted and marked Historic by <xref target="RFC6547"/>).</t> (DoS) attack on the Neighbor Cache. The previous recommendation of <xre
f
target="RFC3627" format="default"/> has
been obsoleted and marked Historic by <xref target="RFC6547"
format="default"/>.</t>
<t>Some environments are also using link-local addressing for <t>Some environments are also using link-local addressing for
point-to-point links. While this practice could further reduce the point-to-point links. While this practice could further reduce the
attack surface of infrastructure devices, the operational attack surface of infrastructure devices, the operational
disadvantages also need to be carefully considered; see also <xref disadvantages also need to be carefully considered; see <xref target="
target="RFC7404"/>.</t> RFC7404"
format="default"/>.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Loopback Addresses"> <name>Loopback Addresses</name>
<t>Many operators reserve a /64 block for all loopback addresses in <t>Many operators reserve a /64 block for all loopback addresses in
their infrastructure and allocate a /128 out of this reserved /64 their infrastructure and allocate a /128 out of this reserved /64
prefix for each loopback interface. This practice facilitates prefix for each loopback interface. This practice facilitates
configuration of Access Control List (ACL) rules to enforce a configuration of Access Control List (ACL) rules to enforce a
security policy for those loopback addresses.</t> security policy for those loopback addresses.</t>
</section> </section>
<section anchor="static" numbered="true" toc="default">
<section anchor="static" title="Stable Addresses"> <name>Stable Addresses</name>
<t>When considering how to assign stable addresses for nodes (either <t>When considering how to assign stable addresses for nodes (either
by static configuration or by pre-provisioned DHCPv6 lease <xref by static configuration or by pre-provisioned DHCPv6 lease (<xref targ
target="dhcp"/>), it is necessary to take into consideration the et="dhcp"
format="default"/>)), it is necessary to take into consideration the
effectiveness of perimeter security in a given environment.</t> effectiveness of perimeter security in a given environment.</t>
<t>There is a trade-off between ease of operation (where some <t>There is a trade-off between ease of operation (where some
portions of the IPv6 address could be easily recognizable for portions of the IPv6 address could be easily recognizable for
operational debugging and troubleshooting) versus the risk of operational debugging and troubleshooting) versus the risk of
trivial scanning used for reconnaissance. <xref target="SCANNING"/> trivial scanning used for reconnaissance. <xref target="SCANNING" form at="default"/>
shows that there are scientifically based mechanisms that make shows that there are scientifically based mechanisms that make
scanning for IPv6 reachable nodes more feasible than expected; see scanning for IPv6-reachable nodes more feasible than expected; see
also <xref target="RFC7707"/>.</t> <xref target="RFC7707" format="default"/>.</t>
<t>Stable addresses also allow easy enforcement of a security policy <t>Stable addresses also allow easy enforcement of a security policy
at the perimeter based on IPv6 addresses. E.g., <xref at the perimeter based on IPv6 addresses. For example, <xref target="R
target="RFC8520">Manufacturer Usage Description (MUD)</xref> is a FC8520" format="default">Manufacturer Usage Description (MUD)</xref> is a
mechanism where the perimeter defense can retrieve security policy mechanism where the perimeter defense can retrieve the security policy
template based on the type of internal device and apply the right template based on the type of internal device and apply the right
security policy based on the device IPv6 address.</t> security policy based on the device's IPv6 address.</t>
<t>The use of well-known IPv6 addresses (such as ff02::1 for all <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 link-local nodes) or the use of commonly repeated addresses could
make it easy to figure out which devices are name servers, routers, make it easy to figure out which devices are name servers, routers,
or other critical devices; even a simple traceroute will expose most or other critical devices; even a simple traceroute will expose most
of the routers on a path. There are many scanning techniques of the routers on a path. There are many scanning techniques
possible and operators should not rely on the 'impossible to find possible and operators should not rely on the 'impossible to find
because my address is random' paradigm (a.k.a. "security by because my address is random' paradigm (a.k.a. "security by
obscurity"), even if it is common practice to have the stable obscurity") even if it is common practice to have the stable
addresses randomly distributed across /64 subnets and to always use addresses randomly distributed across /64 subnets and to always use
DNS (as IPv6 addresses are hard for human brains to remember).</t> DNS (as IPv6 addresses are hard for human brains to remember).</t>
<t>While, in some environments, obfuscating addresses could be
<t>While in some environments obfuscating addresses could be
considered an added benefit, it should not preclude enforcement of considered an added benefit, it should not preclude enforcement of
perimeter rules. Stable addresses following some logical allocation perimeter rules. Stable addresses following some logical allocation
scheme may ease the operation (as simplicity always helps scheme may ease the operation (as simplicity always helps
security).</t> security).</t>
<t>Typical deployments will have a mix of stable and non-stable <t>Typical deployments will have a mix of stable and non-stable
addresses; the stable addresses being either predictable (e.g., ::25 addresses; the stable addresses being either predictable (e.g., ::25
for a mail server) or obfuscated (i.e., appearing as a random 64-bit for a mail server) or obfuscated (i.e., appearing as a random 64-bit
number).</t> number).</t>
</section> </section>
<section anchor="priv" numbered="true" toc="default">
<section anchor="priv" title="Temporary Addresses for SLAAC"> <name>Temporary Addresses for SLAAC</name>
<t>Historically, stateless address autoconfiguration (SLAAC) makes <t>Historically, Stateless Address Autoconfiguration (SLAAC) makes
up the globally unique IPv6 address based on an automatically up the globally unique IPv6 address based on an automatically
generated 64-bit interface identifier (IID) based on the EUI-64 MAC generated 64-bit interface identifier (IID) based on the 64-bit Extend ed Unique Identifier (EUI-64) Media Access Control (MAC)
address combined with the /64 prefix (received in the Prefix address combined with the /64 prefix (received in the Prefix
Information Option (PIO) of the Router Advertisement (RA)). The Information Option (PIO) of the Router Advertisement (RA)). The
EUI-64 address is generated from the stable 48-bit MAC address and 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 does not change even if the host moves to another network; this is
of course bad for privacy as a host can be traced from network of course bad for privacy, as a host can be traced from network
(home) to network (office or Wi-Fi in hotels). <xref (home) to network (office or Wi-Fi in hotels). <xref target="RFC8064"
target="RFC8064"/> recommends against the use of EUI-64 addresses; format="default"/> recommends against the use of EUI-64 addresses,
and it must be noted that most host operating systems do not use and it must be noted that most host operating systems do not use
EUI-64 addresses anymore and rely on either <xref target="RFC8981"/> EUI-64 addresses anymore and rely on either <xref target="RFC8981" for
or <xref target="RFC8064"/>.</t> mat="default"/>
or <xref target="RFC8064" format="default"/>.</t>
<t>Randomly generating an interface ID, as described in <xref <t>Randomly generating an interface ID, as described in <xref target="
target="RFC8981"/>, is part of SLAAC with so-called privacy RFC8981" format="default"/>, is part of SLAAC with so-called privacy
extension addresses and is used to address some privacy concerns. extension addresses and is used to address some privacy concerns.
Privacy extension addresses, a.k.a., temporary addresses may help to Privacy extension addresses, a.k.a. temporary addresses, may help to
mitigate the correlation of activities of a node within the same mitigate the correlation of activities of a node within the same
network and may also reduce the attack exposure window. But using network and may also reduce the attack exposure window. But using
<xref target="RFC8981"/> privacy extension addresses might prevent privacy extension addresses as described in <xref target="RFC8981" f
the operator from building host specific access control lists ormat="default"/> might
(ACLs). The <xref target="RFC8981"/> privacy extension addresses prevent the operator from building host-specific access control lists
could also be used to obfuscate some malevolent activities and (ACLs). These privacy extension addresses
could also be used to obfuscate some malevolent activities, and
specific user attribution/accountability procedures should be put in specific user attribution/accountability procedures should be put in
place as described in <xref target="log"/>.</t> place, as described in <xref target="log" format="default"/>.</t>
<t><xref target="RFC8064" format="default"/> combined with the address
<t><xref target="RFC8064"/> combined with the address generation generation
mechanism of <xref target="RFC7217"/> specifies another way to mechanism of <xref target="RFC7217" format="default"/> specifies anoth
er way to
generate an address while still keeping the same IID for each generate an address while still keeping the same IID for each
network prefix; this allows SLAAC nodes to always have the same network prefix; this allows SLAAC nodes to always have the same
stable IPv6 address on a specific network while having different stable IPv6 address on a specific network while having different
IPv6 addresses on different networks.</t> IPv6 addresses on different networks.</t>
<t>In some specific use cases where user accountability is more <t>In some specific use cases where user accountability is more
important than user privacy, network operators may consider important than user privacy, network operators may consider
disabling SLAAC and relying only on DHCPv6; but not all operating disabling SLAAC and relying only on DHCPv6; however, not all operating
systems support DHCPv6 so some hosts will not get any IPv6 systems support DHCPv6, so some hosts will not get any IPv6
connectivity. Disabling SLAAC and privacy extension addresses can be connectivity. Disabling SLAAC and privacy extension addresses can be
done for most operating systems by sending RA messages with a hint 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 to get addresses via DHCPv6 by setting the M-bit and disabling SLAAC
by resetting all A-bits in all prefix information options. However, by resetting all A-bits in all PIOs. However,
attackers could still find ways to bypass this mechanism if not attackers could still find ways to bypass this mechanism if it is not
enforced at the switch/router level.</t> enforced at the switch/router level.</t>
<t>However, in scenarios where anonymity is a strong desire <t>However, in scenarios where anonymity is a strong desire
(protecting user privacy is more important than user attribution), (protecting user privacy is more important than user attribution),
privacy extension addresses should be used. When mechanisms privacy extension addresses should be used. When mechanisms
recommended by <xref target="RFC8064"/> are available, the stable recommended by <xref target="RFC8064" format="default"/> are available , the stable
privacy address is probably a good balance between privacy (among privacy address is probably a good balance between privacy (among
different networks) and security/user attribution (within a different networks) and security/user attribution (within a
network).</t> network).</t>
</section> </section>
<!----> <section anchor="dhcp" numbered="true" toc="default">
<name>DHCP Considerations</name>
<!---->
<section anchor="dhcp" title="DHCP Considerations">
<t>Some environments use DHCPv6 to provision addresses and other <t>Some environments use DHCPv6 to provision addresses and other
parameters in order to ensure auditability and traceability (see parameters in order to ensure auditability and traceability (see
<xref target="stateful_dhcp"/> for the limitations of DHCPv6 for <xref target="stateful_dhcp" format="default"/> for the limitations of DHCPv6 for
auditability).</t> auditability).</t>
<t>A main security concern is the ability to detect and counteract <t>A main security concern is the ability to detect and counteract
rogue DHCP servers (<xref target="snoop"/>). It must be noted that rogue DHCP servers (<xref target="snoop" format="default"/>). It must
as opposed to DHCPv4, DHCPv6 can lease several IPv6 addresses per be noted
that, as opposed to DHCPv4, DHCPv6 can lease several IPv6 addresses per
client. For DHCPv4, the lease is bound to the 'client identifier', client. For DHCPv4, the lease is bound to the 'client identifier',
which may contain a hardware address, or it may contain another type which may contain a hardware address or another type
of identifier, such as a DNS name. For DHCPv6, the lease is bound to of identifier, such as a DNS name. For DHCPv6, the lease is bound to
the client DHCP Unique ID (DUID), which may, or may not, be bound to the client DHCP Unique Identifier (DUID), which may or may not be boun
the client link-layer address. <xref target="RFC7824"/> describes d to
the client L2 address. <xref target="RFC7824" format="default"/> descr
ibes
the privacy issues associated with the use of DHCPv6 by Internet the privacy issues associated with the use of DHCPv6 by Internet
users. The anonymity profiles <xref target="RFC7844"/> are designed users. The anonymity profiles <xref target="RFC7844" format="default"/ > are designed
for clients that wish to remain anonymous to the visited network. for clients that wish to remain anonymous to the visited network.
<xref target="RFC7707"/> recommends that DHCPv6 servers issue <xref target="RFC7707" format="default"/> recommends that DHCPv6 serve rs issue
addresses randomly from a large pool.</t> addresses randomly from a large pool.</t>
</section> </section>
<section anchor="dns" numbered="true" toc="default">
<section anchor="dns" title="DNS Considerations"> <name>DNS Considerations</name>
<t>While the security concerns of DNS are not fundamentally <t>While the security concerns of DNS are not fundamentally
different between IPv4 and IPv6, there are specific considerations different between IPv4 and IPv6, there are specific considerations
in DNS64 <xref target="RFC6147"/> environments that need to be in DNS64 <xref target="RFC6147" format="default"/> environments that n eed to be
understood. Specifically, the interactions and the potential of understood. Specifically, the interactions and the potential of
interference with DNSSEC (<xref target="RFC4033"/>) implementation interference with DNSSEC <xref target="RFC4033" format="default"/> imp
need to be understood - these are pointed out in more detail in lementation
<xref target="nat64"/>.</t> need to be understood -- these are pointed out in more detail in
<xref target="nat64" format="default"/>.</t>
</section> </section>
<section anchor="sixty4perhost" numbered="true" toc="default">
<section anchor="sixty4perhost" title="Using a /64 per host"> <name>Using a /64 per Host</name>
<t>An interesting approach is using a /64 per host as proposed in <t>An interesting approach is using a /64 per host, as proposed in
<xref target="RFC8273"/> especially in a shared environment. This <xref target="RFC8273" format="default"/>, especially in a shared envi
allows for easier user attribution (typically based on the host MAC ronment.
address) as its /64 prefix is stable even if applications within the This allows for easier user attribution (typically based on the host MA
C
address), as its /64 prefix is stable, even if applications within the
host can change their IPv6 address within this /64 prefix.</t> host can change their IPv6 address within this /64 prefix.</t>
<t>This can also be useful for the generation of ACLs once <t>This can also be useful for the generation of ACLs once
individual systems (e.g. admin workstations) have their own individual systems (e.g., admin workstations) have their own
prefixes.</t> prefixes.</t>
</section> </section>
<section anchor="privacy" numbered="true" toc="default">
<section anchor="privacy" title="Privacy consideration of Addresses"> <name>Privacy Consideration of Addresses</name>
<t>Beside the security aspects of IPv6 addresses, there are also <t>In addition to the security aspects of IPv6 addresses, there are al
so
privacy considerations: mainly because they are of global scope and privacy considerations: mainly because they are of global scope and
visible globally. <xref target="RFC7721"/> goes into more detail on visible globally. <xref target="RFC7721" format="default"/> goes into more detail on
the privacy considerations for IPv6 addresses by comparing the the privacy considerations for IPv6 addresses by comparing the
manually configured IPv6 address, DHCPv6, and SLAAC.</t> manually configured IPv6 address, DHCPv6, and SLAAC.</t>
</section> </section>
</section> </section>
<section anchor="ext_headers" numbered="true" toc="default">
<section anchor="ext_headers" title="Extension Headers"> <name>Extension Headers</name>
<t>Extension headers are an important difference between IPv4 and <t>Extension headers are an important difference between IPv4 and
IPv6. In IPv4-based packets, it's trivial to find the upper-layer IPv6. In IPv4-based packets, it's trivial to find the upper-layer
protocol type and protocol header, while in IPv6 it is more complex protocol type and protocol header, while, in IPv6, it is more complex
since the extension header chain must be parsed completely (even if since the extension header chain must be parsed completely (even if
not processed) in order to find the upper-layer protocol header. IANA not processed) in order to find the upper-layer protocol header. IANA
has closed the existing empty "Next Header Types" registry to new has closed the existing empty "Next Header Types" registry to new
entries and is redirecting its users to a new "IPv6 Extension Header entries and is redirecting its users to the "IPv6 Extension Header
Types" registry per <xref target="RFC7045"/>.</t> Types" registry, per <xref target="RFC7045" format="default"/>.</t>
<t>Extension headers have also become a very controversial topic since <t>Extension headers have also become a very controversial topic since
forwarding nodes that discard packets containing extension headers are forwarding nodes that discard packets containing extension headers are
known to cause connectivity failures and deployment problems <xref known to cause connectivity failures and deployment problems <xref targe
target="RFC7872"/>. Understanding the role of various extension t="RFC7872" format="default"/>. Understanding the role of various extension
headers is important and this section enumerates the ones that need headers is important, and this section enumerates the ones that need
careful consideration.</t> careful consideration.</t>
<t>A clarification on how intermediate nodes should handle packets <t>A clarification on how intermediate nodes should handle packets
with existing or future extension headers is found in <xref with existing or future extension headers is found in <xref target="RFC7
target="RFC7045"/>. The uniform TLV format to be used for defining 045" format="default"/>. The uniform TLV format to be used for defining
future extension headers is described in <xref target="RFC6564"/>. future extension headers is described in <xref target="RFC6564" format="
Sections 5.2 and 5.3 of <xref target="RFC8504"/> provide more default"/>.
Sections <xref target="RFC8504" sectionFormat="bare" section="5.2"/> and
<xref target="RFC8504" sectionFormat="bare" section="5.3"/> of <xref targ
et="RFC8504"/>
provide more
information on the processing of extension headers by IPv6 nodes.</t> information on the processing of extension headers by IPv6 nodes.</t>
<t>Vendors of filtering solutions and operations personnel responsible <t>Vendors of filtering solutions and operations personnel responsible
for implementing packet filtering rules should be aware that the 'Next 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' field in an IPv6 header can both point to an IPv6 extension
header or to an upper layer protocol header. This has to be considered header or to an upper-layer protocol header. This has to be considered
when designing the user interface of filtering solutions or during the when designing the user interface of filtering solutions or during the
creation of filtering rule sets.</t> creation of filtering rule sets.</t>
<t><xref target="I-D.ietf-opsec-ipv6-eh-filtering" format="default"/> di
<t>There is IETF work in progress regarding filtering rules for those scusses filtering rules for those
extension headers: <xref target="I-D.ietf-opsec-ipv6-eh-filtering"/> extension headers at transit routers.</t>
for transit routers.</t> <section numbered="true" toc="default">
<name>Order and Repetition of Extension Headers</name>
<section title="Order and Repetition of Extension Headers"> <t>While <xref target="RFC8200" format="default"/> recommends the orde
<t>While <xref target="RFC8200"/> recommends the order and the r and the
maximum repetition of extension headers, there are still IPv6 maximum repetition of extension headers, at the time of writing, there
implementations, at the time of writing, which support a are still IPv6
non-recommended order of headers (such as ESP before routing) or an implementations that support an
order of headers that is not recommended (such as Encapsulating Securi
ty Payload (ESP)
before routing) or an
illegal repetition of headers (such as multiple routing headers). illegal repetition of headers (such as multiple routing headers).
The same applies for options contained in the extension headers (see The same applies for options contained in the extension headers (see
<xref target="I-D.kampanakis-6man-ipv6-eh-parsing"/>). In some <xref target="I-D.kampanakis-6man-ipv6-eh-parsing" format="default"/>) . In some
cases, it has led to nodes crashing when receiving or forwarding cases, it has led to nodes crashing when receiving or forwarding
wrongly formatted packets.</t> wrongly formatted packets.</t>
<t>A firewall or edge device should be used to enforce the <t>A firewall or edge device should be used to enforce the
recommended order and the maximum occurrences of extension headers recommended order and the maximum occurrences of extension headers
by dropping non-conforming packets.</t> by dropping nonconforming packets.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Hop-by-Hop Options Header"> <name>Hop-by-Hop Options Header</name>
<t>In the previous IPv6 specification <xref target="RFC2460"/>, the <t>In the previous IPv6 specification <xref target="RFC2460" format="d
hop-by-hop options header, when present in an IPv6 packet, forced efault"/>,
the hop-by-hop options header, when present in an IPv6 packet, forced
all nodes to inspect and possibly process this header. This enabled all nodes to inspect and possibly process this header. This enabled
denial-of-service attacks as most, if not all, routers cannot denial-of-service attacks as most, if not all, routers cannot
process this type of packet in hardware but have to process these process this type of packet in hardware; they have to process these
packets in software and hence compete with other software tasks, packets in software and, hence, this task competes with other software
tasks,
such as handling the control and management plane processing.</t> such as handling the control and management plane processing.</t>
<t><xref target="RFC8200" sectionFormat="of" section="4.3"/>, the
<t>Section 4.3 of the current Internet Standard for IPv6, <xref current Internet Standard for IPv6, has taken this attack vector into a
target="RFC8200"/>, has taken this attack vector into account and ccount and
made the processing of hop-by-hop options headers by intermediate made the processing of hop-by-hop options headers by intermediate
routers explicitly configurable.</t> routers explicitly configurable.</t>
</section> </section>
<section anchor="fragments" numbered="true" toc="default">
<section anchor="fragments" title="Fragment Header"> <name>Fragment Header</name>
<t>The fragment header is used by the source (and only the source) <t>The fragment header is used by the source (and only the source)
when it has to fragment packets. <xref target="RFC7112"/> and when it has to fragment packets. <xref target="RFC7112" format="defaul
section 4.5 of <xref target="RFC8200"/> explain why it is important t"/> and
that:<list> <xref target="RFC8200" sectionFormat="of" section="4.5"/> explain why
<t>Firewall and security devices should drop first fragments it is
important 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 that do not contain the entire IPv6 header chain (including the
transport-layer header).</t> transport-layer header).</li>
<li>Destination nodes should discard first fragments that do not
<t>Destination nodes should discard first fragments that do not
contain the entire IPv6 header chain (including the contain the entire IPv6 header chain (including the
transport-layer header).</t> transport-layer header).</li>
</list></t> </ul>
<t>If those requirements are not met, stateless filtering could be <t>If those requirements are not met, stateless filtering could be
bypassed by a hostile party. <xref target="RFC6980"/> applies a bypassed by a hostile party. <xref target="RFC6980" format="default"/>
stricter rule to Neighbor Discovery Protocol (NDP) by enforcing the applies a
stricter rule to NDP by enforcing the
drop of fragmented NDP packets (except for "Certification Path drop of fragmented NDP packets (except for "Certification Path
Advertisement" messages as noted in section <xref Advertisement" messages, as noted in section <xref target="rafiltering
target="rafiltering"/>). <xref target="RFC7113"/> describes how the " format="default"/>). <xref target="RFC7113" format="default"/> describes how t
RA-guard function described in <xref target="RFC6105"/> should he
RA-Guard function described in <xref target="RFC6105" format="default"
/> should
behave in the presence of fragmented RA packets.</t> behave in the presence of fragmented RA packets.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="IP Security Extension Header"> <name>IP Security Extension Header</name>
<t>The <xref target="RFC4301">IPsec</xref> extension headers (<xref <t>The <xref target="RFC4301" format="default">IPsec</xref> extension
target="RFC4302">AH</xref> and <xref target="RFC4303">ESP</xref>) headers (<xref target="RFC4302" format="default">Authentication Header (AH)</xre
are required if IPsec is to be utilized for network level security. f> and <xref target="RFC4303" format="default">ESP</xref>)
Previously, IPv6 mandated implementation of IPsec but <xref are required if IPsec is to be utilized for network-level security.
target="RFC6434"/> updated that recommendation by making support of Previously, IPv6 mandated implementation of IPsec, but <xref target="R
the IPsec architecture <xref target="RFC4301"/> a SHOULD for all FC6434"
IPv6 nodes which is also retained in the latest IPv6 Nodes format="default"/> updated that recommendation by making support of
Requirement standard <xref target="RFC8504"/>.</t> the IPsec architecture <xref target="RFC4301" format="default"/> a
'<bcp14>SHOULD</bcp14>' for all
IPv6 nodes that are also retained in the latest IPv6 Nodes
Requirement standard <xref target="RFC8504" format="default"/>.</t>
</section> </section>
</section> </section>
<section anchor="linklayer" numbered="true" toc="default">
<section anchor="linklayer" title="Link-Layer Security"> <name>Link-Layer Security</name>
<t>IPv6 relies heavily on NDP <xref target="RFC4861"/> to perform a <t>IPv6 relies heavily on NDP <xref target="RFC4861" format="default"/>
variety of link operations such as discovering other nodes on the to perform a
variety of link operations, such as discovering other nodes on the
link, resolving their link-layer addresses, and finding routers 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 link. If not secured, NDP is vulnerable to various attacks, such as
router/neighbor message spoofing, redirect attacks, Duplicate Address router/neighbor message spoofing, redirect attacks, Duplicate Address
Detection (DAD) DoS attacks, etc. Many of these security threats to Detection (DAD) DoS attacks, etc. Many of these security threats to
NDP have been documented in IPv6 ND Trust Models and Threats <xref NDP have been documented in "IPv6 Neighbor Discovery (ND) Trust Models a
target="RFC3756"/> and in <xref target="RFC6583"/>.</t> nd Threats"
<xref target="RFC3756" format="default"/> and in "Operational Neighbor Di
scovery
Problems" <xref target="RFC6583" format="default"/>.</t>
<t>Most of the issues are only applicable when the attacker is on the <t>Most of the issues are only applicable when the attacker is on the
same link but NDP also has security issues when the attacker is same link, but NDP also has security issues when the attacker is
off-link, see the section below <xref target="ratelim"/>.</t> off link; see <xref target="ratelim" format="default"/> below.</t>
<section anchor="ratelim" numbered="true" toc="default">
<section anchor="ratelim" title="Neighbor Solicitation Rate-Limiting"> <name>Neighbor Solicitation Rate-Limiting</name>
<t>NDP can be vulnerable to remote denial of service (DoS) attacks; <t>NDP can be vulnerable to remote DoS attacks,
for example, when a router is forced to perform address resolution for example, when a router is forced to perform address resolution
for a large number of unassigned addresses, i.e., when a prefix is 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 scanned by an attacker in a fast manner. This can keep new devices
from joining the network or render the last-hop router ineffective from joining the network or render the last-hop router ineffective
due to high CPU usage. Easy mitigative steps include rate-limiting due to high CPU usage. Easy mitigative steps include rate limiting
Neighbor Solicitations, restricting the amount of state reserved for Neighbor Solicitations, restricting the amount of state reserved for
unresolved solicitations, and clever cache/timer management.</t> unresolved solicitations, and cleverly managing the cache/timer.</t>
<t><xref target="RFC6583" format="default"/> discusses the potential f
<t><xref target="RFC6583"/> discusses the potential for off-link DoS or off-link DoS
in detail and suggests implementation improvements and operational in detail and suggests implementation improvements and operational
mitigation techniques that may be used to mitigate or alleviate the mitigation techniques that may be used to mitigate or alleviate the
impact of such attacks. Here are some feasible mitigation options impact of such attacks. Here are some feasible mitigation options
that can be employed by network operators today:<list that can be employed by network operators today:</t>
style="symbols"> <ul spacing="normal">
<t>Ingress filtering of unused addresses by ACL. These require <li>Ingress filtering of unused addresses by ACL. These require
stable configuration of the addresses; for example, allocating stable configuration of the addresses, e.g., allocating
the addresses out of a /120 and using a specific ACL to only the addresses out of a /120 and using a specific ACL to only
allow traffic to this /120 (of course, the actual hosts are allow traffic to this /120 (of course, the actual hosts are
configured with a /64 prefix for the link).</t> configured with a /64 prefix for the link).</li>
<li>Tuning of NDP process (where supported), e.g., enforcing
<t>Tuning of NDP process (where supported), e.g., enforcing limits on data structures, such as the number of Neighbor Cache
limits on data structures such as the number of neighbor cache
entries in 'incomplete' state (e.g., 256 incomplete entries per entries in 'incomplete' state (e.g., 256 incomplete entries per
interface) or the rate of NA per interface (e.g., 100 NA per interface) or the rate of NA per interface (e.g., 100 NA per
second).</t> second).</li>
<li>Using a /127 on a point-to-point link, per <xref target="RFC6164
<t>Using a /127 on a point-to-point link, per <xref " format="default"/>.</li>
target="RFC6164"/>.</t> <li>Using only link-local addresses on links where there are only
routers; see <xref target="RFC7404" format="default"/>.</li>
<t>Using only link-local addresses on links where there are only </ul>
routers, see <xref target="RFC7404"/></t>
</list></t>
</section> </section>
<!--ratelim--> <section anchor="filter" numbered="true" toc="default">
<name>Router and Neighbor Advertisements Filtering</name>
<section anchor="filter" <section anchor="rafiltering" numbered="true" toc="default">
title="Router and Neighbor Advertisements Filtering"> <name>Router Advertisement Filtering</name>
<t/> <t>Router Advertisement spoofing is a well-known, on-link attack
<section anchor="rafiltering" title="Router Advertisement Filtering">
<t>Router Advertisement spoofing is a well-known on-link attack
vector and has been extensively documented. The presence of rogue vector and has been extensively documented. The presence of rogue
RAs, either unintentional or malicious, can cause partial or RAs, either unintentional or malicious, can cause partial or
complete failure of operation of hosts on an IPv6 link. For complete failure of operation of hosts on an IPv6 link. For
example, a node can select an incorrect router address which can example, a node can select an incorrect router address, which can
then be used for an on-path attack or the node can assume wrong then be used for an on-path attack, or the node can assume wrong
prefixes to be used for SLAAC. <xref target="RFC6104"/> summarizes prefixes to be used for SLAAC. <xref target="RFC6104" format="defaul
t"/>
summarizes
the scenarios in which rogue RAs may be observed and presents a the scenarios in which rogue RAs may be observed and presents a
list of possible solutions to the problem. <xref list of possible solutions to the problem. <xref target="RFC6105" fo
target="RFC6105"/> (RA-Guard) describes a solution framework for rmat="default"/> (RA-Guard) describes a solution framework for
the rogue RA problem where network segments are designed around the rogue RA problem where network segments are designed around
switching devices that are capable of identifying invalid RAs and switching devices that are capable of identifying invalid RAs and
blocking them before the attack packets actually reach the target blocking them before the attack packets actually reach the target
nodes.</t> nodes.</t>
<t>However, several evasion techniques that circumvent the <t>However, several evasion techniques that circumvent the
protection provided by RA-Guard have surfaced. A key challenge to protection provided by RA-Guard have surfaced. A key challenge to
this mitigation technique is introduced by IPv6 fragmentation. this mitigation technique is introduced by IPv6 fragmentation.
Attackers can conceal their attack by fragmenting their packets Attackers can conceal their attack by fragmenting their packets
into multiple fragments such that the switching device that is into multiple fragments such that the switching device that is
responsible for blocking invalid RAs cannot find all the necessary responsible for blocking invalid RAs cannot find all the necessary
information to perform packet filtering of the same packet. <xref information to perform packet filtering of the same packet. <xref ta
target="RFC7113"/> describes such evasion techniques and provides rget="RFC7113" format="default"/> describes such evasion techniques and provides
advice to RA-Guard implementers such that the aforementioned advice to RA-Guard implementers such that the aforementioned
evasion vectors can be eliminated.</t> evasion vectors can be eliminated.</t>
<t>Given that the IPv6 Fragmentation Header can be leveraged to <t>Given that the IPv6 Fragmentation Header can be leveraged to
circumvent some implementations of RA-Guard, <xref circumvent some implementations of RA-Guard, <xref target="RFC6980"
target="RFC6980"/> updates <xref target="RFC4861"/> such that use format="default"/> updates <xref target="RFC4861" format="default"/> such that u
se
of the IPv6 Fragmentation Header is forbidden in all Neighbor of the IPv6 Fragmentation Header is forbidden in all Neighbor
Discovery messages except "Certification Path Advertisement", thus Discovery messages, except "Certification Path Advertisement", thus
allowing for simple and effective measures to counter fragmented allowing for simple and effective measures to counter fragmented
NDP attacks.</t> NDP attacks.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Neighbor Advertisement Filtering"> <name>Neighbor Advertisement Filtering</name>
<t>The Source Address Validation Improvements (SAVI) working group <t>The Source Address Validation Improvements (savi) Working Group
has worked on other ways to mitigate the effects of such attacks. has worked on other ways to mitigate the effects of such attacks.
<xref target="RFC7513"/> helps in creating bindings between a <xref target="RFC7513" format="default"/> helps in creating bindings
DHCPv4 <xref target="RFC2131"/> /DHCPv6 <xref target="RFC8415"/> between a
assigned source IP address and a binding anchor <xref source IP address assigned to
target="RFC7039"/> on a SAVI device. Also, <xref DHCPv4 <xref target="RFC2131" format="default"/> or DHCPv6 <xref
target="RFC6620"/> describes how to glean similar bindings when target="RFC8415" format="default"/>
and a binding anchor <xref target="RFC7039" format="default"/> on a
SAVI
device. Also, <xref target="RFC6620" format="default"/> describes ho
w to
glean similar bindings when
DHCP is not used. The bindings can be used to filter packets DHCP is not used. The bindings can be used to filter packets
generated on the local link with forged source IP addresses.</t> generated on the local link with forged source IP addresses.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Host Isolation"> <name>Host Isolation</name>
<t>Isolating hosts for the NDP traffic can be done by using a /64 <t>Isolating hosts for the NDP traffic can be done by using a /64
per host, refer to <xref target="sixty4perhost"/>, as NDP is only per host, refer to <xref target="sixty4perhost" format="default"/>,
relevant within a /64 on-link prefix; 3GPP <xref as NDP is
target="threegpp"/> uses a similar mechanism.</t> only relevant within a /64 on-link prefix; 3GPP (<xref target="threeg
pp"
format="default"/>) uses a similar mechanism.</t>
<t>A more drastic technique to prevent all NDP attacks is based on <t>A more drastic technique to prevent all NDP attacks is based on
isolation of all hosts with specific configurations. In such a isolation of all hosts with specific configurations. In such a
scenario, hosts (i.e., all nodes that are not routers) are unable scenario, hosts (i.e., all nodes that are not routers) are unable
to send data-link layer frames to other hosts, therefore, no to send data-link layer frames to other hosts; therefore, no
host-to-host attacks can happen. This specific setup can be host-to-host attacks can happen. This specific setup can be
established on some switches or Wi-Fi access points. This is not established on some switches or Wi-Fi access points. This is not
always feasible when hosts need to communicate with other hosts in always feasible when hosts need to communicate with other hosts in
the same subnet, e.g., for access to file shares.</t> the same subnet, e.g., for access to file shares.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="NDP Recommendations"> <name>NDP Recommendations</name>
<t>It is still recommended that RA-Guard and SAVI be employed as a <t>It is still recommended that RA-Guard and SAVI be employed as a
first line of defense against common attack vectors including first line of defense against common attack vectors, including
misconfigured hosts. This recommendation also applies when DHCPv6 misconfigured hosts. This recommendation also applies when DHCPv6
is used, as RA messages are used to discover the default router(s) 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 and for on-link prefix determination. This line of defense is most
effective when incomplete fragments are dropped by routers and effective when incomplete fragments are dropped by routers and
switches as described in <xref target="fragments"/>. The generated L2 switches, as described in <xref target="fragments" format="defaul
log should also be analyzed to identify and act on violations. t"/>. The
</t> generated log should also be analyzed to identify and act on violatio
ns.</t>
<t>Network operators should be aware that RA-Guard and SAVI do not <t>Network operators should be aware that RA-Guard and SAVI do not
work as expected or could even be harmful in specific network work as expected or could even be harmful in specific network
configurations (notably when there could be multiple routers).</t> configurations (notably when there could be multiple routers).</t>
<t>Enabling RA-Guard by default in managed networks (e.g., Wi-Fi <t>Enabling RA-Guard by default in managed networks (e.g., Wi-Fi
networks, enterprise campus networks, etc.) should be strongly networks, enterprise campus networks, etc.) should be strongly
considered except for specific use cases such as the presence of considered except for specific use cases, such as in the presence of
homenet devices emitting router advertisements.</t> homenet devices emitting router advertisements.</t>
</section> </section>
</section> </section>
<!--filter--> <section anchor="snoop" numbered="true" toc="default">
<name>Securing DHCP</name>
<section anchor="snoop" title="Securing DHCP">
<t>The Dynamic Host Configuration Protocol for IPv6 (DHCPv6), as <t>The Dynamic Host Configuration Protocol for IPv6 (DHCPv6), as
described in <xref target="RFC8415"/>, enables DHCP servers to pass described in <xref target="RFC8415" format="default"/>, enables DHCP s ervers to pass
configuration parameters, such as IPv6 network addresses and other configuration parameters, such as IPv6 network addresses and other
configuration information, to IPv6 nodes. DHCP plays an important configuration information, to IPv6 nodes. DHCP plays an important
role in most large networks by providing robust stateful role in most large networks by providing robust stateful
configuration in the context of automated system provisioning.</t> configuration in the context of automated system provisioning.</t>
<t>The two most common threats to DHCP clients come from malicious <t>The two most common threats to DHCP clients come from malicious
(a.k.a., rogue) or unintentionally misconfigured DHCP servers. in (a.k.a. rogue) or unintentionally misconfigured DHCP servers. In
these scenarios, a malicious DHCP server is established with the these scenarios, a malicious DHCP server is established with the
intent of providing incorrect configuration information to the intent of providing incorrect configuration information to the
clients to cause a denial-of-service attack or to mount on-path clients to cause a denial-of-service attack or to mount an on-path
attack. While unintentional, a misconfigured DHCP server can have attack. While unintentional, a misconfigured DHCP server can have
the same impact. Additional threats against DHCP are discussed in the same impact. Additional threats against DHCP are discussed in
the security considerations section of <xref target="RFC8415"/>.</t> the security considerations section of <xref target="RFC8415"
format="default"/>.</t>
<t><xref target="RFC7610">DHCPv6-Shield, </xref>, specifies a <t><xref target="RFC7610" format="default">DHCPv6-Shield</xref> specif
ies a
mechanism for protecting connected DHCPv6 clients against rogue mechanism for protecting connected DHCPv6 clients against rogue
DHCPv6 servers. This mechanism is based on DHCPv6 packet-filtering DHCPv6 servers. This mechanism is based on DHCPv6 packet filtering
at the layer-2 device, i.e., the administrator specifies the at the L2 device, i.e., the administrator specifies the
interfaces connected to DHCPv6 servers. However, extension headers interfaces connected to DHCPv6 servers. However, extension headers
could be leveraged to bypass DHCPv6-Shield unless <xref could be leveraged to bypass DHCPv6-Shield unless <xref target="RFC711
target="RFC7112"/> is enforced.</t> 2" format="default"/> is enforced.</t>
<t>It is recommended to use DHCPv6-Shield and to analyze the <t>It is recommended to use DHCPv6-Shield and to analyze the
corresponding log messages.</t> corresponding log messages.</t>
</section> </section>
<section anchor="threegpp" numbered="true" toc="default">
<section anchor="threegpp" title="3GPP Link-Layer Security"> <name>3GPP Link-Layer Security</name>
<!--NEED MORE REWORK: too long, should be more straight to the point M <t>The 3GPP link is a point-to-point-like link that has no
K-->
<t>The 3GPP link is a point-to-point like link that has no
link-layer address. This implies there can only be one end host (the link-layer address. This implies there can only be one end host (the
mobile hand-set) and the first-hop router (i.e., a GPRS Gateway mobile handset) and the first-hop router (i.e., a Gateway GPRS
Support Node (GGSN) or a Packet Gateway (PGW)) on that link. The Support Node (GGSN) or a Packet Data Network Gateway (PGW)) on that li
GGSN/PGW never configures a non link-local address on the link using nk. The
the advertised /64 prefix on it; see <xref target="sixty4perhost"/>. GGSN/PGW never configures a non-link-local address on the link using
the advertised /64 prefix on it; see <xref target="sixty4perhost" form
at="default"/>.
The advertised prefix must not be used for on-link determination. The advertised prefix must not be used for on-link determination.
There is no need for address resolution on the 3GPP link, since There is no need for address resolution on the 3GPP link, since
there are no link-layer addresses. Furthermore, the GGSN/PGW assigns there are no link-layer addresses. Furthermore, the GGSN/PGW assigns
a prefix that is unique within each 3GPP link that uses IPv6 a prefix that is unique within each 3GPP link that uses IPv6
stateless address autoconfiguration. This avoids the necessity to Stateless Address Autoconfiguration. This avoids the necessity to
perform DAD at the network level for every address generated by the perform DAD at the network level for every address generated by the
mobile host. The GGSN/PGW always provides an IID to the cellular mobile host. The GGSN/PGW always provides an IID to the cellular
host for the purpose of configuring the link-local address and host for the purpose of configuring the link-local address and
ensures the uniqueness of the IID on the link (i.e., no collisions ensures the uniqueness of the IID on the link (i.e., no collisions
between its own link-local address and the mobile host's between its own link-local address and the mobile host's
address).</t> address).</t>
<t>The 3GPP link model itself mitigates most of the known <t>The 3GPP link model itself mitigates most of the known
NDP-related Denial-of-Service attacks. In practice, the GGSN/PGW NDP-related DoS attacks. In practice, the GGSN/PGW
only needs to route all traffic to the mobile host that falls under 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 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> 3GPP link, there is no need to defend that IPv6 address.</t>
<t>See <xref target="RFC6459" sectionFormat="of" section="5"/> for a m
<t>See Section 5 of <xref target="RFC6459"/> for a more detailed ore detailed
discussion on the 3GPP link model, NDP, and the address discussion on the 3GPP link model, NDP, and the address
configuration details. In some mobile networks, DHCPv6 and DHCP-PD configuration details. In some mobile networks, DHCPv6 and DHCP Prefix
are also used.</t> Delegation
(DHCP-PD) are also used.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Impact of Multicast Traffic"> <name>Impact of Multicast Traffic</name>
<t>IPv6 uses multicast extensively for signaling messages on the <t>IPv6 uses multicast extensively for signaling messages on the
local link to avoid broadcast messages for on-the-wire local link to avoid broadcast messages for on-the-wire
efficiency.</t> efficiency.</t>
<t>The use of multicast has some side effects on wireless networks, <t>The use of multicast has some side effects on wireless networks,
such as a negative impact on battery life of smartphones and other such as a negative impact on battery life of smartphones and other
battery-operated devices that are connected to such networks. <xref battery-operated devices that are connected to such networks. <xref ta
target="RFC7772"/> and <xref target="RFC6775"/> (for specific rget="RFC7772" format="default"/> and <xref target="RFC6775" format="default"/>
(for specific
wireless networks) discuss methods to rate-limit RAs and other ND wireless networks) discuss methods to rate-limit RAs and other ND
messages on wireless networks in order to address this issue.</t> 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 <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 all nodes link-local multicast address) could also be misused for an
amplification attack. Imagine, a hostile node sending an ICMPv6 amplification attack. Imagine a hostile node sending an ICMPv6
ECHO_REQUEST to ff02::1 with a spoofed source address, then, all ECHO_REQUEST to ff02::1 with a spoofed source address, then all
link-local nodes will reply with ICMPv6 ECHO_REPLY packets to the link-local nodes will reply with ICMPv6 ECHO_REPLY packets to the
source address. This could be a DoS attack for the address owner. source address. This could be a DoS attack for the address owner.
This attack is purely local to the layer-2 network as packets with a This attack is purely local to the L2 network, as packets with a
link-local destination are never forwarded by an IPv6 router.</t> link-local destination are never forwarded by an IPv6 router.</t>
<t>This is the reason why large Wi-Fi network deployments often <t>This is the reason why large Wi-Fi network deployments often
limit the use of link-layer multicast either from or to the uplink limit the use of link-layer multicast, either from or to the uplink
of the Wi-Fi access point, i.e., Wi-Fi stations are prevented to of the Wi-Fi access point, i.e., Wi-Fi stations are prevented to
send link-local multicast to their direct neighboring Wi-Fi send link-local multicast to their direct neighboring Wi-Fi
stations; this policy also blocks service discovery via mDNS (<xref stations; this policy also blocks service discovery via Multicast DNS
target="RFC6762"/>) and LLMNR (<xref target="RFC4795"/>).</t> (mDNS)
<xref target="RFC6762" format="default"/> and Link-Local Multicast Name
Resolution (LLMNR) <xref target="RFC4795" format="default"/>.</t>
</section> </section>
<section anchor="send" numbered="true" toc="default">
<section anchor="send" title="SeND and CGA"> <name>SEND and CGA</name>
<t>SEcure Neighbor Discovery (SeND), as described in <xref <t>SEcure Neighbor Discovery (SEND), as described in <xref target="RFC
target="RFC3971"/>, is a mechanism that was designed to secure ND 3971" format="default"/>, is a mechanism that was designed to secure ND
messages. This approach involves the use of new NDP options to carry messages. This approach involves the use of new NDP options to carry
public key-based signatures. Cryptographically Generated Addresses public-key-based signatures. Cryptographically Generated Addresses
(CGA), as described in <xref target="RFC3972"/>, are used to ensure (CGA), as described in <xref target="RFC3972" format="default"/>, are
used to ensure
that the sender of a Neighbor Discovery message is the actual that the sender of a Neighbor Discovery message is the actual
"owner" of the claimed IPv6 address. A new NDP option, the CGA "owner" of the claimed IPv6 address. A new NDP option, the CGA
option, was introduced and is used to carry the public key and option, was introduced and is used to carry the public key and
associated parameters. Another NDP option, the RSA Signature option, associated parameters. Another NDP option, the RSA Signature option,
is used to protect all messages relating to neighbor and Router is used to protect all messages relating to neighbor and router
discovery.</t> discovery.</t>
<t>SEND protects against: </t>
<t>SeND protects against: <list style="symbols"> <ul spacing="normal">
<t>Neighbor Solicitation/Advertisement Spoofing</t> <li>Neighbor Solicitation/Advertisement Spoofing</li>
<li>Neighbor Unreachability Detection Failure</li>
<t>Neighbor Unreachability Detection Failure</t> <li>Duplicate Address Detection DoS Attack</li>
<li>Router Solicitation and Advertisement Attacks</li>
<t>Duplicate Address Detection DoS Attack</t> <li>Replay Attacks</li>
<li>Neighbor Discovery DoS Attacks</li>
<t>Router Solicitation and Advertisement Attacks</t> </ul>
<t>SEND does NOT: </t>
<t>Replay Attacks</t> <ul spacing="normal">
<li>protect statically configured addresses</li>
<t>Neighbor Discovery DoS Attacks</t> <li>protect addresses configured using fixed identifiers (i.e.,
</list></t> EUI-64)</li>
<li>provide confidentiality for NDP communications</li>
<t>SeND does NOT: <list style="symbols"> <li>compensate for an unsecured link -- SEND does not require that
<t>Protect statically configured addresses</t>
<t>Protect addresses configured using fixed identifiers (i.e.,
EUI-64)</t>
<t>Provide confidentiality for NDP communications</t>
<t>Compensate for an unsecured link - SeND does not require that
the addresses on the link and Neighbor Advertisements the addresses on the link and Neighbor Advertisements
correspond.</t> correspond</li>
</list></t> </ul>
<t>However, at this time and over a decade since their original <t>However, at this time and over a decade since their original
specifications, CGA and SeND do not have support from widely specifications, CGA and SEND do not have support from widely
deployed IPv6 devices; hence, their usefulness is limited and should deployed IPv6 devices; hence, their usefulness is limited and should
not be relied upon.</t> not be relied upon.</t>
</section> </section>
</section> </section>
<section anchor="copp" numbered="true" toc="default">
<section anchor="copp" title="Control Plane Security"> <name>Control Plane Security</name>
<t><xref target="RFC6192"/> defines the router control plane and <t><xref target="RFC6192" format="default"/> defines the router control
plane and
provides detailed guidance to secure it for IPv4 and IPv6 networks. provides detailed guidance to secure it for IPv4 and IPv6 networks.
This definition is repeated here for the reader's convenience. Please This definition is repeated here for the reader's convenience. Please
note that the definition is completely protocol-version agnostic (most note that the definition is completely protocol-version agnostic (most
of this section applies to IPv6 in the same way as to IPv4).</t> 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 <t>Preamble: IPv6 control plane security is vastly congruent with its
IPv4 equivalent with the exception of OSPFv3 authentication (<xref IPv4 equivalent, with the exception of OSPFv3 authentication (<xref targ
target="control"/>) and some packet exceptions (see <xref et="control" format="default"/>) and some packet exceptions (see <xref target="e
target="exception"/>) that are specific to IPv6.</t> xception" format="default"/>) that are specific to IPv6.</t>
</aside>
<t>Modern router architecture design maintains a strict separation of <t>Modern router architecture design maintains a strict separation of
forwarding and router control plane hardware and software. The router forwarding and router control plane hardware and software. The router
control plane supports routing and management functions. It is control plane supports routing and management functions. It is
generally described as the router architecture hardware and software generally described as the router architecture hardware and software
components for handling packets destined to the device itself, as well components for handling packets destined to the device itself as well
as, building and sending packets originated locally on the device. The as building and sending packets originated locally on the device. The
forwarding plane is typically described as the router architecture forwarding plane is typically described as the router architecture
hardware and software components responsible for receiving a packet on hardware and software components responsible for receiving a packet on
an incoming interface, performing a lookup to identify the packet's IP an incoming interface, performing a lookup to identify the packet's IP
next hop and best outgoing interface towards the destination, and next hop and best outgoing interface towards the destination, and
forwarding the packet through the appropriate outgoing interface.</t> forwarding the packet through the appropriate outgoing interface.</t>
<t>While the forwarding plane is usually implemented in high-speed <t>While the forwarding plane is usually implemented in high-speed
hardware, the control plane is implemented by a generic processor hardware, the control plane is implemented by a generic processor
(referred to as the route processor (RP)) and cannot process packets (referred to as the routing processor (RP)) and cannot process packets
at a high rate. Hence, this processor can be attacked by flooding its 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 input queue with more packets than it can process. The control plane
processor is then unable to process valid control packets and the processor is then unable to process valid control packets and the
router can lose IGP or BGP adjacencies which can cause a severe router can lose IGP or BGP adjacencies, which can cause a severe
network disruption.</t> network disruption.</t>
<t><xref target="RFC6192" format="default"/> provides detailed guidance
<t><xref target="RFC6192"/> provides detailed guidance to protect the to protect the
router control plane in IPv6 networks. The rest of this section router control plane in IPv6 networks. The rest of this section
contains simplified guidance.</t> contains simplified guidance.</t>
<t>The mitigation techniques are: </t>
<t>The mitigation techniques are: <list style="symbols"> <ul spacing="normal">
<t>To drop non-legit or potentially harmful control packets before <li>to drop illegitimate or potentially harmful control packets before
they are queued to the RP (this can be done by a forwarding plane they are queued to the RP (this can be done by a forwarding plane
ACL) and</t> ACL) and</li>
<li>to rate-limit the remaining packets to a rate that the RP can
<t>To rate-limit the remaining packets to a rate that the RP can
sustain. Protocol-specific protection should also be done (for sustain. Protocol-specific protection should also be done (for
example, a spoofed OSPFv3 packet could trigger the execution of example, a spoofed OSPFv3 packet could trigger the execution of
the Dijkstra algorithm, therefore, the frequency of Dijsktra the Dijkstra algorithm; therefore, the frequency of Dijkstra
calculations should be also rate-limited).</t> calculations should also be rate limited).</li>
</list></t> </ul>
<t>This section will consider several classes of control packets: <t>This section will consider several classes of control packets:
<list style="symbols"> </t>
<t>Control protocols: routing protocols: such as OSPFv3, BGP, <dl newline="true" spacing="normal">
RIPng, and by extension NDP and ICMP</t> <dt>Control protocols:</dt>
<dd>routing protocols, such as OSPFv3, BGP,
<t>Management protocols: SSH, SNMP, NETCONF, RESTCONF, IPFIX, Routing Information Protocol Next Generation (RIPng), and, by extens
etc.</t> ion, NDP and
ICMP</dd>
<t>Packet exceptions: normal data packets that require a specific <dt>Management protocols:</dt>
processing such as generating a packet-too-big ICMP message or <dd>Secure Shell (SSH), SNMP, Network Configuration Protocol (NETCONF),
processing the hop-by-hop options header.</t> RESTCONF,
</list></t> IP Flow Information Export (IPFIX), etc.</dd>
<dt>Packet exceptions:</dt>
<section anchor="control" title="Control Protocols"> <dd>normal data packets that require a specific
<t>This class includes OSPFv3, BGP, NDP, ICMP.</t> processing, such as generating a packet-too-big ICMP message or
processing the hop-by-hop options header</dd>
</dl>
<section anchor="control" 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 <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 packets to be processed by the RP should be configured to: </t>
style="symbols"> <ul spacing="normal">
<t>drop OSPFv3 (identified by Next-Header being 89) and RIPng <li>drop OSPFv3 (identified by Next-Header being 89) and RIPng
(identified by UDP port 521) packets from a non link-local (identified by UDP port 521) packets from a non-link-local
address (except for OSPFv3 virtual links)</t> address (except for OSPFv3 virtual links)</li>
<li>allow BGP (identified by TCP port 179) packets from all BGP
<t>allow BGP (identified by TCP port 179) packets from all BGP neighbors and drop the others</li>
neighbors and drop the others</t> <li>allow all ICMP packets (transit and to the router
interfaces)</li>
<t>allow all ICMP packets (transit and to the router </ul>
interfaces)</t> <aside>
</list></t> <t>Note: Dropping OSPFv3 packets that are authenticated by IPsec
<t>Note: dropping OSPFv3 packets which are authenticated by IPsec
could be impossible on some routers that are unable to parse the could be impossible on some routers that are unable to parse the
IPsec ESP or AH extension headers during ACL classification.</t> IPsec ESP or AH extension headers during ACL classification.</t>
</aside>
<t>Rate-limiting of the valid packets should be done, see also <xref <t>Rate-limiting of the valid packets should be done; see <xref target
target="RFC8541"/> for a side benefit for OSPv3. The exact ="RFC8541"
format="default"/> for a side benefit for OSPv3. The exact
configuration will depend on the available resources of the router configuration will depend on the available resources of the router
(CPU, TCAM, ...).</t> (CPU, Ternary Content-Addressable Memory (TCAM), etc.).</t>
</section> </section>
<!--control--> <section anchor="mgmt" numbered="true" toc="default">
<name>Management Protocols</name>
<section anchor="mgmt" title="Management Protocols"> <t>This class includes SSH, SNMP, RESTCONF, NETCONF, gRPC Remote Proce
<t>This class includes: SSH, SNMP, RESTCONF, NETCONF, gRPC, syslog, dure Calls
NTP, etc.</t> (gRPC), syslog, NTP, etc.</t>
<t>An ingress ACL to be applied on all the router interfaces (or at <t>An ingress ACL to be applied on all the router interfaces (or at
ingress interfaces of the security perimeter or by using specific ingress interfaces of the security perimeter or by using specific
features of the platform) should be configured for packets destined features of the platform) should be configured for packets destined
to the RP such as: <list style="symbols"> to the RP, such as: </t>
<t>Drop packets destined to the routers except those belonging <ul spacing="normal">
to protocols which are used (for example, permit TCP 22 and drop <li>drop packets destined to the routers, except those belonging
all others when only SSH is used);</t> to protocols that are used (for example, permit TCP 22 and drop
all others when only SSH is used) and</li>
<t>Drop packets where the source does not match the security <li>drop packets where the source does not match the security
policy, for example, if SSH connections should only be policy (for example, if SSH connections should only be
originated from the Network Operation Center (NOC), then the ACL originated from the Network Operation Center (NOC), then the ACL
should permit TCP port 22 packets only from the NOC prefix.</t> should permit TCP port 22 packets only from the NOC prefix).</li>
</list></t> </ul>
<t>Rate-limiting of valid packets should be done. The exact <t>Rate-limiting of valid packets should be done. The exact
configuration will depend on the available router resources.</t> configuration will depend on the available router resources.</t>
</section> </section>
<!--mgmt--> <section anchor="exception" numbered="true" toc="default">
<name>Packet Exceptions</name>
<section anchor="exception" title="Packet Exceptions">
<t>This class covers multiple cases where a data plane packet is <t>This class covers multiple cases where a data plane packet is
punted to the route processor because it requires specific punted to the route processor because it requires specific
processing: <list style="symbols"> processing: </t>
<t>generation of an ICMP packet-too-big message when a data <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 plane packet cannot be forwarded because it is too large
(required to discover the Path MTU);</t> (required to discover the Path MTU);</li>
<li>generation of an ICMP hop-limit-expired message when a data
<t>generation of an ICMP hop-limit-expired message when a data
plane packet cannot be forwarded because its hop-limit field has plane packet cannot be forwarded because its hop-limit field has
reached 0 (also used by the traceroute utility);</t> reached 0 (also used by the traceroute utility);</li>
<li>generation of an ICMP destination-unreachable message when a
<t>generation of an ICMP destination-unreachable message when a data plane packet cannot be forwarded for any reason;</li>
data plane packet cannot be forwarded for any reason;</t> <li>processing of the hop-by-hop options header; new
implementations follow <xref target="RFC8200" sectionFormat="of"
<t>processing of the hop-by-hop options header, new section="4.3"/> where this processing is optional; or</li>
implementations follow section 4.3 of <xref target="RFC8200"/> <li>more specific to some router implementations, an oversized
where this processing is optional;</t> extension header chain that cannot be processed by the hardware
and cannot force the packet to be punted to the RP.</li>
<t>or more specific to some router implementation: an oversized </ul>
extension header chain which cannot be processed by the hardware
and force the packet to be punted to the RP.</t>
</list></t>
<t>On some routers, not everything can be done by the specialized <t>On some routers, not everything can be done by the specialized
data plane hardware which requires some packets to be 'punted' to data plane hardware that requires some packets to be 'punted' to
the generic RP. This could include for example the processing of a the generic RP. This could include, for example, the processing of a
long extension header chain in order to apply an ACL based on long extension header chain in order to apply an ACL based on
layer-4 information. <xref target="RFC6980"/> and more generally Layer 4 information. <xref target="RFC6980" format="default"/> and mor
<xref target="RFC7112"/> highlight the security implications of e generally
oversized extension header chains on routers and updates the <xref target="RFC7112" format="default"/> highlight the security impli
original IPv6 specifications, <xref target="RFC2460"/>, such that cations of
oversized extension header chains on routers and update the
original IPv6 specifications <xref target="RFC2460" format="default"/>
such that
the first fragment of a packet is required to contain the entire the first fragment of a packet is required to contain the entire
IPv6 header chain. Those changes are incorporated in the IPv6 IPv6 header chain. Those changes are incorporated in the IPv6
standard <xref target="RFC8200"/></t> standard <xref target="RFC8200" format="default"/>.</t>
<t>An ingress ACL cannot mitigate a control plane attack using these <t>An ingress ACL cannot mitigate a control plane attack using these
packet exceptions. The only protection for the RP is to rate-limit packet exceptions. The only protection for the RP is to rate-limit
those packet exceptions that are forwarded to the RP, this means those packet exceptions that are forwarded to the RP. This means
that some data plane packets will be dropped without an ICMP message that some data plane packets will be dropped without an ICMP message
sent to the source which may delay Path MTU discovery and cause sent to the source, which may delay Path MTU Discovery and cause
drops.</t> drops.</t>
<t>In addition to limiting the rate of data plane packets queued to <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 the RP, it is also important to rate-limit the generation of ICMP
messages. This is important both to preserve RP resources and also messages. This is important both to preserve RP resources and also
to prevent an amplification attack using the router as a reflector. to prevent an amplification attack using the router as a reflector.
It is worth noting that some platforms implement this rate-limiting It is worth noting that some platforms implement this rate-limiting
in hardware. Of course, a consequence of not generating an ICMP in hardware. Of course, a consequence of not generating an ICMP
message will break some IPv6 mechanisms such as Path MTU discovery message will break some IPv6 mechanisms, such as Path MTU Discovery
or a simple traceroute.</t> or a simple traceroute.</t>
</section> </section>
<!--exception-->
</section> </section>
<!--copp--> <section anchor="rsec" numbered="true" toc="default">
<name>Routing Security</name>
<section anchor="rsec" title="Routing Security"> <aside>
<!-- Note to authors: Markus de Bruen would like to see this section sho
rtened as it does not contain IPv6 specific -->
<t>Preamble: IPv6 routing security is congruent with IPv4 routing <t>Preamble: IPv6 routing security is congruent with IPv4 routing
security with the exception of OSPv3 neighbor authentication (see security, with the exception of OSPv3 neighbor authentication (see
<xref target="auth"/>).</t> <xref target="auth" format="default"/>).</t>
</aside>
<t>Routing security in general can be broadly divided into three <t>Routing security in general can be broadly divided into three
sections: <list style="numbers"> sections: </t>
<t>Authenticating neighbors/peers</t> <ol spacing="normal" type="1">
<li>authenticating neighbors/peers</li>
<t>Securing routing updates between peers</t> <li>securing routing updates between peers</li>
<li>route filtering</li>
<t>Route filtering</t> </ol>
</list></t> <t><xref target="RFC5082" format="default"/> is also applicable to IPv6
and can ensure
<t><xref target="RFC5082"/> is also applicable to IPv6 and can ensure
that routing protocol packets are coming from the local network; it that routing protocol packets are coming from the local network; it
must also be noted that in IPv6 all interior gateway protocols use must also be noted that in IPv6 all interior gateway protocols use
link-local addresses.</t> link-local addresses.</t>
<t>As for IPv4, it is recommended to enable a routing protocol only on <t>As for IPv4, it is recommended to enable a routing protocol only on
interfaces where it is required.</t> interfaces where it is required.</t>
<section numbered="true" toc="default">
<section title="BGP Security"> <name>BGP Security</name>
<t>As BGP is identical for IPv4 and IPv6 and as <xref <t>As BGP is identical for IPv4 and IPv6 and as <xref target="RFC7454"
target="RFC7454"/> covers all the security aspects for BGP in format="default"/> covers all the security aspects for BGP in
detail, <xref target="RFC7454"/> is also applicable to IPv6.</t> detail, <xref target="RFC7454" format="default"/> is also applicable t
o IPv6.</t>
</section> </section>
<section anchor="auth" numbered="true" toc="default">
<section anchor="auth" title="Authenticating OSPFv3 Neighbors"> <name>Authenticating OSPFv3 Neighbors</name>
<t>OSPFv3 can rely on IPsec to fulfill the authentication function. <t>OSPFv3 can rely on IPsec to fulfill the authentication function.
Operators should note that IPsec support is not standard on all Operators should note that IPsec support is not standard on all
routing platforms. In some cases, this requires specialized hardware routing platforms. In some cases, this requires specialized hardware
that offloads crypto over to dedicated ASICs or enhanced software that offloads crypto over to dedicated Application-Specific Integrated
Circuits
(ASICs) or enhanced software
images (both of which often come with added financial cost) to images (both of which often come with added financial cost) to
provide such functionality. An added detail is to determine whether provide such functionality. An added detail is to determine whether
OSPFv3 IPsec implementations use AH or ESP-Null for integrity OSPFv3 IPsec implementations use AH or ESP-NULL for integrity
protection. In early implementations, all OSPFv3 IPsec protection. In early implementations, all OSPFv3 IPsec
configurations relied on AH since the details weren't specified in configurations relied on AH since the details weren't specified in
<xref target="RFC5340"/>. However, the document which specifically <xref target="RFC5340" format="default"/>.
describes how IPsec should be implemented for OSPFv3 <xref However, the document that specifically
target="RFC4552"/> specifically states that "ESP-Null MUST and AH describes how IPsec should be implemented for OSPFv3 <xref target="RFC
MAY be implemented" since it follows the overall IPsec standards 4552"
format="default"/> states that "implementations <bcp14>MUST</bcp14> sup
port ESP[-NULL] and
<bcp14>MAY</bcp14> support AH" since it follows the overall IPsec stan
dards
wording. OSPFv3 can also use normal ESP to encrypt the OSPFv3 wording. OSPFv3 can also use normal ESP to encrypt the OSPFv3
payload to provide confidentiality for the routing information.</t> payload to provide confidentiality for the routing information.</t>
<t><xref target="RFC7166" format="default"/> changes OSPFv3 reliance o
<t><xref target="RFC7166"/> changes OSPFv3 reliance on IPsec by n IPsec by
appending an authentication trailer to the end of the OSPFv3 appending an authentication trailer to the end of the OSPFv3
packets; it does not specifically authenticate the specific packets. It does not authenticate the specific
originator of an OSPFv3 packet; rather, it allows a router to originator of an OSPFv3 packet; rather, it allows a router to
confirm that the packet has been issued by a router that had access confirm that the packet has been issued by a router that had access
to the shared authentication key.</t> to the shared authentication key.</t>
<t>With all authentication mechanisms, operators should confirm that <t>With all authentication mechanisms, operators should confirm that
implementations can support re-keying mechanisms that do not cause implementations can support rekeying mechanisms that do not cause
outages. There have been instances where any re-keying causes outages. There have been instances where any rekeying causes
outages and therefore, the tradeoff between utilizing this outages; therefore, the trade-off between utilizing this
functionality needs to be weighed against the protection it functionality needs to be weighed against the protection it
provides. <xref target="RFC4107"/> documents some guidelines for provides. <xref target="RFC4107" format="default"/> documents some gui delines for
crypto keys management.</t> crypto keys management.</t>
</section> </section>
<!--auth--> <section anchor="updates" numbered="true" toc="default">
<name>Securing Routing Updates</name>
<section anchor="updates" title="Securing Routing Updates">
<t>IPv6 initially mandated the provisioning of IPsec capability in <t>IPv6 initially mandated the provisioning of IPsec capability in
all nodes. However, in the updated IPv6 Nodes Requirement standard all nodes. However, in the updated IPv6 Nodes Requirement standard
<xref target="RFC8504"/>, IPsec is a 'SHOULD' and not a 'MUST' <xref target="RFC8504" format="default"/>, IPsec is a '<bcp14>SHOULD</
implement. Theoretically, it is possible that all communication bcp14>' and not a
'<bcp14>MUST</bcp14>'
implementation. Theoretically, it is possible that all communication
between two IPv6 nodes, especially routers exchanging routing between two IPv6 nodes, especially routers exchanging routing
information, is encrypted using IPsec. In practice however, information, is encrypted using IPsec. However, in practice,
deploying IPsec is not always feasible given hardware and software deploying IPsec is not always feasible given hardware and software
limitations of the various platforms deployed.</t> limitations of the various platforms deployed.</t>
<t>Many routing protocols support the use of cryptography to protect <t>Many routing protocols support the use of cryptography to protect
the routing updates, the use of this protection is recommended; the routing updates; the use of this protection is recommended.
<xref target="RFC8177"/> is a YANG data model for key chains that <xref target="RFC8177" format="default"/> is a YANG data model for key
includes re-keying functionality.</t> chains
that includes rekeying functionality.</t>
</section> </section>
<!--updates--> <section anchor="rfilter" numbered="true" toc="default">
<name>Route Filtering</name>
<section anchor="rfilter" title="Route Filtering">
<t>Route filtering policies will be different depending on whether <t>Route filtering policies will be different depending on whether
they pertain to edge route filtering vs. internal route filtering. they pertain to edge route filtering or internal route filtering.
At a minimum, IPv6 routing policy as it pertains to routing between At a minimum, the IPv6 routing policy, as it pertains to routing betwe
different administrative domains should aim to maintain parity with en
IPv4 from a policy perspective, e.g., <list style="symbols"> different administrative domains, should aim to maintain parity with
<t>Filter internal-use, non-globally routable IPv6 addresses at IPv4 from a policy perspective, for example: </t>
the perimeter;</t> <ul spacing="normal">
<li>filter internal-use IPv6 addresses that are not globally routabl
<t>Discard routes for bogon <xref target="CYMRU"/> and reserved e at
space (see <xref target="RFC8190"/>);</t> the perimeter;</li>
<li>discard routes
<t>Configure ingress route filters that validate route origin, for bogon <xref target="CYMRU" format="default"/> and reserved
prefix ownership, etc. through the use of various routing space (see <xref target="RFC8190" format="default"/>); and</li>
databases, e.g., <xref target="RADB"/>. <xref target="RFC8210"/> <li>configure ingress route filters that validate route origin,
formally validates the origin ASs of BGP announcements. </t> prefix ownership, etc., through the use of various routing
</list></t> databases, e.g., <xref target="RADB" format="default"/>. <xref tar
get="RFC8210" format="default"/>
<t>Some good guidance can be found at <xref target="RFC7454"/>.</t> formally validates the origin Autonomous Systems (ASes) of BGP ann
ouncements. </li>
</ul>
<t>Some good guidance can be found at <xref target="RFC7454" format="d
efault"/>.</t>
<t>A valid routing table can also be used to apply network ingress <t>A valid routing table can also be used to apply network ingress
filtering (see <xref target="RFC2827"/>).</t> filtering (see <xref target="RFC2827" format="default"/>).</t>
</section> </section>
<!--rfilter-->
</section> </section>
<!--rsec--> <section anchor="log" numbered="true" toc="default">
<name>Logging/Monitoring</name>
<section anchor="log" title="Logging/Monitoring">
<t>In order to perform forensic research in the cases of a security <t>In order to perform forensic research in the cases of a security
incident or detecting abnormal behavior, network operators should log incident or detecting abnormal behavior, network operators should log
multiple pieces of information. In some cases, this requires a multiple pieces of information. In some cases, this requires a
frequent poll of devices via a Network Management Station.</t> frequent poll of devices via a Network Management Station.</t>
<t>This logging should include but is not limited to: </t>
<t>This logging should include, but not limited to: <list <ul spacing="normal">
style="symbols"> <li>logs of all applications using the network (including user
<t>logs of all applications using the network (including user space and kernel space) when available (for example, web servers
space and kernel space) when available (for example web servers that the network operator manages);</li>
that the network operator manages);</t> <li>data from <xref target="RFC7011" format="default">IP Flow Informat
ion Export
<t>data from <xref target="RFC7011">IP Flow Information Export </xref>, also known as IPFIX;</li>
</xref> also known as IPFIX;</t> <li>data from various SNMP <xref target="RFC4293" format="default">MIB
s</xref> or
<t>data from various SNMP <xref target="RFC4293">MIBs</xref> or YANG data via <xref target="RFC8040" format="default">RESTCONF</xref
YANG data via RESTCONF <xref target="RFC8040"/> or NETCONF <xref > or <xref target="RFC6241" format="default">NETCONF</xref>;</li>
target="RFC6241"/>;</t> <li>historical data of Neighbor Cache entries;</li>
<li>
<t>historical data of Neighbor Cache entries;</t> <xref target="RFC8415" format="default">stateful DHCPv6</xref> lease
cache,
<t><xref target="RFC8415">stateful DHCPv6</xref> lease cache, especially when a <xref target="RFC6221" format="default">relay agen
especially when a <xref target="RFC6221">relay agent</xref> is t</xref> is
used;</t> used;</li>
<li><xref target="RFC7039" format="default">Source Address Validation
<t>Source Address Validation Improvement (SAVI) <xref Improvement
target="RFC7039"/> events, especially the binding of an IPv6 (SAVI)</xref> events, especially the binding of an IPv6
address to a MAC address and a specific switch or router address to a MAC address and a specific switch or router
interface;</t> interface;</li>
<li>firewall ACL logs;</li>
<t>firewall ACL log;</t> <li>authentication server logs; and</li>
<li>
<t>authentication server log;</t> <xref target="RFC2866" format="default">RADIUS</xref> accounting rec
ords.</li>
<t><xref target="RFC2866">RADIUS</xref> accounting records.</t> </ul>
</list></t>
<t>Please note that there are privacy issues or regulations related to <t>Please note that there are privacy issues or regulations related to
how these logs are collected, stored, used, and safely discarded. how these logs are collected, stored, used, and safely discarded.
Operators are urged to check their country legislation (e.g., General Operators are urged to check their country legislation (e.g., General
Data Protection Regulation <xref target="GDPR">GDPR</xref> in the Data Protection Regulation <xref target="GDPR" format="default"></xref> in the
European Union).</t> European Union).</t>
<t>All those pieces of information can be used for:</t>
<t>All those pieces of information can be used for:<list <ul spacing="normal">
style="symbols"> <li>
<t><xref target="forensic">forensic</xref> investigations such as <xref target="forensic" format="default">forensic</xref> investigati
who did what and when?</t> ons:
who did what and when?</li>
<t><xref target="correlation">correlation</xref>: which IP <li>
addresses were used by a specific node (assuming the use of <xref <xref target="correlation" format="default">correlation</xref>: whic
target="RFC8981">privacy extensions addresses </xref>)</t> h IP
addresses were used by a specific node (assuming the use of <xref ta
<t><xref target="inventory">inventory</xref>: which IPv6 nodes are rget="RFC8981" format="default">privacy extensions addresses </xref>)?</li>
on my network?</t> <li>
<xref target="inventory" format="default">inventory</xref>: which IP
<t><xref target="abnormal_behavior">abnormal behavior v6 nodes
are on my network?</li>
<li>
<xref target="abnormal_behavior" format="default">abnormal behavior
detection</xref>: unusual traffic patterns are often the symptoms detection</xref>: unusual traffic patterns are often the symptoms
of an abnormal behavior which is in turn a potential attack of an abnormal behavior, which is in turn a potential attack
(denial-of-service, network scan, a node being part of a botnet, (denial of service, network scan, a node being part of a botnet,
etc.)</t> etc.).</li>
</list></t> </ul>
<section anchor="data_sources" numbered="true" toc="default">
<section anchor="data_sources" title="Data Sources"> <name>Data Sources</name>
<t>This section lists the most important sources of data that are <t>This section lists the most important sources of data that are
useful for operational security.</t> useful for operational security.</t>
<section numbered="true" toc="default">
<section title="Application Logs"> <name>Application Logs</name>
<t>Those logs are usually text files where the remote IPv6 address <t>Those logs are usually text files where the remote IPv6 address
is stored in clear text (not binary). This can complicate the is stored in cleartext (not binary). This can complicate the
processing since one IPv6 address, for example 2001:db8::1 can be processing since one IPv6 address, for example, 2001:db8::1, can be
written in multiple ways, such as:<list style="symbols"> written in multiple ways, such as:</t>
<t>2001:DB8::1 (in uppercase)</t> <ul spacing="normal">
<li>2001:DB8::1 (in uppercase),</li>
<t>2001:0db8::0001 (with leading 0)</t> <li>2001:0db8::0001 (with leading 0), and</li>
<li>many other ways, including the reverse DNS mapping into
<t>and many other ways including the reverse DNS mapping into a Fully Qualified Domain Name (FQDN) (which should not be truste
a FQDN (which should not be trusted).</t> d).</li>
</list></t> </ul>
<t><xref target="RFC5952" format="default"/> explains this problem i
<t><xref target="RFC5952"/> explains this problem in detail and n detail and
recommends the use of a single canonical format. This document recommends the use of a single canonical format. This document
recommends the use of <xref target="RFC5952">canonical recommends the use of <xref target="RFC5952" format="default">canoni cal
format</xref> for IPv6 addresses in all possible cases. If the format</xref> for IPv6 addresses in all possible cases. If the
existing application cannot log using the canonical format, then existing application cannot log using the canonical format, then
it is recommended to use an external post-processing program in it is recommended to use an external post-processing program in
order to canonicalize all IPv6 addresses.</t> order to canonicalize all IPv6 addresses.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="IP Flow Information Export by IPv6 Routers"> <name>IP Flow Information Export by IPv6 Routers</name>
<t><xref target="RFC7012">IPFIX</xref> defines some data elements <t><xref target="RFC7012" format="default">IPFIX</xref> defines some
that are useful for security:<list style="symbols"> data elements
<t>nextHeaderIPv6, sourceIPv6Address, and that are useful for security:</t>
destinationIPv6Address;</t> <ul spacing="normal">
<li>nextHeaderIPv6, sourceIPv6Address, and
<t>sourceMacAddress and destinationMacAddress.</t> destinationIPv6Address</li>
</list></t> <li>sourceMacAddress and destinationMacAddress</li>
</ul>
<t>The IP version is the ipVersion element defined in <xref <t>The IP version is the ipVersion element defined in <xref target="
target="IANA-IPFIX"/>.</t> IANA-IPFIX" format="default"/>.</t>
<t>Moreover, IPFIX is very efficient in terms of data handling and <t>Moreover, IPFIX is very efficient in terms of data handling and
transport. It can also aggregate flows by a key such as transport. It can also aggregate flows by a key, such as
sourceMacAddress in order to have aggregated data associated with sourceMacAddress, in order to have aggregated data associated with
a specific sourceMacAddress. This memo recommends the use of IPFIX a specific sourceMacAddress. This memo recommends the use of IPFIX
and aggregation on nextHeaderIPv6, sourceIPv6Address, and and aggregation on nextHeaderIPv6, sourceIPv6Address, and
sourceMacAddress.</t> sourceMacAddress.</t>
</section> </section>
<section anchor="mib" numbered="true" toc="default">
<section anchor="mib" <name>SNMP MIB and NETCONF/RESTCONF YANG Modules Data by IPv6 Router
title="SNMP MIB and NETCONF/RESTCONF YANG Modules data by IPv s</name>
6 Routers"> <t><xref target="RFC4293" format="default"></xref> defines a Managem
<t><xref target="RFC4293">RFC 4293</xref> defines a Management ent
Information Base (MIB) for the two address families of IP. This Information Base (MIB) for the two address families of IP. This
memo recommends the use of:<list style="symbols"> memo recommends the use of:</t>
<t>ipIfStatsTable table which collects traffic counters per <ul spacing="normal">
interface;</t> <li>ipIfStatsTable table, which collects traffic counters per
interface, and</li>
<t>ipNetToPhysicalTable table which is the content of the <li>ipNetToPhysicalTable table, which is the content of the
Neighbor cache, i.e., the mapping between IPv6 and data-link Neighbor Cache, i.e., the mapping between IPv6 and data-link
layer addresses.</t> layer addresses.</li>
</list></t> </ul>
<t>There are also YANG modules relating to the two IP address
<t>There are also YANG modules relating to the two IP addresses families and that can be used with <xref target="RFC6241" format="de
families and can be used with <xref target="RFC6241"/> and <xref fault"/> and <xref target="RFC8040" format="default"/>. This memo recommends the
target="RFC8040"/>. This memo recommends the use of:<list use of:</t>
style="symbols"> <ul spacing="normal">
<t>interfaces-state/interface/statistics from <xref <li>interfaces-state/interface/statistics from <xref target="RFC83
target="RFC8343">ietf-interfaces@2018-02-20.yang</xref> which 43" format="default">ietf-interfaces@2018-02-20.yang</xref>, which
contains counters for interfaces.</t> contains counters for interfaces, and</li>
<li>ipv6/neighbor from <xref target="RFC8344" format="default">iet
<t>ipv6/neighbor from <xref f-ip@2018-02-22.yang</xref>, which is the
target="RFC8344">ietf-ip@2018-02-22.yang</xref> which is the content of the Neighbor Cache, i.e., the mapping between IPv6
content of the Neighbor cache, i.e., the mapping between IPv6 and data-link layer addresses.</li>
and data-link layer addresses.</t> </ul>
</list></t>
</section> </section>
<section anchor="ndp_cache" numbered="true" toc="default">
<section anchor="ndp_cache" title="Neighbor Cache of IPv6 Routers"> <name>Neighbor Cache of IPv6 Routers</name>
<t>The neighbor cache of routers contains all mappings between <t>The Neighbor Cache of routers contains all mappings between
IPv6 addresses and data-link layer addresses. There are multiple IPv6 addresses and data-link layer addresses. There are multiple
ways to collect the current entries in the Neighbor Cache, notably ways to collect the current entries in the Neighbor Cache, notably,
but not limited to:<list style="symbols"> but not limited to:</t>
<t>the <xref target="mib">SNMP MIB</xref> as explained <ul spacing="normal">
above;</t> <li>using the <xref target="mib" format="default">SNMP MIB</xref>,
as
<t>using streaming telemetry or <xref explained above;</li>
target="RFC6241">NETCONF</xref> and <xref <li>using streaming telemetry or <xref target="RFC6241"
target="RFC8040">RESTCONF</xref> to collect the operational format="default">NETCONF</xref> and <xref target="RFC8040"
state of the neighbor cache;</t> format="default">RESTCONF</xref> to collect the operational
state of the Neighbor Cache; and</li>
<t>also, by connecting over a secure management channel (such <li>connecting over a secure management channel (such
as SSH) and explicitly requesting a neighbor cache dump via as SSH) and explicitly requesting a Neighbor Cache dump via
the Command Line Interface (CLI) or another monitoring the Command-Line Interface (CLI) or another monitoring
mechanism.</t> mechanism.</li>
</ul>
<!-- Mikael Abrahamsson: let's add some text around YANG as ther <t>The Neighbor Cache is highly dynamic, as mappings are added when
e is a model for doing just that -->
</list></t>
<t>The neighbor cache is highly dynamic as mappings are added when
a new IPv6 address appears on the network. This could be quite a new IPv6 address appears on the network. This could be quite
frequently with <xref target="RFC8981">privacy extension frequently with <xref target="RFC8981" format="default">privacy exte nsion
addresses</xref> or when they are removed when the state goes from addresses</xref> or when they are removed when the state goes from
UNREACH to removed (the default time for a removal per <xref UNREACH to removed (the default time for a removal per <xref target=
target="RFC4861">Neighbor Unreachability Detection</xref> "RFC4861" format="default">Neighbor Unreachability Detection</xref>
algorithm is 38 seconds for a host using Windows 7). This means algorithm is 38 seconds for a host using Windows 7). This means
that the content of the neighbor cache must periodically be that the content of the Neighbor Cache must be
fetched at an interval which does not exhaust the router resources fetched periodically at an interval that does not exhaust the router
and still provides valuable information (suggested value is 30 resources
seconds but this should be verified in the actual deployment) and and still provides valuable information (the suggested value is 30
seconds, but this should be verified in the actual deployment) and
stored for later use.</t> stored for later use.</t>
<t>This is an important source of information because it is <t>This is an important source of information because it is
trivial (on a switch not using the <xref trivial (on a switch not using the <xref target="RFC7039" format="de
target="RFC7039">SAVI</xref> algorithm) to defeat the mapping fault">SAVI</xref> algorithm) to defeat the mapping
between data-link layer address and IPv6 address. Let us rephrase between data-link layer address and an IPv6 address. Put another way
the previous statement: having access to the current and past , having access to the current and past
content of the neighbor cache has a paramount value for the content of the Neighbor Cache has a paramount value for the
forensic and audit trail. It should also be noted that in certain forensic and audit trails. It should also be noted that, in certain
threat models this information is also deemed valuable and could threat models, this information is also deemed valuable and could
itself be a target.</t> itself be a target.</t>
<t>When using one /64 per host (<xref target="sixty4perhost" format=
<t>When using one /64 per host (<xref target="sixty4perhost"/>) or "default"/>)
DHCP-PD, it is sufficient to keep the history of the allocated or DHCP-PD, it is sufficient to keep the history of the allocated
prefixes when combined with strict source address prefix prefixes when combined with strict source address prefix
enforcement on the routers and layer-2 switches to prevent IPv6 enforcement on the routers and L2 switches to prevent IPv6
spoofing.</t> spoofing.</t>
</section> </section>
<section anchor="stateful_dhcp" numbered="true" toc="default">
<section anchor="stateful_dhcp" title="Stateful DHCPv6 Lease"> <name>Stateful DHCPv6 Lease</name>
<t>In some networks, IPv6 addresses/prefixes are managed by a <t>In some networks, IPv6 addresses/prefixes are managed by a
stateful <xref target="RFC8415">DHCPv6 server</xref> that leases stateful <xref target="RFC8415" format="default">DHCPv6 server</xref > that leases
IPv6 addresses/prefixes to clients. It is indeed quite similar to 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 DHCP for IPv4, so it can be tempting to use this DHCP lease file
to discover the mapping between IPv6 addresses/prefixes and to discover the mapping between IPv6 addresses/prefixes and
data-link layer addresses as is commonly used in IPv4 data-link layer addresses, as is commonly used in IPv4
networking.</t> networking.</t>
<t>It is not so easy in the IPv6 networks, because not all nodes <t>It is not so easy in the IPv6 networks, because not all nodes
will use DHCPv6 (there are nodes which can only do stateless will use DHCPv6 (there are nodes that can only do stateless
autoconfiguration) but also because DHCPv6 clients are identified autoconfiguration) and also because DHCPv6 clients are identified
not by their hardware-client address as in IPv4 but by a DHCP not by their hardware-client address, as in IPv4, but by a DHCP
Unique ID (DUID), which can have several formats: some being the Unique Identifier (DUID). The DUID can have several formats: the
data-link layer address, some being data-link layer address data-link layer address, the data-link layer address
prepended with time information, or even an opaque number that prepended with time information, or even an opaque number that
requires correlation with another data source to be usable for requires correlation with another data source to be usable for
operational security. Moreover, when the DUID is based on the operational security. Moreover, when the DUID is based on the
data-link address, this address can be of any client interface data-link address, this address can be of any client interface
(such as the wireless interface while the client actually uses its (such as the wireless interface, while the client actually uses its
wired interface to connect to the network).</t> wired interface to connect to the network).</t>
<t>If a <xref target="RFC6221" format="default">lightweight DHCP rel
<t>If a <xref target="RFC6221">lightweight DHCP relay agent</xref> ay
is used in a layer-2 switch, then the DHCP servers also receive agent</xref>
the Interface-ID information which could be saved in order to is used in a L2 switch, then the DHCP servers also receive
the interface ID information, which could be saved in order to
identify the interface on which the switch received a specific identify the interface on which the switch received a specific
leased IPv6 address. Also, if a 'normal' (not lightweight) relay leased IPv6 address. Also, if a 'normal' (not lightweight) relay
agent adds the data-link layer address in the option for <xref agent adds the data-link layer address in the option for Relay Agent
target="RFC4649">Relay Agent Remote-ID</xref> or <xref Remote-ID <xref target="RFC4649" format="default"></xref> <xref
target="RFC6939"/>, then the DHCPv6 server can keep track of the target="RFC6939" format="default"/>, then the DHCPv6 server can keep
data-link and leased IPv6 addresses.</t> track of the data-link and leased IPv6 addresses.</t>
<t>In short, the DHCPv6 lease file is less interesting than lease fi
<t>In short, the DHCPv6 lease file is less interesting than for les for
IPv4 networks. If possible, it is recommended to use DHCPv6 IPv4 networks. If possible, it is recommended to use DHCPv6
servers that keep the relayed data-link layer address in addition servers that keep the relayed data-link layer address in addition
to the DUID in the lease file as those servers have the equivalent to the DUID in the lease file, as those servers have the equivalent
information to IPv4 DHCP servers.</t> information to IPv4 DHCP servers.</t>
<t>The mapping between the data-link layer address and the IPv6
<t>The mapping between data-link layer address and the IPv6
address can be secured by deploying switches implementing the address can be secured by deploying switches implementing the
<xref target="RFC7513">SAVI</xref> mechanisms. Of course, this <xref target="RFC7513" format="default">SAVI</xref> mechanisms. Of c
also requires that the data-link layer address is protected by ourse, this
using a layer-2 mechanism such as <xref also requires that the data-link layer address be protected by
target="IEEE-802.1X"/>.</t> using a L2 mechanism, such as <xref target="IEEE-802.1X" format="def
ault"/>.</t>
</section> </section>
<section anchor="radius_accounting" numbered="true" toc="default">
<section anchor="radius_accounting" title="RADIUS Accounting Log"> <name>RADIUS Accounting Log</name>
<t>For interfaces where the user is authenticated via a <xref <t>For interfaces where the user is authenticated via a <xref target
target="RFC2866">RADIUS</xref> server, and if RADIUS accounting is ="RFC2866" format="default">RADIUS</xref> server, and if RADIUS accounting is
enabled, then the RADIUS server receives accounting enabled, then the RADIUS server receives accounting
Acct-Status-Type records at the start and at the end of the Acct-Status-Type records at the start and at the end of the
connection which include all IPv6 (and IPv4) addresses used by the connection, which include all IPv6 (and IPv4) addresses used by the
user. This technique can be used notably for Wi-Fi networks with user. This technique can be used notably for Wi-Fi networks with
Wi-Fi Protected Address (WPA) or other <xref Wi-Fi Protected Access (WPA) or other <xref target="IEEE-802.1X" for
target="IEEE-802.1X">IEEE 802.1X</xref> wired interface on an mat="default">IEEE 802.1X</xref> wired interfaces on an
Ethernet switch.</t> Ethernet switch.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Other Data Sources"> <name>Other Data Sources</name>
<t>There are other data sources for log information that must be <t>There are other data sources for log information that must be
collected (as currently collected in IPv4 networks):<list collected (as currently collected in IPv4 networks):</t>
style="symbols"> <ul spacing="normal">
<t>historical mapping of IPv6 addresses to users of remote <li>historical mappings of IPv6 addresses to users of remote
access VPN;</t> access VPN and</li>
<li>historical mappings of MAC addresses to switch ports in a
<t>historical mappings of MAC addresses to switch ports in a wired network.</li>
wired network.</t> </ul>
</list></t>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="Use of Collected Data"> <name>Use of Collected Data</name>
<t>This section leverages the data collected as described <xref <t>This section leverages the data collected, as described in <xref
format="default" target="data_sources">before</xref> in order to format="default" target="data_sources"></xref>, in order to
achieve several security benefits. Section 9.1 of <xref achieve several security benefits. <xref target="RFC7934" sectionForma
target="RFC7934"/> contains more details about host tracking.</t> t="of"
section="9.1"/> contains more details about host tracking.</t>
<section anchor="forensic" title="Forensic and User Accountability"> <section anchor="forensic" numbered="true" toc="default">
<name>Forensic and User Accountability</name>
<t>The forensic use case is when the network operator must locate <t>The forensic use case is when the network operator must locate
an IPv6 address (and the assocated port, access point/switch, or an IPv6 address (and the associated port, access point/switch, or
VPN tunnel) that was present in the network at a certain time or VPN tunnel) that was present in the network at a certain time or
is currently in the network.</t> is currently in the network.</t>
<t>To locate an IPv6 address in an enterprise network where the <t>To locate an IPv6 address in an enterprise network where the
operator has control over all resources, the source of information operator has control over all resources, the source of information
can be the neighbor cache, or, if not found, the DHCP lease file. can be the Neighbor Cache, or, if not found, the DHCP lease file.
Then, the procedure is: <list style="numbers"> Then, the procedure is: </t>
<t>Based on the IPv6 prefix of the IPv6 address, find the <ol spacing="normal" type="1">
router(s) which is(are) used to reach this prefix (assuming <li>based on the IPv6 prefix of the IPv6 address; find one or more
that anti-spoofing mechanisms are used) perhaps based on an routers that are used to reach this prefix (assuming
IPAM.</t> that anti-spoofing mechanisms are used), perhaps based on an
IPAM.</li>
<t>Based on this limited set of routers, on the incident time <li>based on this limited set of routers, on the incident time,
and on the IPv6 address, retrieve the data-link address from and on the IPv6 address; retrieve the data-link address from
the live neighbor cache, from the historical neighbor cache the live Neighbor Cache, from the historical Neighbor Cache
data, or from SAVI events, or retrieve the data-link address data, or from SAVI events, or retrieve the data-link address
from the DHCP lease file (<xref target="stateful_dhcp"/>).</t> from the DHCP lease file (<xref target="stateful_dhcp"
format="default"/>).</li>
<t>Based on the data-link layer address, look-up the switch <li>based on the data-link layer address; look up the switch
interface associated with the data-link layer address. In the interface associated with the data-link layer address. In the
case of wireless LAN with RADIUS accounting (see <xref case of wireless LAN with RADIUS accounting (see <xref target="r
target="radius_accounting"/>), the RADIUS log has the mapping adius_accounting" format="default"/>), the RADIUS log has the mapping
between the user identification and the MAC address. If a between the user identification and the MAC address. If a
Configuration Management Data Base (CMDB) is used, then it can Configuration Management Database (CMDB) is used, then it can
be used to map the data-link layer address to a switch be used to map the data-link layer address to a switch
port.</t> port.</li>
</list></t> </ol>
<t>At the end of the process, the interface of the host <t>At the end of the process, the interface of the host
originating, or the subscriber identity associated with, the originating or the subscriber identity associated with the
activity in question has been determined.</t> activity in question has been determined.</t>
<t>To identify the subscriber of an IPv6 address in a residential <t>To identify the subscriber of an IPv6 address in a residential
Internet Service Provider, the starting point is the DHCP-PD Internet Service Provider, the starting point is the DHCP-PD
leased prefix covering the IPv6 address; this prefix can often be leased prefix covering the IPv6 address; this prefix can often be
linked to a subscriber via the RADIUS log. Alternatively, the linked to a subscriber via the RADIUS log. Alternatively, the
Forwarding Information Base (FIB) of the Cable Modem Termination Forwarding Information Base (FIB) of the Cable Modem Termination
System (CMTS) or Broadband Network Gateway (BNG) indicates the CPE System (CMTS) or Broadband Network Gateway (BNG) indicates the Custo
mer Premises
Equipment (CPE)
of the subscriber and the RADIUS log can be used to retrieve the of the subscriber and the RADIUS log can be used to retrieve the
actual subscriber.</t> actual subscriber.</t>
<t>More generally, a mix of the above techniques can be used in <t>More generally, a mix of the above techniques can be used in
most, if not all, networks.</t> most, if not all, networks.</t>
</section> </section>
<section anchor="inventory" numbered="true" toc="default">
<section anchor="inventory" title="Inventory"> <name>Inventory</name>
<t><xref target="RFC7707">RFC 7707</xref> describes the <t><xref target="RFC7707" format="default"></xref> describes the
difficulties for an attacker to scan an IPv6 network due to 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 vast number of IPv6 addresses per link (and why in some cases it
can still be done). While the huge addressing space can sometimes can still be done). While the huge addressing space can sometimes
be perceived as a 'protection', it also makes the inventory task 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 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 network (a simple enumeration of all IPv4 addresses, followed by a
ping and a TCP/UDP port scan). Getting an inventory of all ping and a TCP/UDP port scan). Getting an inventory of all
connected devices is of prime importance for a secure network connected devices is of prime importance for a secure network
operation.</t> operation.</t>
<t>There are many ways to do an inventory of an IPv6 network.</t> <t>There are many ways to do an inventory of an IPv6 network.</t>
<t>The first technique is to use passive inspection, such as IPFIX.
<t>The first technique is to use passive inspection such as IPFIX.
Using exported IPFIX information and extracting the list of all Using exported IPFIX information and extracting the list of all
IPv6 source addresses allows finding all IPv6 nodes that sent IPv6 source addresses allows finding all IPv6 nodes that sent
packets through a router. This is very efficient but, alas, will packets through a router. This is very efficient but, alas, will
not discover silent nodes that never transmitted packets not discover silent nodes that never transmitted packets
traversing the IPFIX target router. Also, it must be noted that traversing the IPFIX target router. Also, it must be noted that
link-local addresses will never be discovered by this means. </t> link-local addresses will never be discovered by this means. </t>
<t>The second way is again to use the collected Neighbor Cache
<t>The second way is again to use the collected neighbor cache
content to find all IPv6 addresses in the cache. This process will content to find all IPv6 addresses in the cache. This process will
also discover all link-local addresses. See <xref also discover all link-local addresses. See <xref target="ndp_cache"
target="ndp_cache"/>.</t> format="default"/>.</t>
<t>Another way that works only for a local network consists of
<t>Another way that works only for a local network, consists of sending an ICMP ECHO_REQUEST to the link-local multicast address
sending a ICMP ECHO_REQUEST to the link-local multicast address ff02::1, which addresses all IPv6 nodes on the network. All nodes
ff02::1 which addresses all IPv6 nodes on the network. All nodes should reply to this ECHO_REQUEST, per <xref target="RFC4443"
should reply to this ECHO_REQUEST per <xref format="default"/>.</t>
target="RFC4443"/>.</t>
<t>Other techniques involve obtaining data from DNS, parsing log <t>Other techniques involve obtaining data from DNS, parsing log
files, leveraging service discovery such as mDNS <xref files, and leveraging service discovery, such as mDNS <xref target="
target="RFC6762"/> and <xref target="RFC6763"/>.</t> RFC6762"
format="default"/> <xref target="RFC6763" format="default"/>.</t>
<t>Enumerating DNS zones, especially looking at reverse DNS <t>Enumerating DNS zones, especially looking at reverse DNS
records and CNAMES, is another common method employed by various records and CNAMEs, is another common method employed by various
tools. As already mentioned in <xref target="RFC7707"/>, this tools. As already mentioned in <xref target="RFC7707" format="defaul
allows an attacker to prune the IPv6 reverse DNS tree, and hence t"/>, this
allows an attacker to prune the IPv6 reverse DNS tree and hence
enumerate it in a feasible time. Furthermore, authoritative enumerate it in a feasible time. Furthermore, authoritative
servers that allow zone transfers (AXFR) may be a further servers that allow zone transfers (i.e., Authoritative Transfers (AX
information source. An interesting research paper has analysed the FRs)) may be a further
entropy in various IPv6 addresses: see <xref information source. An interesting research paper has analyzed the
target="ENTROPYIP"/>.</t> entropy in various IPv6 addresses: see <xref target="ENTROPYIP" form
at="default"/>.</t>
</section> </section>
<section anchor="correlation" numbered="true" toc="default">
<section anchor="correlation" title="Correlation"> <name>Correlation</name>
<t>In an IPv4 network, it is easy to correlate multiple logs, for <t>In an IPv4 network, it is easy to correlate multiple logs, for
example to find events related to a specific IPv4 address. A example, to find events related to a specific IPv4 address. A
simple Unix grep command is enough to scan through multiple simple Unix grep command is enough to scan through multiple
text-based files and extract all lines relevant to a specific IPv4 text-based files and extract all lines relevant to a specific IPv4
address.</t> address.</t>
<t>In an IPv6 network, this is slightly more difficult because <t>In an IPv6 network, this is slightly more difficult because
different character strings can express the same IPv6 address. different character strings can express the same IPv6 address.
Therefore, the simple Unix grep command cannot be used. Moreover, Therefore, the simple Unix grep command cannot be used. Moreover,
an IPv6 node can have multiple IPv6 addresses.</t> an IPv6 node can have multiple IPv6 addresses.</t>
<t>In order to do correlation in IPv6-related logs, it is advised <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 to have all logs in a format with only canonical IPv6 addresses
<xref target="RFC5952"/>. Then, the neighbor cache current (or <xref target="RFC5952" format="default"/>. Then, the current (or
historical) data set must be searched to find the data-link layer historical) Neighbor Cache data set must be searched to find the dat
address of the IPv6 address. Then, the current and historical a-link layer
neighbor cache data sets must be searched for all IPv6 addresses address of the IPv6 address. Next, the current and historical
Neighbor Cache data sets must be searched for all IPv6 addresses
associated with this data-link layer address to derive the search associated with this data-link layer address to derive the search
set. The last step is to search in all log files (containing only set. The last step is to search in all log files (containing only
IPv6 addresses in canonical format) for any IPv6 addresses in the IPv6 addresses in canonical format) for any IPv6 addresses in the
search set.</t> search set.</t>
<t>Moreover, <xref target="RFC7934" format="default"/> recommends us
<t>Moreover, <xref target="RFC7934"/> recommends using multiple ing multiple
IPv6 addresses per prefix, so, the correlation must also be done IPv6 addresses per prefix, so the correlation must also be done
among those multiple IPv6 addresses, for example by discovering in among those multiple IPv6 addresses, for example, by discovering all
the <xref target="ndp_cache">NDP cache</xref> all IPv6 addresses IPv6 addresses
associated with the same MAC address and interface.</t> associated with the same MAC address and interface in
the <xref target="ndp_cache" format="default">NDP cache</xref>.</t>
</section> </section>
<section anchor="abnormal_behavior" numbered="true" toc="default">
<section anchor="abnormal_behavior" <name>Abnormal Behavior Detection</name>
title="Abnormal Behavior Detection">
<t>Abnormal behavior (such as network scanning, spamming, <t>Abnormal behavior (such as network scanning, spamming,
denial-of-service) can be detected in the same way as in an IPv4 DoS) can be detected in the same way as in an IPv4
network.<list style="symbols"> network:</t>
<t>Sudden increase of traffic detected by interface counter <ul spacing="normal">
(SNMP) or by aggregated traffic from <xref <li>a sudden increase of traffic detected by interface counter
target="RFC7012">IPFIX records</xref>.</t> (SNMP) or by aggregated traffic from <xref target="RFC7012"
format="default">IPFIX records</xref>,</li>
<t>Rapid growth of ND cache size.</t> <li>rapid growth of ND cache size, or</li>
<li>change in traffic pattern (number of connections per
<t>Change in traffic pattern (number of connections per second, number of connections per host, etc.) observed with the
second, number of connections per host...) observed with the use of <xref target="RFC7012" format="default">IPFIX</xref>.</li
use of <xref target="RFC7012">IPFIX</xref>.</t> >
</list></t> </ul>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="Summary"> <name>Summary</name>
<t>While some data sources (IPFIX, MIB, switch CAM tables, logs, <t>While some data sources (IPFIX, MIB, switch Content Addressable Mem
...) used in IPv4 are also used in the secure operation of an IPv6 ory (CAM)
network, the DHCPv6 lease file is less reliable and the neighbor tables, logs, etc.) used in IPv4 are also used in the secure operation
cache is of prime importance.</t> of an IPv6
network, the DHCPv6 lease file is less reliable and the Neighbor
Cache is of prime importance.</t>
<t>The fact that there are multiple ways to express the same IPv6 <t>The fact that there are multiple ways to express the same IPv6
address in a character string renders the use of filters mandatory address in a character string renders the use of filters mandatory
when correlation must be done.</t> when correlation must be done.</t>
</section> </section>
</section> </section>
<section anchor="coexistence" numbered="true" toc="default">
<section anchor="coexistence" <name>Transition/Coexistence Technologies</name>
title="Transition/Coexistence Technologies">
<t>As it is expected that some networks will not run in a pure <t>As it is expected that some networks will not run in a pure
IPv6-only mode, the different transition mechanisms must be deployed IPv6-only mode, the different transition mechanisms must be deployed
and operated in a secure way. This section proposes operational and operated in a secure way. This section proposes operational
guidelines for the most known and deployed transition techniques. guidelines for the most-known and deployed transition techniques.
<xref target="RFC4942"/> also contains security considerations for <xref target="RFC4942" format="default"/> also contains security conside
rations for
transition or coexistence scenarios.</t> transition or coexistence scenarios.</t>
<section anchor="dual" numbered="true" toc="default">
<section anchor="dual" title="Dual Stack"> <name>Dual Stack</name>
<t>Dual stack is often the first deployment choice for network <t>Dual stack is often the first deployment choice for network
operators. Dual stacking the network offers some advantages over operators. Dual stacking the network offers some advantages over
other transition mechanisms. Firstly, the impact on existing IPv4 other transition mechanisms. Firstly, the impact on existing IPv4
operations is reduced. Secondly, in the absence of tunnels or operations is reduced. Secondly, in the absence of tunnels or
address translation, the IPv4 and IPv6 traffic are native (easier to address translation, the IPv4 and IPv6 traffic are native (easier to
observe and secure) and should have the same network processing observe and secure) and should have the same network processing
(network path, quality of service, ...). Dual stack enables a (network path, quality of service, etc.). Dual stack enables a
gradual termination of the IPv4 operations when the IPv6 network is gradual termination of the IPv4 operations when the IPv6 network is
ready for prime time. On the other hand, the operators have to ready for prime time. On the other hand, the operators have to
manage two network stacks with the added complexities.</t> manage two network stacks with the added complexities.</t>
<t>From an operational security perspective, this now means that the <t>From an operational security perspective, this now means that the
network operator has twice the exposure. One needs to think about network operator has twice the exposure. One needs to think about
protecting both protocols now. At a minimum, the IPv6 portion of a protecting both protocols now. At a minimum, the IPv6 portion of a
dual-stacked network should be consistent with IPv4 from a security dual-stacked network should be consistent with IPv4 from a security
policy point of view. Typically, the following methods are employed policy point of view. Typically, the following methods are employed
to protect IPv4 networks at the edge or security perimeter: <list to protect IPv4 networks at the edge or security perimeter: </t>
style="symbols"> <ul spacing="normal">
<t>ACLs to permit or deny traffic;</t> <li>ACLs to permit or deny traffic,</li>
<li>firewalls with stateful packet inspection, and</li>
<t>Firewalls with stateful packet inspection;</t> <li>application firewalls inspecting the application flows.</li>
</ul>
<t>Application firewalls inspecting the application flows.</t>
</list></t>
<t>It is recommended that these ACLs and/or firewalls be <t>It is recommended that these ACLs and/or firewalls be
additionally configured to protect IPv6 communications. The enforced additionally configured to protect IPv6 communications. The enforced
IPv6 security must be congruent with the IPv4 security policy, IPv6 security must be congruent with the IPv4 security policy;
otherwise the attacker will use the protocol version having the more otherwise, the attacker will use the protocol version that has the mor
e
relaxed security policy. Maintaining the congruence between security relaxed security policy. Maintaining the congruence between security
policies can be challenging (especially over time); it is policies can be challenging (especially over time); it is
recommended to use a firewall or an ACL manager that is dual-stack, recommended to use a firewall or an ACL manager that is dual stack,
i.e., a system that can apply a single ACL entry to a mixed group of i.e., a system that can apply a single ACL entry to a mixed group of
IPv4 and IPv6 addresses.</t> IPv4 and IPv6 addresses.</t>
<t>Application firewalls work at the application layer and are <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 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 IPv4 and the same application security policy will work for both
protocol versions.</t> protocol versions.</t>
<t>Also, given the end-to-end connectivity that IPv6 provides, it is <t>Also, given the end-to-end connectivity that IPv6 provides, it is
recommended that hosts be fortified against threats. General device recommended that hosts be fortified against threats. General device
hardening guidelines are provided in <xref target="device"/>.</t> hardening guidelines are provided in <xref target="device" format="def
ault"/>.</t>
<t>For many years, all host operating systems have IPv6 enabled by <t>For many years, all host operating systems have IPv6 enabled by
default, so, it is possible even in an 'IPv4-only' network to attack default, so it is possible even in an 'IPv4-only' network to attack
layer-2 adjacent victims via their IPv6 link-local address or via a L2-adjacent victims via their IPv6 link-local address or via a
global IPv6 address when the attacker provides rogue RAs or a rogue global IPv6 address when the attacker provides rogue RAs or a rogue
DHCPv6 service.</t> DHCPv6 service.</t>
<t><xref target="RFC7123" format="default"/> discusses the security im
<t><xref target="RFC7123"/> discusses the security implications of plications of
native IPv6 support and IPv6 transition/coexistence technologies on native IPv6 support and IPv6 transition/coexistence technologies on
"IPv4-only" networks and describes possible mitigations for the 'IPv4-only' networks and describes possible mitigations for the
aforementioned issues.</t> aforementioned issues.</t>
</section> </section>
<!--dual--> <section anchor="transition" numbered="true" toc="default">
<name>Encapsulation Mechanisms</name>
<section anchor="transition" title="Encapsulation Mechanisms">
<!-- Note to authors: Markus de Bruen would like to see this section s
hortened as it does not contain IPv6 specific -->
<t>There are many tunnels used for specific use cases. Except when <t>There are many tunnels used for specific use cases. Except when
protected by <xref target="RFC4301">IPsec</xref> or alternative protected by <xref target="RFC4301" format="default">IPsec</xref> or a lternative
tunnel encryption methods, all those tunnels have a number of tunnel encryption methods, all those tunnels have a number of
security issues as described in <xref target="RFC6169">RFC security issues, as described in <xref target="RFC6169"
6169</xref>;<list style="symbols"> format="default"></xref>:</t>
<t>tunnel injection: a malevolent actor knowing a few pieces of <dl newline="true" spacing="normal">
information (for example the tunnel endpoints and the <dt>tunnel injection:</dt>
encapsulation protocol) can forge a packet which looks like a <dd>A malevolent actor knowing a few pieces of
information (for example, the tunnel endpoints and the
encapsulation protocol) can forge a packet that looks like a
legitimate and valid encapsulated packet that will gladly be legitimate and valid encapsulated packet that will gladly be
accepted by the destination tunnel endpoint. This is a specific accepted by the destination tunnel endpoint. This is a specific
case of spoofing;</t> case of spoofing.</dd>
<dt>traffic interception:</dt>
<t>traffic interception: no confidentiality is provided by the <dd>No confidentiality is provided by the
tunnel protocols (without the use of IPsec or alternative tunnel protocols (without the use of IPsec or alternative
encryption methods), therefore anybody on the tunnel path can encryption methods); therefore, anybody on the tunnel path can
intercept the traffic and have access to the clear-text IPv6 intercept the traffic and have access to the cleartext IPv6
packet; combined with the absence of authentication, an on-path packet. Combined with the absence of authentication, an on-path
attack can also be mounted;</t> attack can also be mounted.</dd>
<dt>service theft:</dt>
<t>service theft: as there is no authorization, even a <dd>As there is no authorization, even an
non-authorized user can use a tunnel relay for free (this is a unauthorized user can use a tunnel relay for free (this is a
specific case of tunnel injection);</t> specific case of tunnel injection).</dd>
<dt>reflection attack:</dt>
<t>reflection attack: another specific use case of tunnel <dd>Another specific use case of tunnel
injection where the attacker injects packets with an IPv4 injection where the attacker injects packets with an IPv4
destination address not matching the IPv6 address causing the destination address not matching the IPv6 address causing the
first tunnel endpoint to re-encapsulate the packet to the first tunnel endpoint to re-encapsulate the packet to the
destination... Hence, the final IPv4 destination will not see destination. Hence, the final IPv4 destination will not see
the original IPv4 address but only the IPv4 address of the relay the original IPv4 address but only the IPv4 address of the relay
router.</t> router.</dd>
<dt>bypassing security policy:</dt>
<t>bypassing security policy: if a firewall or an Intrusion <dd>If a firewall or an Intrusion
Prevention System (IPS) is on the path of the tunnel, then it Prevention System (IPS) is on the path of the tunnel, then it
may neither inspect nor detect malevolent IPv6 traffic may neither inspect nor detect malevolent IPv6 traffic
transmitted over the tunnel.</t> transmitted over the tunnel.</dd>
</list></t> </dl>
<t>To mitigate the bypassing of security policies, it is often <t>To mitigate the bypassing of security policies, it is often
recommended to block all automatic tunnels in default OS recommended to block all automatic tunnels in default OS
configuration (if they are not required) by denying IPv4 packets configuration (if they are not required) by denying IPv4 packets
matching:<list style="symbols"> matching:</t>
<t>IP protocol 41: 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 protocol 47: this will block <xref
target="statictunnel">GRE</xref> tunnels;</t>
<t>UDP port 3544: this will block the default encapsulation of
<xref target="teredo">Teredo</xref> tunnels.</t>
</list></t>
<t><xref target="RFC2827">Ingress filtering</xref> should also be <dl newline="false" spacing="normal">
applied on all tunnel endpoints if applicable to prevent IPv6 <dt>IP protocol 41:</dt>
<dd>This will block Intra-Site Automatic Tunnel Addressing Protocol (
ISATAP) (<xref
target="isatap" format="default"></xref>), 6to4 (<xref
target="sixtofour" format="default"></xref>), 6rd (<xref target="sixr
d"
format="default"></xref>), and 6in4 (<xref target="statictunnel"
format="default"></xref>) tunnels.</dd>
<dt>IP protocol 47:</dt>
<dd>This will block GRE (<xref target="statictunnel" format="default"
></xref>)
tunnels.</dd>
<dt>UDP port 3544:</dt>
<dd>This will block the default encapsulation of Teredo
(<xref target="teredo" format="default"></xref>) tunnels.</dd>
</dl>
<t><xref target="RFC2827" format="default">Ingress filtering</xref> sh
ould also
be applied on all tunnel endpoints, if applicable, to prevent IPv6
address spoofing.</t> address spoofing.</t>
<t>The reflection attack cited above should also be prevented by <t>The reflection attack cited above should also be prevented by
using an IPv6 ACL preventing the hair pinning of the traffic.</t> using an IPv6 ACL preventing the hair pinning of the traffic.</t>
<t>As several of the tunnel techniques share the same encapsulation <t>As several of the tunnel techniques share the same encapsulation
(i.e., IPv4 protocol 41) and embed the IPv4 address in the IPv6 (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 address, there are a set of well-known looping attacks described in
<xref target="RFC6324">RFC 6324</xref>. This RFC also proposes <xref target="RFC6324" format="default"></xref>. This RFC also propose s
mitigation techniques.</t> mitigation techniques.</t>
<section anchor="statictunnel" numbered="true" toc="default">
<section anchor="statictunnel" title="Site-to-Site Static Tunnels"> <name>Site-to-Site Static Tunnels</name>
<t>Site-to-site static tunnels are described in <xref <t>Site-to-site static tunnels are described in <xref target="RFC252
target="RFC2529">RFC 2529</xref> and in <xref 9"
target="RFC2784">GRE</xref>. As the IPv4 endpoints are statically format="default"></xref> and in <xref target="RFC2784"
format="default">GRE</xref>. As the IPv4 endpoints are statically
configured and are not dynamic, they are slightly more secure configured and are not dynamic, they are slightly more secure
(bi-directional service theft is mostly impossible) but traffic (bidirectional service theft is mostly impossible), but traffic
interception and tunnel injection are still possible. Therefore, interception and tunnel injection are still possible. Therefore,
the use of <xref target="RFC4301">IPsec</xref> in transport mode the use of <xref target="RFC4301" format="default">IPsec</xref> in t ransport mode
to protect the encapsulated IPv4 packets is recommended for those to protect the encapsulated IPv4 packets is recommended for those
tunnels. Alternatively, IPsec in tunnel mode can be used to tunnels. Alternatively, IPsec in tunnel mode can be used to
transport IPv6 traffic over a non-trusted IPv4 network.</t> transport IPv6 traffic over an untrusted IPv4 network.</t>
</section> </section>
<section anchor="isatap" numbered="true" toc="default">
<section anchor="isatap" title="ISATAP"> <name>ISATAP</name>
<t>ISATAP tunnels <xref target="RFC5214"/> are mainly used within <t>ISATAP tunnels <xref target="RFC5214" format="default"/> are main
ly used within
a single administrative domain and to connect a single IPv6 host a single administrative domain and to connect a single IPv6 host
to the IPv6 network. This often implies that those systems are to the IPv6 network. This often implies that those systems are
usually managed by a single entity; therefore, audit trail and usually managed by a single entity; therefore, audit trail and
strict anti-spoofing are usually possible and this raises the strict anti-spoofing are usually possible, and this raises the
overall security. Even if ISATAP is no more often used, its overall security. Even if ISATAP is no more often used, its
security issues are relevant per <xref target="KRISTOFF"/>.</t> security issues are relevant, per <xref target="KRISTOFF" format="de
fault"/>.</t>
<t>Special care must be taken to avoid a looping attack by <t>Special care must be taken to avoid a looping attack by
implementing the measures of <xref target="RFC6324"/> and <xref implementing the measures of <xref target="RFC6324" format="default"
target="RFC6964"/> (especially the section 3.6).</t> /> and <xref target="RFC6964" format="default"/> (especially in Section <xref ta
rget="RFC6964" sectionFormat="bare" section="3.6"/>).</t>
<t><xref target="RFC4301">IPsec</xref> in transport or tunnel mode <t><xref target="RFC4301" format="default">IPsec</xref> in transport
or tunnel mode
can be used to secure the IPv4 ISATAP traffic to provide IPv6 can be used to secure the IPv4 ISATAP traffic to provide IPv6
traffic confidentiality and prevent service theft.</t> traffic confidentiality and prevent service theft.</t>
</section> </section>
<section anchor="sixrd" numbered="true" toc="default">
<section anchor="sixrd" title="6rd"> <name>6rd</name>
<t>While 6rd tunnels share the same encapsulation as <xref <t>While 6rd tunnels share the same encapsulation as <xref target="s
target="sixtofour">6to4 tunnels</xref>, they are designed to be ixtofour"
used within a single SP domain, in other words, they are deployed format="default">6to4 tunnels</xref>, they are designed to be
used within a single SP domain; in other words, they are deployed
in a more constrained environment (e.g., anti-spoofing, protocol in a more constrained environment (e.g., anti-spoofing, protocol
41 filtering at the edge) than 6to4 tunnels and have few security 41 filtering at the edge) than 6to4 tunnels and have few security
issues other than lack of confidentiality. The security issues other than lack of confidentiality. The security
considerations (Section 12) of <xref target="RFC5969"/> describes considerations in <xref target="RFC5969" sectionFormat="of" section=
how to secure 6rd tunnels.</t> "12"/>
describes how to secure 6rd tunnels.</t>
<t><xref target="RFC4301">IPsec</xref> for the transported IPv6 <t><xref target="RFC4301" format="default">IPsec</xref> for the tran
traffic can be used if confidentiality is important.</t> sported
IPv6 traffic can be used if confidentiality is important.</t>
</section> </section>
<section anchor="sixpe" numbered="true" toc="default">
<section anchor="sixpe" title="6PE, 6VPE, and LDPv6"> <name>6PE, 6VPE, and LDPv6</name>
<t>Organizations using MPLS in their core can also use 6PE <xref <t>Organizations using MPLS in their core can also use IPv6 Provider
target="RFC4798"/> and 6VPE <xref target="RFC4659"/> to enable Edge (6PE) <xref target="RFC4798" format="default"/> and IPv6 Virtual Private E
xtension (6VPE) <xref target="RFC4659" format="default"/> to enable
IPv6 access over MPLS. As 6PE and 6VPE are really similar to IPv6 access over MPLS. As 6PE and 6VPE are really similar to
BGP/MPLS IP VPNs described in <xref target="RFC4364"/>, the BGP/MPLS IP VPNs described in <xref target="RFC4364" format="default "/>, the
security properties of these networks are also similar to those security properties of these networks are also similar to those
described in <xref target="RFC4381"/> (please note that this RFC described in <xref target="RFC4381" format="default"/> (please note
may resemble a published IETF work but it is not based on an IETF that this RFC
may resemble a published IETF work, but it is not based on an IETF
review and the IETF disclaims any knowledge of the fitness of this review and the IETF disclaims any knowledge of the fitness of this
RFC for any purpose). They rely on:<list style="symbols"> RFC for any purpose). They rely on:</t>
<t>Address space, routing, and traffic separation with the <ul spacing="normal">
help of VRFs (only applicable to 6VPE);</t> <li>address space, routing, and traffic separation with the
help of VRFs (only applicable to 6VPE);</li>
<t>Hiding the IPv4 core, hence removing all attacks against <li>hiding the IPv4 core, hence, removing all attacks against
P-routers;</t> P-routers; and</li>
<li>securing the routing protocol between Customer Edge (CE) and P
<t>Securing the routing protocol between CE and PE; in the rovider
case of 6PE and 6VPE, link-local addresses (see <xref Edge (PE); in the
target="RFC7404"/>) can be used and as these addresses cannot case of 6PE and 6VPE, link-local addresses (see <xref target="RF
C7404" format="default"/>) can be used, and, as these addresses cannot
be reached from outside of the link, the security of 6PE and be reached from outside of the link, the security of 6PE and
6VPE is even higher than an IPv4 BGP/MPLS IP VPN.</t> 6VPE is even higher than an IPv4 BGP/MPLS IP VPN.</li>
</list>LDPv6 itself does not induce new risks, see also <xref </ul>
target="RFC7552"/>.</t> <t>LDPv6 itself does not induce new risks; see <xref target="RFC7552
"
format="default"/>.</t>
</section> </section>
<section anchor="dslite_first" numbered="true" toc="default">
<section anchor="dslite_first" title="DS-Lite"> <name>DS-Lite</name>
<t>DS-lite is also a translation mechanism and is therefore <t>Dual-Stack Lite (DS-Lite) is also a translation mechanism and is
analyzed <xref target="dslite">further</xref> in this document as therefore
it includes IPv4 NAPT.</t> analyzed <xref target="dslite" format="default">further</xref> in th
is document,
as it includes IPv4 NAPT.</t>
</section> </section>
<!--dslite_first--> <section anchor="map_first" numbered="true" toc="default">
<name>Mapping of Address and Port</name>
<section anchor="map_first" title="Mapping of Address and Port"> <t>With the encapsulation and translation versions of Mapping of
<t>With the encapsulation and translation versions of mapping of Address and Port (MAP) -- abbreviated MAP-E <xref target="RFC7597" f
Address and Port (MAP) (<xref target="RFC7597">MAP-E</xref> and ormat="default"></xref> and MAP-T <xref target="RFC7599" format="default"></xref
<xref target="RFC7599">MAP-T</xref>), the access network is purely > -- the access
an IPv6 network and MAP protocols are used to provide IPv4 hosts network is purely
an IPv6 network, and MAP protocols are used to provide IPv4 hosts
on the subscriber network access to IPv4 hosts on the Internet. on the subscriber network access to IPv4 hosts on the Internet.
The subscriber router does stateful operations in order to map all The subscriber router does stateful operations in order to map all
internal IPv4 addresses and layer-4 ports to the IPv4 address and internal IPv4 addresses and Layer 4 ports to the IPv4 address and
the set of layer-4 ports received through the MAP configuration the set of Layer 4 ports received through the MAP configuration
process. The SP equipment always does stateless operations (either process. The SP equipment always does stateless operations (either
decapsulation or stateless translation). Therefore, as opposed to decapsulation or stateless translation). Therefore, as opposed to
<xref target="dslite"/>, there is no state-exhaustion DoS attack <xref target="dslite" format="default"/>, there is no state exhausti on DoS attack
against the SP equipment because there is no state and there is no against the SP equipment because there is no state and there is no
operation caused by a new layer-4 connection (no logging operation caused by a new Layer 4 connection (no logging
operation).</t> operation).</t>
<t>The SP MAP equipment should implement all the security <t>The SP MAP equipment should implement all the security
considerations of <xref target="RFC7597"/>; notably, ensuring that considerations of <xref target="RFC7597" format="default"/>, notably ensuring that
the mapping of the IPv4 address and port are consistent with the the mapping of the IPv4 address and port are consistent with the
configuration. As MAP has a predictable IPv4 address and port configuration. As MAP has a predictable IPv4 address and port
mapping, the audit logs are easier to use as there is a clear mapping, the audit logs are easier to use, as there is a clear
mapping between the IPv6 address and the IPv4 address and mapping between the IPv6 address and the IPv4 address and
ports.</t> ports.</t>
</section> </section>
<section anchor="sixtofour" numbered="true" toc="default">
<section anchor="sixtofour" title="6to4"> <name>6to4</name>
<t>In <xref target="RFC3056"/>; 6to4 tunnels require a public <t>In <xref target="RFC3056" format="default"/>, 6to4 tunnels requir
routable IPv4 address in order to work correctly. They can be used e
a public-routable IPv4 address in order to work correctly. They can b
e used
to provide either single IPv6 host connectivity to the IPv6 to provide either single IPv6 host connectivity to the IPv6
Internet or multiple IPv6 networks connectivity to the IPv6 Internet or multiple IPv6 networks connectivity to the IPv6
Internet. The 6to4 relay was historically the anycast address Internet. The 6to4 relay was historically the anycast address
defined in <xref target="RFC3068"/> which has been deprecated by defined in <xref target="RFC3068" format="default"/>, which has been
<xref target="RFC7526"/> and is no longer used by recent Operating deprecated by
Systems. Some security considerations are explained in <xref <xref target="RFC7526" format="default"/> and is no longer used by r
target="RFC3964"/>.</t> ecent
Operating
<t><xref target="RFC6343"/> points out that if an operator Systems. Some security considerations are explained in <xref target=
"RFC3964" format="default"/>.</t>
<t><xref target="RFC6343" format="default"/> points out that if an o
perator
provides well-managed servers and relays for 6to4, provides well-managed servers and relays for 6to4,
non-encapsulated IPv6 packets will pass through well-defined nonencapsulated IPv6 packets will pass through well-defined
points (the native IPv6 interfaces of those servers and relays) at points (the native IPv6 interfaces of those servers and relays) at
which security mechanisms may be applied. Client usage of 6to4 by which security mechanisms may be applied. Client usage of 6to4 by
default is now discouraged, and significant precautions are needed default is now discouraged, and significant precautions are needed
to avoid operational problems.</t> to avoid operational problems.</t>
</section> </section>
<section anchor="teredo" numbered="true" toc="default">
<section anchor="teredo" title="Teredo"> <name>Teredo</name>
<t>Teredo tunnels <xref target="RFC4380"/> are mainly used in a <t>Teredo tunnels <xref target="RFC4380" format="default"/> are main
ly used in a
residential environment because Teredo easily traverses an IPv4 residential environment because Teredo easily traverses an IPv4
NAPT device thanks to its UDP encapsulation. Teredo tunnels NAPT device thanks to its UDP encapsulation. Teredo tunnels
connect a single host to the IPv6 Internet. Teredo shares the same connect a single host to the IPv6 Internet.
Teredo shares the same
issues as other tunnels: no authentication, no confidentiality, issues as other tunnels: no authentication, no confidentiality,
possible spoofing and reflection attacks.</t> possible spoofing, and reflection attacks.</t>
<t><xref target="RFC4301" format="default">IPsec</xref> for the tran
<t><xref target="RFC4301">IPsec</xref> for the transported IPv6 sported IPv6
traffic is recommended.</t> traffic is recommended.</t>
<t>The biggest threat to Teredo is probably for an IPv4-only <t>The biggest threat to Teredo is probably for an IPv4-only
network as Teredo has been designed to easily traverse IPv4 NAT-PT network, as Teredo has been designed to easily traverse IPv4 NAT-PT
devices which are quite often co-located with a stateful firewall. devices, which are quite often co-located with a stateful firewall.
Therefore, if the stateful IPv4 firewall allows unrestricted UDP Therefore, if the stateful IPv4 firewall allows unrestricted UDP
outbound and accepts the return UDP traffic, then Teredo actually outbound and accepts the return UDP traffic, then Teredo actually
punches a hole in this firewall for all IPv6 traffic to the punches a hole in this firewall for all IPv6 traffic to
Internet and from the Internet. Host policies can be deployed to and from the Internet. Host policies can be deployed to
block Teredo in an IPv4-only network in order to avoid this block Teredo in an IPv4-only network in order to avoid this
firewall bypass. On the IPv4 firewall all outbound UDP should be firewall bypass. On the IPv4 firewall, all outbound UDPs should be
blocked except for the commonly used services (e.g., port 53 for 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, port DNS, port 123 for NTP, port 443 for QUIC, port 500 for Internet Key
3478 for STUN, etc.).</t> Exchange
Protocol (IKE), port 3478 for Session Traversal Utilities for NAT (ST
UN),
etc.).</t>
<t>Teredo is now hardly ever used and no longer enabled by default <t>Teredo is now hardly ever used and no longer enabled by default
in most environments, so it is less of a threat, however, special in most environments so it is less of a threat; however, special
consideration must be taken in cases when devices with older or consideration must be made in cases when devices with older or
non-updated operating systems may be present and by default were operating systems that have not been updated may be present and by d
efault were
running Teredo.</t> running Teredo.</t>
</section> </section>
</section> </section>
<!--tunnel--> <section anchor="xlate" numbered="true" toc="default">
<name>Translation Mechanisms</name>
<section anchor="xlate" title="Translation Mechanisms">
<t>Translation mechanisms between IPv4 and IPv6 networks are <t>Translation mechanisms between IPv4 and IPv6 networks are
alternate coexistence strategies while networks transition to IPv6. alternate coexistence strategies while networks transition to IPv6.
While a framework is described in <xref target="RFC6144"/>, the While a framework is described in <xref target="RFC6144" format="defau lt"/>, the
specific security considerations are documented with each individual specific security considerations are documented with each individual
mechanism. For the most part, they specifically mention interference mechanism. For the most part, they specifically mention interference
with IPsec or DNSSEC deployments, how to mitigate spoofed traffic, with IPsec or DNSSEC deployments, how to mitigate spoofed traffic,
and what some effective filtering strategies may be.</t> and what some effective filtering strategies may be.</t>
<t>While not really a transition mechanism to IPv6, this section <t>While not really a transition mechanism to IPv6, this section
also includes the discussion about the use of heavy IPv4-to-IPv4 also includes the discussion about the use of heavy IPv4-to-IPv4
network address and port translation to prolong the life of network addresses and port translation to prolong the life of
IPv4-only networks.</t> IPv4-only networks.</t>
<section anchor="cgn" numbered="true" toc="default">
<section anchor="cgn" title="Carrier-Grade NAT (CGN)"> <name>Carrier-Grade NAT (CGN)</name>
<t>Carrier-Grade NAT (CGN), also called NAT444 CGN or Large Scale <t>Carrier-Grade NAT (CGN), also called NAT444 CGN or Large-Scale
NAT (LSN) or SP NAT is described in <xref target="RFC6264"/> and NAT (LSN) or SP NAT, is described in <xref target="RFC6264"
format="default"/> and
is utilized as an interim measure to extend the use of IPv4 in a is utilized as an interim measure to extend the use of IPv4 in a
large service provider network until the provider can deploy an large service provider network until the provider can deploy an
effective IPv6 solution. <xref target="RFC6598"/> requested a effective IPv6 solution. <xref target="RFC6598" format="default"/> r
specific IANA allocated /10 IPv4 address block to be used as equested a
specific IANA-allocated /10 IPv4 address block to be used as
address space shared by all access networks using CGN. This has address space shared by all access networks using CGN. This has
been allocated as 100.64.0.0/10.</t> been allocated as 100.64.0.0/10.</t>
<t><xref target="RFC6269" sectionFormat="of" section="13"/> lists so
<t>Section 13 of <xref target="RFC6269"/> lists some specific me specific
security-related issues caused by large scale address sharing. The security-related issues caused by large-scale address sharing. The
Security Considerations section of <xref target="RFC6598"/> also Security Considerations section of <xref target="RFC6598" format="de
fault"/> also
lists some specific mitigation techniques for potential misuse of lists some specific mitigation techniques for potential misuse of
shared address space. Some Law Enforcement Agencies have shared address space. Some law enforcement agencies have
identified CGN as impeding their cyber-crime investigations (for identified CGN as impeding their cybercrime investigations (for
example <xref target="europol-cgn">Europol press release on example, see the <xref target="europol-cgn" format="default">Europol
CGN</xref>). Many translation techniques (NAT64, DS-lite, ...) press
release on
CGN</xref>). Many translation techniques (NAT64, DS-Lite, etc.)
have the same security issues as CGN when one part of the have the same security issues as CGN when one part of the
connection is IPv4-only.</t> connection is IPv4 only.</t>
<t><xref target="RFC6302" format="default"/> has recommendations for
<t><xref target="RFC6302"/> has recommendations for
Internet-facing servers to also log the source TCP or UDP ports of Internet-facing servers to also log the source TCP or UDP ports of
incoming connections in an attempt to help identify the users incoming connections in an attempt to help identify the users
behind such a CGN.</t> behind such a CGN.</t>
<t><xref target="RFC7422" format="default"/> suggests the use of det
<t><xref target="RFC7422"/> suggests the use of deterministic erministic
address mapping in order to reduce logging requirements for CGN. address mapping in order to reduce logging requirements for CGN.
The idea is to have a known algorithm for mapping the internal The idea is to have a known algorithm for mapping the internal
subscriber to/from public TCP and UDP ports.</t> subscriber to/from public TCP and UDP ports.</t>
<t><xref target="RFC6888" format="default"/> lists common requiremen
<t><xref target="RFC6888"/> lists common requirements for CGNs. ts for CGNs.
<xref target="RFC6967"/> analyzes some solutions to enforce <xref target="RFC6967" format="default"/> analyzes some solutions to
policies on misbehaving nodes when address sharing is used. <xref enforce
target="RFC7857"/> also updates the NAT behavioral policies on misbehaving nodes when address sharing is used. <xref ta
rget="RFC7857" format="default"/> also updates the NAT behavioral
requirements.</t> requirements.</t>
</section> </section>
<!--cgn--> <section anchor="nat64" numbered="true" toc="default">
<name>NAT64/DNS64 and 464XLAT</name>
<section anchor="nat64" title="NAT64/DNS64 and 464XLAT"> <t>Stateful NAT64 translation <xref target="RFC6146" format="default
<t>Stateful NAT64 translation <xref target="RFC6146"/> allows "/> allows
IPv6-only clients to contact IPv4 servers using unicast UDP, TCP, IPv6-only clients to contact IPv4 servers using unicast UDP, TCP,
or ICMP. It can be used in conjunction with DNS64 <xref or ICMP. It can be used in conjunction with DNS64 <xref target="RFC6
target="RFC6147"/>, a mechanism which synthesizes AAAA records 147"
format="default"/>, a mechanism that synthesizes AAAA records
from existing A records. There is also a stateless NAT64 <xref from existing A records. There is also a stateless NAT64 <xref
target="RFC7915"/>, which has similar security aspects but with target="RFC7915" format="default"/>, which has similar security aspec
the added benefit of being stateless, so, less prone to a state ts but
exhaustion attack.</t> with the added benefit of being stateless and is thereby less prone t
o a state exhaustion attack.</t>
<t>The Security Consideration sections of <xref target="RFC6146"/> <t>The Security Consideration sections of <xref target="RFC6146" for
and <xref target="RFC6147"/> list the comprehensive issues; in mat="default"/>
section 8 of <xref target="RFC6147"/> there are some and <xref target="RFC6147" format="default"/> list the comprehensive
issues; in
<xref target="RFC6147" sectionFormat="of" section="8"/>, there are s
ome
considerations on the interaction between NAT64 and DNSSEC. A considerations on the interaction between NAT64 and DNSSEC. A
specific issue with the use of NAT64 is that it will interfere specific issue with the use of NAT64 is that it will interfere
with most IPsec deployments unless UDP encapsulation is used.</t> with most IPsec deployments unless UDP encapsulation is used.</t>
<t>Another translation mechanism relying on a combination of <t>Another translation mechanism relying on a combination of
stateful and stateless translation, 464XLAT <xref stateful and stateless translation, 464XLAT <xref target="RFC6877" f
target="RFC6877"/>, can be used to do host local translation from ormat="default"/>,
can be used to do a host-local translation from
IPv4 to IPv6 and a network provider translation from IPv6 to IPv4, IPv4 to IPv6 and a network provider translation from IPv6 to IPv4,
i.e., giving IPv4-only application access to an IPv4-only server i.e., giving IPv4-only application access to an IPv4-only server
over an IPv6-only network. 464XLAT shares the same security over an IPv6-only network. 464XLAT shares the same security
considerations as NAT64 and DNS64, however it can be used without considerations as NAT64 and DNS64; however, it can be used without
DNS64, avoiding the DNSSEC implications.</t> DNS64, avoiding the DNSSEC implications.</t>
</section> </section>
<!--nat64--> <section anchor="dslite" numbered="true" toc="default">
<name>DS-Lite</name>
<section anchor="dslite" title="DS-Lite"> <t>Dual-Stack Lite (DS-Lite) <xref target="RFC6333" format="default"
<t>Dual-Stack Lite (DS-Lite) <xref target="RFC6333"/> is a /> is a
transition technique that enables a service provider to share IPv4 transition technique that enables a service provider to share IPv4
addresses among customers by combining two well-known addresses among customers by combining two well-known
technologies: IP in IP (IPv4-in-IPv6) and IPv4 NAPT.</t> technologies: IP in IP (IPv4-in-IPv6) and IPv4 NAPT.</t>
<t>Security considerations, with respect to DS-Lite, mainly revolve
<t>Security considerations with respect to DS-Lite mainly revolve
around logging data, preventing DoS attacks from rogue devices (as around logging data, preventing DoS attacks from rogue devices (as
the Address Family Translation Router (AFTR) <xref the Address Family Translation Router (AFTR) <xref target="RFC6333"
target="RFC6333"/> function is stateful) and restricting service format="default"/> function is stateful), and restricting service
offered by the AFTR only to registered customers.</t> offered by the AFTR only to registered customers.</t>
<t><xref target="RFC6333" sectionFormat="of" section="11"/> and <xre
<t>Section 11 of <xref target="RFC6333"/> and section 2 of <xref f target="RFC7785" sectionFormat="of" section="2"/> describe important security
target="RFC7785"/> describe important security issues associated issues associated
with this technology.</t> with this technology.</t>
</section> </section>
<!--dslite-->
</section> </section>
<!--xlate-->
</section> </section>
<!--coexistence--> <section anchor="device" numbered="true" toc="default">
<name>General Device Hardening</name>
<section anchor="device" title="General Device Hardening">
<t>With almost all devices being IPv6 enabled by default and with many <t>With almost all devices being IPv6 enabled by default and with many
end points having IPv6 connectivity to the Internet, it is critical to endpoints having IPv6 connectivity to the Internet, it is critical to
also harden those devices against attacks over IPv6.</t> also harden those devices against attacks over IPv6.</t>
<t>The same techniques used to protect devices against attacks over IPv4
<t>The ame techniques used to protect devices against attack over IPv4 should be used for IPv6 and should include but are not limited to:</t>
should be used for IPv6 and should include, but not limited to:<list <ul spacing="normal">
style="symbols"> <li>restricting device access to authorized individuals;</li>
<t>Restrict device access to authorized individuals</t> <li>monitoring and auditing access to the device;</li>
<li>turning off any unused services on the end node</li>
<t>Monitor and audit access to the device</t> <li>understanding which IPv6 addresses are being used to source
traffic and changing defaults if necessary;</li>
<t>Turn off any unused services on the end node</t> <li>using cryptographically protected protocols for device management
(Secure Copy Protocol (SCP), SNMPv3, SSH, TLS, etc.);</li>
<t>Understand which IPv6 addresses are being used to source <li>using host firewall capabilities to control traffic that gets
traffic and change defaults if necessary</t> processed by upper-layer protocols;</li>
<li>applying firmware, OS, and application patches/upgrades to the
<t>Use cryptographically protected protocols for device management devices in a timely manner;</li>
(SCP, SNMPv3, SSH, TLS, etc.)</t> <li>using multifactor credentials to authenticate to devices; and</li>
<li>using virus scanners to detect malicious programs.</li>
<t>Use host firewall capabilities to control traffic that gets </ul>
processed by upper-layer protocols</t>
<t>apply firmware, OS and application patches/upgrades to the
devices in a timely manner</t>
<t>use multi-factor credentials to authenticate to devices</t>
<t>Use virus scanners to detect malicious programs</t>
</list></t>
</section> </section>
<!--device-->
</section> </section>
<!--generic--> <section anchor="enterprise" numbered="true" toc="default">
<name>Enterprises-Specific Security Considerations</name>
<section anchor="enterprise" <t>Enterprises <xref target="RFC7381" format="default"/> generally have ro
title="Enterprises Specific Security Considerations"> bust network
<t>Enterprises <xref target="RFC7381"/> generally have robust network
security policies in place to protect existing IPv4 networks. These security policies in place to protect existing IPv4 networks. These
policies have been distilled from years of experiential knowledge of policies have been distilled from years of experiential knowledge of
securing IPv4 networks. At the very least, it is recommended that securing IPv4 networks. At the very least, it is recommended that
enterprise networks have parity between their security policies for both enterprise networks have parity between their security policies for both
protocol versions. This section also applies to the enterprise part of 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 all SP networks, i.e., the part of the network where the SP employees
are connected.</t> are connected.</t>
<t>Security considerations in the enterprise can be broadly categorized <t>Security considerations in the enterprise can be broadly categorized
into two groups: External and Internal.</t> into two groups: external and internal.</t>
<section anchor="external" numbered="true" toc="default">
<section anchor="external" title="External Security Considerations"> <name>External Security Considerations</name>
<t>The external aspect deals with providing security at the edge or <t>The external aspect deals with providing security at the edge or
perimeter of the enterprise network where it meets the service perimeter of the enterprise network where it meets the service
provider's network. This is commonly achieved by enforcing a security provider's network. This is commonly achieved by enforcing a security
policy either by implementing dedicated firewalls with stateful packet policy, either by implementing dedicated firewalls with stateful packet
inspection or a router with ACLs. A common default IPv4 policy on 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 firewalls that could easily be ported to IPv6 is to allow all traffic
outbound while only allowing specific traffic, such as established outbound while only allowing specific traffic, such as established
sessions, inbound (see also <xref target="RFC6092"/>). Section 3.2 of sessions, inbound (see <xref target="RFC6092" format="default"/>).
<xref target="RFC7381"/> also provides similar recommendations.</t> <xref 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: <t>Here are a few more things that could enhance the default policy:
<list style="symbols"> </t>
<t>Filter internal-use IPv6 addresses at the perimeter, this will <ul spacing="normal">
also mitigate the vulnerabilities listed in <xref <li>Filter internal-use IPv6 addresses at the perimeter; this will
target="RFC7359"/></t> also mitigate the vulnerabilities listed in <xref target="RFC7359" f
ormat="default"/>.</li>
<t>Discard packets from and to bogon and reserved space, see also <li>Discard packets from and to bogon and reserved space; see
<xref target="CYMRU"/> and <xref target="RFC8190"/></t> <xref target="CYMRU" format="default"/> and <xref target="RFC8190" f
ormat="default"/>.</li>
<t>Accept certain ICMPv6 messages to allow proper operation of ND <li>Accept certain ICMPv6 messages to allow proper operation of ND
and PMTUD, see also <xref target="RFC4890"/> or <xref and Path MTU Discovery (PMTUD); see <xref target="RFC4890" format="d
target="REY_PF"/> for hosts</t> efault"/> or <xref target="REY_PF" format="default"/> for hosts.</li>
<li>Based on the use of the network, filter specific extension
<t>Based on the use of the network, filter specific extension headers by accepting only the required ones (permit list approach),
headers by accepting only the required ones (permit list approach)
such as ESP, AH, and not forgetting the required transport layers: such as ESP, AH, and not forgetting the required transport layers:
ICMP, TCP, UDP, ... This filtering should be done where applicable ICMP, TCP, UDP, etc. This filtering should be done where applicable
at the edge and possibly inside the perimeter; see also <xref at the edge and possibly inside the perimeter; see <xref target="I-D
target="I-D.ietf-opsec-ipv6-eh-filtering"/></t> .ietf-opsec-ipv6-eh-filtering" format="default"/>.</li>
<li>Filter packets having an illegal IPv6 header chain at the
<t>Filter packets having an illegal IPv6 headers chain at the perimeter (and, if possible, inside the network as well); see <xref
perimeter (and if possible, inside the network as well), see <xref target="ext_headers" format="default"/>.</li>
target="ext_headers"/></t> <li>Filter unneeded services at the perimeter.</li>
<li>Implement ingress and egress anti-spoofing in the forwarding
<t>Filter unneeded services at the perimeter</t> and control planes; see <xref target="RFC2827" format="default"/> an
d <xref target="RFC3704" format="default"/>.</li>
<t>Implement ingress and egress anti-spoofing in the forwarding <li>Implement appropriate rate-limiters and control plane policers
and control planes, see <xref target="RFC2827"/> and <xref based on traffic baselines.</li>
target="RFC3704"/></t> </ul>
<t>Implement appropriate rate-limiters and control-plane policers
based on traffic baselines</t>
</list></t>
<t>Having global IPv6 addresses on all the enterprise sites is <t>Having global IPv6 addresses on all the enterprise sites is
different than in IPv4 where <xref target="RFC1918"/> addresses are different than in IPv4, where <xref target="RFC1918" format="default"/>
often used internally and not routed over the Internet. <xref addresses are
target="RFC7359"/> and <xref target="WEBER_VPN"/> explain that without often used internally and not routed over the Internet. <xref target="RF
careful design, there could be IPv6 leakages from layer-3 VPNs.</t> C7359" format="default"/> and <xref target="WEBER_VPN" format="default"/> explai
n that without
careful design, there could be IPv6 leakages from Layer 3 VPNs.</t>
</section> </section>
<!-- external--> <section anchor="internal" numbered="true" toc="default">
<name>Internal Security Considerations</name>
<section anchor="internal" title="Internal Security Considerations">
<t>The internal aspect deals with providing security inside the <t>The internal aspect deals with providing security inside the
perimeter of the network, including end hosts. Internal networks of perimeter of the network, including end hosts. Internal networks of
enterprises are often different: University campus, wireless guest enterprises are often different, e.g., University campus, wireless guest
access, ... so there is no "one size fits all" recommendation.</t> access, etc., so there is no "one size fits all" recommendation.</t>
<t>The most significant concerns here are related to Neighbor <t>The most significant concerns here are related to Neighbor
Discovery. At the network level, it is recommended that all security Discovery. At the network level, it is recommended that all security
considerations discussed in <xref target="linklayer"/> be reviewed considerations discussed in <xref target="linklayer" format="default"/> be reviewed
carefully and the recommendations be considered in-depth as well. carefully and the recommendations be considered in-depth as well.
Section 4.1 of <xref target="RFC7381"/> also provides some <xref target="RFC7381" sectionFormat="of" section="4.1"/> also provides some
recommendations.</t> recommendations.</t>
<t>As mentioned in <xref target="transition" format="default"/>, care mu
<t>As mentioned in <xref target="transition"/>, care must be taken st be taken
when running automated IPv6-in-IPv4 tunnels.</t> when running automated IPv6-in-IPv4 tunnels.</t>
<t>When site-to-site VPNs are used, it should be kept in mind that,
<t>When site-to-site VPNs are used it should be kept in mind that,
given the global scope of IPv6 global addresses as opposed to the given the global scope of IPv6 global addresses as opposed to the
common use of IPv4 private address space <xref target="RFC1918"/>, common use of IPv4 private address space <xref target="RFC1918" format=" default"/>,
sites might be able to communicate with each other over the Internet sites might be able to communicate with each other over the Internet
even when the VPN mechanism is not available and hence no traffic even when the VPN mechanism is not available. Hence, no traffic
encryption is performed and traffic could be injected from the encryption is performed and traffic could be injected from the
Internet into the site, see <xref target="WEBER_VPN"/>. It is Internet into the site; see <xref target="WEBER_VPN" format="default"/>. It is
recommended to filter at Internet connection(s) packets having a recommended to filter at Internet connection(s) packets having a
source or destination address belonging to the site internal source or destination address belonging to the site internal
prefix(es); this should be done for ingress and egress traffic.</t> prefix or prefixes; this should be done for ingress and egress traffic.<
/t>
<t>Hosts need to be hardened directly through security policy to <t>Hosts need to be hardened directly through security policy to
protect against security threats. The host firewall default protect against security threats. The host firewall default
capabilities have to be clearly understood. In some cases, 3rd party capabilities have to be clearly understood. In some cases, third-party
firewalls have no IPv6 support whereas the native firewall installed firewalls have no IPv6 support, whereas the native firewall installed
by default has IPv6 support. General device hardening guidelines are by default has IPv6 support. General device hardening guidelines are
provided in <xref target="device"/>.</t> provided in <xref target="device" format="default"/>.</t>
<t>It should also be noted that many hosts still use IPv4 for <t>It should also be noted that many hosts still use IPv4 for
transporting logs for RADIUS, DIAMETER, TACACS+, SYSLOG, etc. transporting logs for RADIUS, DIAMETER, TACACS+, syslog, etc.
Operators cannot rely on an IPv6-only security policy to secure such Operators cannot rely on an IPv6-only security policy to secure such
protocols that are still using IPv4.</t> protocols that are still using IPv4.</t>
</section> </section>
<!-- internal-->
</section> </section>
<!-- enterprise--> <section anchor="sp" numbered="true" toc="default">
<name>Service Provider Security Considerations</name>
<section anchor="sp" title="Service Providers Security Considerations"> <section anchor="bgp" numbered="true" toc="default">
<section anchor="bgp" title="BGP"> <name>BGP</name>
<t>The threats and mitigation techniques are identical between IPv4 <t>The threats and mitigation techniques are identical between IPv4
and IPv6. Broadly speaking they are: <list style="symbols"> and IPv6. Broadly speaking, they are: </t>
<t>Authenticating the TCP session;</t> <ul spacing="normal">
<li>authenticating the TCP session;</li>
<t>TTL security (which becomes hop-limit security in IPv6) as <li>TTL security (which becomes hop-limit security in IPv6), as in
<xref target="RFC5082"/>;</t> <xref target="RFC5082" format="default"/>;</li>
<li>bogon AS filtering; see <xref target="CYMRU" format="default"/>; a
<t>bogon AS filtering, see <xref target="CYMRU"/>;</t> nd</li>
<li>prefix filtering.</li>
<t>Prefix filtering.</t> </ul>
</list> These are explained in more detail in <xref target="rsec"/>. <t> These are explained in more detail in <xref target="rsec" format="de
Also, the recommendations of <xref target="RFC7454"/> should be fault"/>.
Also, the recommendations of <xref target="RFC7454" format="default"/> s
hould be
considered.</t> considered.</t>
<section anchor="rtbh" numbered="true" toc="default">
<section anchor="rtbh" <name>Remote Triggered Black Hole Filtering</name>
title="Remote Triggered Black Hole Filtering (RTBH)"> <t>A Remote Triggered Black Hole (RTBH) <xref target="RFC5635" format=
<t>RTBH <xref target="RFC5635"/> works identically in IPv4 and IPv6. "default"/> works identically in IPv4 and IPv6.
IANA has allocated the 100::/64 prefix to be used as the discard IANA has allocated the 100::/64 prefix to be used as the discard
prefix <xref target="RFC6666"/></t> prefix <xref target="RFC6666" format="default"/>.</t>
</section> </section>
<!---->
</section> </section>
<!-- BGP--> <section anchor="sptrans" numbered="true" toc="default">
<name>Transition/Coexistence Mechanism</name>
<section anchor="sptrans" title="Transition/Coexistence Mechanism"> <t>SPs will typically use transition mechanisms, such as 6rd, 6PE, MAP,
<t>SPs will typically use transition mechanisms such as 6rd, 6PE, MAP, and NAT64, which have been analyzed in the transition and coexistence
and NAT64 which have been analyzed in the transition and coexistence (<xref target="coexistence" format="default"/>).</t>
<xref target="coexistence"/> section.</t>
</section> </section>
<!-- sptrans--> <section anchor="li" numbered="true" toc="default">
<name>Lawful Intercept</name>
<section anchor="li" title="Lawful Intercept"> <t>The lawful intercept requirements are similar for IPv6 and IPv4
<t>The Lawful Intercept requirements are similar for IPv6 and IPv4
architectures and will be subject to the laws enforced in different architectures and will be subject to the laws enforced in different
geographic regions. The local issues with each jurisdiction can make geographic regions. The local issues with each jurisdiction can make
this challenging and both corporate legal and privacy personnel should this challenging and both corporate legal and privacy personnel should
be involved in discussions pertaining to what information gets logged be involved in discussions pertaining to what information gets logged
and with regard to the respective log retention policies for this and with regard to the respective log retention policies for this
information.</t> information.</t>
<t>The target of interception will usually be a residential subscriber <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 (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 absence of IPv6 NAT on the CPE, IPv6 has the possibility to allow for
skipping to change at line 2243 skipping to change at line 1842
be involved in discussions pertaining to what information gets logged be involved in discussions pertaining to what information gets logged
and with regard to the respective log retention policies for this and with regard to the respective log retention policies for this
information.</t> information.</t>
<t>The target of interception will usually be a residential subscriber <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 (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 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) 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 rather than the whole set of hosts of a subscriber (which could be a
/48, /60, or /64).</t> /48, /60, or /64).</t>
<t>In contrast, in mobile environments, since the 3GPP specifications <t>In contrast, in mobile environments, since the 3GPP specifications
allocate a /64 per device, it may be sufficient to intercept traffic allocate a /64 per device, it may be sufficient to intercept traffic
from the /64 rather than specific /128's (since each time the device from the /64 rather than specific /128s (since each time the device
establishes a data connection it gets a new IID).</t> establishes a data connection, it gets a new IID).</t>
</section> </section>
<!-- li -->
</section> </section>
<!-- SP--> <section anchor="residential" numbered="true" toc="default">
<name>Residential Users Security Considerations</name>
<section anchor="residential" <t>The IETF Home Networking (homenet) Working Group is working on standard
title="Residential Users Security Considerations"> s and
<t>The IETF Homenet working group is working on standards and guidelines guidelines
for IPv6 residential networks; this obviously includes operational for IPv6 residential networks; this obviously includes operational
security considerations; but this is still work in progress. <xref security considerations, but this is still a work in progress. <xref targe
target="RFC8520"/> is an interesting approach on how firewalls could t="RFC8520" format="default"/> is an interesting approach on how firewalls could
retrieve and apply specific security policies to some residential retrieve and apply specific security policies to some residential
devices.</t> devices.</t>
<t>Some residential users have less experience and knowledge about <t>Some residential users have less experience and knowledge about
security or networking than experimented operators. As most of the security or networking than experimented operators. As most of the
recent hosts (e.g., smartphones, tablets) have IPv6 enabled by default, recent hosts (e.g., smartphones and tablets) have IPv6 enabled by default,
IPv6 security is important for those users. Even with an IPv4-only ISP, 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 those users can get IPv6 Internet access with the help of <xref target="te
target="teredo">Teredo</xref> tunnels. Several peer-to-peer programs redo" format="default">Teredo</xref> tunnels. Several peer-to-peer programs
support IPv6 and those programs can initiate a Teredo tunnel through an support IPv6, and those programs can initiate a Teredo tunnel through an
IPv4 residential gateway, with the consequence of making the internal IPv4 residential gateway, with the consequence of making the internal
host reachable from any IPv6 host on the Internet. It is therefore host reachable from any IPv6 host on the Internet. Therefore, it is
recommended that all host security products (including personal recommended that all host security products (including personal
firewalls) are configured with a dual-stack security policy.</t> firewalls) are configured with a dual-stack security policy.</t>
<t>If the residential CPE has IPv6 connectivity, <xref target="RFC7084" fo
<t>If the residential CPE has IPv6 connectivity, <xref rmat="default"/> defines the requirements of an IPv6 CPE and does not
target="RFC7084"/> defines the requirements of an IPv6 CPE and does not take a position on the debate of default IPv6 security policy, as defined
take a position on the debate of default IPv6 security policy as defined in <xref target="RFC6092" format="default"/>:</t>
in <xref target="RFC6092"/>:<list style="symbols"> <dl newline="true" spacing="normal">
<t>outbound only: allowing all internally initiated connections and <dt>outbound only:</dt>
block all externally initiated ones, which is a common default <dd>Allowing all internally initiated connections and
security policy enforced by IPv4 Residential Gateway doing NAPT but blocking all externally initiated ones, which is a common default
security policy enforced by IPv4 residential gateway doing NAPT, but
it also breaks the end-to-end reachability promise of IPv6. <xref it also breaks the end-to-end reachability promise of IPv6. <xref
target="RFC6092"/> lists several recommendations to design such a target="RFC6092"
CPE;</t> format="default"/> lists several recommendations to design such a
CPE.</dd>
<t>open/transparent: allowing all internally and externally <dt>open/transparent:</dt>
initiated connections, therefore restoring the end-to-end nature of <dd>Allowing all internally and externally
initiated connections, therefore, restoring the end-to-end nature of
the Internet for IPv6 traffic but having a different security policy the Internet for IPv6 traffic but having a different security policy
for IPv6 than for IPv4.</t> for IPv6 than for IPv4.</dd>
</list></t> </dl>
<t>REC-49 states that a choice must be given to
<t><xref target="RFC6092"/> REC-49 states that a choice must be given to the user to select one of those two policies <xref target="RFC6092" format
the user to select one of those two policies.</t> ="default"/>.</t>
</section> </section>
<!-- residentialThe --> <section numbered="true" toc="default">
<name>Further Reading</name>
<section title="Further Reading">
<t>There are several documents that describe in more detail the security <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 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 of them are dated but are listed here for the reader's convenience:</t>
style="numbers"> <ul spacing="normal">
<t><xref target="NIST">Guidelines for the Secure Deployment of <li>Guidelines for the Secure Deployment of IPv6 <xref target="NIST"
IPv6</xref></t> format="default"></xref></li>
<li>North American IPv6 Task Force Technology Report - IPv6 Security Tec
<t><xref target="NAv6TF_Security">North American IPv6 Task Force hnology Paper
Technology Report - IPv6 Security Technology Paper</xref></t> <xref target="NAv6TF_Security" format="default"></xref></li>
<li>IPv6 Security <xref target="IPv6_Security_Book" format="default"></x
<t><xref target="IPv6_Security_Book">IPv6 Security</xref></t> ref></li>
</list></t> </ul>
</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>
</section> </section>
<section anchor="Security" title="Security Considerations"> <section anchor="Security" numbered="true" toc="default">
<name>Security Considerations</name>
<t>This memo attempts to give an overview of security considerations of <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 operating an IPv6 network both for an IPv6-only network and for networks
utilizing the most widely deployed IPv4/IPv6 coexistence strategies.</t> utilizing the most widely deployed IPv4/IPv6 coexistence strategies.</t>
</section> </section>
<section anchor="IANA_Considerations" numbered="true" toc="default">
<name>IANA Considerations</name>
<t>This document has no IANA actions.</t>
</section>
</middle> </middle>
<!-- *****BACK MATTER ***** -->
<back> <back>
<references title="Normative References">
<!-- Here we use entities that we defined at the beginning. -->
&RFC8200;
</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; <displayreference target="I-D.kampanakis-6man-ipv6-eh-parsing" to="IPV6-EH-PARSI
NG"/>
&RFC7844; <displayreference target="I-D.ietf-opsec-ipv6-eh-filtering" to="IPV6-EH-FILTERIN
G"/>
&RFC7857;
&RFC7872;
&RFC7915;
&RFC7934;
&RFC8040;
&RFC8064;
&RFC8190;
&RFC8177;
&RFC8210;
&RFC8273;
&RFC8343;
&RFC8344;
&RFC8415;
&RFC8504;
&RFC8520;
&RFC8541;
<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>
<reference anchor="I-D.kampanakis-6man-ipv6-eh-parsing">
<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 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 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 IPv6 EHs with a goal of
providing a common and consistent parsing methodology for IPv6
implementers among the industry.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft"
value="draft-kampanakis-6man-ipv6-eh-parsing-01"/>
<format target="http://www.ietf.org/internet-drafts/draft-kampanakis-6ma
n-ipv6-eh-parsing-01.txt"
type="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 Network Access Control</title>
<author fullname="IEEE" surname="IEEE"/>
<date month="February" year="2010"/>
</front>
<seriesInfo name="IEEE Std" value="802.1X-2010"/>
</reference>
<reference anchor="SCANNING"
target="http://www.caida.org/workshops/isma/1202/slides/aims120
2_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"/> <references>
<name>References</name>
<references>
<name>Normative References</name>
<date month="February" year="2012"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
</front> .8200.xml"/>
</reference> <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>
<name>Informative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.0826.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.1918.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2131.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2460.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2529.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2663.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2784.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2827.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2866.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3056.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3068.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3627.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3704.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3756.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3964.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3971.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3972.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4107.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4033.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4302.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4303.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4193.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4293.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4301.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4364.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4380.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4381.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4443.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4552.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4649.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4659.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4795.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4798.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4861.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4864.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4890.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8981.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4942.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5082.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5214.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5340.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5635.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5952.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5969.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6092.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6104.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6105.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6144.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6146.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6147.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6164.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6169.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6177.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6192.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6221.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6241.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6264.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6269.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6296.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6302.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6324.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6343.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6434.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6333.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6459.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6547.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6564.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6583.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6598.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6620.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6666.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6762.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6763.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6775.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6877.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6888.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6939.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6964.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6967.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6980.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7010.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7011.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7012.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7039.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7045.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7084.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7112.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7113.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7123.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7166.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7217.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7359.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7381.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7404.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7422.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7454.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7513.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7526.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7552.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7597.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7599.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7610.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7707.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7721.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7785.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7772.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7824.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7844.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7857.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7872.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7915.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7934.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8040.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8064.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8190.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8177.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8210.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8273.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8343.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8344.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8415.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8504.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8520.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8541.xml"/>
<reference anchor="IPv6_Security_Book"> <reference anchor="IANA-IPFIX" target="http://www.iana.org/assignments/i
<front> pfix">
<title>IPv6 Security</title> <front>
<title>IP Flow Information Export (IPFIX) Entities</title>
<author>
<organization>IANA</organization>
</author>
</front>
</reference>
<author fullname="Scott Hogg" surname="Hogg"/> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.kampana kis-6man-ipv6-eh-parsing.xml"/>
<author fullname="Eric Vyncke" surname="Vyncke"/> <reference anchor='I-D.ietf-opsec-ipv6-eh-filtering'>
<front>
<title>Recommendations on the Filtering of IPv6 Packets Containing IPv6 Extensio
n 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-ietf-opsec-ipv6-eh-filtering-08'/
>
<format type='TXT' target='https://www.ietf.org/internet-drafts/draft-ietf-opsec
-ipv6-eh-filtering-08.txt'/>
</reference>
<date month="December" year="2008"/> <reference anchor="IEEE-802.1X">
</front> <front>
<title>IEEE Standard for Local and Metropolitan Area Networks--Port-
Based Network Access
Control</title>
<author><organization>IEEE</organization></author>
<date month="February" year="2020"/>
</front>
<seriesInfo name="IEEE Std" value="802.1X-2020"/>
</reference>
<seriesInfo name="ISBN" value="1-58705-594-5"/> <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>
<seriesInfo name="Publisher" value="CiscoPress"/> <reference anchor="IPv6_Security_Book">
</reference> <front>
<title>IPv6 Security</title>
<author fullname="Scott Hogg" surname="Hogg"/>
<author fullname="Éric Vyncke" surname="Vyncke"/>
<date month="December" year="2008"/>
</front>
<seriesInfo name="ISBN" value="1587055945"/>
<refcontent>CiscoPress</refcontent>
</reference>
<reference anchor="NAv6TF_Security" <reference anchor="NAv6TF_Security" target="http://www.ipv6forum.com/dl/
target="http://www.ipv6forum.com/dl/white/NAv6TF_Security_Repor white/NAv6TF_Security_Report.pdf">
t.pdf"> <front>
<front> <title>North American IPv6 Task Force (NAv6TF) Technology Report "IP
<title>North American IPv6 Task Force Technology Report - IPv6 v6
Security Technology Paper</title> 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>
<author fullname="Merike Kaeo" surname="Kaeo"/> <reference anchor="GDPR" target="https://eur-lex.europa.eu/eli/reg/2016/
679/oj">
<author fullname="David Green" surname="Green"/> <front>
<title>Regulation (EU) 2016/679 of the European Parliament and of
<author fullname="Jim Bound" surname="Bound"/>
<author fullname="Yanick Pouffary" surname="Pouffary"/>
<date 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 the Council of 27 April 2016 on the protection of natural persons
with regard to the processing of personal data and on the free with regard to the processing of personal data and on the free
movement of such data, and repealing Directive 95/46/EC (General movement of such data, and repealing Directive 95/46/EC (General
Data Protection Regulation)</title> Data Protection Regulation)</title>
<author><organization>European Union</organization></author>
<date month="April" year="2016"/>
</front>
<refcontent>Official Journal of the European Union</refcontent>
</reference>
<author fullname="Official Journal of the European Union"/> <reference anchor="RADB" target="https://www.radb.net/">
<front>
<date day="27" month="April" year="2016"/> <title>RADb: The Internet Routing Registry</title>
</front> <author><organization>Merit Network, Inc.</organization></author>
</reference> </front>
</reference>
<reference anchor="RADB" target="https://www.radb.net/">
<front>
<title>RADb The Internet Routing Registry</title>
<author fullname="MERIT NETWORK, INC."/>
<date year="Existing in 2021"/>
</front>
</reference>
<reference anchor="europol-cgn"
target="https://www.europol.europa.eu/newsroom/news/are-you-sha
ring-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 IP ADDRESS AS A CRIMINAL? LAW
ENFORCEMENT CALL FOR THE END OF CARRIER GRADE NAT (CGN) TO INCREASE
ACCOUNTABILITY ONLINE</title>
<author fullname="Europol"/>
<date day="17" month="October" year="2017"/>
</front>
</reference>
<reference anchor="NIST"
target="http://csrc.nist.gov/publications/nistpubs/800-119/sp80
0-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 year="2010"/>
</front>
</reference>
<reference anchor="WEBER_VPN"
target="https://blog.webernetz.net/wp-content/uploads/2018/03/T
R18-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-referen
ce/">
<front>
<title>The Bogon Reference</title>
<author fullname="Cymru Team"/> <reference anchor="europol-cgn" target="https://www.europol.europa.eu/ne
wsroom/news/are-you-sharing-same-ip-address-criminal-law-enforcement-call-for-en
d-of-carrier-grade-nat-cgn-to-increase-accountability-online">
<front>
<title>Are you sharing the same IP address as a criminal? Law enforc
ement call for the end of Carrier Grade Nat (CGN) to increase accountability onl
ine</title>
<author><organization>Europol</organization></author>
<date month="October" year="2017"/>
</front>
</reference>
<date year="Existing in 2021"/> <reference anchor="NIST" target="http://csrc.nist.gov/publications/nistp
</front> ubs/800-119/sp800-119.pdf">
</reference> <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="REY_PF" <reference anchor="WEBER_VPN" target="https://blog.webernetz.net/wp-cont
target="https://labs.ripe.net/Members/enno_rey/local-packet-fil ent/uploads/2018/03/TR18-Johannes-Weber-Dynamic-IPv6-Prefix-Problems-and-VPNs.pd
tering-with-ipv6"> f">
<front> <front>
<title>Local Packet Filtering with IPv6</title> <title>Dynamic IPv6 Prefix - Problems and VPNs</title>
<author fullname="Johannes Weber" surname="Weber"/>
<date month="March" year="2018"/>
</front>
</reference>
<author fullname="Enno Rey" surname="Rey"/> <reference anchor="CYMRU" target="https://team-cymru.com/community-servi
ces/bogon-reference/">
<front>
<title>The Bogon Reference</title>
<author><organization>Team Cymru</organization></author>
</front>
</reference>
<date day="13" month="July" year="2017"/> <reference anchor="REY_PF" target="https://labs.ripe.net/Members/enno_re
</front> y/local-packet-filtering-with-ipv6">
</reference> <front>
<title>Local Packet Filtering with IPv6</title>
<author fullname="Enno Rey" surname="Rey"/>
<date month="July" year="2017"/>
</front>
</reference>
<reference anchor="KRISTOFF" <reference anchor="KRISTOFF" target="https://dataplane.org/jtk/publicati
target="https://dataplane.org/jtk/publications/kgkp-pam-21.pdf" ons/kgkp-pam-21.pdf">
> <front>
<front> <title>Plight at the End of the Tunnel: Legacy IPv6 Transition
<title>Plight at the End of the Tunnel: Legacy IPv6 Transition
Mechanisms in the Wild</title> 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 month="March" year="2021"/>
</front>
</reference>
<author fullname="John Kristoff" surname="Kristoff"/> <reference anchor="ENTROPYIP" target="http://www.entropy-ip.com/">
<front>
<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> <title>Entropy/IP: Uncovering Structure in IPv6 Addresses</title>
<author fullname="Pawel Foremski" surname="Foremski"/>
<author fullname="Dave Plonka" surname="Plonla"/>
<author fullname="Arthur Berger" surname="Berger"/>
<date month="November" year="2016"/>
</front>
</reference>
<author fullname="P. Foremski" surname="Foremski"/> </references>
<author fullname="D. Plonka" surname="Plonla"/>
<author fullname="A. Berger" surname="Berger"/>
<date />
</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="Ti
m Chown"/>,
<contact fullname="Lorenzo Colitti"/>, <contact fullname="Roman Danyliw"/>
(IESG Review), <contact fullname="Markus de Bruen"/>, <contact fullname="L
ars Eggert"/>
(IESG review), <contact fullname="Tobias Fiebig"/>, <contact fullname="Fer
nando Gont"/>,
<contact fullname="Jeffry Handal"/>, <contact fullname="Lee Howard"/>,
<contact fullname="Benjamin Kaduk"/> (IESG
review), <contact fullname="Panos Kampanakis"/>, <contact fullname="Erik K
line"/>,
<contact fullname="Jouni Korhonen"/>, <contact fullname="Warren Kumari"/>
(IESG review), <contact fullname="Ted Lemon"/>, <contact fullname="Mark Le
ntczner"/>,
<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> </back>
</rfc> </rfc>
 End of changes. 458 change blocks. 
2101 lines changed or deleted 1756 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/