doc: Add RFC documents

1 files changed, 2762 insertions, 0 deletions

diff --git a/doc/rfc/rfc9099.txt b/doc/rfc/rfc9099.txt
new file mode 100644
index 0000000..7b82305
--- /dev/null
+++ b/doc/rfc/rfc9099.txt
@@ -0,0 +1,2762 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                         É. Vyncke
+Request for Comments: 9099                                         Cisco
+Category: Informational                                  K. Chittimaneni
+ISSN: 2070-1721                                                         
+                                                                 M. Kaeo
+                                                    Double Shot Security
+                                                                  E. Rey
+                                                                    ERNW
+                                                             August 2021
+
+
+         Operational Security Considerations for IPv6 Networks
+
+Abstract
+
+   Knowledge and experience on how to operate IPv4 networks securely is
+   available, whether the operator is an Internet Service Provider (ISP)
+   or an enterprise internal network.  However, IPv6 presents some new
+   security challenges.  RFC 4942 describes security issues in the
+   protocol, but network managers also need a more practical,
+   operations-minded document to enumerate advantages and/or
+   disadvantages of certain choices.
+
+   This document analyzes the operational security issues associated
+   with several types of networks and proposes technical and procedural
+   mitigation techniques.  This document is only applicable to managed
+   networks, such as enterprise networks, service provider networks, or
+   managed residential networks.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Not all documents
+   approved by the IESG are candidates for any level of Internet
+   Standard; see Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc9099.
+
+Copyright Notice
+
+   Copyright (c) 2021 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (https://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+Table of Contents
+
+   1.  Introduction
+     1.1.  Applicability Statement
+     1.2.  Requirements Language
+   2.  Generic Security Considerations
+     2.1.  Addressing
+       2.1.1.  Use of ULAs
+       2.1.2.  Point-to-Point Links
+       2.1.3.  Loopback Addresses
+       2.1.4.  Stable Addresses
+       2.1.5.  Temporary Addresses for SLAAC
+       2.1.6.  DHCP Considerations
+       2.1.7.  DNS Considerations
+       2.1.8.  Using a /64 per Host
+       2.1.9.  Privacy Consideration of Addresses
+     2.2.  Extension Headers
+       2.2.1.  Order and Repetition of Extension Headers
+       2.2.2.  Hop-by-Hop Options Header
+       2.2.3.  Fragment Header
+       2.2.4.  IP Security Extension Header
+     2.3.  Link-Layer Security
+       2.3.1.  Neighbor Solicitation Rate-Limiting
+       2.3.2.  Router and Neighbor Advertisements Filtering
+       2.3.3.  Securing DHCP
+       2.3.4.  3GPP Link-Layer Security
+       2.3.5.  Impact of Multicast Traffic
+       2.3.6.  SEND and CGA
+     2.4.  Control Plane Security
+       2.4.1.  Control Protocols
+       2.4.2.  Management Protocols
+       2.4.3.  Packet Exceptions
+     2.5.  Routing Security
+       2.5.1.  BGP Security
+       2.5.2.  Authenticating OSPFv3 Neighbors
+       2.5.3.  Securing Routing Updates
+       2.5.4.  Route Filtering
+     2.6.  Logging/Monitoring
+       2.6.1.  Data Sources
+       2.6.2.  Use of Collected Data
+       2.6.3.  Summary
+     2.7.  Transition/Coexistence Technologies
+       2.7.1.  Dual Stack
+       2.7.2.  Encapsulation Mechanisms
+       2.7.3.  Translation Mechanisms
+     2.8.  General Device Hardening
+   3.  Enterprises-Specific Security Considerations
+     3.1.  External Security Considerations
+     3.2.  Internal Security Considerations
+   4.  Service Provider Security Considerations
+     4.1.  BGP
+       4.1.1.  Remote Triggered Black Hole Filtering
+     4.2.  Transition/Coexistence Mechanism
+     4.3.  Lawful Intercept
+   5.  Residential Users Security Considerations
+   6.  Further Reading
+   7.  Security Considerations
+   8.  IANA Considerations
+   9.  References
+     9.1.  Normative References
+     9.2.  Informative References
+   Acknowledgements
+   Authors' Addresses
+
+1.  Introduction
+
+   Running an IPv6 network is new for most operators not only because
+   they are not yet used to large-scale IPv6 networks but also because
+   there are subtle but critical and important differences between IPv4
+   and IPv6, especially with respect to security.  For example, all
+   Layer 2 (L2) interactions are now done using the Neighbor Discovery
+   Protocol (NDP) [RFC4861] rather than the Address Resolution Protocol
+   [RFC0826].  Also, there is no Network Address Port Translation (NAPT)
+   defined in [RFC2663] for IPv6 even if [RFC6296] specifies an IPv6-to-
+   IPv6 Network Prefix 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 headers.
+
+   IPv6 networks are deployed using a variety of techniques, each of
+   which have their own specific security concerns.
+
+   This document complements [RFC4942] by listing security issues when
+   operating a network (including various transition technologies).  It
+   also provides operational deployment experiences where warranted.
+
+1.1.  Applicability Statement
+
+   This document is applicable to managed networks, i.e., when the
+   network is operated by the user organization itself.  Indeed, many of
+   the recommended mitigation techniques must be configured with
+   detailed knowledge of the network (which are the default routers, the
+   switch trunk ports, etc.).  This covers Service Providers (SPs),
+   enterprise networks, and some knowledgeable home-user-managed
+   residential networks.  This applicability statement especially
+   applies to Sections 2.3 and 2.5.4.
+
+1.2.  Requirements Language
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in
+   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+   capitals, as shown here.
+
+2.  Generic Security Considerations
+
+2.1.  Addressing
+
+   IPv6 address allocations and overall architecture are important parts
+   of securing IPv6.  Initial designs, even if intended to 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 (IPAM)
+   system.  [RFC7010] introduces the mechanisms that could be utilized
+   for IPv6 site renumbering and tries to cover most of the explicit
+   issues and requirements associated with IPv6 renumbering.
+
+   A key task for a successful IPv6 deployment is to prepare an
+   addressing plan.  Because an abundance of address space is available,
+   structuring an address plan around both services and geographic
+   locations allows address space to become a basis for more structured
+   security policies to permit or deny services between geographic
+   regions.  [RFC6177] documents some operational considerations of
+   using different prefix sizes for address assignments at end sites.
+
+   A common question is whether companies should use Provider-
+   Independent (PI) or Provider-Aggregated (PA) space [RFC7381], but,
+   from a security perspective, there is little difference.  However,
+   one aspect to keep in mind is who has administrative ownership of the
+   address space and who is technically responsible if/when there is a
+   need to enforce restrictions on routability of the space, e.g., due
+   to malicious criminal activity originating from it.  Relying on PA
+   address space may also increase the perceived need for address
+   translation techniques, such as NPTv6; thereby, the complexity of the
+   operations, including the security operations, is augmented.
+
+   In [RFC7934], it is recommended that IPv6 network deployments provide
+   multiple IPv6 addresses from each prefix to general-purpose hosts,
+   and it specifically does not recommend limiting a host to only one
+   IPv6 address per prefix.  It also recommends that the network give
+   the host the ability to use new addresses without requiring explicit
+   requests (for example, by using Stateless Address Autoconfiguration
+   (SLAAC)).  Privacy extensions, as of [RFC8981], 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 compared to the unique IPv4 address
+   per interface for hosts (secondary IPv4 addresses are not common),
+   especially for audits (see Section 2.6.2.3).
+
+2.1.1.  Use of ULAs
+
+   Unique Local Addresses (ULAs) [RFC4193] are intended for scenarios
+   where interfaces are not globally reachable, despite being routed
+   within a domain.  They formally have global scope, but [RFC4193]
+   specifies that they must be filtered at domain boundaries.  ULAs are
+   different from the addresses described in [RFC1918] and have
+   different use cases.  One use of ULAs is described in [RFC4864];
+   another one is for internal communication stability in networks where
+   external connectivity may come and go (e.g., some ISPs provide ULAs
+   in home networks connected via a cable modem).  It should further be
+   kept in mind that ULA /48s from the fd00::/8 space (L=1) MUST be
+   generated with a pseudorandom algorithm, per Section 3.2.1 of
+   [RFC4193].
+
+2.1.2.  Point-to-Point Links
+
+   Section 5.1 of [RFC6164] specifies the rationale of using /127 for
+   inter-router, point-to-point links to prevent the ping-pong issue
+   between routers not correctly implementing [RFC4443], and it also
+   prevents a denial-of-service (DoS) attack on the Neighbor Cache.  The
+   previous recommendation of [RFC3627] has been obsoleted and marked
+   Historic by [RFC6547].
+
+   Some environments are also using link-local addressing for point-to-
+   point links.  While this practice could further reduce the attack
+   surface of infrastructure devices, the operational disadvantages also
+   need to be carefully considered; see [RFC7404].
+
+2.1.3.  Loopback Addresses
+
+   Many operators reserve a /64 block for all loopback addresses in
+   their infrastructure and allocate a /128 out of this reserved /64
+   prefix for each loopback interface.  This practice facilitates
+   configuration of Access Control List (ACL) rules to enforce a
+   security policy for those loopback addresses.
+
+2.1.4.  Stable Addresses
+
+   When considering how to assign stable addresses for nodes (either by
+   static configuration or by pre-provisioned DHCPv6 lease
+   (Section 2.1.6)), it is necessary to take into consideration the
+   effectiveness of perimeter security in a given environment.
+
+   There is a trade-off between ease of operation (where some portions
+   of the IPv6 address could be easily recognizable for operational
+   debugging and troubleshooting) versus the risk of trivial scanning
+   used for reconnaissance.  [SCANNING] shows that there are
+   scientifically based mechanisms that make scanning for IPv6-reachable
+   nodes more feasible than expected; see [RFC7707].
+
+   Stable addresses also allow easy enforcement of a security policy at
+   the perimeter based on IPv6 addresses.  For example, Manufacturer
+   Usage Description (MUD) [RFC8520] is a mechanism where the perimeter
+   defense can retrieve the security policy template based on the type
+   of internal device and apply the right security policy based on the
+   device's IPv6 address.
+
+   The use of well-known IPv6 addresses (such as ff02::1 for all link-
+   local nodes) or the use of commonly repeated addresses could make it
+   easy to figure out which devices are name servers, routers, or other
+   critical devices; even a simple traceroute will expose most of the
+   routers on a path.  There are many scanning techniques possible and
+   operators should not rely on the 'impossible to find because my
+   address is random' paradigm (a.k.a. "security by obscurity") even if
+   it is common practice to have the stable addresses randomly
+   distributed across /64 subnets and to always use DNS (as IPv6
+   addresses are hard for human brains to remember).
+
+   While, in some environments, obfuscating addresses could be
+   considered an added benefit, it should not preclude enforcement of
+   perimeter rules.  Stable addresses following some logical allocation
+   scheme may ease the operation (as simplicity always helps security).
+
+   Typical deployments will have a mix of stable and non-stable
+   addresses; the stable addresses being either predictable (e.g., ::25
+   for a mail server) or obfuscated (i.e., appearing as a random 64-bit
+   number).
+
+2.1.5.  Temporary Addresses for SLAAC
+
+   Historically, Stateless Address Autoconfiguration (SLAAC) makes up
+   the globally unique IPv6 address based on an automatically generated
+   64-bit interface identifier (IID) based on the 64-bit Extended Unique
+   Identifier (EUI-64) Media Access Control (MAC) address combined with
+   the /64 prefix (received in the Prefix Information Option (PIO) of
+   the Router Advertisement (RA)).  The EUI-64 address is generated from
+   the stable 48-bit MAC address and does not change even if the host
+   moves to another network; this is of course bad for privacy, as a
+   host can be traced from network (home) to network (office or Wi-Fi in
+   hotels).  [RFC8064] recommends against the use of EUI-64 addresses,
+   and it must be noted that most host operating systems do not use
+   EUI-64 addresses anymore and rely on either [RFC8981] or [RFC8064].
+
+   Randomly generating an interface ID, as described in [RFC8981], is
+   part of SLAAC with so-called privacy extension addresses and is used
+   to address some privacy concerns.  Privacy extension addresses,
+   a.k.a. temporary addresses, may help to mitigate the correlation of
+   activities of a node within the same network and may also reduce the
+   attack exposure window.  But using privacy extension addresses as
+   described in [RFC8981] might prevent the operator from building host-
+   specific access control lists (ACLs).  These privacy extension
+   addresses could also be used to obfuscate some malevolent activities,
+   and specific user attribution/accountability procedures should be put
+   in place, as described in Section 2.6.
+
+   [RFC8064] combined with the address generation mechanism of [RFC7217]
+   specifies another way to generate an address while still keeping the
+   same IID for each network prefix; this allows SLAAC nodes to always
+   have the same stable IPv6 address on a specific network while having
+   different IPv6 addresses on different networks.
+
+   In some specific use cases where user accountability is more
+   important than user privacy, network operators may consider disabling
+   SLAAC and relying only on DHCPv6; however, not all operating systems
+   support DHCPv6, so some hosts will not get any IPv6 connectivity.
+   Disabling SLAAC and privacy extension addresses can be done for most
+   operating systems by sending RA messages with a hint to get addresses
+   via DHCPv6 by setting the M-bit and disabling SLAAC by resetting all
+   A-bits in all PIOs.  However, attackers could still find ways to
+   bypass this mechanism if it is not enforced at the switch/router
+   level.
+
+   However, in scenarios where anonymity is a strong desire (protecting
+   user privacy is more important than user attribution), privacy
+   extension addresses should be used.  When mechanisms recommended by
+   [RFC8064] are available, the stable privacy address is probably a
+   good balance between privacy (among different networks) and security/
+   user attribution (within a network).
+
+2.1.6.  DHCP Considerations
+
+   Some environments use DHCPv6 to provision addresses and other
+   parameters in order to ensure auditability and traceability (see
+   Section 2.6.1.5 for the limitations of DHCPv6 for auditability).
+
+   A main security concern is the ability to detect and counteract rogue
+   DHCP servers (Section 2.3.3).  It must 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', which may
+   contain a hardware address or another type of identifier, such as a
+   DNS name.  For DHCPv6, the lease is bound to the client DHCP Unique
+   Identifier (DUID), which may or may not be bound to the client L2
+   address.  [RFC7824] describes the privacy issues associated with the
+   use of DHCPv6 by Internet users.  The anonymity profiles [RFC7844]
+   are designed for clients that wish to remain anonymous to the visited
+   network.  [RFC7707] recommends that DHCPv6 servers issue addresses
+   randomly from a large pool.
+
+2.1.7.  DNS Considerations
+
+   While the security concerns of DNS are not fundamentally different
+   between IPv4 and IPv6, there are specific considerations in DNS64
+   [RFC6147] environments that need to be understood.  Specifically, the
+   interactions and the potential of interference with DNSSEC [RFC4033]
+   implementation need to be understood -- these are pointed out in more
+   detail in Section 2.7.3.2.
+
+2.1.8.  Using a /64 per Host
+
+   An interesting approach is using a /64 per host, as proposed in
+   [RFC8273], especially in a shared environment.  This allows for
+   easier user attribution (typically based on the host MAC address), as
+   its /64 prefix is stable, even if applications within the host can
+   change their IPv6 address within this /64 prefix.
+
+   This can also be useful for the generation of ACLs once individual
+   systems (e.g., admin workstations) have their own prefixes.
+
+2.1.9.  Privacy Consideration of Addresses
+
+   In addition to the security aspects of IPv6 addresses, there are also
+   privacy considerations: mainly because they are of global scope and
+   visible globally.  [RFC7721] goes into more detail on the privacy
+   considerations for IPv6 addresses by comparing the manually
+   configured IPv6 address, DHCPv6, and SLAAC.
+
+2.2.  Extension Headers
+
+   Extension headers are an important difference between IPv4 and IPv6.
+   In IPv4-based packets, it's trivial to find the upper-layer protocol
+   type and protocol header, while, in IPv6, it is more complex since
+   the extension header chain must be parsed completely (even if not
+   processed) in order to find the upper-layer protocol header.  IANA
+   has closed the existing empty "Next Header Types" registry to new
+   entries and is redirecting its users to the "IPv6 Extension Header
+   Types" registry, per [RFC7045].
+
+   Extension headers have also become a very controversial topic since
+   forwarding nodes that discard packets containing extension headers
+   are known to cause connectivity failures and deployment problems
+   [RFC7872].  Understanding the role of various extension headers is
+   important, and this section enumerates the ones that need careful
+   consideration.
+
+   A clarification on how intermediate nodes should handle packets with
+   existing or future extension headers is found in [RFC7045].  The
+   uniform TLV format to be used for defining future extension headers
+   is described in [RFC6564].  Sections 5.2 and 5.3 of [RFC8504] provide
+   more information on the processing of extension headers by IPv6
+   nodes.
+
+   Vendors of filtering solutions and operations personnel responsible
+   for implementing packet filtering rules should be aware that the
+   'Next Header' field in an IPv6 header can both point to an IPv6
+   extension header or to an upper-layer protocol header.  This has to
+   be considered when designing the user interface of filtering
+   solutions or during the creation of filtering rule sets.
+
+   [IPV6-EH-FILTERING] discusses filtering rules for those extension
+   headers at transit routers.
+
+2.2.1.  Order and Repetition of Extension Headers
+
+   While [RFC8200] recommends the order and the maximum repetition of
+   extension headers, at the time of writing, there are still IPv6
+   implementations that support an order of headers that is not
+   recommended (such as Encapsulating Security Payload (ESP) before
+   routing) or an illegal repetition of headers (such as multiple
+   routing headers).  The same applies for options contained in the
+   extension headers (see [IPV6-EH-PARSING]).  In some cases, it has led
+   to nodes crashing when receiving or forwarding wrongly formatted
+   packets.
+
+   A firewall or edge device should be used to enforce the recommended
+   order and the maximum occurrences of extension headers by dropping
+   nonconforming packets.
+
+2.2.2.  Hop-by-Hop Options Header
+
+   In the previous IPv6 specification [RFC2460], the hop-by-hop options
+   header, when present in an IPv6 packet, forced all nodes to inspect
+   and possibly process this header.  This enabled denial-of-service
+   attacks as most, if not all, routers cannot process this type of
+   packet in hardware; they have to process these packets in software
+   and, hence, this task competes with other software tasks, such as
+   handling the control and management plane processing.
+
+   Section 4.3 of [RFC8200], the current Internet Standard for IPv6, has
+   taken this attack vector into account and made the processing of hop-
+   by-hop options headers by intermediate routers explicitly
+   configurable.
+
+2.2.3.  Fragment Header
+
+   The fragment header is used by the source (and only the source) when
+   it has to fragment packets.  [RFC7112] and Section 4.5 of [RFC8200]
+   explain why it is important that:
+
+   *  Firewall and security devices should drop first fragments that do
+      not contain the entire IPv6 header chain (including the transport-
+      layer header).
+
+   *  Destination nodes should discard first fragments that do not
+      contain the entire IPv6 header chain (including the transport-
+      layer header).
+
+   If those requirements are not met, stateless filtering could be
+   bypassed by a hostile party.  [RFC6980] applies a stricter rule to
+   NDP by enforcing the drop of fragmented NDP packets (except for
+   "Certification Path Advertisement" messages, as noted in section
+   Section 2.3.2.1).  [RFC7113] describes how the RA-Guard function
+   described in [RFC6105] should behave in the presence of fragmented RA
+   packets.
+
+2.2.4.  IP Security Extension Header
+
+   The IPsec [RFC4301] extension headers (Authentication Header (AH)
+   [RFC4302] and ESP [RFC4303]) are required if IPsec is to be utilized
+   for network-level security.  Previously, IPv6 mandated implementation
+   of IPsec, but [RFC6434] updated that recommendation by making support
+   of the IPsec architecture [RFC4301] a 'SHOULD' for all IPv6 nodes
+   that are also retained in the latest IPv6 Nodes Requirement standard
+   [RFC8504].
+
+2.3.  Link-Layer Security
+
+   IPv6 relies heavily on NDP [RFC4861] 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.  If not
+   secured, NDP is vulnerable to various attacks, such as router/
+   neighbor message spoofing, redirect attacks, Duplicate Address
+   Detection (DAD) DoS attacks, etc.  Many of these security threats to
+   NDP have been documented in "IPv6 Neighbor Discovery (ND) Trust
+   Models and Threats" [RFC3756] and in "Operational Neighbor Discovery
+   Problems" [RFC6583].
+
+   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 off
+   link; see Section 2.3.1 below.
+
+2.3.1.  Neighbor Solicitation Rate-Limiting
+
+   NDP can be vulnerable to remote DoS attacks, for example, when a
+   router is forced to perform address resolution for a large number of
+   unassigned addresses, i.e., when a prefix is scanned by an attacker
+   in a fast manner.  This can keep new devices from joining the network
+   or render the last-hop router ineffective due to high CPU usage.
+   Easy mitigative steps include rate limiting Neighbor Solicitations,
+   restricting the amount of state reserved for unresolved
+   solicitations, and cleverly managing the cache/timer.
+
+   [RFC6583] discusses the potential for off-link DoS in detail and
+   suggests implementation improvements and operational mitigation
+   techniques that may be used to mitigate or alleviate the impact of
+   such attacks.  Here are some feasible mitigation options that can be
+   employed by network operators today:
+
+   *  Ingress filtering of unused addresses by ACL.  These require
+      stable configuration of the addresses, e.g., allocating the
+      addresses out of a /120 and using a specific ACL to only allow
+      traffic to this /120 (of course, the actual hosts are configured
+      with a /64 prefix for the link).
+
+   *  Tuning of NDP process (where supported), e.g., enforcing limits on
+      data structures, such as the number of Neighbor Cache entries in
+      'incomplete' state (e.g., 256 incomplete entries per interface) or
+      the rate of NA per interface (e.g., 100 NA per second).
+
+   *  Using a /127 on a point-to-point link, per [RFC6164].
+
+   *  Using only link-local addresses on links where there are only
+      routers; see [RFC7404].
+
+2.3.2.  Router and Neighbor Advertisements Filtering
+
+2.3.2.1.  Router Advertisement Filtering
+
+   Router Advertisement spoofing is a well-known, on-link attack vector
+   and has been extensively documented.  The presence of rogue RAs,
+   either unintentional or malicious, can cause partial or complete
+   failure of operation of hosts on an IPv6 link.  For example, a node
+   can select an incorrect router address, which can then be used for an
+   on-path attack, or the node can assume wrong prefixes to be used for
+   SLAAC.  [RFC6104] summarizes the scenarios in which rogue RAs may be
+   observed and presents a list of possible solutions to the problem.
+   [RFC6105] (RA-Guard) describes a solution framework for the rogue RA
+   problem where network segments are designed around switching devices
+   that are capable of identifying invalid RAs and blocking them before
+   the attack packets actually reach the target nodes.
+
+   However, several evasion techniques that circumvent the protection
+   provided by RA-Guard have surfaced.  A key challenge to this
+   mitigation technique is introduced by IPv6 fragmentation.  Attackers
+   can conceal their attack by fragmenting their packets into multiple
+   fragments such that the switching device that is responsible for
+   blocking invalid RAs cannot find all the necessary information to
+   perform packet filtering of the same packet.  [RFC7113] describes
+   such evasion techniques and provides advice to RA-Guard implementers
+   such that the aforementioned evasion vectors can be eliminated.
+
+   Given that the IPv6 Fragmentation Header can be leveraged to
+   circumvent some implementations of RA-Guard, [RFC6980] updates
+   [RFC4861] such that use of the IPv6 Fragmentation Header is forbidden
+   in all Neighbor Discovery messages, except "Certification Path
+   Advertisement", thus allowing for simple and effective measures to
+   counter fragmented NDP attacks.
+
+2.3.2.2.  Neighbor Advertisement Filtering
+
+   The Source Address Validation Improvements (savi) Working Group has
+   worked on other ways to mitigate the effects of such attacks.
+   [RFC7513] helps in creating bindings between a source IP address
+   assigned to DHCPv4 [RFC2131] or DHCPv6 [RFC8415] and a binding anchor
+   [RFC7039] on a SAVI device.  Also, [RFC6620] describes how to glean
+   similar bindings when DHCP is not used.  The bindings can be used to
+   filter packets generated on the local link with forged source IP
+   addresses.
+
+2.3.2.3.  Host Isolation
+
+   Isolating hosts for the NDP traffic can be done by using a /64 per
+   host, refer to Section 2.1.8, as NDP is only relevant within a /64
+   on-link prefix; 3GPP (Section 2.3.4) uses a similar mechanism.
+
+   A more drastic technique to prevent all NDP attacks is based on
+   isolation of all hosts with specific configurations.  In such a
+   scenario, hosts (i.e., all nodes that are not routers) are unable to
+   send data-link layer frames to other hosts; therefore, no host-to-
+   host attacks can happen.  This specific setup can be established on
+   some switches or Wi-Fi access points.  This is not always feasible
+   when hosts need to communicate with other hosts in the same subnet,
+   e.g., for access to file shares.
+
+2.3.2.4.  NDP Recommendations
+
+   It is still recommended that RA-Guard and SAVI be employed as a first
+   line of defense against common attack vectors, including
+   misconfigured hosts.  This recommendation also applies when DHCPv6 is
+   used, as RA messages are used to discover the default router(s) and
+   for on-link prefix determination.  This line of defense is most
+   effective when incomplete fragments are dropped by routers and L2
+   switches, as described in Section 2.2.3.  The generated log should
+   also be analyzed to identify and act on violations.
+
+   Network operators should be aware that RA-Guard and SAVI do not work
+   as expected or could even be harmful in specific network
+   configurations (notably when there could be multiple routers).
+
+   Enabling RA-Guard by default in managed networks (e.g., Wi-Fi
+   networks, enterprise campus networks, etc.) should be strongly
+   considered except for specific use cases, such as in the presence of
+   homenet devices emitting router advertisements.
+
+2.3.3.  Securing DHCP
+
+   The Dynamic Host Configuration Protocol for IPv6 (DHCPv6), as
+   described in [RFC8415], enables DHCP servers to pass configuration
+   parameters, such as IPv6 network addresses and other configuration
+   information, to IPv6 nodes.  DHCP plays an important role in most
+   large networks by providing robust stateful configuration in the
+   context of automated system provisioning.
+
+   The two most common threats to DHCP clients come from malicious
+   (a.k.a. rogue) or unintentionally misconfigured DHCP servers.  In
+   these scenarios, a malicious DHCP server is established with the
+   intent of providing incorrect configuration information to the
+   clients to cause a denial-of-service attack or to mount an on-path
+   attack.  While unintentional, a misconfigured DHCP server can have
+   the same impact.  Additional threats against DHCP are discussed in
+   the security considerations section of [RFC8415].
+
+   DHCPv6-Shield [RFC7610] specifies a mechanism for protecting
+   connected DHCPv6 clients against rogue DHCPv6 servers.  This
+   mechanism is based on DHCPv6 packet filtering at the L2 device, i.e.,
+   the administrator specifies the interfaces connected to DHCPv6
+   servers.  However, extension headers could be leveraged to bypass
+   DHCPv6-Shield unless [RFC7112] is enforced.
+
+   It is recommended to use DHCPv6-Shield and to analyze the
+   corresponding log messages.
+
+2.3.4.  3GPP Link-Layer Security
+
+   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 mobile
+   handset) and the first-hop router (i.e., a Gateway GPRS Support Node
+   (GGSN) or a Packet Data Network Gateway (PGW)) on that link.  The
+   GGSN/PGW never configures a non-link-local address on the link using
+   the advertised /64 prefix on it; see Section 2.1.8.  The advertised
+   prefix must not be used for on-link determination.  There is no need
+   for address resolution on the 3GPP link, since there are no link-
+   layer addresses.  Furthermore, the GGSN/PGW assigns a prefix that is
+   unique within each 3GPP link that uses IPv6 Stateless Address
+   Autoconfiguration.  This avoids the necessity to perform DAD at the
+   network level for every address generated by the mobile host.  The
+   GGSN/PGW always provides an IID to the cellular host for the purpose
+   of configuring the link-local address and ensures the uniqueness of
+   the IID on the link (i.e., no collisions between its own link-local
+   address and the mobile host's address).
+
+   The 3GPP link model itself mitigates most of the known NDP-related
+   DoS attacks.  In practice, the GGSN/PGW only needs to route all
+   traffic to the mobile host that falls under the prefix assigned to
+   it.  As there is also a single host on the 3GPP link, there is no
+   need to defend that IPv6 address.
+
+   See Section 5 of [RFC6459] for a more detailed discussion on the 3GPP
+   link model, NDP, and the address configuration details.  In some
+   mobile networks, DHCPv6 and DHCP Prefix Delegation (DHCP-PD) are also
+   used.
+
+2.3.5.  Impact of Multicast Traffic
+
+   IPv6 uses multicast extensively for signaling messages on the local
+   link to avoid broadcast messages for on-the-wire efficiency.
+
+   The use of multicast has some side effects on wireless networks, such
+   as a negative impact on battery life of smartphones and other
+   battery-operated devices that are connected to such networks.
+   [RFC7772] and [RFC6775] (for specific wireless networks) discuss
+   methods to rate-limit RAs and other ND messages on wireless networks
+   in order to address this issue.
+
+   The use of link-layer multicast addresses (e.g., ff02::1 for the all
+   nodes link-local multicast address) could also be misused for an
+   amplification attack.  Imagine a hostile node sending an ICMPv6
+   ECHO_REQUEST to ff02::1 with a spoofed source address, then all link-
+   local nodes will reply with ICMPv6 ECHO_REPLY packets to the source
+   address.  This could be a DoS attack for the address owner.  This
+   attack is purely local to the L2 network, as packets with a link-
+   local destination are never forwarded by an IPv6 router.
+
+   This is the reason why large Wi-Fi network deployments often 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 send link-
+   local multicast to their direct neighboring Wi-Fi stations; this
+   policy also blocks service discovery via Multicast DNS (mDNS)
+   [RFC6762] and Link-Local Multicast Name Resolution (LLMNR) [RFC4795].
+
+2.3.6.  SEND and CGA
+
+   SEcure Neighbor Discovery (SEND), as described in [RFC3971], is a
+   mechanism that was designed to secure ND messages.  This approach
+   involves the use of new NDP options to carry public-key-based
+   signatures.  Cryptographically Generated Addresses (CGA), as
+   described in [RFC3972], are used to ensure that the sender of a
+   Neighbor Discovery message is the actual "owner" of the claimed IPv6
+   address.  A new NDP option, the CGA option, was introduced and is
+   used to carry the public key and associated parameters.  Another NDP
+   option, the RSA Signature option, is used to protect all messages
+   relating to neighbor and router discovery.
+
+   SEND protects against:
+
+   *  Neighbor Solicitation/Advertisement Spoofing
+
+   *  Neighbor Unreachability Detection Failure
+
+   *  Duplicate Address Detection DoS Attack
+
+   *  Router Solicitation and Advertisement Attacks
+
+   *  Replay Attacks
+
+   *  Neighbor Discovery DoS Attacks
+
+   SEND does NOT:
+
+   *  protect statically configured addresses
+
+   *  protect addresses configured using fixed identifiers (i.e., EUI-
+      64)
+
+   *  provide confidentiality for NDP communications
+
+   *  compensate for an unsecured link -- SEND does not require that the
+      addresses on the link and Neighbor Advertisements correspond
+
+   However, at this time and over a decade since their original
+   specifications, CGA and SEND do not have support from widely deployed
+   IPv6 devices; hence, their usefulness is limited and should not be
+   relied upon.
+
+2.4.  Control Plane Security
+
+   [RFC6192] defines the router control plane and provides detailed
+   guidance to secure it for IPv4 and IPv6 networks.  This definition is
+   repeated here for the reader's convenience.  Please note that the
+   definition is completely protocol-version agnostic (most of this
+   section applies to IPv6 in the same way as to IPv4).
+
+      |  Preamble: IPv6 control plane security is vastly congruent with
+      |  its IPv4 equivalent, with the exception of OSPFv3
+      |  authentication (Section 2.4.1) and some packet exceptions (see
+      |  Section 2.4.3) that are specific to IPv6.
+
+   Modern router architecture design maintains a strict separation of
+   forwarding and router control plane hardware and software.  The
+   router control plane supports routing and management functions.  It
+   is generally described as the router architecture hardware and
+   software components for handling packets destined to the device
+   itself as well as building and sending packets originated locally on
+   the device.  The forwarding plane is typically described as the
+   router architecture hardware and software components responsible for
+   receiving a packet on an incoming interface, performing a lookup to
+   identify the packet's IP next hop and best outgoing interface towards
+   the destination, and forwarding the packet through the appropriate
+   outgoing interface.
+
+   While the forwarding plane is usually implemented in high-speed
+   hardware, the control plane is implemented by a generic processor
+   (referred to as the routing processor (RP)) and cannot process
+   packets at a high rate.  Hence, this processor can be attacked by
+   flooding its input queue with more packets than it can process.  The
+   control plane processor is then unable to process valid control
+   packets and the router can lose IGP or BGP adjacencies, which can
+   cause a severe network disruption.
+
+   [RFC6192] provides detailed guidance to protect the router control
+   plane in IPv6 networks.  The rest of this section contains simplified
+   guidance.
+
+   The mitigation techniques are:
+
+   *  to drop illegitimate or potentially harmful control packets before
+      they are queued to the RP (this can be done by a forwarding plane
+      ACL) and
+
+   *  to rate-limit the remaining packets to a rate that the RP can
+      sustain.  Protocol-specific protection should also be done (for
+      example, a spoofed OSPFv3 packet could trigger the execution of
+      the Dijkstra algorithm; therefore, the frequency of Dijkstra
+      calculations should also be rate limited).
+
+   This section will consider several classes of control packets:
+
+   Control protocols:
+      routing protocols, such as OSPFv3, BGP, Routing Information
+      Protocol Next Generation (RIPng), and, by extension, NDP and ICMP
+
+   Management protocols:
+      Secure Shell (SSH), SNMP, Network Configuration Protocol
+      (NETCONF), RESTCONF, IP Flow Information Export (IPFIX), etc.
+
+   Packet exceptions:
+      normal data packets that require a specific processing, such as
+      generating a packet-too-big ICMP message or processing the hop-by-
+      hop options header
+
+2.4.1.  Control Protocols
+
+   This class includes OSPFv3, BGP, NDP, and ICMP.
+
+   An ingress ACL to be applied on all the router interfaces for packets
+   to be processed by the RP should be configured to:
+
+   *  drop OSPFv3 (identified by Next-Header being 89) and RIPng
+      (identified by UDP port 521) packets from a non-link-local address
+      (except for OSPFv3 virtual links)
+
+   *  allow BGP (identified by TCP port 179) packets from all BGP
+      neighbors and drop the others
+
+   *  allow all ICMP packets (transit and to the router interfaces)
+
+      |  Note: Dropping OSPFv3 packets that are authenticated by IPsec
+      |  could be impossible on some routers that are unable to parse
+      |  the IPsec ESP or AH extension headers during ACL
+      |  classification.
+
+   Rate-limiting of the valid packets should be done; see [RFC8541] for
+   a side benefit for OSPv3.  The exact configuration will depend on the
+   available resources of the router (CPU, Ternary Content-Addressable
+   Memory (TCAM), etc.).
+
+2.4.2.  Management Protocols
+
+   This class includes SSH, SNMP, RESTCONF, NETCONF, gRPC Remote
+   Procedure Calls (gRPC), syslog, NTP, etc.
+
+   An ingress ACL to be applied on all the router interfaces (or at
+   ingress interfaces of the security perimeter or by using specific
+   features of the platform) should be configured for packets destined
+   to the RP, such as:
+
+   *  drop packets destined to the routers, except those belonging to
+      protocols that are used (for example, permit TCP 22 and drop all
+      others when only SSH is used) and
+
+   *  drop packets where the source does not match the security policy
+      (for example, if SSH connections should only be originated from
+      the Network Operation Center (NOC), then the ACL should permit TCP
+      port 22 packets only from the NOC prefix).
+
+   Rate-limiting of valid packets should be done.  The exact
+   configuration will depend on the available router resources.
+
+2.4.3.  Packet Exceptions
+
+   This class covers multiple cases where a data plane packet is punted
+   to the route processor because it requires specific processing:
+
+   *  generation of an ICMP packet-too-big message when a data plane
+      packet cannot be forwarded because it is too large (required to
+      discover the Path MTU);
+
+   *  generation of an ICMP hop-limit-expired message when a data plane
+      packet cannot be forwarded because its hop-limit field has reached
+      0 (also used by the traceroute utility);
+
+   *  generation of an ICMP destination-unreachable message when a data
+      plane packet cannot be forwarded for any reason;
+
+   *  processing of the hop-by-hop options header; new implementations
+      follow Section 4.3 of [RFC8200] where this processing is optional;
+      or
+
+   *  more specific to some router implementations, an oversized
+      extension header chain that cannot be processed by the hardware
+      and cannot force the packet to be punted to the RP.
+
+   On some routers, not everything can be done by the specialized data
+   plane hardware that requires some packets to be 'punted' to the
+   generic RP.  This could include, for example, the processing of a
+   long extension header chain in order to apply an ACL based on Layer 4
+   information.  [RFC6980] and more generally [RFC7112] highlight the
+   security implications of oversized extension header chains on routers
+   and update the original IPv6 specifications [RFC2460] such that the
+   first fragment of a packet is required to contain the entire IPv6
+   header chain.  Those changes are incorporated in the IPv6 standard
+   [RFC8200].
+
+   An ingress ACL cannot mitigate a control plane attack using these
+   packet exceptions.  The only protection for the RP is to rate-limit
+   those packet exceptions that are forwarded to the RP.  This means
+   that some data plane packets will be dropped without an ICMP message
+   sent to the source, which may delay Path MTU Discovery and cause
+   drops.
+
+   In addition to limiting the rate of data plane packets queued to the
+   RP, it is also important to rate-limit the generation of ICMP
+   messages.  This is important both to preserve RP resources and also
+   to prevent an amplification attack using the router as a reflector.
+   It is worth noting that some platforms implement this rate-limiting
+   in hardware.  Of course, a consequence of not generating an ICMP
+   message will break some IPv6 mechanisms, such as Path MTU Discovery
+   or a simple traceroute.
+
+2.5.  Routing Security
+
+      |  Preamble: IPv6 routing security is congruent with IPv4 routing
+      |  security, with the exception of OSPv3 neighbor authentication
+      |  (see Section 2.5.2).
+
+   Routing security in general can be broadly divided into three
+   sections:
+
+   1.  authenticating neighbors/peers
+
+   2.  securing routing updates between peers
+
+   3.  route filtering
+
+   [RFC5082] is also applicable to IPv6 and can ensure that routing
+   protocol packets are coming from the local network; it must also be
+   noted that in IPv6 all interior gateway protocols use link-local
+   addresses.
+
+   As for IPv4, it is recommended to enable a routing protocol only on
+   interfaces where it is required.
+
+2.5.1.  BGP Security
+
+   As BGP is identical for IPv4 and IPv6 and as [RFC7454] covers all the
+   security aspects for BGP in detail, [RFC7454] is also applicable to
+   IPv6.
+
+2.5.2.  Authenticating OSPFv3 Neighbors
+
+   OSPFv3 can rely on IPsec to fulfill the authentication function.
+   Operators should note that IPsec support is not standard on all
+   routing platforms.  In some cases, this requires specialized hardware
+   that offloads crypto over to dedicated Application-Specific
+   Integrated Circuits (ASICs) or enhanced software images (both of
+   which often come with added financial cost) to provide such
+   functionality.  An added detail is to determine whether OSPFv3 IPsec
+   implementations use AH or ESP-NULL for integrity protection.  In
+   early implementations, all OSPFv3 IPsec configurations relied on AH
+   since the details weren't specified in [RFC5340].  However, the
+   document that specifically describes how IPsec should be implemented
+   for OSPFv3 [RFC4552] states that "implementations MUST support ESP[-
+   NULL] and MAY support AH" since it follows the overall IPsec
+   standards wording.  OSPFv3 can also use normal ESP to encrypt the
+   OSPFv3 payload to provide confidentiality for the routing
+   information.
+
+   [RFC7166] changes OSPFv3 reliance on IPsec by appending an
+   authentication trailer to the end of the OSPFv3 packets.  It does not
+   authenticate the specific originator of an OSPFv3 packet; rather, it
+   allows a router to confirm that the packet has been issued by a
+   router that had access to the shared authentication key.
+
+   With all authentication mechanisms, operators should confirm that
+   implementations can support rekeying mechanisms that do not cause
+   outages.  There have been instances where any rekeying causes
+   outages; therefore, the trade-off between utilizing this
+   functionality needs to be weighed against the protection it provides.
+   [RFC4107] documents some guidelines for crypto keys management.
+
+2.5.3.  Securing Routing Updates
+
+   IPv6 initially mandated the provisioning of IPsec capability in all
+   nodes.  However, in the updated IPv6 Nodes Requirement standard
+   [RFC8504], IPsec is a 'SHOULD' and not a 'MUST' implementation.
+   Theoretically, it is possible that all communication between two IPv6
+   nodes, especially routers exchanging routing information, is
+   encrypted using IPsec.  However, in practice, deploying IPsec is not
+   always feasible given hardware and software limitations of the
+   various platforms deployed.
+
+   Many routing protocols support the use of cryptography to protect the
+   routing updates; the use of this protection is recommended.
+   [RFC8177] is a YANG data model for key chains that includes rekeying
+   functionality.
+
+2.5.4.  Route Filtering
+
+   Route filtering policies will be different depending on whether they
+   pertain to edge route filtering or internal route filtering.  At a
+   minimum, the IPv6 routing policy, as it pertains to routing between
+   different administrative domains, should aim to maintain parity with
+   IPv4 from a policy perspective, for example:
+
+   *  filter internal-use IPv6 addresses that are not globally routable
+      at the perimeter;
+
+   *  discard routes for bogon [CYMRU] and reserved space (see
+      [RFC8190]); and
+
+   *  configure ingress route filters that validate route origin, prefix
+      ownership, etc., through the use of various routing databases,
+      e.g., [RADB].  [RFC8210] formally validates the origin Autonomous
+      Systems (ASes) of BGP announcements.
+
+   Some good guidance can be found at [RFC7454].
+
+   A valid routing table can also be used to apply network ingress
+   filtering (see [RFC2827]).
+
+2.6.  Logging/Monitoring
+
+   In order to perform forensic research in the cases of a security
+   incident or detecting abnormal behavior, network operators should log
+   multiple pieces of information.  In some cases, this requires a
+   frequent poll of devices via a Network Management Station.
+
+   This logging should include but is not limited to:
+
+   *  logs of all applications using the network (including user space
+      and kernel space) when available (for example, web servers that
+      the network operator manages);
+
+   *  data from IP Flow Information Export [RFC7011], also known as
+      IPFIX;
+
+   *  data from various SNMP MIBs [RFC4293] or YANG data via RESTCONF
+      [RFC8040] or NETCONF [RFC6241];
+
+   *  historical data of Neighbor Cache entries;
+
+   *  stateful DHCPv6 [RFC8415] lease cache, especially when a relay
+      agent [RFC6221] is used;
+
+   *  Source Address Validation Improvement (SAVI) [RFC7039] events,
+      especially the binding of an IPv6 address to a MAC address and a
+      specific switch or router interface;
+
+   *  firewall ACL logs;
+
+   *  authentication server logs; and
+
+   *  RADIUS [RFC2866] accounting records.
+
+   Please note that there are privacy issues or regulations related to
+   how these logs are collected, stored, used, and safely discarded.
+   Operators are urged to check their country legislation (e.g., General
+   Data Protection Regulation [GDPR] in the European Union).
+
+   All those pieces of information can be used for:
+
+   *  forensic (Section 2.6.2.1) investigations: who did what and when?
+
+   *  correlation (Section 2.6.2.3): which IP addresses were used by a
+      specific node (assuming the use of privacy extensions addresses
+      [RFC8981])?
+
+   *  inventory (Section 2.6.2.2): which IPv6 nodes are on my network?
+
+   *  abnormal behavior detection (Section 2.6.2.4): unusual traffic
+      patterns are often the symptoms of an abnormal behavior, which is
+      in turn a potential attack (denial of service, network scan, a
+      node being part of a botnet, etc.).
+
+2.6.1.  Data Sources
+
+   This section lists the most important sources of data that are useful
+   for operational security.
+
+2.6.1.1.  Application Logs
+
+   Those logs are usually text files where the remote IPv6 address is
+   stored in cleartext (not binary).  This can complicate the processing
+   since one IPv6 address, for example, 2001:db8::1, can be written in
+   multiple ways, such as:
+
+   *  2001:DB8::1 (in uppercase),
+
+   *  2001:0db8::0001 (with leading 0), and
+
+   *  many other ways, including the reverse DNS mapping into a Fully
+      Qualified Domain Name (FQDN) (which should not be trusted).
+
+   [RFC5952] explains this problem in detail and recommends the use of a
+   single canonical format.  This document recommends the use of
+   canonical format [RFC5952] for IPv6 addresses in all possible cases.
+   If the existing application cannot log using the canonical format,
+   then it is recommended to use an external post-processing program in
+   order to canonicalize all IPv6 addresses.
+
+2.6.1.2.  IP Flow Information Export by IPv6 Routers
+
+   IPFIX [RFC7012] defines some data elements that are useful for
+   security:
+
+   *  nextHeaderIPv6, sourceIPv6Address, and destinationIPv6Address
+
+   *  sourceMacAddress and destinationMacAddress
+
+   The IP version is the ipVersion element defined in [IANA-IPFIX].
+
+   Moreover, IPFIX is very efficient in terms of data handling and
+   transport.  It can also aggregate flows by a key, such as
+   sourceMacAddress, in order to have aggregated data associated with a
+   specific sourceMacAddress.  This memo recommends the use of IPFIX and
+   aggregation on nextHeaderIPv6, sourceIPv6Address, and
+   sourceMacAddress.
+
+2.6.1.3.  SNMP MIB and NETCONF/RESTCONF YANG Modules Data by IPv6
+          Routers
+
+   [RFC4293] defines a Management Information Base (MIB) for the two
+   address families of IP.  This memo recommends the use of:
+
+   *  ipIfStatsTable table, which collects traffic counters per
+      interface, and
+
+   *  ipNetToPhysicalTable table, which is the content of the Neighbor
+      Cache, i.e., the mapping between IPv6 and data-link layer
+      addresses.
+
+   There are also YANG modules relating to the two IP address families
+   and that can be used with [RFC6241] and [RFC8040].  This memo
+   recommends the use of:
+
+   *  interfaces-state/interface/statistics from
+      ietf-interfaces@2018-02-20.yang [RFC8343], which contains counters
+      for interfaces, and
+
+   *  ipv6/neighbor from ietf-ip@2018-02-22.yang [RFC8344], which is the
+      content of the Neighbor Cache, i.e., the mapping between IPv6 and
+      data-link layer addresses.
+
+2.6.1.4.  Neighbor Cache of IPv6 Routers
+
+   The Neighbor Cache of routers contains all mappings between IPv6
+   addresses and data-link layer addresses.  There are multiple ways to
+   collect the current entries in the Neighbor Cache, notably, but not
+   limited to:
+
+   *  using the SNMP MIB (Section 2.6.1.3), as explained above;
+
+   *  using streaming telemetry or NETCONF [RFC6241] and RESTCONF
+      [RFC8040] to collect the operational state of the Neighbor Cache;
+      and
+
+   *  connecting over a secure management channel (such as SSH) and
+      explicitly requesting a Neighbor Cache dump via the Command-Line
+      Interface (CLI) or another monitoring mechanism.
+
+   The Neighbor Cache is highly dynamic, as mappings are added when a
+   new IPv6 address appears on the network.  This could be quite
+   frequently with privacy extension addresses [RFC8981] or when they
+   are removed when the state goes from UNREACH to removed (the default
+   time for a removal per Neighbor Unreachability Detection [RFC4861]
+   algorithm is 38 seconds for a host using Windows 7).  This means that
+   the content of the Neighbor Cache must be fetched periodically at an
+   interval that does not exhaust the router resources 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.
+
+   This is an important source of information because it is trivial (on
+   a switch not using the SAVI [RFC7039] algorithm) to defeat the
+   mapping between data-link layer address and an IPv6 address.  Put
+   another way, having access to the current and past content of the
+   Neighbor Cache has a paramount value for the forensic and audit
+   trails.  It should also be noted that, in certain threat models, this
+   information is also deemed valuable and could itself be a target.
+
+   When using one /64 per host (Section 2.1.8) or DHCP-PD, it is
+   sufficient to keep the history of the allocated prefixes when
+   combined with strict source address prefix enforcement on the routers
+   and L2 switches to prevent IPv6 spoofing.
+
+2.6.1.5.  Stateful DHCPv6 Lease
+
+   In some networks, IPv6 addresses/prefixes are managed by a stateful
+   DHCPv6 server [RFC8415] that leases IPv6 addresses/prefixes to
+   clients.  It is indeed quite similar to DHCP for IPv4, so it can be
+   tempting to use this DHCP lease file to discover the mapping between
+   IPv6 addresses/prefixes and data-link layer addresses, as is commonly
+   used in IPv4 networking.
+
+   It is not so easy in the IPv6 networks, because not all nodes will
+   use DHCPv6 (there are nodes that can only do stateless
+   autoconfiguration) and also because DHCPv6 clients are identified not
+   by their hardware-client address, as in IPv4, but by a DHCP Unique
+   Identifier (DUID).  The DUID can have several formats: the data-link
+   layer address, the data-link layer address prepended with time
+   information, or even an opaque number that requires correlation with
+   another data source to be usable for operational security.  Moreover,
+   when the DUID is based on the data-link address, this address can be
+   of any client interface (such as the wireless interface, while the
+   client actually uses its wired interface to connect to the network).
+
+   If a lightweight DHCP relay agent [RFC6221] 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 leased IPv6 address.  Also, if a 'normal'
+   (not lightweight) relay agent adds the data-link layer address in the
+   option for Relay Agent Remote-ID [RFC4649] [RFC6939], then the DHCPv6
+   server can keep track of the data-link and leased IPv6 addresses.
+
+   In short, the DHCPv6 lease file is less interesting than lease files
+   for IPv4 networks.  If possible, it is recommended to use DHCPv6
+   servers that keep the relayed data-link layer address in addition to
+   the DUID in the lease file, as those servers have the equivalent
+   information to IPv4 DHCP servers.
+
+   The mapping between the data-link layer address and the IPv6 address
+   can be secured by deploying switches implementing the SAVI [RFC7513]
+   mechanisms.  Of course, this also requires that the data-link layer
+   address be protected by using a L2 mechanism, such as [IEEE-802.1X].
+
+2.6.1.6.  RADIUS Accounting Log
+
+   For interfaces where the user is authenticated via a RADIUS [RFC2866]
+   server, and if RADIUS accounting is enabled, then the RADIUS server
+   receives accounting Acct-Status-Type records at the start and at the
+   end of the connection, which include all IPv6 (and IPv4) addresses
+   used by the user.  This technique can be used notably for Wi-Fi
+   networks with Wi-Fi Protected Access (WPA) or other IEEE 802.1X
+   [IEEE-802.1X] wired interfaces on an Ethernet switch.
+
+2.6.1.7.  Other Data Sources
+
+   There are other data sources for log information that must be
+   collected (as currently collected in IPv4 networks):
+
+   *  historical mappings of IPv6 addresses to users of remote access
+      VPN and
+
+   *  historical mappings of MAC addresses to switch ports in a wired
+      network.
+
+2.6.2.  Use of Collected Data
+
+   This section leverages the data collected, as described in
+   Section 2.6.1, in order to achieve several security benefits.
+   Section 9.1 of [RFC7934] contains more details about host tracking.
+
+2.6.2.1.  Forensic and User Accountability
+
+   The forensic use case is when the network operator must locate an
+   IPv6 address (and the associated port, access point/switch, or VPN
+   tunnel) that was present in the network at a certain time or is
+   currently in the network.
+
+   To locate an IPv6 address in an enterprise network where the operator
+   has control over all resources, the source of information can be the
+   Neighbor Cache, or, if not found, the DHCP lease file.  Then, the
+   procedure is:
+
+   1.  based on the IPv6 prefix of the IPv6 address; find one or more
+       routers that are used to reach this prefix (assuming that anti-
+       spoofing mechanisms are used), perhaps based on an IPAM.
+
+   2.  based on this limited set of routers, on the incident time, and
+       on the IPv6 address; retrieve the data-link address from the live
+       Neighbor Cache, from the historical Neighbor Cache data, or from
+       SAVI events, or retrieve the data-link address from the DHCP
+       lease file (Section 2.6.1.5).
+
+   3.  based on the data-link layer address; look up the switch
+       interface associated with the data-link layer address.  In the
+       case of wireless LAN with RADIUS accounting (see
+       Section 2.6.1.6), the RADIUS log has the mapping between the user
+       identification and the MAC address.  If a Configuration
+       Management Database (CMDB) is used, then it can be used to map
+       the data-link layer address to a switch port.
+
+   At the end of the process, the interface of the host originating or
+   the subscriber identity associated with the activity in question has
+   been determined.
+
+   To identify the subscriber of an IPv6 address in a residential
+   Internet Service Provider, the starting point is the DHCP-PD leased
+   prefix covering the IPv6 address; this prefix can often be linked to
+   a subscriber via the RADIUS log.  Alternatively, the Forwarding
+   Information Base (FIB) of the Cable Modem Termination System (CMTS)
+   or Broadband Network Gateway (BNG) indicates the Customer Premises
+   Equipment (CPE) of the subscriber and the RADIUS log can be used to
+   retrieve the actual subscriber.
+
+   More generally, a mix of the above techniques can be used in most, if
+   not all, networks.
+
+2.6.2.2.  Inventory
+
+   [RFC7707] describes the difficulties for an attacker to scan an IPv6
+   network due to the vast number of IPv6 addresses per link (and why in
+   some cases it can still be done).  While the huge addressing space
+   can sometimes be perceived as a 'protection', it also makes the
+   inventory task difficult in an IPv6 network while it was trivial to
+   do in an IPv4 network (a simple enumeration of all IPv4 addresses,
+   followed by a ping and a TCP/UDP port scan).  Getting an inventory of
+   all connected devices is of prime importance for a secure network
+   operation.
+
+   There are many ways to do an inventory of an IPv6 network.
+
+   The first technique is to use passive inspection, such as IPFIX.
+   Using exported IPFIX information and extracting the list of all IPv6
+   source addresses allows finding all IPv6 nodes that sent packets
+   through a router.  This is very efficient but, alas, will not
+   discover silent nodes that never transmitted packets traversing the
+   IPFIX target router.  Also, it must be noted that link-local
+   addresses will never be discovered by this means.
+
+   The second way is again to use the collected Neighbor Cache content
+   to find all IPv6 addresses in the cache.  This process will also
+   discover all link-local addresses.  See Section 2.6.1.4.
+
+   Another way that works only for a local network consists of sending
+   an ICMP ECHO_REQUEST to the link-local multicast address ff02::1,
+   which addresses all IPv6 nodes on the network.  All nodes should
+   reply to this ECHO_REQUEST, per [RFC4443].
+
+   Other techniques involve obtaining data from DNS, parsing log files,
+   and leveraging service discovery, such as mDNS [RFC6762] [RFC6763].
+
+   Enumerating DNS zones, especially looking at reverse DNS records and
+   CNAMEs, is another common method employed by various tools.  As
+   already mentioned in [RFC7707], this allows an attacker to prune the
+   IPv6 reverse DNS tree and hence enumerate it in a feasible time.
+   Furthermore, authoritative servers that allow zone transfers (i.e.,
+   Authoritative Transfers (AXFRs)) may be a further information source.
+   An interesting research paper has analyzed the entropy in various
+   IPv6 addresses: see [ENTROPYIP].
+
+2.6.2.3.  Correlation
+
+   In an IPv4 network, it is easy to correlate multiple logs, for
+   example, to find events related to a specific IPv4 address.  A simple
+   Unix grep command is enough to scan through multiple text-based files
+   and extract all lines relevant to a specific IPv4 address.
+
+   In an IPv6 network, this is slightly more difficult because different
+   character strings can express the same IPv6 address.  Therefore, the
+   simple Unix grep command cannot be used.  Moreover, an IPv6 node can
+   have multiple IPv6 addresses.
+
+   In order to do correlation in IPv6-related logs, it is advised to
+   have all logs in a format with only canonical IPv6 addresses
+   [RFC5952].  Then, the current (or historical) Neighbor Cache data set
+   must be searched to find the data-link layer 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 set.  The last step is to
+   search in all log files (containing only IPv6 addresses in canonical
+   format) for any IPv6 addresses in the search set.
+
+   Moreover, [RFC7934] recommends using multiple IPv6 addresses per
+   prefix, so the correlation must also be done among those multiple
+   IPv6 addresses, for example, by discovering all IPv6 addresses
+   associated with the same MAC address and interface in the NDP cache
+   (Section 2.6.1.4).
+
+2.6.2.4.  Abnormal Behavior Detection
+
+   Abnormal behavior (such as network scanning, spamming, DoS) can be
+   detected in the same way as in an IPv4 network:
+
+   *  a sudden increase of traffic detected by interface counter (SNMP)
+      or by aggregated traffic from IPFIX records [RFC7012],
+
+   *  rapid growth of ND cache size, or
+
+   *  change in traffic pattern (number of connections per second,
+      number of connections per host, etc.) observed with the use of
+      IPFIX [RFC7012].
+
+2.6.3.  Summary
+
+   While some data sources (IPFIX, MIB, switch Content Addressable
+   Memory (CAM) tables, logs, etc.) used in IPv4 are also used in the
+   secure operation of an IPv6 network, the DHCPv6 lease file is less
+   reliable and the Neighbor Cache is of prime importance.
+
+   The fact that there are multiple ways to express the same IPv6
+   address in a character string renders the use of filters mandatory
+   when correlation must be done.
+
+2.7.  Transition/Coexistence Technologies
+
+   As it is expected that some networks will not run in a pure IPv6-only
+   mode, the different transition mechanisms must be deployed and
+   operated in a secure way.  This section proposes operational
+   guidelines for the most-known and deployed transition techniques.
+   [RFC4942] also contains security considerations for transition or
+   coexistence scenarios.
+
+2.7.1.  Dual Stack
+
+   Dual stack is often the first deployment choice for network
+   operators.  Dual stacking the network offers some advantages over
+   other transition mechanisms.  Firstly, the impact on existing IPv4
+   operations is reduced.  Secondly, in the absence of tunnels or
+   address translation, the IPv4 and IPv6 traffic are native (easier to
+   observe and secure) and should have the same network processing
+   (network path, quality of service, etc.).  Dual stack enables a
+   gradual termination of the IPv4 operations when the IPv6 network is
+   ready for prime time.  On the other hand, the operators have to
+   manage two network stacks with the added complexities.
+
+   From an operational security perspective, this now means that the
+   network operator has twice the exposure.  One needs to think about
+   protecting both protocols now.  At a minimum, the IPv6 portion of a
+   dual-stacked network should be consistent with IPv4 from a security
+   policy point of view.  Typically, the following methods are employed
+   to protect IPv4 networks at the edge or security perimeter:
+
+   *  ACLs to permit or deny traffic,
+
+   *  firewalls with stateful packet inspection, and
+
+   *  application firewalls inspecting the application flows.
+
+   It is recommended that these ACLs and/or firewalls be additionally
+   configured to protect IPv6 communications.  The enforced IPv6
+   security must be congruent with the IPv4 security policy; otherwise,
+   the attacker will use the protocol version that has the more relaxed
+   security policy.  Maintaining the congruence between security
+   policies can be challenging (especially over time); it is recommended
+   to use a firewall or an ACL manager that is dual stack, i.e., a
+   system that can apply a single ACL entry to a mixed group of IPv4 and
+   IPv6 addresses.
+
+   Application firewalls work at the application layer and are oblivious
+   to the IP version, i.e., they work as well for IPv6 as for IPv4 and
+   the same application security policy will work for both protocol
+   versions.
+
+   Also, given the end-to-end connectivity that IPv6 provides, it is
+   recommended that hosts be fortified against threats.  General device
+   hardening guidelines are provided in Section 2.8.
+
+   For many years, all host operating systems have IPv6 enabled by
+   default, so it is possible even in an 'IPv4-only' network to attack
+   L2-adjacent victims via their IPv6 link-local address or via a global
+   IPv6 address when the attacker provides rogue RAs or a rogue DHCPv6
+   service.
+
+   [RFC7123] discusses the security implications of native IPv6 support
+   and IPv6 transition/coexistence technologies on 'IPv4-only' networks
+   and describes possible mitigations for the aforementioned issues.
+
+2.7.2.  Encapsulation Mechanisms
+
+   There are many tunnels used for specific use cases.  Except when
+   protected by IPsec [RFC4301] or alternative tunnel encryption
+   methods, all those tunnels have a number of security issues, as
+   described in [RFC6169]:
+
+   tunnel injection:
+      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 accepted by the destination tunnel
+      endpoint.  This is a specific case of spoofing.
+
+   traffic interception:
+      No confidentiality is provided by the tunnel protocols (without
+      the use of IPsec or alternative encryption methods); therefore,
+      anybody on the tunnel path can intercept the traffic and have
+      access to the cleartext IPv6 packet.  Combined with the absence of
+      authentication, an on-path attack can also be mounted.
+
+   service theft:
+      As there is no authorization, even an unauthorized user can use a
+      tunnel relay for free (this is a specific case of tunnel
+      injection).
+
+   reflection attack:
+      Another specific use case of tunnel injection where the attacker
+      injects packets with an IPv4 destination address not matching the
+      IPv6 address causing the first tunnel endpoint to re-encapsulate
+      the packet to the destination.  Hence, the final IPv4 destination
+      will not see the original IPv4 address but only the IPv4 address
+      of the relay router.
+
+   bypassing security policy:
+      If a firewall or an Intrusion Prevention System (IPS) is on the
+      path of the tunnel, then it may neither inspect nor detect
+      malevolent IPv6 traffic transmitted over the tunnel.
+
+   To mitigate the bypassing of security policies, it is often
+   recommended to block all automatic tunnels in default OS
+   configuration (if they are not required) by denying IPv4 packets
+   matching:
+
+   IP protocol 41:  This will block Intra-Site Automatic Tunnel
+      Addressing Protocol (ISATAP) (Section 2.7.2.2), 6to4
+      (Section 2.7.2.7), 6rd (Section 2.7.2.3), and 6in4
+      (Section 2.7.2.1) tunnels.
+
+   IP protocol 47:  This will block GRE (Section 2.7.2.1) tunnels.
+
+   UDP port 3544:  This will block the default encapsulation of Teredo
+      (Section 2.7.2.8) tunnels.
+
+   Ingress filtering [RFC2827] should also be applied on all tunnel
+   endpoints, if applicable, to prevent IPv6 address spoofing.
+
+   The reflection attack cited above should also be prevented by using
+   an IPv6 ACL preventing the hair pinning of the traffic.
+
+   As several of the tunnel techniques share the same encapsulation
+   (i.e., IPv4 protocol 41) and embed the IPv4 address in the IPv6
+   address, there are a set of well-known looping attacks described in
+   [RFC6324].  This RFC also proposes mitigation techniques.
+
+2.7.2.1.  Site-to-Site Static Tunnels
+
+   Site-to-site static tunnels are described in [RFC2529] and in GRE
+   [RFC2784].  As the IPv4 endpoints are statically configured and are
+   not dynamic, they are slightly more secure (bidirectional service
+   theft is mostly impossible), but traffic interception and tunnel
+   injection are still possible.  Therefore, the use of IPsec [RFC4301]
+   in transport mode to protect the encapsulated IPv4 packets is
+   recommended for those tunnels.  Alternatively, IPsec in tunnel mode
+   can be used to transport IPv6 traffic over an untrusted IPv4 network.
+
+2.7.2.2.  ISATAP
+
+   ISATAP tunnels [RFC5214] are mainly used within a single
+   administrative domain and to connect a single IPv6 host to the IPv6
+   network.  This often implies that those systems are usually managed
+   by a single entity; therefore, audit trail and strict anti-spoofing
+   are usually possible, and this raises the overall security.  Even if
+   ISATAP is no more often used, its security issues are relevant, per
+   [KRISTOFF].
+
+   Special care must be taken to avoid a looping attack by implementing
+   the measures of [RFC6324] and [RFC6964] (especially in Section 3.6).
+
+   IPsec [RFC4301] in transport or tunnel mode can be used to secure the
+   IPv4 ISATAP traffic to provide IPv6 traffic confidentiality and
+   prevent service theft.
+
+2.7.2.3.  6rd
+
+   While 6rd tunnels share the same encapsulation as 6to4 tunnels
+   (Section 2.7.2.7), 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 41 filtering at the edge)
+   than 6to4 tunnels and have few security issues other than lack of
+   confidentiality.  The security considerations in Section 12 of
+   [RFC5969] describes how to secure 6rd tunnels.
+
+   IPsec [RFC4301] for the transported IPv6 traffic can be used if
+   confidentiality is important.
+
+2.7.2.4.  6PE, 6VPE, and LDPv6
+
+   Organizations using MPLS in their core can also use IPv6 Provider
+   Edge (6PE) [RFC4798] and IPv6 Virtual Private Extension (6VPE)
+   [RFC4659] to enable IPv6 access over MPLS.  As 6PE and 6VPE are
+   really similar to BGP/MPLS IP VPNs described in [RFC4364], the
+   security properties of these networks are also similar to those
+   described in [RFC4381] (please note 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 RFC for any
+   purpose).  They rely on:
+
+   *  address space, routing, and traffic separation with the help of
+      VRFs (only applicable to 6VPE);
+
+   *  hiding the IPv4 core, hence, removing all attacks against
+      P-routers; and
+
+   *  securing the routing protocol between Customer Edge (CE) and
+      Provider Edge (PE); in the case of 6PE and 6VPE, link-local
+      addresses (see [RFC7404]) can be used, and, as these addresses
+      cannot be reached from outside of the link, the security of 6PE
+      and 6VPE is even higher than an IPv4 BGP/MPLS IP VPN.
+
+   LDPv6 itself does not induce new risks; see [RFC7552].
+
+2.7.2.5.  DS-Lite
+
+   Dual-Stack Lite (DS-Lite) is also a translation mechanism and is
+   therefore analyzed further (Section 2.7.3.3) in this document, as it
+   includes IPv4 NAPT.
+
+2.7.2.6.  Mapping of Address and Port
+
+   With the encapsulation and translation versions of Mapping of Address
+   and Port (MAP) -- abbreviated MAP-E [RFC7597] and MAP-T [RFC7599] --
+   the access 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.  The subscriber router does stateful
+   operations in order to map all internal IPv4 addresses and Layer 4
+   ports to the IPv4 address and the set of Layer 4 ports received
+   through the MAP configuration process.  The SP equipment always does
+   stateless operations (either decapsulation or stateless translation).
+   Therefore, as opposed to Section 2.7.3.3, there is no state
+   exhaustion DoS attack against the SP equipment because there is no
+   state and there is no operation caused by a new Layer 4 connection
+   (no logging operation).
+
+   The SP MAP equipment should implement all the security considerations
+   of [RFC7597], notably ensuring that the mapping of the IPv4 address
+   and port are consistent with the configuration.  As MAP has a
+   predictable IPv4 address and port mapping, the audit logs are easier
+   to use, as there is a clear mapping between the IPv6 address and the
+   IPv4 address and ports.
+
+2.7.2.7.  6to4
+
+   In [RFC3056], 6to4 tunnels require a public-routable IPv4 address in
+   order to work correctly.  They can be used to provide either single
+   IPv6 host connectivity to the IPv6 Internet or multiple IPv6 networks
+   connectivity to the IPv6 Internet.  The 6to4 relay was historically
+   the anycast address defined in [RFC3068], which has been deprecated
+   by [RFC7526] and is no longer used by recent Operating Systems.  Some
+   security considerations are explained in [RFC3964].
+
+   [RFC6343] points out that if an operator provides well-managed
+   servers and relays for 6to4, nonencapsulated IPv6 packets will pass
+   through well-defined points (the native IPv6 interfaces of those
+   servers and relays) at which security mechanisms may be applied.
+   Client usage of 6to4 by default is now discouraged, and significant
+   precautions are needed to avoid operational problems.
+
+2.7.2.8.  Teredo
+
+   Teredo tunnels [RFC4380] are mainly used in a residential environment
+   because Teredo easily traverses an IPv4 NAPT device thanks to its UDP
+   encapsulation.  Teredo tunnels connect a single host to the IPv6
+   Internet.  Teredo shares the same issues as other tunnels: no
+   authentication, no confidentiality, possible spoofing, and reflection
+   attacks.
+
+   IPsec [RFC4301] for the transported IPv6 traffic is recommended.
+
+   The biggest threat to Teredo is probably for an IPv4-only network, as
+   Teredo has been designed to easily traverse IPv4 NAT-PT devices,
+   which are quite often co-located with a stateful firewall.
+   Therefore, if the stateful IPv4 firewall allows unrestricted UDP
+   outbound and accepts the return UDP traffic, then Teredo actually
+   punches a hole in this firewall for all IPv6 traffic to and from the
+   Internet.  Host policies can be deployed to block Teredo in an
+   IPv4-only network in order to avoid this firewall bypass.  On the
+   IPv4 firewall, all outbound UDPs should be blocked except for the
+   commonly used services (e.g., port 53 for DNS, port 123 for NTP, port
+   443 for QUIC, port 500 for Internet Key Exchange Protocol (IKE), port
+   3478 for Session Traversal Utilities for NAT (STUN), etc.).
+
+   Teredo is now hardly ever used and no longer enabled by default in
+   most environments so it is less of a threat; however, special
+   consideration must be made in cases when devices with older or
+   operating systems that have not been updated may be present and by
+   default were running Teredo.
+
+2.7.3.  Translation Mechanisms
+
+   Translation mechanisms between IPv4 and IPv6 networks are alternate
+   coexistence strategies while networks transition to IPv6.  While a
+   framework is described in [RFC6144], the specific security
+   considerations are documented with each individual mechanism.  For
+   the most part, they specifically mention interference with IPsec or
+   DNSSEC deployments, how to mitigate spoofed traffic, and what some
+   effective filtering strategies may be.
+
+   While not really a transition mechanism to IPv6, this section also
+   includes the discussion about the use of heavy IPv4-to-IPv4 network
+   addresses and port translation to prolong the life of IPv4-only
+   networks.
+
+2.7.3.1.  Carrier-Grade NAT (CGN)
+
+   Carrier-Grade NAT (CGN), also called NAT444 CGN or Large-Scale NAT
+   (LSN) or SP NAT, is described in [RFC6264] and is utilized as an
+   interim measure to extend the use of IPv4 in a large service provider
+   network until the provider can deploy an effective IPv6 solution.
+   [RFC6598] requested a specific IANA-allocated /10 IPv4 address block
+   to be used as address space shared by all access networks using CGN.
+   This has been allocated as 100.64.0.0/10.
+
+   Section 13 of [RFC6269] lists some specific security-related issues
+   caused by large-scale address sharing.  The Security Considerations
+   section of [RFC6598] also lists some specific mitigation techniques
+   for potential misuse of shared address space.  Some law enforcement
+   agencies have identified CGN as impeding their cybercrime
+   investigations (for example, see the Europol press release on CGN
+   [europol-cgn]).  Many translation techniques (NAT64, DS-Lite, etc.)
+   have the same security issues as CGN when one part of the connection
+   is IPv4 only.
+
+   [RFC6302] has recommendations for Internet-facing servers to also log
+   the source TCP or UDP ports of incoming connections in an attempt to
+   help identify the users behind such a CGN.
+
+   [RFC7422] suggests the use of deterministic address mapping in order
+   to reduce logging requirements for CGN.  The idea is to have a known
+   algorithm for mapping the internal subscriber to/from public TCP and
+   UDP ports.
+
+   [RFC6888] lists common requirements for CGNs.  [RFC6967] analyzes
+   some solutions to enforce policies on misbehaving nodes when address
+   sharing is used.  [RFC7857] also updates the NAT behavioral
+   requirements.
+
+2.7.3.2.  NAT64/DNS64 and 464XLAT
+
+   Stateful NAT64 translation [RFC6146] allows IPv6-only clients to
+   contact IPv4 servers using unicast UDP, TCP, or ICMP.  It can be used
+   in conjunction with DNS64 [RFC6147], a mechanism that synthesizes
+   AAAA records from existing A records.  There is also a stateless
+   NAT64 [RFC7915], which has similar security aspects but with the
+   added benefit of being stateless and is thereby less prone to a state
+   exhaustion attack.
+
+   The Security Consideration sections of [RFC6146] and [RFC6147] list
+   the comprehensive issues; in Section 8 of [RFC6147], there are some
+   considerations on the interaction between NAT64 and DNSSEC.  A
+   specific issue with the use of NAT64 is that it will interfere with
+   most IPsec deployments unless UDP encapsulation is used.
+
+   Another translation mechanism relying on a combination of stateful
+   and stateless translation, 464XLAT [RFC6877], can be used to do a
+   host-local translation from IPv4 to IPv6 and a network provider
+   translation from IPv6 to IPv4, i.e., giving IPv4-only application
+   access to an IPv4-only server over an IPv6-only network. 464XLAT
+   shares the same security considerations as NAT64 and DNS64; however,
+   it can be used without DNS64, avoiding the DNSSEC implications.
+
+2.7.3.3.  DS-Lite
+
+   Dual-Stack Lite (DS-Lite) [RFC6333] is a transition technique that
+   enables a service provider to share IPv4 addresses among customers by
+   combining two well-known technologies: IP in IP (IPv4-in-IPv6) and
+   IPv4 NAPT.
+
+   Security considerations, with respect to DS-Lite, mainly revolve
+   around logging data, preventing DoS attacks from rogue devices (as
+   the Address Family Translation Router (AFTR) [RFC6333] function is
+   stateful), and restricting service offered by the AFTR only to
+   registered customers.
+
+   Section 11 of [RFC6333] and Section 2 of [RFC7785] describe important
+   security issues associated with this technology.
+
+2.8.  General Device Hardening
+
+   With almost all devices being IPv6 enabled by default and with many
+   endpoints having IPv6 connectivity to the Internet, it is critical to
+   also harden those devices against attacks over IPv6.
+
+   The same techniques used to protect devices against attacks over IPv4
+   should be used for IPv6 and should include but are not limited to:
+
+   *  restricting device access to authorized individuals;
+
+   *  monitoring and auditing access to the device;
+
+   *  turning off any unused services on the end node
+
+   *  understanding which IPv6 addresses are being used to source
+      traffic and changing defaults if necessary;
+
+   *  using cryptographically protected protocols for device management
+      (Secure Copy Protocol (SCP), SNMPv3, SSH, TLS, etc.);
+
+   *  using host firewall capabilities to control traffic that gets
+      processed by upper-layer protocols;
+
+   *  applying firmware, OS, and application patches/upgrades to the
+      devices in a timely manner;
+
+   *  using multifactor credentials to authenticate to devices; and
+
+   *  using virus scanners to detect malicious programs.
+
+3.  Enterprises-Specific Security Considerations
+
+   Enterprises [RFC7381] generally have robust network security policies
+   in place to protect existing IPv4 networks.  These policies have been
+   distilled from years of experiential knowledge of securing IPv4
+   networks.  At the very least, it is recommended that enterprise
+   networks have parity between their security policies for both
+   protocol versions.  This section also applies to the enterprise part
+   of all SP networks, i.e., the part of the network where the SP
+   employees are connected.
+
+   Security considerations in the enterprise can be broadly categorized
+   into two groups: external and internal.
+
+3.1.  External Security Considerations
+
+   The external aspect deals with providing security at the edge or
+   perimeter of the enterprise network where it meets the service
+   provider's network.  This is commonly achieved by enforcing a
+   security policy, either by implementing dedicated firewalls with
+   stateful packet inspection or a router with ACLs.  A common default
+   IPv4 policy on firewalls that could easily be ported to IPv6 is to
+   allow all traffic outbound while only allowing specific traffic, such
+   as established sessions, inbound (see [RFC6092]).  Section 3.2 of
+   [RFC7381] also provides similar recommendations.
+
+   Here are a few more things that could enhance the default policy:
+
+   *  Filter internal-use IPv6 addresses at the perimeter; this will
+      also mitigate the vulnerabilities listed in [RFC7359].
+
+   *  Discard packets from and to bogon and reserved space; see [CYMRU]
+      and [RFC8190].
+
+   *  Accept certain ICMPv6 messages to allow proper operation of ND and
+      Path MTU Discovery (PMTUD); see [RFC4890] or [REY_PF] for hosts.
+
+   *  Based on the use of the network, filter specific extension headers
+      by accepting only the required ones (permit list approach), such
+      as ESP, AH, and not forgetting the required transport layers:
+      ICMP, TCP, UDP, etc.  This filtering should be done where
+      applicable at the edge and possibly inside the perimeter; see
+      [IPV6-EH-FILTERING].
+
+   *  Filter packets having an illegal IPv6 header chain at the
+      perimeter (and, if possible, inside the network as well); see
+      Section 2.2.
+
+   *  Filter unneeded services at the perimeter.
+
+   *  Implement ingress and egress anti-spoofing in the forwarding and
+      control planes; see [RFC2827] and [RFC3704].
+
+   *  Implement appropriate rate-limiters and control plane policers
+      based on traffic baselines.
+
+   Having global IPv6 addresses on all the enterprise sites is different
+   than in IPv4, where [RFC1918] addresses are often used internally and
+   not routed over the Internet.  [RFC7359] and [WEBER_VPN] explain that
+   without careful design, there could be IPv6 leakages from Layer 3
+   VPNs.
+
+3.2.  Internal Security Considerations
+
+   The internal aspect deals with providing security inside the
+   perimeter of the network, including end hosts.  Internal networks of
+   enterprises are often different, e.g., University campus, wireless
+   guest access, etc., so there is no "one size fits all"
+   recommendation.
+
+   The most significant concerns here are related to Neighbor Discovery.
+   At the network level, it is recommended that all security
+   considerations discussed in Section 2.3 be reviewed carefully and the
+   recommendations be considered in-depth as well.  Section 4.1 of
+   [RFC7381] also provides some recommendations.
+
+   As mentioned in Section 2.7.2, care must be taken when running
+   automated IPv6-in-IPv4 tunnels.
+
+   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
+   common use of IPv4 private address space [RFC1918], sites might be
+   able to communicate with each other over the Internet even when the
+   VPN mechanism is not available.  Hence, no traffic encryption is
+   performed and traffic could be injected from the Internet into the
+   site; see [WEBER_VPN].  It is recommended to filter at Internet
+   connection(s) packets having a source or destination address
+   belonging to the site internal prefix or prefixes; this should be
+   done for ingress and egress traffic.
+
+   Hosts need to be hardened directly through security policy to protect
+   against security threats.  The host firewall default capabilities
+   have to be clearly understood.  In some cases, third-party firewalls
+   have no IPv6 support, whereas the native firewall installed by
+   default has IPv6 support.  General device hardening guidelines are
+   provided in Section 2.8.
+
+   It should also be noted that many hosts still use IPv4 for
+   transporting logs for RADIUS, DIAMETER, TACACS+, syslog, etc.
+   Operators cannot rely on an IPv6-only security policy to secure such
+   protocols that are still using IPv4.
+
+4.  Service Provider Security Considerations
+
+4.1.  BGP
+
+   The threats and mitigation techniques are identical between IPv4 and
+   IPv6.  Broadly speaking, they are:
+
+   *  authenticating the TCP session;
+
+   *  TTL security (which becomes hop-limit security in IPv6), as in
+      [RFC5082];
+
+   *  bogon AS filtering; see [CYMRU]; and
+
+   *  prefix filtering.
+
+   These are explained in more detail in Section 2.5.  Also, the
+   recommendations of [RFC7454] should be considered.
+
+4.1.1.  Remote Triggered Black Hole Filtering
+
+   A Remote Triggered Black Hole (RTBH) [RFC5635] works identically in
+   IPv4 and IPv6.  IANA has allocated the 100::/64 prefix to be used as
+   the discard prefix [RFC6666].
+
+4.2.  Transition/Coexistence Mechanism
+
+   SPs will typically use transition mechanisms, such as 6rd, 6PE, MAP,
+   and NAT64, which have been analyzed in the transition and coexistence
+   (Section 2.7).
+
+4.3.  Lawful Intercept
+
+   The lawful intercept requirements are similar for IPv6 and IPv4
+   architectures and will be subject to the laws enforced in different
+   geographic regions.  The local issues with each jurisdiction can make
+   this challenging and both corporate legal and privacy personnel
+   should be involved in discussions pertaining to what information gets
+   logged and with regard to the respective log retention policies for
+   this information.
+
+   The target of interception will usually be a residential subscriber
+   (e.g., his/her PPP session, physical line, or CPE MAC address).  In
+   the absence of IPv6 NAT on the CPE, IPv6 has the possibility to allow
+   for intercepting the traffic from a single host (i.e., a /128 target)
+   rather than the whole set of hosts of a subscriber (which could be a
+   /48, /60, or /64).
+
+   In contrast, in mobile environments, since the 3GPP specifications
+   allocate a /64 per device, it may be sufficient to intercept traffic
+   from the /64 rather than specific /128s (since each time the device
+   establishes a data connection, it gets a new IID).
+
+5.  Residential Users Security Considerations
+
+   The IETF Home Networking (homenet) Working Group is working on
+   standards and guidelines for IPv6 residential networks; this
+   obviously includes operational security considerations, but this is
+   still a work in progress.  [RFC8520] is an interesting approach on
+   how firewalls could retrieve and apply specific security policies to
+   some residential devices.
+
+   Some residential users have less experience and knowledge about
+   security or networking than experimented operators.  As most of the
+   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, those users can get IPv6 Internet access with the help
+   of Teredo (Section 2.7.2.8) tunnels.  Several peer-to-peer programs
+   support IPv6, and those programs can initiate a Teredo tunnel through
+   an IPv4 residential gateway, with the consequence of making the
+   internal host reachable from any IPv6 host on the Internet.
+   Therefore, it is recommended that all host security products
+   (including personal firewalls) are configured with a dual-stack
+   security policy.
+
+   If the residential CPE has IPv6 connectivity, [RFC7084] defines the
+   requirements of an IPv6 CPE and does not take a position on the
+   debate of default IPv6 security policy, as defined in [RFC6092]:
+
+   outbound only:
+      Allowing all internally initiated connections and 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.
+      [RFC6092] lists several recommendations to design such a CPE.
+
+   open/transparent:
+      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 for IPv6 than
+      for IPv4.
+
+   REC-49 states that a choice must be given to the user to select one
+   of those two policies [RFC6092].
+
+6.  Further Reading
+
+   There are several documents that describe in more detail the security
+   of an IPv6 network; these documents are not written by the IETF and
+   some of them are dated but are listed here for the reader's
+   convenience:
+
+   *  Guidelines for the Secure Deployment of IPv6 [NIST]
+
+   *  North American IPv6 Task Force Technology Report - IPv6 Security
+      Technology Paper [NAv6TF_Security]
+
+   *  IPv6 Security [IPv6_Security_Book]
+
+7.  Security Considerations
+
+   This memo attempts to give an overview of security considerations of
+   operating an IPv6 network both for an IPv6-only network and for
+   networks utilizing the most widely deployed IPv4/IPv6 coexistence
+   strategies.
+
+8.  IANA Considerations
+
+   This document has no IANA actions.
+
+9.  References
+
+9.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <https://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+              May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+   [RFC8200]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
+              (IPv6) Specification", STD 86, RFC 8200,
+              DOI 10.17487/RFC8200, July 2017,
+              <https://www.rfc-editor.org/info/rfc8200>.
+
+9.2.  Informative References
+
+   [CYMRU]    Team Cymru, "The Bogon Reference", <https://team-
+              cymru.com/community-services/bogon-reference/>.
+
+   [ENTROPYIP]
+              Foremski, P., Plonka, D., and A. Berger, "Entropy/IP:
+              Uncovering Structure in IPv6 Addresses", November 2016,
+              <http://www.entropy-ip.com/>.
+
+   [europol-cgn]
+              Europol, "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",
+              October 2017,
+              <https://www.europol.europa.eu/newsroom/news/are-you-
+              sharing-same-ip-address-criminal-law-enforcement-call-for-
+              end-of-carrier-grade-nat-cgn-to-increase-accountability-
+              online>.
+
+   [GDPR]     European Union, "Regulation (EU) 2016/679 of the European
+              Parliament and of the Council of 27 April 2016 on the
+              protection of natural persons with regard to the
+              processing of personal data and on the free movement of
+              such data, and repealing Directive 95/46/EC (General Data
+              Protection Regulation)", Official Journal of the European
+              Union, April 2016,
+              <https://eur-lex.europa.eu/eli/reg/2016/679/oj>.
+
+   [IANA-IPFIX]
+              IANA, "IP Flow Information Export (IPFIX) Entities",
+              <http://www.iana.org/assignments/ipfix>.
+
+   [IEEE-802.1X]
+              IEEE, "IEEE Standard for Local and Metropolitan Area
+              Networks--Port-Based Network Access Control", IEEE Std 
+              802.1X-2020, February 2020.
+
+   [IPV6-EH-FILTERING]
+              Gont, F. and W. Liu, "Recommendations on the Filtering of
+              IPv6 Packets Containing IPv6 Extension Headers at Transit
+              Routers", Work in Progress, Internet-Draft, draft-ietf-
+              opsec-ipv6-eh-filtering-08, 3 June 2021,
+              <https://datatracker.ietf.org/doc/html/draft-ietf-opsec-
+              ipv6-eh-filtering-08>.
+
+   [IPV6-EH-PARSING]
+              Kampanakis, P., "Implementation Guidelines for parsing
+              IPv6 Extension Headers", Work in Progress, Internet-Draft,
+              draft-kampanakis-6man-ipv6-eh-parsing-01, 5 August 2014,
+              <https://datatracker.ietf.org/doc/html/draft-kampanakis-
+              6man-ipv6-eh-parsing-01>.
+
+   [IPv6_Security_Book]
+              Hogg, S. and É. Vyncke, "IPv6 Security", CiscoPress,
+              ISBN 1587055945, December 2008.
+
+   [KRISTOFF] Kristoff, J., Ghasemisharif, M., Kanich, C., and J.
+              Polakis, "Plight at the End of the Tunnel: Legacy IPv6
+              Transition Mechanisms in the Wild", March 2021,
+              <https://dataplane.org/jtk/publications/kgkp-pam-21.pdf>.
+
+   [NAv6TF_Security]
+              Kaeo, M., Green, D., Bound, J., and Y. Pouffary, "North
+              American IPv6 Task Force (NAv6TF) Technology Report "IPv6
+              Security Technology Paper", July 2006,
+              <http://www.ipv6forum.com/dl/white/
+              NAv6TF_Security_Report.pdf>.
+
+   [NIST]     Frankel, S., Graveman, R., Pearce, J., and M. Rooks,
+              "Guidelines for the Secure Deployment of IPv6", December
+              2010, <http://csrc.nist.gov/publications/nistpubs/800-119/
+              sp800-119.pdf>.
+
+   [RADB]     Merit Network, Inc., "RADb: The Internet Routing
+              Registry", <https://www.radb.net/>.
+
+   [REY_PF]   Rey, E., "Local Packet Filtering with IPv6", July 2017,
+              <https://labs.ripe.net/Members/enno_rey/local-packet-
+              filtering-with-ipv6>.
+
+   [RFC0826]  Plummer, D., "An Ethernet Address Resolution Protocol: Or
+              Converting Network Protocol Addresses to 48.bit Ethernet
+              Address for Transmission on Ethernet Hardware", STD 37,
+              RFC 826, DOI 10.17487/RFC0826, November 1982,
+              <https://www.rfc-editor.org/info/rfc826>.
+
+   [RFC1918]  Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.
+              J., and E. Lear, "Address Allocation for Private
+              Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918,
+              February 1996, <https://www.rfc-editor.org/info/rfc1918>.
+
+   [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol",
+              RFC 2131, DOI 10.17487/RFC2131, March 1997,
+              <https://www.rfc-editor.org/info/rfc2131>.
+
+   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
+              (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
+              December 1998, <https://www.rfc-editor.org/info/rfc2460>.
+
+   [RFC2529]  Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4
+              Domains without Explicit Tunnels", RFC 2529,
+              DOI 10.17487/RFC2529, March 1999,
+              <https://www.rfc-editor.org/info/rfc2529>.
+
+   [RFC2663]  Srisuresh, P. and M. Holdrege, "IP Network Address
+              Translator (NAT) Terminology and Considerations",
+              RFC 2663, DOI 10.17487/RFC2663, August 1999,
+              <https://www.rfc-editor.org/info/rfc2663>.
+
+   [RFC2784]  Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
+              Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
+              DOI 10.17487/RFC2784, March 2000,
+              <https://www.rfc-editor.org/info/rfc2784>.
+
+   [RFC2827]  Ferguson, P. and D. Senie, "Network Ingress Filtering:
+              Defeating Denial of Service Attacks which employ IP Source
+              Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827,
+              May 2000, <https://www.rfc-editor.org/info/rfc2827>.
+
+   [RFC2866]  Rigney, C., "RADIUS Accounting", RFC 2866,
+              DOI 10.17487/RFC2866, June 2000,
+              <https://www.rfc-editor.org/info/rfc2866>.
+
+   [RFC3056]  Carpenter, B. and K. Moore, "Connection of IPv6 Domains
+              via IPv4 Clouds", RFC 3056, DOI 10.17487/RFC3056, February
+              2001, <https://www.rfc-editor.org/info/rfc3056>.
+
+   [RFC3068]  Huitema, C., "An Anycast Prefix for 6to4 Relay Routers",
+              RFC 3068, DOI 10.17487/RFC3068, June 2001,
+              <https://www.rfc-editor.org/info/rfc3068>.
+
+   [RFC3627]  Savola, P., "Use of /127 Prefix Length Between Routers
+              Considered Harmful", RFC 3627, DOI 10.17487/RFC3627,
+              September 2003, <https://www.rfc-editor.org/info/rfc3627>.
+
+   [RFC3704]  Baker, F. and P. Savola, "Ingress Filtering for Multihomed
+              Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March
+              2004, <https://www.rfc-editor.org/info/rfc3704>.
+
+   [RFC3756]  Nikander, P., Ed., Kempf, J., and E. Nordmark, "IPv6
+              Neighbor Discovery (ND) Trust Models and Threats",
+              RFC 3756, DOI 10.17487/RFC3756, May 2004,
+              <https://www.rfc-editor.org/info/rfc3756>.
+
+   [RFC3964]  Savola, P. and C. Patel, "Security Considerations for
+              6to4", RFC 3964, DOI 10.17487/RFC3964, December 2004,
+              <https://www.rfc-editor.org/info/rfc3964>.
+
+   [RFC3971]  Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander,
+              "SEcure Neighbor Discovery (SEND)", RFC 3971,
+              DOI 10.17487/RFC3971, March 2005,
+              <https://www.rfc-editor.org/info/rfc3971>.
+
+   [RFC3972]  Aura, T., "Cryptographically Generated Addresses (CGA)",
+              RFC 3972, DOI 10.17487/RFC3972, March 2005,
+              <https://www.rfc-editor.org/info/rfc3972>.
+
+   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "DNS Security Introduction and Requirements",
+              RFC 4033, DOI 10.17487/RFC4033, March 2005,
+              <https://www.rfc-editor.org/info/rfc4033>.
+
+   [RFC4107]  Bellovin, S. and R. Housley, "Guidelines for Cryptographic
+              Key Management", BCP 107, RFC 4107, DOI 10.17487/RFC4107,
+              June 2005, <https://www.rfc-editor.org/info/rfc4107>.
+
+   [RFC4193]  Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
+              Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,
+              <https://www.rfc-editor.org/info/rfc4193>.
+
+   [RFC4293]  Routhier, S., Ed., "Management Information Base for the
+              Internet Protocol (IP)", RFC 4293, DOI 10.17487/RFC4293,
+              April 2006, <https://www.rfc-editor.org/info/rfc4293>.
+
+   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
+              Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
+              December 2005, <https://www.rfc-editor.org/info/rfc4301>.
+
+   [RFC4302]  Kent, S., "IP Authentication Header", RFC 4302,
+              DOI 10.17487/RFC4302, December 2005,
+              <https://www.rfc-editor.org/info/rfc4302>.
+
+   [RFC4303]  Kent, S., "IP Encapsulating Security Payload (ESP)",
+              RFC 4303, DOI 10.17487/RFC4303, December 2005,
+              <https://www.rfc-editor.org/info/rfc4303>.
+
+   [RFC4364]  Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
+              Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
+              2006, <https://www.rfc-editor.org/info/rfc4364>.
+
+   [RFC4380]  Huitema, C., "Teredo: Tunneling IPv6 over UDP through
+              Network Address Translations (NATs)", RFC 4380,
+              DOI 10.17487/RFC4380, February 2006,
+              <https://www.rfc-editor.org/info/rfc4380>.
+
+   [RFC4381]  Behringer, M., "Analysis of the Security of BGP/MPLS IP
+              Virtual Private Networks (VPNs)", RFC 4381,
+              DOI 10.17487/RFC4381, February 2006,
+              <https://www.rfc-editor.org/info/rfc4381>.
+
+   [RFC4443]  Conta, A., Deering, S., and M. Gupta, Ed., "Internet
+              Control Message Protocol (ICMPv6) for the Internet
+              Protocol Version 6 (IPv6) Specification", STD 89,
+              RFC 4443, DOI 10.17487/RFC4443, March 2006,
+              <https://www.rfc-editor.org/info/rfc4443>.
+
+   [RFC4552]  Gupta, M. and N. Melam, "Authentication/Confidentiality
+              for OSPFv3", RFC 4552, DOI 10.17487/RFC4552, June 2006,
+              <https://www.rfc-editor.org/info/rfc4552>.
+
+   [RFC4649]  Volz, B., "Dynamic Host Configuration Protocol for IPv6
+              (DHCPv6) Relay Agent Remote-ID Option", RFC 4649,
+              DOI 10.17487/RFC4649, August 2006,
+              <https://www.rfc-editor.org/info/rfc4649>.
+
+   [RFC4659]  De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur,
+              "BGP-MPLS IP Virtual Private Network (VPN) Extension for
+              IPv6 VPN", RFC 4659, DOI 10.17487/RFC4659, September 2006,
+              <https://www.rfc-editor.org/info/rfc4659>.
+
+   [RFC4795]  Aboba, B., Thaler, D., and L. Esibov, "Link-local
+              Multicast Name Resolution (LLMNR)", RFC 4795,
+              DOI 10.17487/RFC4795, January 2007,
+              <https://www.rfc-editor.org/info/rfc4795>.
+
+   [RFC4798]  De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur,
+              "Connecting IPv6 Islands over IPv4 MPLS Using IPv6
+              Provider Edge Routers (6PE)", RFC 4798,
+              DOI 10.17487/RFC4798, February 2007,
+              <https://www.rfc-editor.org/info/rfc4798>.
+
+   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
+              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
+              DOI 10.17487/RFC4861, September 2007,
+              <https://www.rfc-editor.org/info/rfc4861>.
+
+   [RFC4864]  Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and
+              E. Klein, "Local Network Protection for IPv6", RFC 4864,
+              DOI 10.17487/RFC4864, May 2007,
+              <https://www.rfc-editor.org/info/rfc4864>.
+
+   [RFC4890]  Davies, E. and J. Mohacsi, "Recommendations for Filtering
+              ICMPv6 Messages in Firewalls", RFC 4890,
+              DOI 10.17487/RFC4890, May 2007,
+              <https://www.rfc-editor.org/info/rfc4890>.
+
+   [RFC4942]  Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/
+              Co-existence Security Considerations", RFC 4942,
+              DOI 10.17487/RFC4942, September 2007,
+              <https://www.rfc-editor.org/info/rfc4942>.
+
+   [RFC5082]  Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C.
+              Pignataro, "The Generalized TTL Security Mechanism
+              (GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007,
+              <https://www.rfc-editor.org/info/rfc5082>.
+
+   [RFC5214]  Templin, F., Gleeson, T., and D. Thaler, "Intra-Site
+              Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214,
+              DOI 10.17487/RFC5214, March 2008,
+              <https://www.rfc-editor.org/info/rfc5214>.
+
+   [RFC5340]  Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
+              for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,
+              <https://www.rfc-editor.org/info/rfc5340>.
+
+   [RFC5635]  Kumari, W. and D. McPherson, "Remote Triggered Black Hole
+              Filtering with Unicast Reverse Path Forwarding (uRPF)",
+              RFC 5635, DOI 10.17487/RFC5635, August 2009,
+              <https://www.rfc-editor.org/info/rfc5635>.
+
+   [RFC5952]  Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
+              Address Text Representation", RFC 5952,
+              DOI 10.17487/RFC5952, August 2010,
+              <https://www.rfc-editor.org/info/rfc5952>.
+
+   [RFC5969]  Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4
+              Infrastructures (6rd) -- Protocol Specification",
+              RFC 5969, DOI 10.17487/RFC5969, August 2010,
+              <https://www.rfc-editor.org/info/rfc5969>.
+
+   [RFC6092]  Woodyatt, J., Ed., "Recommended Simple Security
+              Capabilities in Customer Premises Equipment (CPE) for
+              Providing Residential IPv6 Internet Service", RFC 6092,
+              DOI 10.17487/RFC6092, January 2011,
+              <https://www.rfc-editor.org/info/rfc6092>.
+
+   [RFC6104]  Chown, T. and S. Venaas, "Rogue IPv6 Router Advertisement
+              Problem Statement", RFC 6104, DOI 10.17487/RFC6104,
+              February 2011, <https://www.rfc-editor.org/info/rfc6104>.
+
+   [RFC6105]  Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J.
+              Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105,
+              DOI 10.17487/RFC6105, February 2011,
+              <https://www.rfc-editor.org/info/rfc6105>.
+
+   [RFC6144]  Baker, F., Li, X., Bao, C., and K. Yin, "Framework for
+              IPv4/IPv6 Translation", RFC 6144, DOI 10.17487/RFC6144,
+              April 2011, <https://www.rfc-editor.org/info/rfc6144>.
+
+   [RFC6146]  Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
+              NAT64: Network Address and Protocol Translation from IPv6
+              Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146,
+              April 2011, <https://www.rfc-editor.org/info/rfc6146>.
+
+   [RFC6147]  Bagnulo, M., Sullivan, A., Matthews, P., and I. van
+              Beijnum, "DNS64: DNS Extensions for Network Address
+              Translation from IPv6 Clients to IPv4 Servers", RFC 6147,
+              DOI 10.17487/RFC6147, April 2011,
+              <https://www.rfc-editor.org/info/rfc6147>.
+
+   [RFC6164]  Kohno, M., Nitzan, B., Bush, R., Matsuzaki, Y., Colitti,
+              L., and T. Narten, "Using 127-Bit IPv6 Prefixes on Inter-
+              Router Links", RFC 6164, DOI 10.17487/RFC6164, April 2011,
+              <https://www.rfc-editor.org/info/rfc6164>.
+
+   [RFC6169]  Krishnan, S., Thaler, D., and J. Hoagland, "Security
+              Concerns with IP Tunneling", RFC 6169,
+              DOI 10.17487/RFC6169, April 2011,
+              <https://www.rfc-editor.org/info/rfc6169>.
+
+   [RFC6177]  Narten, T., Huston, G., and L. Roberts, "IPv6 Address
+              Assignment to End Sites", BCP 157, RFC 6177,
+              DOI 10.17487/RFC6177, March 2011,
+              <https://www.rfc-editor.org/info/rfc6177>.
+
+   [RFC6192]  Dugal, D., Pignataro, C., and R. Dunn, "Protecting the
+              Router Control Plane", RFC 6192, DOI 10.17487/RFC6192,
+              March 2011, <https://www.rfc-editor.org/info/rfc6192>.
+
+   [RFC6221]  Miles, D., Ed., Ooghe, S., Dec, W., Krishnan, S., and A.
+              Kavanagh, "Lightweight DHCPv6 Relay Agent", RFC 6221,
+              DOI 10.17487/RFC6221, May 2011,
+              <https://www.rfc-editor.org/info/rfc6221>.
+
+   [RFC6241]  Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
+              and A. Bierman, Ed., "Network Configuration Protocol
+              (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
+              <https://www.rfc-editor.org/info/rfc6241>.
+
+   [RFC6264]  Jiang, S., Guo, D., and B. Carpenter, "An Incremental
+              Carrier-Grade NAT (CGN) for IPv6 Transition", RFC 6264,
+              DOI 10.17487/RFC6264, June 2011,
+              <https://www.rfc-editor.org/info/rfc6264>.
+
+   [RFC6269]  Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and
+              P. Roberts, "Issues with IP Address Sharing", RFC 6269,
+              DOI 10.17487/RFC6269, June 2011,
+              <https://www.rfc-editor.org/info/rfc6269>.
+
+   [RFC6296]  Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix
+              Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011,
+              <https://www.rfc-editor.org/info/rfc6296>.
+
+   [RFC6302]  Durand, A., Gashinsky, I., Lee, D., and S. Sheppard,
+              "Logging Recommendations for Internet-Facing Servers",
+              BCP 162, RFC 6302, DOI 10.17487/RFC6302, June 2011,
+              <https://www.rfc-editor.org/info/rfc6302>.
+
+   [RFC6324]  Nakibly, G. and F. Templin, "Routing Loop Attack Using
+              IPv6 Automatic Tunnels: Problem Statement and Proposed
+              Mitigations", RFC 6324, DOI 10.17487/RFC6324, August 2011,
+              <https://www.rfc-editor.org/info/rfc6324>.
+
+   [RFC6333]  Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
+              Stack Lite Broadband Deployments Following IPv4
+              Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011,
+              <https://www.rfc-editor.org/info/rfc6333>.
+
+   [RFC6343]  Carpenter, B., "Advisory Guidelines for 6to4 Deployment",
+              RFC 6343, DOI 10.17487/RFC6343, August 2011,
+              <https://www.rfc-editor.org/info/rfc6343>.
+
+   [RFC6434]  Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node
+              Requirements", RFC 6434, DOI 10.17487/RFC6434, December
+              2011, <https://www.rfc-editor.org/info/rfc6434>.
+
+   [RFC6459]  Korhonen, J., Ed., Soininen, J., Patil, B., Savolainen,
+              T., Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation
+              Partnership Project (3GPP) Evolved Packet System (EPS)",
+              RFC 6459, DOI 10.17487/RFC6459, January 2012,
+              <https://www.rfc-editor.org/info/rfc6459>.
+
+   [RFC6547]  George, W., "RFC 3627 to Historic Status", RFC 6547,
+              DOI 10.17487/RFC6547, February 2012,
+              <https://www.rfc-editor.org/info/rfc6547>.
+
+   [RFC6564]  Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and
+              M. Bhatia, "A Uniform Format for IPv6 Extension Headers",
+              RFC 6564, DOI 10.17487/RFC6564, April 2012,
+              <https://www.rfc-editor.org/info/rfc6564>.
+
+   [RFC6583]  Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational
+              Neighbor Discovery Problems", RFC 6583,
+              DOI 10.17487/RFC6583, March 2012,
+              <https://www.rfc-editor.org/info/rfc6583>.
+
+   [RFC6598]  Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and
+              M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address
+              Space", BCP 153, RFC 6598, DOI 10.17487/RFC6598, April
+              2012, <https://www.rfc-editor.org/info/rfc6598>.
+
+   [RFC6620]  Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS
+              SAVI: First-Come, First-Served Source Address Validation
+              Improvement for Locally Assigned IPv6 Addresses",
+              RFC 6620, DOI 10.17487/RFC6620, May 2012,
+              <https://www.rfc-editor.org/info/rfc6620>.
+
+   [RFC6666]  Hilliard, N. and D. Freedman, "A Discard Prefix for IPv6",
+              RFC 6666, DOI 10.17487/RFC6666, August 2012,
+              <https://www.rfc-editor.org/info/rfc6666>.
+
+   [RFC6762]  Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
+              DOI 10.17487/RFC6762, February 2013,
+              <https://www.rfc-editor.org/info/rfc6762>.
+
+   [RFC6763]  Cheshire, S. and M. Krochmal, "DNS-Based Service
+              Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
+              <https://www.rfc-editor.org/info/rfc6763>.
+
+   [RFC6775]  Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C.
+              Bormann, "Neighbor Discovery Optimization for IPv6 over
+              Low-Power Wireless Personal Area Networks (6LoWPANs)",
+              RFC 6775, DOI 10.17487/RFC6775, November 2012,
+              <https://www.rfc-editor.org/info/rfc6775>.
+
+   [RFC6877]  Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT:
+              Combination of Stateful and Stateless Translation",
+              RFC 6877, DOI 10.17487/RFC6877, April 2013,
+              <https://www.rfc-editor.org/info/rfc6877>.
+
+   [RFC6888]  Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa,
+              A., and H. Ashida, "Common Requirements for Carrier-Grade
+              NATs (CGNs)", BCP 127, RFC 6888, DOI 10.17487/RFC6888,
+              April 2013, <https://www.rfc-editor.org/info/rfc6888>.
+
+   [RFC6939]  Halwasia, G., Bhandari, S., and W. Dec, "Client Link-Layer
+              Address Option in DHCPv6", RFC 6939, DOI 10.17487/RFC6939,
+              May 2013, <https://www.rfc-editor.org/info/rfc6939>.
+
+   [RFC6964]  Templin, F., "Operational Guidance for IPv6 Deployment in
+              IPv4 Sites Using the Intra-Site Automatic Tunnel
+              Addressing Protocol (ISATAP)", RFC 6964,
+              DOI 10.17487/RFC6964, May 2013,
+              <https://www.rfc-editor.org/info/rfc6964>.
+
+   [RFC6967]  Boucadair, M., Touch, J., Levis, P., and R. Penno,
+              "Analysis of Potential Solutions for Revealing a Host
+              Identifier (HOST_ID) in Shared Address Deployments",
+              RFC 6967, DOI 10.17487/RFC6967, June 2013,
+              <https://www.rfc-editor.org/info/rfc6967>.
+
+   [RFC6980]  Gont, F., "Security Implications of IPv6 Fragmentation
+              with IPv6 Neighbor Discovery", RFC 6980,
+              DOI 10.17487/RFC6980, August 2013,
+              <https://www.rfc-editor.org/info/rfc6980>.
+
+   [RFC7010]  Liu, B., Jiang, S., Carpenter, B., Venaas, S., and W.
+              George, "IPv6 Site Renumbering Gap Analysis", RFC 7010,
+              DOI 10.17487/RFC7010, September 2013,
+              <https://www.rfc-editor.org/info/rfc7010>.
+
+   [RFC7011]  Claise, B., Ed., Trammell, B., Ed., and P. Aitken,
+              "Specification of the IP Flow Information Export (IPFIX)
+              Protocol for the Exchange of Flow Information", STD 77,
+              RFC 7011, DOI 10.17487/RFC7011, September 2013,
+              <https://www.rfc-editor.org/info/rfc7011>.
+
+   [RFC7012]  Claise, B., Ed. and B. Trammell, Ed., "Information Model
+              for IP Flow Information Export (IPFIX)", RFC 7012,
+              DOI 10.17487/RFC7012, September 2013,
+              <https://www.rfc-editor.org/info/rfc7012>.
+
+   [RFC7039]  Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, Ed.,
+              "Source Address Validation Improvement (SAVI) Framework",
+              RFC 7039, DOI 10.17487/RFC7039, October 2013,
+              <https://www.rfc-editor.org/info/rfc7039>.
+
+   [RFC7045]  Carpenter, B. and S. Jiang, "Transmission and Processing
+              of IPv6 Extension Headers", RFC 7045,
+              DOI 10.17487/RFC7045, December 2013,
+              <https://www.rfc-editor.org/info/rfc7045>.
+
+   [RFC7084]  Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic
+              Requirements for IPv6 Customer Edge Routers", RFC 7084,
+              DOI 10.17487/RFC7084, November 2013,
+              <https://www.rfc-editor.org/info/rfc7084>.
+
+   [RFC7112]  Gont, F., Manral, V., and R. Bonica, "Implications of
+              Oversized IPv6 Header Chains", RFC 7112,
+              DOI 10.17487/RFC7112, January 2014,
+              <https://www.rfc-editor.org/info/rfc7112>.
+
+   [RFC7113]  Gont, F., "Implementation Advice for IPv6 Router
+              Advertisement Guard (RA-Guard)", RFC 7113,
+              DOI 10.17487/RFC7113, February 2014,
+              <https://www.rfc-editor.org/info/rfc7113>.
+
+   [RFC7123]  Gont, F. and W. Liu, "Security Implications of IPv6 on
+              IPv4 Networks", RFC 7123, DOI 10.17487/RFC7123, February
+              2014, <https://www.rfc-editor.org/info/rfc7123>.
+
+   [RFC7166]  Bhatia, M., Manral, V., and A. Lindem, "Supporting
+              Authentication Trailer for OSPFv3", RFC 7166,
+              DOI 10.17487/RFC7166, March 2014,
+              <https://www.rfc-editor.org/info/rfc7166>.
+
+   [RFC7217]  Gont, F., "A Method for Generating Semantically Opaque
+              Interface Identifiers with IPv6 Stateless Address
+              Autoconfiguration (SLAAC)", RFC 7217,
+              DOI 10.17487/RFC7217, April 2014,
+              <https://www.rfc-editor.org/info/rfc7217>.
+
+   [RFC7359]  Gont, F., "Layer 3 Virtual Private Network (VPN) Tunnel
+              Traffic Leakages in Dual-Stack Hosts/Networks", RFC 7359,
+              DOI 10.17487/RFC7359, August 2014,
+              <https://www.rfc-editor.org/info/rfc7359>.
+
+   [RFC7381]  Chittimaneni, K., Chown, T., Howard, L., Kuarsingh, V.,
+              Pouffary, Y., and E. Vyncke, "Enterprise IPv6 Deployment
+              Guidelines", RFC 7381, DOI 10.17487/RFC7381, October 2014,
+              <https://www.rfc-editor.org/info/rfc7381>.
+
+   [RFC7404]  Behringer, M. and E. Vyncke, "Using Only Link-Local
+              Addressing inside an IPv6 Network", RFC 7404,
+              DOI 10.17487/RFC7404, November 2014,
+              <https://www.rfc-editor.org/info/rfc7404>.
+
+   [RFC7422]  Donley, C., Grundemann, C., Sarawat, V., Sundaresan, K.,
+              and O. Vautrin, "Deterministic Address Mapping to Reduce
+              Logging in Carrier-Grade NAT Deployments", RFC 7422,
+              DOI 10.17487/RFC7422, December 2014,
+              <https://www.rfc-editor.org/info/rfc7422>.
+
+   [RFC7454]  Durand, J., Pepelnjak, I., and G. Doering, "BGP Operations
+              and Security", BCP 194, RFC 7454, DOI 10.17487/RFC7454,
+              February 2015, <https://www.rfc-editor.org/info/rfc7454>.
+
+   [RFC7513]  Bi, J., Wu, J., Yao, G., and F. Baker, "Source Address
+              Validation Improvement (SAVI) Solution for DHCP",
+              RFC 7513, DOI 10.17487/RFC7513, May 2015,
+              <https://www.rfc-editor.org/info/rfc7513>.
+
+   [RFC7526]  Troan, O. and B. Carpenter, Ed., "Deprecating the Anycast
+              Prefix for 6to4 Relay Routers", BCP 196, RFC 7526,
+              DOI 10.17487/RFC7526, May 2015,
+              <https://www.rfc-editor.org/info/rfc7526>.
+
+   [RFC7552]  Asati, R., Pignataro, C., Raza, K., Manral, V., and R.
+              Papneja, "Updates to LDP for IPv6", RFC 7552,
+              DOI 10.17487/RFC7552, June 2015,
+              <https://www.rfc-editor.org/info/rfc7552>.
+
+   [RFC7597]  Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S.,
+              Murakami, T., and T. Taylor, Ed., "Mapping of Address and
+              Port with Encapsulation (MAP-E)", RFC 7597,
+              DOI 10.17487/RFC7597, July 2015,
+              <https://www.rfc-editor.org/info/rfc7597>.
+
+   [RFC7599]  Li, X., Bao, C., Dec, W., Ed., Troan, O., Matsushima, S.,
+              and T. Murakami, "Mapping of Address and Port using
+              Translation (MAP-T)", RFC 7599, DOI 10.17487/RFC7599, July
+              2015, <https://www.rfc-editor.org/info/rfc7599>.
+
+   [RFC7610]  Gont, F., Liu, W., and G. Van de Velde, "DHCPv6-Shield:
+              Protecting against Rogue DHCPv6 Servers", BCP 199,
+              RFC 7610, DOI 10.17487/RFC7610, August 2015,
+              <https://www.rfc-editor.org/info/rfc7610>.
+
+   [RFC7707]  Gont, F. and T. Chown, "Network Reconnaissance in IPv6
+              Networks", RFC 7707, DOI 10.17487/RFC7707, March 2016,
+              <https://www.rfc-editor.org/info/rfc7707>.
+
+   [RFC7721]  Cooper, A., Gont, F., and D. Thaler, "Security and Privacy
+              Considerations for IPv6 Address Generation Mechanisms",
+              RFC 7721, DOI 10.17487/RFC7721, March 2016,
+              <https://www.rfc-editor.org/info/rfc7721>.
+
+   [RFC7772]  Yourtchenko, A. and L. Colitti, "Reducing Energy
+              Consumption of Router Advertisements", BCP 202, RFC 7772,
+              DOI 10.17487/RFC7772, February 2016,
+              <https://www.rfc-editor.org/info/rfc7772>.
+
+   [RFC7785]  Vinapamula, S. and M. Boucadair, "Recommendations for
+              Prefix Binding in the Context of Softwire Dual-Stack
+              Lite", RFC 7785, DOI 10.17487/RFC7785, February 2016,
+              <https://www.rfc-editor.org/info/rfc7785>.
+
+   [RFC7824]  Krishnan, S., Mrugalski, T., and S. Jiang, "Privacy
+              Considerations for DHCPv6", RFC 7824,
+              DOI 10.17487/RFC7824, May 2016,
+              <https://www.rfc-editor.org/info/rfc7824>.
+
+   [RFC7844]  Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity
+              Profiles for DHCP Clients", RFC 7844,
+              DOI 10.17487/RFC7844, May 2016,
+              <https://www.rfc-editor.org/info/rfc7844>.
+
+   [RFC7857]  Penno, R., Perreault, S., Boucadair, M., Ed., Sivakumar,
+              S., and K. Naito, "Updates to Network Address Translation
+              (NAT) Behavioral Requirements", BCP 127, RFC 7857,
+              DOI 10.17487/RFC7857, April 2016,
+              <https://www.rfc-editor.org/info/rfc7857>.
+
+   [RFC7872]  Gont, F., Linkova, J., Chown, T., and W. Liu,
+              "Observations on the Dropping of Packets with IPv6
+              Extension Headers in the Real World", RFC 7872,
+              DOI 10.17487/RFC7872, June 2016,
+              <https://www.rfc-editor.org/info/rfc7872>.
+
+   [RFC7915]  Bao, C., Li, X., Baker, F., Anderson, T., and F. Gont,
+              "IP/ICMP Translation Algorithm", RFC 7915,
+              DOI 10.17487/RFC7915, June 2016,
+              <https://www.rfc-editor.org/info/rfc7915>.
+
+   [RFC7934]  Colitti, L., Cerf, V., Cheshire, S., and D. Schinazi,
+              "Host Address Availability Recommendations", BCP 204,
+              RFC 7934, DOI 10.17487/RFC7934, July 2016,
+              <https://www.rfc-editor.org/info/rfc7934>.
+
+   [RFC8040]  Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
+              Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
+              <https://www.rfc-editor.org/info/rfc8040>.
+
+   [RFC8064]  Gont, F., Cooper, A., Thaler, D., and W. Liu,
+              "Recommendation on Stable IPv6 Interface Identifiers",
+              RFC 8064, DOI 10.17487/RFC8064, February 2017,
+              <https://www.rfc-editor.org/info/rfc8064>.
+
+   [RFC8177]  Lindem, A., Ed., Qu, Y., Yeung, D., Chen, I., and J.
+              Zhang, "YANG Data Model for Key Chains", RFC 8177,
+              DOI 10.17487/RFC8177, June 2017,
+              <https://www.rfc-editor.org/info/rfc8177>.
+
+   [RFC8190]  Bonica, R., Cotton, M., Haberman, B., and L. Vegoda,
+              "Updates to the Special-Purpose IP Address Registries",
+              BCP 153, RFC 8190, DOI 10.17487/RFC8190, June 2017,
+              <https://www.rfc-editor.org/info/rfc8190>.
+
+   [RFC8210]  Bush, R. and R. Austein, "The Resource Public Key
+              Infrastructure (RPKI) to Router Protocol, Version 1",
+              RFC 8210, DOI 10.17487/RFC8210, September 2017,
+              <https://www.rfc-editor.org/info/rfc8210>.
+
+   [RFC8273]  Brzozowski, J. and G. Van de Velde, "Unique IPv6 Prefix
+              per Host", RFC 8273, DOI 10.17487/RFC8273, December 2017,
+              <https://www.rfc-editor.org/info/rfc8273>.
+
+   [RFC8343]  Bjorklund, M., "A YANG Data Model for Interface
+              Management", RFC 8343, DOI 10.17487/RFC8343, March 2018,
+              <https://www.rfc-editor.org/info/rfc8343>.
+
+   [RFC8344]  Bjorklund, M., "A YANG Data Model for IP Management",
+              RFC 8344, DOI 10.17487/RFC8344, March 2018,
+              <https://www.rfc-editor.org/info/rfc8344>.
+
+   [RFC8415]  Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
+              Richardson, M., Jiang, S., Lemon, T., and T. Winters,
+              "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
+              RFC 8415, DOI 10.17487/RFC8415, November 2018,
+              <https://www.rfc-editor.org/info/rfc8415>.
+
+   [RFC8504]  Chown, T., Loughney, J., and T. Winters, "IPv6 Node
+              Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504,
+              January 2019, <https://www.rfc-editor.org/info/rfc8504>.
+
+   [RFC8520]  Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage
+              Description Specification", RFC 8520,
+              DOI 10.17487/RFC8520, March 2019,
+              <https://www.rfc-editor.org/info/rfc8520>.
+
+   [RFC8541]  Litkowski, S., Decraene, B., and M. Horneffer, "Impact of
+              Shortest Path First (SPF) Trigger and Delay Strategies on
+              IGP Micro-loops", RFC 8541, DOI 10.17487/RFC8541, March
+              2019, <https://www.rfc-editor.org/info/rfc8541>.
+
+   [RFC8981]  Gont, F., Krishnan, S., Narten, T., and R. Draves,
+              "Temporary Address Extensions for Stateless Address
+              Autoconfiguration in IPv6", RFC 8981,
+              DOI 10.17487/RFC8981, February 2021,
+              <https://www.rfc-editor.org/info/rfc8981>.
+
+   [SCANNING] Barnes, R., Altmann, R., and D. Kerr, "Mapping the Great
+              Void - Smarter scanning for IPv6", February 2012,
+              <http://www.caida.org/workshops/isma/1202/slides/
+              aims1202_rbarnes.pdf>.
+
+   [WEBER_VPN]
+              Weber, J., "Dynamic IPv6 Prefix - Problems and VPNs",
+              March 2018, <https://blog.webernetz.net/wp-
+              content/uploads/2018/03/TR18-Johannes-Weber-Dynamic-IPv6-
+              Prefix-Problems-and-VPNs.pdf>.
+
+Acknowledgements
+
+   The authors would like to thank the following people for their useful
+   comments (in alphabetical order): 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, and Bernie
+   Volz.
+
+Authors' Addresses
+
+   Éric Vyncke
+   Cisco
+   De Kleetlaan 6a
+   1831 Diegem
+   Belgium
+
+   Phone: +32 2 778 4677
+   Email: evyncke@cisco.com
+
+
+   Kiran Kumar Chittimaneni
+
+   Email: kk.chittimaneni@gmail.com
+
+
+   Merike Kaeo
+   Double Shot Security
+   3518 Fremont Ave N 363
+   Seattle,  98103
+   United States of America
+
+   Phone: +12066696394
+   Email: merike@doubleshotsecurity.com
+
+
+   Enno Rey
+   ERNW
+   Carl-Bosch-Str. 4
+   69115 Heidelberg Baden-Wuertemberg
+   Germany
+
+   Phone: +49 6221 480390
+   Email: erey@ernw.de