RFC 9099

RFC 9099: Operational Security Considerations for IPv6 Networks 🎀

Okay bestie, let's start with the title block ✨. This one is from the IETF (Internet Engineering Task Force) and it's an Informational doc, so it's published for info and is not a Standards Track spec 🦋. It came out in August 2021 (ISSN 2070-1721). The authors are É. Vyncke (Cisco), K. Chittimaneni, M. Kaeo (Double Shot Security), and E. Rey (ERNW) 💜. The header has no "Obsoletes" or "Updates" line, so this doc doesn't replace or update anything 🌸.

---

Abstract 🌈

Knowing how to run IPv4 networks securely is already a solved-ish problem, whether you're an ISP or an enterprise internal network 💅. IPv6 is giving us some new security challenges though 😭. RFC 4942 covers the security issues in the protocol, but network managers also want a practical, ops-minded doc that lists the pros and/or cons of different choices 🧚.

This doc digs into the operational security issues across several types of networks and proposes technical and procedural mitigations 🔥. It only applies to managed networks, like enterprise networks, service provider networks, or managed residential networks 🫶.

Status of This Memo 🦋

This document is not an Internet Standards Track specification. It's published for informational purposes 💅.

It's a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community, received public review, and was approved for publication by the Internet Engineering Steering Group (IESG) ✨. Not every doc the IESG approves is a candidate for any level of Internet Standard, so see Section 2 of RFC 7841 🙈.

For the current status, any errata, and how to give feedback, check 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, because 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 they're 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 🌸. It's not just because they aren't used to large-scale IPv6 networks yet. There are also subtle but critical differences between IPv4 and IPv6, especially for security 😭. For example, all Layer 2 (L2) interactions now happen with the Neighbor Discovery Protocol (NDP) [RFC4861], not the Address Resolution Protocol [RFC0826] 💅. Also, there's no Network Address Port Translation (NAPT) defined in [RFC2663] for IPv6, even though [RFC6296] specifies an IPv6-to-IPv6 Network Prefix Translation (NPTv6), which is a 1-to-1 mapping of IPv6 addresses 🦋. Another big difference is that IPv6 is extensible through extension headers 👑.

IPv6 networks get deployed using a variety of techniques, and each one has its own specific security concerns 🧚.

This doc complements [RFC4942] by listing the security issues when you operate a network (including various transition technologies) 🫶. It also shares operational deployment experiences where they're warranted 💖.

1.1. Applicability Statement 🎀

This document applies to managed networks, i.e., networks run by the user organization itself 💅. Real talk, a lot of the recommended mitigations must be configured with detailed knowledge of the network (like which routers are the default routers, which switch ports are the 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 the overall architecture are a big part of securing IPv6 😭. Initial designs tend to last way longer than expected, even when they were meant to be temporary 💀. IPv6 was first thought to make renumbering easy, but in practice it can be extremely difficult to renumber without a proper IP Address Management (IPAM) system 🙈. [RFC7010] introduces the mechanisms that could be used for IPv6 site renumbering, and it tries to cover most of the explicit issues and requirements tied to IPv6 renumbering 🎀.

A key task for a successful IPv6 deployment is preparing an addressing plan 🌸. There's an abundance of address space, so structuring your plan around both services and geographic locations means the address space can be the basis for more structured security policies that permit or deny services between regions 👑. [RFC6177] documents some operational considerations for 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]. From a security perspective though, there's little difference 🫶. What you do need to keep in mind is who has administrative ownership of the address space, and who is technically responsible if there's ever a need to enforce restrictions on the space's routability (for example, because of malicious criminal activity coming from it) 🔥. Relying on PA address space may also increase the perceived need for address translation techniques, such as NPTv6, which makes operations (including security operations) more complex 🌈.

In [RFC7934], it is recommended that IPv6 network deployments provide multiple IPv6 addresses from each prefix to general-purpose hosts. It specifically does not recommend limiting a host to only one IPv6 address per prefix 💖. It also recommends that the network give hosts the ability to use new addresses without requiring explicit requests (for example, by using Stateless Address Autoconfiguration (SLAAC)) ✨. Privacy extensions, as of [RFC8981], are one of the main scenarios where hosts are expected to generate multiple addresses from the same prefix. Having multiple IPv6 addresses per interface is a major change from the unique IPv4 address per interface for hosts (secondary IPv4 addresses aren't common), and it especially matters for audits (see Section 2.6.2.3) 👀💅.

2.1.1. Use of ULAs 🌸

Unique Local Addresses (ULAs) [RFC4193] are meant for scenarios where interfaces aren't globally reachable, even though they're 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 they have different use cases 🦋. One use of ULAs is described in [RFC4864]. Another is 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 reasoning behind using /127 for inter-router point-to-point links. It prevents the ping-pong issue between routers that don't correctly implement [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 also use link-local addressing for point-to-point links. This could further reduce the attack surface of infrastructure devices, but 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 then allocate a /128 out of that reserved /64 prefix for each loopback interface 💖. This practice makes it easier to configure Access Control List (ACL) rules that enforce a security policy for those loopback addresses 🫶✨.

2.1.4. Stable Addresses 💖

Okay so bestie, when you're deciding how to give nodes stable addresses (either by static config or by a pre-provisioned DHCPv6 lease, see Section 2.1.6), you HAVE to think about how good your perimeter security is in that environment. It's giving "check your locks before you leave the house" 🏠🔒

There's a real trade-off here 🦋 Easy ops is lowkey amazing, because if parts of the IPv6 address are recognizable, debugging and troubleshooting become way less painful. BUT that same predictability makes trivial scanning for recon super easy. [SCANNING] shows there are scientifically based ways to scan for IPv6-reachable nodes that are way more doable than you'd expect, see [RFC7707]. Not me being dramatic, it's literally the math 😭

Stable addresses also make it easy to enforce security policy at the perimeter based on IPv6 addresses. For example, Manufacturer Usage Description (MUD) [RFC8520] is a mechanism where the perimeter defense can fetch the security policy template based on the type of internal device, then apply the right policy based on that device's IPv6 address. Iconic, honestly 👑

Now the not-so-iconic part 💀 Well-known addresses (like ff02::1 for all link-local nodes) or commonly repeated addresses make it super easy to figure out which devices are name servers, routers, or other critical stuff. Even a simple traceroute will expose most of the routers on a path. Operators should NOT rely on the "impossible to find because my address is random" paradigm (a.k.a. "security by obscurity") 🙈 Even if it's common practice to randomly spread stable addresses across /64 subnets, and to always use DNS (because IPv6 addresses are hard for human brains to remember), that's still not a security plan, bestie.

While obfuscating addresses can be a bonus in some environments, it SHOULD NOT get in the way of enforcing perimeter rules. Stable addresses that follow some logical allocation scheme may make operations easier, and simplicity always helps security ✨

Most deployments end up with a mix of stable and non-stable addresses 🌈 The stable ones are either predictable (like ::25 for a mail server) or obfuscated (looking like a random 64-bit number).

2.1.5. Temporary Addresses for SLAAC 🧚

Historically, Stateless Address Autoconfiguration (SLAAC) builds the globally unique IPv6 address from an automatically generated 64-bit interface identifier (IID), based on the 64-bit Extended Unique Identifier (EUI-64) derived from the 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 comes from the stable 48-bit MAC address and never changes, even if the host moves to another network. That is SO bad for privacy, because a host can be traced from network (home) to network (office or hotel Wi-Fi) 😬 [RFC8064] recommends AGAINST using EUI-64 addresses, and it's important to note that most host operating systems don't use EUI-64 addresses anymore and instead 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 it's used to address some privacy concerns 🎀 Privacy extension addresses (a.k.a. temporary addresses) may help reduce the correlation of a node's activities within the same network, and they may also shrink the attack exposure window. BUT using privacy extension addresses as described in [RFC8981] might stop the operator from building host-specific access control lists (ACLs). These addresses could also be used to hide some malicious activity, so specific user attribution and accountability procedures SHOULD be put in place, as described in Section 2.6.

[RFC8064] combined with the address generation mechanism of [RFC7217] gives another way to generate an address while still keeping the same IID for each network prefix. So SLAAC nodes can always have the same stable IPv6 address on a specific network, while having different IPv6 addresses on different networks. Clever, right? 🧠✨

In some specific use cases where user accountability matters more than user privacy, network operators MAY consider disabling SLAAC and relying only on DHCPv6. HOWEVER, not all operating systems support DHCPv6, so some hosts won't get any IPv6 connectivity at all 😭 For most operating systems, you can disable SLAAC and privacy extension addresses by sending RA messages with a hint to get addresses via DHCPv6 (setting the M-bit), and by resetting all A-bits in all PIOs. But attackers could still find ways around this if it's not enforced at the switch/router level 🙈

However, when anonymity is a strong desire (protecting user privacy matters more than user attribution), privacy extension addresses SHOULD be used. When the mechanisms recommended by [RFC8064] are available, the stable privacy address is probably a good balance between privacy (across different networks) and security/user attribution (within a network) 🦋

2.1.6. DHCP Considerations 🌸

Some environments use DHCPv6 to provision addresses and other parameters, so they can 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, unlike 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 Internet users using DHCPv6. The anonymity profiles in [RFC7844] are designed for clients that want to stay 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 for 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 makes user attribution easier (typically based on the host MAC address), because its /64 prefix stays stable, even if applications within the host change their IPv6 address within that /64 prefix 🫶

This can also be useful for generating 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 have global scope and are visible globally. [RFC7721] goes into more detail on the privacy considerations for IPv6 addresses by comparing manually configured IPv6 addresses, DHCPv6, and SLAAC 👀

2.2. Extension Headers 🎀

Extension headers are a big difference between IPv4 and IPv6, and it's a whole vibe. In IPv4 packets, it's trivial to find the upper-layer protocol type and header. In IPv6, it's more complex, because the extension header chain has to be parsed completely (even if not processed) before you can find the upper-layer protocol header 😤 IANA has closed the old empty "Next Header Types" registry to new entries and is redirecting people 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 the various extension headers is important, and this section lists 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 how IPv6 nodes process extension headers 💫

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 point to either an IPv6 extension header or an upper-layer protocol header. This has to be considered when designing the user interface of filtering solutions or when creating 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 to options contained in the extension headers (see [IPV6-EH-PARSING]). In some cases this 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. That enabled denial-of-service attacks, because most, if not all, routers cannot process this type of packet in hardware. They have to process these packets in software, so the task competes with other software tasks, such as handling 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 MUST 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

okay so the IPsec extension headers, Authentication Header (AH) [RFC4302] and ESP [RFC4303], are what you need if you want IPsec handling your network-level security 🔐 [RFC4301] is the IPsec architecture doc. Back in the day IPv6 flat out mandated IPsec, but [RFC6434] changed that. Now supporting the IPsec architecture [RFC4301] is a 'SHOULD' for all IPv6 nodes, and that's still true in the latest IPv6 Nodes Requirement standard [RFC8504] 🎀

2.3. Link-Layer Security

NDP [RFC4861] is basically the MVP of IPv6 link stuff ✨ It's how nodes find each other on the link, resolve link-layer addresses, and find routers. But if it isn't secured, it's super vulnerable to router/neighbor message spoofing, redirect attacks, Duplicate Address Detection (DAD) DoS attacks, etc. 😭 A lot of these threats are written up in "IPv6 Neighbor Discovery (ND) Trust Models and Threats" [RFC3756] and "Operational Neighbor Discovery Problems" [RFC6583].

Most of the drama only happens 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 hit by remote DoS attacks, for example when a router is forced to do address resolution for a huge number of unassigned addresses. That's when an attacker scans a prefix super fast 🏃‍♀️ This can stop new devices from joining the network, or make the last-hop router ineffective because its CPU is cooked. The easy mitigation steps are rate limiting Neighbor Solicitations, restricting how much state gets reserved for unresolved solicitations, and cleverly managing the cache/timer 🧠

[RFC6583] goes deep on off-link DoS 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 network operators can use 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 it's been extensively documented 📚 Rogue RAs, whether unintentional or malicious, can cause partial or complete failure of operation for 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 where rogue RAs may be observed and presents a list of possible solutions. [RFC6105] (RA-Guard) describes a solution framework for the rogue RA problem, where network segments are designed around switching devices that can identify invalid RAs and block them before the attack packets reach the target nodes. 🛡️

However, several evasion techniques that get around RA-Guard have surfaced 🙈 A key challenge for this mitigation is IPv6 fragmentation. Attackers can hide their attack by fragmenting their packets into multiple fragments, so the switching device responsible for blocking invalid RAs can't find all the info it needs to filter the same packet. [RFC7113] describes these evasion techniques and gives advice to RA-Guard implementers so the evasion vectors can be eliminated.

The IPv6 Fragmentation Header can be leveraged to get around some RA-Guard implementations, so [RFC6980] updates [RFC4861] to forbid use of the IPv6 Fragmentation Header in all Neighbor Discovery messages, except "Certification Path Advertisement". That keeps things simple and effective for countering 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 these attacks 🦋 [RFC7513] helps create bindings between a source IP address assigned via DHCPv4 [RFC2131] or DHCPv6 [RFC8415] and a binding anchor [RFC7039] on a SAVI device. [RFC6620] also describes how to glean similar bindings when DHCP is not used. The bindings can then be used to filter packets generated on the local link with forged source IP addresses.

2.3.2.3. Host Isolation

Isolating hosts for NDP traffic can be done by using a /64 per host (refer to Section 2.1.8), since NDP is only relevant within a /64 on-link prefix. 3GPP (Section 2.3.4) uses a similar mechanism 📱

There's also a more drastic technique to prevent all NDP attacks, based on isolating all hosts with specific configurations. In that setup, hosts (i.e., all nodes that are not routers) are unable to send data-link layer frames to other hosts, so no host-to-host attacks can happen. This specific setup can be established on some switches or Wi-Fi access points. It's not always feasible when hosts need to talk to other hosts in the same subnet, e.g., for access to file shares 📁

2.3.2.4. NDP Recommendations

RA-Guard and SAVI are still recommended as a first line of defense against common attack vectors, including misconfigured hosts 🫶 This also applies when DHCPv6 is used, since 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 so you can identify and act on violations 👀

Network operators should be aware that RA-Guard and SAVI don't 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 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], lets DHCP servers pass configuration parameters, such as IPv6 network addresses and other configuration information, to IPv6 nodes. DHCP is a big deal in most large networks because it provides robust stateful configuration for automated system provisioning 🤖

The two most common threats to DHCP clients come from malicious (a.k.a. rogue) or unintentionally misconfigured DHCP servers. A malicious DHCP server gets set up to hand out incorrect configuration info, either to cause a denial-of-service attack or to mount an on-path attack. A misconfigured DHCP server, though unintentional, 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. It's based on DHCPv6 packet filtering at the L2 device, meaning 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 with no link-layer address. That means 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's 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 need 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 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. Since there's also a single host on the 3GPP link, there's no need to defend that IPv6 address.

See Section 5 of [RFC6459] for a more detailed discussion of 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 📡

Multicast has some side effects on wireless networks, such as a negative impact on battery life of smartphones and other battery-operated devices connected to them 🔋 [RFC7772] and [RFC6775] (for specific wireless networks) discuss methods to rate-limit RAs and other ND messages on wireless networks to address this issue.

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. That could be a DoS attack for the address owner. This attack is purely local to the L2 network, since packets with a link-local destination are never forwarded by an IPv6 router.

This is the reason 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. In other words, Wi-Fi stations are prevented from sending 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 ✨

okay so SEcure Neighbor Discovery (SEND), as described in [RFC3971], is a mechanism that was designed to secure ND messages 🔐. It works by using new NDP options to carry public-key-based signatures. Cryptographically Generated Addresses (CGA), as described in [RFC3972], are used to make sure the sender of a Neighbor Discovery message is the actual "owner" of the IPv6 address they claim 💅. A new NDP option, the CGA option, was introduced to carry the public key and its associated parameters. Another NDP option, the RSA Signature option, protects all messages related 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

but 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

ngl, the big plot twist is that CGA and SEND still don't have support from widely deployed IPv6 devices, even after over a decade since their original specifications 😭. So their usefulness is limited and they should not be relied upon 💀.

---

2.4. Control Plane Security 👑

[RFC6192] defines the router control plane and gives detailed guidance on securing 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, so most of this section applies to IPv6 the same way it applies 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 keeps a strict separation between 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 that handle packets destined to the device itself, as well as building and sending packets that originate 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 out through the appropriate outgoing interface.

Here's the spicy part 🌶️. While the forwarding plane is usually implemented in high-speed hardware, the control plane is run by a generic processor (referred to as the routing processor (RP)) that cannot process packets at a high rate. So this processor can be attacked by flooding its input queue with more packets than it can handle. The control plane processor then can't 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 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, so some packets need to be "punted" to the generic RP. This could include, for example, processing 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 some data plane packets will be dropped without an ICMP message sent to the source, which may delay Path MTU Discovery and cause drops 😬.

On top of limiting the rate of data plane packets queued to the RP, it is also important to rate-limit the generation of ICMP messages. This matters both to preserve RP resources and to prevent an amplification attack using the router as a reflector 🚨. It's worth noting that some platforms implement this rate-limiting in hardware. Of course, 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] also applies 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 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 determining 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, which provides confidentiality for the routing information 🧚.

[RFC7166] changes OSPFv3's reliance on IPsec by appending an authentication trailer to the end of OSPFv3 packets. It does not authenticate the specific originator of an OSPFv3 packet. Instead, it allows a router to confirm that the packet was 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 caused outages, so the trade-off between using this functionality and the protection it provides needs to be weighed carefully ⚖️. [RFC4107] documents some guidelines for crypto keys management 🌈.

2.5.3. Securing Routing Updates 🔐

okay so IPv6 originally said every node MUST have IPsec, bestie 😭 but the updated IPv6 Nodes Requirement standard [RFC8504] downgraded it to a 'SHOULD' and not a 'MUST' implementation. Theoretically you could encrypt all the traffic between two IPv6 nodes with IPsec, especially routers swapping routing info, but in practice it's not always doable because of hardware and software limits on the different platforms out there. real talk, not every box can handle it 💀

Lots of routing protocols can use cryptography to protect their routing updates, and using that protection is recommended ✨🔒 [RFC8177] is a YANG data model for key chains, and it includes rekeying functionality, so your keys can get refreshed 🔑💖

2.5.4. Route Filtering 🧹

Route filtering looks different depending on whether it's edge route filtering or internal route filtering 👀 At a minimum, your IPv6 routing policy (the stuff that handles routing between different administrative domains) should aim to keep 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 📊

okay so when something goes sideways (a security incident or weird abnormal behavior), you need receipts 🧾 Network operators should log multiple pieces of information so they can do forensic research later. In some cases this means frequently polling 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 about how these logs get collected, stored, used, and safely discarded 🙈 Operators are urged to check their country's legislation (e.g., General Data Protection Regulation [GDPR] in the European Union) ⚖️

All of that info 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) 👀 That can make processing messy, because 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, so you get aggregated data tied to 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 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 holds all the mappings between IPv6 addresses and data-link layer addresses 🧠 There are multiple ways to collect the current entries, 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 🌪️ Mappings get added when a new IPv6 address appears on the network, which could happen quite frequently with privacy extension addresses [RFC8981]. They also get 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 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 then stored for later use 💾

This is an important source of info because it is trivial (on a switch not using the SAVI [RFC7039] algorithm) to defeat the mapping between a data-link layer address and an IPv6 address 😱 Put another way, having access to the current and past content of the Neighbor Cache has paramount value for 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, as long as you combine it 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 them to clients 🧾 It's pretty similar to DHCP for IPv4, so it's tempting to use the DHCP lease file to find the mapping between IPv6 addresses/prefixes and data-link layer addresses, like people commonly do in IPv4 networking 🙈

It's not so easy in IPv6 networks, though 😤 Not all nodes use DHCPv6 (some can only do stateless autoconfiguration), and DHCPv6 clients are identified not by their hardware-client address, as in IPv4, but by a DHCP Unique Identifier (DUID) 🆔 The DUID can come in several formats: the data-link layer address, the data-link layer address prepended with time information, or even an opaque number that needs correlation with another data source before it's usable for operational security. Plus, when the DUID is based on the data-link address, that address can belong to any client interface (like the wireless interface, even though the client actually connects to the network over its wired interface) 📶

If a lightweight DHCP relay agent [RFC6221] is used in an L2 switch, the DHCP servers also receive the interface ID information, which could be saved 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 both 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, since 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 that implement the SAVI [RFC7513] mechanisms 🔒 Of course, this also requires that the data-link layer address be protected by an 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, the RADIUS server receives accounting Acct-Status-Type records at the start and at the end of the connection 🎬 These 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 puts the data collected in Section 2.6.1 to work, so you get several security benefits 🌟 Section 9.1 of [RFC7934] contains more details about host tracking 🦋

2.6.2.1. Forensic and User Accountability ✨

okay so the forensic use case is when the network operator needs to track down an IPv6 address (plus the port, access point/switch, or VPN tunnel it was hanging out on) that was in the network at some point in time, or is still there right now 🕵️‍♀️💅

to find an IPv6 address in an enterprise network where the operator controls all the resources, you can check the Neighbor Cache first, and if it's not there, the DHCP lease file. then the steps go like this:

1. start with the IPv6 prefix of the address and find one or more routers used to reach that prefix (assuming anti-spoofing mechanisms are used), maybe with the help of an IPAM 🗺️
2. from that small set of routers, plus the incident time and the IPv6 address, grab the data-link address. you can pull it from the live Neighbor Cache, the historical Neighbor Cache data, or SAVI events, or from the DHCP lease file (Section 2.6.1.5) 🔍
3. with the data-link layer address in hand, look up the switch interface that goes with it. if it's a 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, and if a Configuration Management Database (CMDB) is in play, it can map the data-link layer address to a switch port 🎀

at the end of all that, you've figured out either the interface of the host that started the activity or the subscriber identity tied to it. slay, you found the culprit 💖

now, if you want to identify the subscriber of an IPv6 address in a residential Internet Service Provider, the starting point is the DHCP-PD leased prefix that covers the address. this prefix can often be linked to a subscriber through the RADIUS log 🏠 another option: the Forwarding Information Base (FIB) of the Cable Modem Termination System (CMTS) or Broadband Network Gateway (BNG) tells you which Customer Premises Equipment (CPE) belongs to the subscriber, and then the RADIUS log can get you the actual subscriber 🧚

and honestly? most networks (if not all of them) end up mixing a bunch of these techniques together 🌈

2.6.2.2. Inventory

ngl, [RFC7707] explains how hard it is for an attacker to scan an IPv6 network, because there are so many IPv6 addresses per link (and it explains why, in some cases, it can still be done 🙈). the huge address space can feel like a protection, but it also makes inventory way harder in IPv6 than in IPv4, where it was super easy (just enumerate every IPv4 address, ping them, then run a TCP/UDP port scan 💀). getting an inventory of every connected device is a top priority for keeping a network secure 🔐

there are lots of ways to inventory an IPv6 network 🦋

the first technique is passive inspection, like IPFIX. if you use the exported IPFIX info and pull out the list of all IPv6 source addresses, you can find every IPv6 node that sent packets through a router. this is really efficient, but (sadly) it won't find silent nodes that never sent any packets through the IPFIX target router. also, link-local addresses will never be found this way 😭

the second way is to use the collected Neighbor Cache content to find every IPv6 address in the cache. this will also find all the link-local addresses. see Section 2.6.1.4 🌸

another option that only works for a local network is sending an ICMP ECHO_REQUEST to the link-local multicast address ff02::1, which reaches all IPv6 nodes on the network. all nodes should reply to this ECHO_REQUEST, per [RFC4443] 📡

other techniques involve pulling data from DNS, parsing log files, and using service discovery, like mDNS [RFC6762] [RFC6763] 👀

enumerating DNS zones (especially looking at reverse DNS records and CNAMEs) is another super common move that tons of tools use 🛠️ as already mentioned in [RFC7707], this lets an attacker prune the IPv6 reverse DNS tree and enumerate it in a feasible amount of time. authoritative servers that allow zone transfers (i.e., Authoritative Transfers (AXFRs)) can be another information source too. and there's an interesting research paper that analyzed the entropy in various IPv6 addresses: see [ENTROPYIP] 🧠

⚠️ bestie, the inventory section is the one where the "big address space = safe" myth gets absolutely destroyed. don't let your guard down just because scanning is harder! 😤

2.6.2.3. Correlation

in an IPv4 network, correlating multiple logs is easy. you can find events tied to one specific IPv4 address with a simple Unix grep command, which scans multiple text-based files and pulls out every line that's relevant to that address 🥰

in IPv6, it's a little harder, because different character strings can express the same IPv6 address 🤯 so the simple Unix grep command can't be used. plus, a single IPv6 node can have multiple IPv6 addresses, which makes things messier 🌀

so to correlate IPv6-related logs, it is advised to have all the logs in a format that uses only canonical IPv6 addresses [RFC5952] ✨ then you search the current (or historical) Neighbor Cache data set to find the data-link layer address of the IPv6 address. next, you search the current and historical Neighbor Cache data sets for all IPv6 addresses tied to that data-link layer address, which gives you your search set. the last step is to search every log file (which only contains IPv6 addresses in canonical format) for any IPv6 address in that search set 🔎

and here's the thing: [RFC7934] recommends using multiple IPv6 addresses per prefix, so the correlation must also be done across those multiple addresses. for example, you can discover 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 (things like network scanning, spamming, or DoS) can be detected the same way as in an IPv4 network 🚨 you can watch for:

• a sudden spike in traffic, spotted through an interface counter (SNMP) or through aggregated traffic from IPFIX records [RFC7012] 📈
• rapid growth of the ND cache size, or 🌱
• a change in traffic pattern (like the number of connections per second, or the number of connections per host, etc.), observed with IPFIX [RFC7012] 👀

2.6.3. Summary

some data sources (IPFIX, MIB, switch Content Addressable Memory (CAM) tables, logs, etc.) that are used in IPv4 are also used to keep an IPv6 network secure 🎀 but the DHCPv6 lease file is less reliable, and the Neighbor Cache is of prime importance 👑

the fact that there are multiple ways to write the same IPv6 address as a string means filters are mandatory whenever you need to do correlation 🫶

---

2.7. Transition/Coexistence Technologies 🌈

as it's expected that some networks won't run in a pure IPv6-only mode, the different transition mechanisms must be deployed and operated in a secure way 🔒 this section offers operational guidelines for the most well-known and widely deployed transition techniques. [RFC4942] also has security considerations for transition or coexistence scenarios 📚

2.7.1. Dual Stack

dual stack is often the first deployment choice for network operators, and honestly it makes sense 💖 dual stacking offers a few advantages over other transition mechanisms. first, the impact on existing IPv4 operations is reduced. second, without tunnels or address translation, the IPv4 and IPv6 traffic is native (easier to observe and secure) and should have the same network processing (network path, quality of service, etc.). dual stack also allows a gradual retirement of IPv4 operations once the IPv6 network is ready for prime time 🎉 on the other hand, operators have to manage two network stacks, which brings extra complexity 😵‍💫

from an operational security perspective, this means the network operator now has twice the exposure 😬 you need 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, these methods are used 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 also be configured to protect IPv6 communications. the enforced IPv6 security must be congruent with the IPv4 security policy, otherwise the attacker will just use whichever protocol version has the more relaxed security policy 🙈 keeping those policies congruent can be challenging (especially over time), so it is recommended to use a firewall or an ACL manager that is dual stack, meaning 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 don't care about the IP version. they work just 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 now, all host operating systems have had IPv6 enabled by default. so even in an 'IPv4-only' network, an attacker can target 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 these issues 🦋

2.7.2. Encapsulation Mechanisms ✨

Okay bestie, there are SO many tunnels 🌈 and each one is built for a specific use case. Except when they're protected by IPsec [RFC4301] or other tunnel encryption methods, they all come with a bunch of security issues, as described in [RFC6169]:

• tunnel injection: A sneaky actor who knows a few things (like the tunnel endpoints and the encapsulation protocol) can forge a packet that looks like a legit, valid encapsulated packet. The destination tunnel endpoint will happily accept it 😤. This is a specific case of spoofing.
• traffic interception: The tunnel protocols don't give you any confidentiality (unless you add IPsec or another encryption method), so anybody on the tunnel path can intercept the traffic and read the cleartext IPv6 packet 👀. Since there's no authentication either, an on-path attack can also be pulled off.
• service theft: There's no authorization, so even an unauthorized user can use a tunnel relay for free 💸. This is a specific case of tunnel injection.
• reflection attack: Another specific case of tunnel injection, where the attacker injects packets with an IPv4 destination address that doesn't match the IPv6 address. This makes the first tunnel endpoint re-encapsulate the packet and send it on to the destination. So the final IPv4 destination never sees the original IPv4 address, only the IPv4 address of the relay router 🙈.
• bypassing security policy: If a firewall or an Intrusion Prevention System (IPS) sits on the tunnel path, it may neither inspect nor detect malevolent IPv6 traffic sent over the tunnel 🚨.

To mitigate the bypassing of security policies, it is often recommended to block all automatic tunnels in the default OS configuration (if they aren't required). You do this by denying IPv4 packets that match:

• IP protocol 41: This blocks 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 blocks GRE (Section 2.7.2.1) tunnels.
• UDP port 3544: This blocks 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 I mentioned above should also be prevented by using an IPv6 ACL that stops the hair pinning of the traffic 💅.

As several of the tunnel techniques share the same encapsulation (IPv4 protocol 41) and embed the IPv4 address in the IPv6 address, there's 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]. Since the IPv4 endpoints are statically configured and not dynamic, they're slightly more secure (bidirectional service theft is mostly impossible) 🙌. But traffic interception and tunnel injection are still possible, so the use of IPsec [RFC4301] in transport mode to protect the encapsulated IPv4 packets is recommended for these 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 usually means a single entity manages those systems, so audit trails and strict anti-spoofing are usually possible, and that raises the overall security 📈. Even if ISATAP isn't used that often anymore, its security issues are still 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, which gives IPv6 traffic confidentiality and prevents service theft 🧚.

2.7.2.3. 6rd 🦋

While 6rd tunnels share the same encapsulation as 6to4 tunnels (Section 2.7.2.7), they're designed to be used within a single SP domain. So they live in a more constrained environment (for example, anti-spoofing and protocol 41 filtering at the edge) than 6to4 tunnels 💁. They have few security issues other than a lack of confidentiality. The security considerations in Section 12 of [RFC5969] describe 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. Since 6PE and 6VPE are really similar to the BGP/MPLS IP VPNs described in [RFC4364], their security properties 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 since these addresses can't be reached from outside the link, the security of 6PE and 6VPE is even higher than that of 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, so it's analyzed further (Section 2.7.3.3) in this document, since 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. MAP protocols are used to give IPv4 hosts on the subscriber network access to IPv4 hosts on the Internet 🌐. The subscriber router does stateful operations 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). So, unlike Section 2.7.3.3, there's no state exhaustion DoS attack against the SP equipment, because there's no state and there's 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 making sure that the mapping of the IPv4 address and port is consistent with the configuration. Since MAP has a predictable IPv4 address and port mapping, audit logs are easier to use, because there's 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 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 was 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) where 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 residential environments, 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 an IPv4-only network, because Teredo was designed to easily traverse IPv4 NAT-PT devices, which are quite often co-located with a stateful firewall. So if the stateful IPv4 firewall allows unrestricted UDP outbound and accepts the return UDP traffic, Teredo actually punches a hole in that firewall for all IPv6 traffic to and from the Internet 🕳️. Host policies can be deployed to block Teredo in an IPv4-only network to avoid this firewall bypass. On the IPv4 firewall, all outbound UDP should be blocked except for commonly used services (for example, 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 is no longer enabled by default in most environments, so it's less of a threat. However, special consideration must be made when devices with older operating systems that haven't 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 covers the use of heavy IPv4-to-IPv4 network address and port translation to prolong the life of IPv4-only networks 🌙.

2.7.3.1. Carrier-Grade NAT (CGN) 🎀

okay bestie, so Carrier-Grade NAT (CGN) is also called NAT444 CGN, Large-Scale NAT (LSN), or SP NAT 💅. [RFC6264] covers it, and it's basically a stopgap 🩹 that lets a big service provider keep stretching IPv4 until they can get a proper IPv6 setup running. [RFC6598] asked IANA for a special /10 block of IPv4 addresses that every access network using CGN could share, and that block ended up as 100.64.0.0/10 🌸

the security side is kinda spicy 🌶️. Section 13 of [RFC6269] lists specific security issues that come with large-scale address sharing, and the Security Considerations section of [RFC6598] lists mitigation techniques for when someone misuses that shared space 🙈. some law enforcement agencies have said CGN makes their cybercrime investigations way harder (the Europol press release is [europol-cgn], if you want the receipts 🧾). and honestly, lots of translation techniques (NAT64, DS-Lite, etc.) have the same security problems as CGN whenever one side of the connection is IPv4 only 😬

[RFC6302] says Internet-facing servers should also log the source TCP or UDP ports of incoming connections 📝, which helps identify the actual users hiding behind a CGN. [RFC7422] suggests deterministic address mapping to cut down on logging requirements for CGN ✨. the idea is that there's a known algorithm mapping each internal subscriber to and from public TCP and UDP ports, so you don't have to log everything 🧠

[RFC6888] lists the common requirements for CGNs 📋. [RFC6967] looks at solutions for enforcing policies on misbehaving nodes when address sharing is in play 🚓. and [RFC7857] also updates the NAT behavioral requirements 🔄

2.7.3.2. NAT64/DNS64 and 464XLAT 🦋

okay so stateful NAT64 [RFC6146] lets IPv6-only clients reach IPv4 servers over unicast UDP, TCP, or ICMP 🚀. it can pair up with DNS64 [RFC6147], which makes up AAAA records from existing A records (wild, right? 🪄). there's also stateless NAT64 [RFC7915], which has similar security vibes but is stateless, so it's less vulnerable to a state exhaustion attack 💪

for the full list of issues, check the Security Considerations sections of [RFC6146] and [RFC6147] 📚. Section 8 of [RFC6147] also talks about how NAT64 and DNSSEC interact 🔐. the big drama here is that NAT64 messes with most IPsec deployments unless UDP encapsulation is used 💀

then there's 464XLAT [RFC6877] 🌈, which combines stateful and stateless translation. it does a host-local translation from IPv4 to IPv6, plus a network provider translation from IPv6 back to IPv4. so an IPv4-only app can reach an IPv4-only server over an IPv6-only network, iconic 👑. 464XLAT has the same security considerations as NAT64 and DNS64, but it can run without DNS64, which means it dodges the DNSSEC implications 🫶

2.7.3.3. DS-Lite 🧚

Dual-Stack Lite (DS-Lite) [RFC6333] is a transition technique that lets a service provider share IPv4 addresses among customers 🍓. it does this by mixing two well-known technologies: IP in IP (IPv4-in-IPv6) and IPv4 NAPT 🎀

the security stuff for DS-Lite is mostly about logging data, stopping DoS attacks from rogue devices (because the Address Family Translation Router (AFTR) [RFC6333] function is stateful 😤), and only letting registered customers use the service the AFTR provides 🔒. Section 11 of [RFC6333] and Section 2 of [RFC7785] go deeper on these important issues 📖

2.8. General Device Hardening 🛡️

with almost all devices IPv6 enabled by default, and so many endpoints having IPv6 connectivity to the Internet, it is critical to harden those devices against IPv6 attacks too 🚨. honestly it's giving "lock your doors" energy 🔐

the same techniques you use to protect devices against IPv4 attacks should also be used for IPv6, and that includes (but isn't 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 🔑
• using virus scanners to detect malicious programs 🦠

---

3. Enterprises-Specific Security Considerations 🏢

enterprises [RFC7381] usually have robust network security policies protecting their existing IPv4 networks 💼. those policies come from years of hard-earned experience securing IPv4 💅. at the very least, it's 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, meaning the part where SP employees are connected 🧑‍💻

security considerations in the enterprise can be broadly sorted into two groups: external and internal 🌗

3.1. External Security Considerations 🚪

the external side is all about security at the edge or perimeter of the enterprise network, where it meets the service provider's network 🌐. this usually happens by enforcing a security policy, either with dedicated firewalls doing stateful packet inspection or with a router using ACLs 🧱. a common default IPv4 policy on firewalls that could easily be ported to IPv6 is to allow all outbound traffic while only letting specific traffic, like established sessions, come in inbound (see [RFC6092]) ✨. Section 3.2 of [RFC7381] also gives similar recommendations 📜

here are a few more things that could level up 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 so ND and Path MTU Discovery (PMTUD) can work properly; see [RFC4890] or [REY_PF] for hosts 📡
• based on how the network is used, filter specific extension headers by accepting only the required ones (permit list approach), such as ESP and AH, and don't forget the transport layers you actually need: ICMP, TCP, UDP, etc. this filtering should happen where applicable at the edge and possibly inside the perimeter too; see [IPV6-EH-FILTERING] 🎯
• filter packets with 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 enterprise sites is totally different from IPv4 💖, where [RFC1918] addresses are often used internally and never routed over the Internet. [RFC7359] and [WEBER_VPN] explain that without careful design, IPv6 can leak out of Layer 3 VPNs 😱

3.2. Internal Security Considerations 🏠

the internal side is about security inside the perimeter of the network, including end hosts 🧸. internal networks in enterprises are often different (think a university campus, or wireless guest access), so there's no "one size fits all" recommendation 🙅‍♀️

the biggest concerns here involve Neighbor Discovery 🔍. at the network level, it's recommended that all the security considerations from Section 2.3 get reviewed carefully and considered in depth too 🧐. Section 4.1 of [RFC7381] has some recommendations on this as well 📚

as mentioned in Section 2.7.2, you need to be careful when running automated IPv6-in-IPv4 tunnels ⚠️

when site-to-site VPNs are in use, keep in mind that IPv6 global addresses have global scope, unlike the common use of IPv4 private address space [RFC1918] 🌍. that means sites might be able to talk to each other over the Internet even when the VPN mechanism isn't available 😳. so no traffic encryption is performed, and traffic could be injected from the Internet into the site; see [WEBER_VPN] 💀. it's recommended to filter packets with a source or destination address from the site's internal prefix or prefixes at the Internet connection(s), for both ingress and egress traffic 🚧

hosts need to be hardened directly through security policy to protect against security threats 🛡️. make sure you actually understand what the host firewall does by default, because third-party firewalls sometimes have no IPv6 support while the native firewall installed by default does ✨

General device hardening guidelines are in Section 2.8 📖

it's also worth noting that lots of hosts still use IPv4 to transport logs for RADIUS, DIAMETER, TACACS+, syslog, etc. 🥺. operators can't rely on an IPv6-only security policy to secure protocols that are still running over 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. the recommendations of [RFC7454] are also worth considering 📘

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 like 6rd, 6PE, MAP, and NAT64, which were analyzed in the transition and coexistence discussion (Section 2.7) 🧠

4.3. Lawful Intercept ⚖️

the lawful intercept requirements are similar for IPv6 and IPv4 architectures, and they'll be subject to the laws enforced in different geographic regions 🌏. the local issues in each jurisdiction can make this seriously challenging 😵‍💫. that's why corporate legal and privacy personnel should be involved in conversations about what information gets logged, and about the matching log retention policies 📂

the target of interception is usually a residential subscriber (e.g., his/her PPP session, physical line, or CPE MAC address) 🏡. without IPv6 NAT on the CPE, IPv6 makes it possible to intercept traffic from a single host (a /128 target) instead of the whole set of hosts behind a subscriber (which could be a /48, /60, or /64) 🎯

in mobile environments, though, the 3GPP specifications allocate a /64 per device, so it may be enough to intercept traffic from the /64 rather than specific /128s 📱. that's because each time the device sets up a data connection, it gets a new IID 🔄

5. Residential Users Security Considerations 🏡✨

okay so the IETF Home Networking (homenet) Working Group is working on standards and guidelines for IPv6 residential networks 🏠 this obviously includes operational security stuff, but it's still a work in progress 🚧 and [RFC8520] is lowkey an interesting approach to how firewalls could fetch and apply specific security policies for some residential devices 🔥

some residential users have less experience with security or networking than seasoned operators 🥺 and most recent hosts (smartphones and tablets, I'm looking at you 📱) come with IPv6 enabled by default, so IPv6 security matters a lot for them 💖 even with an IPv4-only ISP, those users can get IPv6 Internet access with the help of Teredo (Section 2.7.2.8) tunnels 🦋 and several peer-to-peer programs support IPv6, so they can start a Teredo tunnel through an IPv4 residential gateway 😭 the result is that the internal host becomes reachable from any IPv6 host on the Internet 💀 so, bestie, it is recommended that all host security products (including personal firewalls) get configured with a dual-stack security policy 🛡️💅

if the residential CPE has IPv6 connectivity, [RFC7084] defines the requirements of an IPv6 CPE 📦 and it doesn't take a side in the debate over the default IPv6 security policy, which is described in [RFC6092] 🤷‍♀️ there are two camps:

• outbound only: Allowing all internally initiated connections and blocking all externally initiated ones. This is a common default security policy enforced by IPv4 residential gateways doing NAPT 🧱 but it also breaks the end-to-end reachability promise of IPv6 💔 [RFC6092] lists several recommendations for designing such a CPE 📝
• open/transparent: Allowing all internally and externally initiated connections. This restores the end-to-end nature of the Internet for IPv6 traffic 🌈 but it means IPv6 has a different security policy than IPv4 👀

REC-49 says the user must be given a choice between those two policies [RFC6092] 🫶 giving the choice to the human is very much the moment 👑

---

6. Further Reading 📚

there are a bunch of documents that go deeper into the security of an IPv6 network 🧠 these aren't written by the IETF, and some are a little dated, but they're listed here for your 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 gives an overview of the security considerations of operating an IPv6 network 🌐 it covers both an IPv6-only network and networks using the most widely deployed IPv4/IPv6 coexistence strategies 🦋 so yes, it's a whole vibe 💖

---

8. IANA Considerations 🌷

this document has no IANA actions 🙈 nothing to register, nothing to update, we're chilling ✨

---

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> 🗑️

✨ Okay bestie, here's the rest of the references list, and it's giving very organised vibes 📚💖

[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 🫶

Okay bestie, the authors wanted to give a huge shoutout to everyone who helped make this doc better, listed 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. Literally iconic, every single one of you 👑😭

---

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

And that's the whole doc, bestie! 🌈 The authors are the girls who made it happen, so if you ever need to find them, these are their deets. 🧚💖