RFC 9099: Operational Security Considerations for IPv6

RFC 9099Operational Security Considerations for IPv6Networks

AbstractKnowledge and experience on how to operate IPv4 networks securely is available, whether theoperator is an Internet Service Provider (ISP) or an enterprise internal network. However, IPv6presents some new security challenges. RFC 4942 describes security issues in the protocol, butnetwork managers also need a more practical, operations-minded document to enumerateadvantages and/or disadvantages of certain choices.

This document analyzes the operational security issues associated with several types of networksand proposes technical and procedural mitigation techniques. This document is only applicableto managed networks, such as enterprise networks, service provider networks, or managedresidential networks.

Stream: Internet Engineering Task Force (IETF)RFC: 9099Category: InformationalPublished: August 2021 ISSN: 2070-1721Authors: É. Vyncke

CiscoK. Chittimaneni M. Kaeo

Double Shot SecurityE. ReyERNW

Status of This Memo This document is not an Internet Standards Track specification; it is published for informationalpurposes.

This document is a product of the Internet Engineering Task Force (IETF). It represents theconsensus of the IETF community. It has received public review and has been approved forpublication by the Internet Engineering Steering Group (IESG). Not all documents approved bythe IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.

Information about the current status of this document, any errata, and how to provide feedbackon it may be obtained at .https://www.rfc-editor.org/info/rfc9099

Copyright Notice Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rightsreserved.

Vyncke, et al. Informational Page 1

https://www.rfc-editor.org/rfc/rfc9099

https://www.rfc-editor.org/info/rfc9099

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETFDocuments ( ) in effect on the date of publication of thisdocument. Please review these documents carefully, as they describe your rights and restrictionswith respect to this document. Code Components extracted from this document must includeSimplified BSD License text as described in Section 4.e of the Trust Legal Provisions and areprovided without warranty as described in the Simplified BSD License.

https://trustee.ietf.org/license-info

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

RFC 9099 OPsec IPv6 August 2021


https://trustee.ietf.org/license-info

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



1. Introduction Running an IPv6 network is new for most operators not only because they are not yet used tolarge-scale IPv6 networks but also because there are subtle but critical and important differencesbetween IPv4 and IPv6, especially with respect to security. For example, all Layer 2 (L2)interactions are now done using the Neighbor Discovery Protocol (NDP) rather thanthe Address Resolution Protocol . Also, there is no Network Address Port Translation(NAPT) defined in for IPv6 even if specifies an IPv6-to-IPv6 Network PrefixTranslation (NPTv6), which is a 1-to-1 mapping of IPv6 addresses. Another important differenceis that IPv6 is extensible with the use of extension headers.

IPv6 networks are deployed using a variety of techniques, each of which have their own specificsecurity concerns.

This document complements by listing security issues when operating a network(including various transition technologies). It also provides operational deployment experienceswhere warranted.

1.1. Applicability Statement This document is applicable to managed networks, i.e., when the network is operated by the userorganization itself. Indeed, many of the recommended mitigation techniques must be configuredwith detailed knowledge of the network (which are the default routers, the switch trunk ports,etc.). This covers Service Providers (SPs), enterprise networks, and some knowledgeable home-user-managed residential networks. This applicability statement especially applies to Sections 2.3and 2.5.4.

6. Further Reading

7. Security Considerations

8. IANA Considerations

9. References

9.1. Normative References

9.2. Informative References

Acknowledgements

Authors' Addresses

[RFC4861][RFC0826]

[RFC2663] [RFC6296]

[RFC4942]



1.2. Requirements Language The key words " ", " ", " ", " ", " ", " ", "

", " ", " ", " ", and " " in this document are tobe interpreted as described in BCP 14 when, and only when, they appear inall capitals, as shown here.

MUST MUST NOT REQUIRED SHALL SHALL NOT SHOULD SHOULDNOT RECOMMENDED NOT RECOMMENDED MAY OPTIONAL

[RFC2119] [RFC8174]

2. Generic Security Considerations

2.1. Addressing IPv6 address allocations and overall architecture are important parts of securing IPv6. Initialdesigns, even if intended to be temporary, tend to last much longer than expected. Although IPv6was initially thought to make renumbering easy, in practice, it may be extremely difficult torenumber without a proper IP Address Management (IPAM) system. introduces themechanisms that could be utilized for IPv6 site renumbering and tries to cover most of theexplicit issues and requirements associated with IPv6 renumbering.

A key task for a successful IPv6 deployment is to prepare an addressing plan. Because anabundance of address space is available, structuring an address plan around both services andgeographic locations allows address space to become a basis for more structured security policiesto permit or deny services between geographic regions. documents some operationalconsiderations of using different prefix sizes for address assignments at end sites.

A common question is whether companies should use Provider-Independent (PI) or Provider-Aggregated (PA) space , but, from a security perspective, there is little difference.However, one aspect to keep in mind is who has administrative ownership of the address spaceand who is technically responsible if/when there is a need to enforce restrictions on routabilityof the space, e.g., due to malicious criminal activity originating from it. Relying on PA addressspace may also increase the perceived need for address translation techniques, such as NPTv6;thereby, the complexity of the operations, including the security operations, is augmented.

In , it is recommended that IPv6 network deployments provide multiple IPv6 addressesfrom each prefix to general-purpose hosts, and it specifically does not recommend limiting a hostto only one IPv6 address per prefix. It also recommends that the network give the host the abilityto use new addresses without requiring explicit requests (for example, by using Stateless AddressAutoconfiguration (SLAAC)). Privacy extensions, as of , constitute one of the mainscenarios where hosts are expected to generate multiple addresses from the same prefix, andhaving multiple IPv6 addresses per interface is a major change compared to the unique IPv4address per interface for hosts (secondary IPv4 addresses are not common), especially for audits(see Section 2.6.2.3).

[RFC7010]

[RFC6177]

[RFC7381]

[RFC7934]

[RFC8981]



2.1.3. Loopback Addresses

Many operators reserve a /64 block for all loopback addresses in their infrastructure and allocatea /128 out of this reserved /64 prefix for each loopback interface. This practice facilitatesconfiguration of Access Control List (ACL) rules to enforce a security policy for those loopbackaddresses.

2.1.1. Use of ULAs

Unique Local Addresses (ULAs) are intended for scenarios where interfaces are notglobally reachable, despite being routed within a domain. They formally have global scope, but

specifies that they must be filtered at domain boundaries. ULAs are different from theaddresses described in and have different use cases. One use of ULAs is described in

; another one is for internal communication stability in networks where externalconnectivity may come and go (e.g., some ISPs provide ULAs in home networks connected via acable modem). It should further be kept in mind that ULA /48s from the fd00::/8 space (L=1) be generated with a pseudorandom algorithm, per .

[RFC4193]

[RFC4193][RFC1918]

[RFC4864]

MUSTSection 3.2.1 of [RFC4193]

2.1.2. Point-to-Point Links

specifies the rationale of using /127 for inter-router, point-to-point linksto prevent the ping-pong issue between routers not correctly implementing , and it alsoprevents a denial-of-service (DoS) attack on the Neighbor Cache. The previous recommendationof has been obsoleted and marked Historic by .

Some environments are also using link-local addressing for point-to-point links. While thispractice could further reduce the attack surface of infrastructure devices, the operationaldisadvantages also need to be carefully considered; see .

Section 5.1 of [RFC6164][RFC4443]

[RFC3627] [RFC6547]

[RFC7404]

2.1.4. Stable Addresses

When considering how to assign stable addresses for nodes (either by static configuration or bypre-provisioned DHCPv6 lease (Section 2.1.6)), it is necessary to take into consideration theeffectiveness of perimeter security in a given environment.

There is a trade-off between ease of operation (where some portions of the IPv6 address could beeasily recognizable for operational debugging and troubleshooting) versus the risk of trivialscanning used for reconnaissance. shows that there are scientifically basedmechanisms that make scanning for IPv6-reachable nodes more feasible than expected; see

.

Stable addresses also allow easy enforcement of a security policy at the perimeter based on IPv6addresses. For example, is a mechanismwhere the perimeter defense can retrieve the security policy template based on the type ofinternal device and apply the right security policy based on the device's IPv6 address.

The use of well-known IPv6 addresses (such as ff02::1 for all link-local nodes) or the use ofcommonly repeated addresses could make it easy to figure out which devices are name servers,routers, or other critical devices; even a simple traceroute will expose most of the routers on a

[SCANNING]

[RFC7707]

Manufacturer Usage Description (MUD) [RFC8520]



https://www.rfc-editor.org/rfc/rfc4193#section-3.2.1

https://www.rfc-editor.org/rfc/rfc6164#section-5.1

path. There are many scanning techniques possible and operators should not rely on the'impossible to find because my address is random' paradigm (a.k.a. "security by obscurity") evenif it is common practice to have the stable addresses randomly distributed across /64 subnets andto always use DNS (as IPv6 addresses are hard for human brains to remember).

While, in some environments, obfuscating addresses could be considered an added benefit, itshould not preclude enforcement of perimeter rules. Stable addresses following some logicalallocation scheme may ease the operation (as simplicity always helps security).

Typical deployments will have a mix of stable and non-stable addresses; the stable addressesbeing either predictable (e.g., ::25 for a mail server) or obfuscated (i.e., appearing as a random 64-bit number).

2.1.5. Temporary Addresses for SLAAC

Historically, Stateless Address Autoconfiguration (SLAAC) makes up the globally unique IPv6address based on an automatically generated 64-bit interface identifier (IID) based on the 64-bitExtended Unique Identifier (EUI-64) Media Access Control (MAC) address combined with the /64prefix (received in the Prefix Information Option (PIO) of the Router Advertisement (RA)). TheEUI-64 address is generated from the stable 48-bit MAC address and does not change even if thehost moves to another network; this is of course bad for privacy, as a host can be traced fromnetwork (home) to network (office or Wi-Fi in hotels). recommends against the use ofEUI-64 addresses, and it must be noted that most host operating systems do not use EUI-64addresses anymore and rely on either or .

Randomly generating an interface ID, as described in , is part of SLAAC with so-calledprivacy extension addresses and is used to address some privacy concerns. Privacy extensionaddresses, a.k.a. temporary addresses, may help to mitigate the correlation of activities of a nodewithin the same network and may also reduce the attack exposure window. But using privacyextension addresses as described in might prevent the operator from building host-specific access control lists (ACLs). These privacy extension addresses could also be used toobfuscate some malevolent activities, and specific user attribution/accountability proceduresshould be put in place, as described in Section 2.6.

combined with the address generation mechanism of specifies another wayto generate an address while still keeping the same IID for each network prefix; this allowsSLAAC nodes to always have the same stable IPv6 address on a specific network while havingdifferent IPv6 addresses on different networks.

In some specific use cases where user accountability is more important than user privacy,network operators may consider disabling SLAAC and relying only on DHCPv6; however, not alloperating systems support DHCPv6, so some hosts will not get any IPv6 connectivity. DisablingSLAAC and privacy extension addresses can be done for most operating systems by sending RAmessages with a hint to get addresses via DHCPv6 by setting the M-bit and disabling SLAAC byresetting all A-bits in all PIOs. However, attackers could still find ways to bypass this mechanismif it is not enforced at the switch/router level.

[RFC8064]

[RFC8981] [RFC8064]

[RFC8981]

[RFC8981]

[RFC8064] [RFC7217]



However, in scenarios where anonymity is a strong desire (protecting user privacy is moreimportant than user attribution), privacy extension addresses should be used. Whenmechanisms recommended by are available, the stable privacy address is probably agood balance between privacy (among different networks) and security/user attribution (withina network).

[RFC8064]

2.1.6. DHCP Considerations

Some environments use DHCPv6 to provision addresses and other parameters in order to ensureauditability 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 (Section2.3.3). It must be noted that, as opposed to DHCPv4, DHCPv6 can lease several IPv6 addresses perclient. For DHCPv4, the lease is bound to the 'client identifier', which may contain a hardwareaddress or another type of identifier, such as a DNS name. For DHCPv6, the lease is bound to theclient DHCP Unique Identifier (DUID), which may or may not be bound to the client L2 address.

describes the privacy issues associated with the use of DHCPv6 by Internet users. Theanonymity profiles are designed for clients that wish to remain anonymous to thevisited network. recommends that DHCPv6 servers issue addresses randomly from alarge pool.

[RFC7824][RFC7844]

[RFC7707]

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 environments that need to be understood.Specifically, the interactions and the potential of interference with DNSSEC implementation need to be understood -- these are pointed out in more detail in Section 2.7.3.2.

[RFC6147][RFC4033]

2.1.8. Using a /64 per Host

An interesting approach is using a /64 per host, as proposed in , especially in a sharedenvironment. This allows for easier user attribution (typically based on the host MAC address), asits /64 prefix is stable, even if applications within the host can change their IPv6 address withinthis /64 prefix.

This can also be useful for the generation of ACLs once individual systems (e.g., adminworkstations) have their own prefixes.

[RFC8273]

2.1.9. Privacy Consideration of Addresses

In addition to the security aspects of IPv6 addresses, there are also privacy considerations:mainly because they are of global scope and visible globally. goes into more detail onthe privacy considerations for IPv6 addresses by comparing the manually configured IPv6address, DHCPv6, and SLAAC.

[RFC7721]

2.2. Extension HeadersExtension headers are an important difference between IPv4 and IPv6. In IPv4-based packets, it'strivial to find the upper-layer protocol type and protocol header, while, in IPv6, it is morecomplex since the extension header chain must be parsed completely (even if not processed) in



order to find the upper-layer protocol header. IANA has closed the existing empty "Next HeaderTypes" registry to new entries and is redirecting its users to the "IPv6 Extension Header Types"registry, per .

Extension headers have also become a very controversial topic since forwarding nodes thatdiscard packets containing extension headers are known to cause connectivity failures anddeployment problems . Understanding the role of various extension headers isimportant, and this section enumerates the ones that need careful consideration.

A clarification on how intermediate nodes should handle packets with existing or futureextension headers is found in . The uniform TLV format to be used for defining futureextension headers is described in . Sections 5.2 and 5.3 of provide moreinformation on the processing of extension headers by IPv6 nodes.

Vendors of filtering solutions and operations personnel responsible for implementing packetfiltering rules should be aware that the 'Next Header' field in an IPv6 header can both point to anIPv6 extension header or to an upper-layer protocol header. This has to be considered whendesigning the user interface of filtering solutions or during the creation of filtering rule sets.

discusses filtering rules for those extension headers at transit routers.

2.2.1. Order and Repetition of Extension Headers

While recommends the order and the maximum repetition of extension headers, atthe time of writing, there are still IPv6 implementations that support an order of headers that isnot recommended (such as Encapsulating Security Payload (ESP) before routing) or an illegalrepetition of headers (such as multiple routing headers). The same applies for options containedin the extension headers (see ). In some cases, it has led to nodes crashingwhen receiving or forwarding wrongly formatted packets.

A firewall or edge device should be used to enforce the recommended order and the maximumoccurrences of extension headers by dropping nonconforming packets.

2.2.2. Hop-by-Hop Options Header

In the previous IPv6 specification , the hop-by-hop options header, when present in anIPv6 packet, forced all nodes to inspect and possibly process this header. This enabled denial-of-service attacks as most, if not all, routers cannot process this type of packet in hardware; theyhave to process these packets in software and, hence, this task competes with other softwaretasks, such as handling the control and management plane processing.

, the current Internet Standard for IPv6, has taken this attack vector intoaccount and made the processing of hop-by-hop options headers by intermediate routersexplicitly configurable.

[RFC7045]

[RFC7872]

[RFC7045][RFC6564] [RFC8504]

[IPV6-EH-FILTERING]

[RFC8200]

[IPV6-EH-PARSING]

[RFC2460]

Section 4.3 of [RFC8200]






2.2.4. IP Security Extension Header

The extension headers ( and ) are required if IPsec is to be utilized for network-level security. Previously, IPv6

mandated implementation of IPsec, but updated that recommendation by makingsupport of the IPsec architecture a ' ' for all IPv6 nodes that are also retained inthe latest IPv6 Nodes Requirement standard .

2.2.3. Fragment Header

The fragment header is used by the source (and only the source) when it has to fragment packets. and explain why it is important that:

Firewall and security devices should drop first fragments that do not contain the entire IPv6header chain (including the transport-layer header). Destination nodes should discard first fragments that do not contain the entire IPv6 headerchain (including the transport-layer header).

If those requirements are not met, stateless filtering could be bypassed by a hostile party. 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). describes how the RA-Guard function described in should behave in the presence offragmented RA packets.

[RFC7112] Section 4.5 of [RFC8200]

•

•

[RFC6980][RFC7113]

[RFC6105]

IPsec [RFC4301] Authentication Header (AH) [RFC4302] ESP[RFC4303]

[RFC6434][RFC4301] SHOULD

[RFC8504]

2.3. Link-Layer Security IPv6 relies heavily on NDP to perform a variety of link operations, such as discoveringother nodes on the link, resolving their link-layer addresses, and finding routers on the link. Ifnot secured, NDP is vulnerable to various attacks, such as router/neighbor message spoofing,redirect attacks, Duplicate Address Detection (DAD) DoS attacks, etc. Many of these securitythreats to NDP have been documented in "IPv6 Neighbor Discovery (ND) Trust Models andThreats" and in "Operational Neighbor Discovery Problems" .

Most of the issues are only applicable when the attacker is on the same link, but NDP also hassecurity issues when the attacker is off link; see Section 2.3.1 below.

[RFC4861]

[RFC3756] [RFC6583]

2.3.1. Neighbor Solicitation Rate-Limiting

NDP can be vulnerable to remote DoS attacks, for example, when a router is forced to performaddress resolution for a large number of unassigned addresses, i.e., when a prefix is scanned byan attacker in a fast manner. This can keep new devices from joining the network or render thelast-hop router ineffective due to high CPU usage. Easy mitigative steps include rate limitingNeighbor Solicitations, restricting the amount of state reserved for unresolved solicitations, andcleverly managing the cache/timer.




discusses the potential for off-link DoS in detail and suggests implementationimprovements and operational mitigation techniques that may be used to mitigate or alleviatethe impact of such attacks. Here are some feasible mitigation options that can be employed bynetwork operators today:

Ingress filtering of unused addresses by ACL. These require stable configuration of theaddresses, e.g., allocating the addresses out of a /120 and using a specific ACL to only allowtraffic 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 asthe number of Neighbor Cache entries in 'incomplete' state (e.g., 256 incomplete entries perinterface) or the rate of NA per interface (e.g., 100 NA per second). Using a /127 on a point-to-point link, per . Using only link-local addresses on links where there are only routers; see .

[RFC6583]

•

•

• [RFC6164]• [RFC7404]

2.3.2. Router and Neighbor Advertisements Filtering

2.3.2.2. Neighbor Advertisement Filtering The Source Address Validation Improvements (savi) Working Group has worked on other ways tomitigate the effects of such attacks. helps in creating bindings between a source IPaddress assigned to DHCPv4 or DHCPv6 and a binding anchor on

2.3.2.1. Router Advertisement Filtering Router Advertisement spoofing is a well-known, on-link attack vector and has been extensivelydocumented. The presence of rogue RAs, either unintentional or malicious, can cause partial orcomplete failure of operation of hosts on an IPv6 link. For example, a node can select anincorrect router address, which can then be used for an on-path attack, or the node can assumewrong prefixes to be used for SLAAC. summarizes the scenarios in which rogue RAsmay be observed and presents a list of possible solutions to the problem. (RA-Guard)describes a solution framework for the rogue RA problem where network segments are designedaround switching devices that are capable of identifying invalid RAs and blocking them beforethe attack packets actually reach the target nodes.

However, several evasion techniques that circumvent the protection provided by RA-Guard havesurfaced. A key challenge to this mitigation technique is introduced by IPv6 fragmentation.Attackers can conceal their attack by fragmenting their packets into multiple fragments such thatthe switching device that is responsible for blocking invalid RAs cannot find all the necessaryinformation to perform packet filtering of the same packet. describes such evasiontechniques and provides advice to RA-Guard implementers such that the aforementionedevasion vectors can be eliminated.

Given that the IPv6 Fragmentation Header can be leveraged to circumvent someimplementations of RA-Guard, updates such that use of the IPv6Fragmentation Header is forbidden in all Neighbor Discovery messages, except "CertificationPath Advertisement", thus allowing for simple and effective measures to counter fragmentedNDP attacks.

[RFC6104][RFC6105]

[RFC7113]

[RFC6980] [RFC4861]

[RFC7513][RFC2131] [RFC8415] [RFC7039]



a SAVI device. Also, describes how to glean similar bindings when DHCP is not used.The bindings can be used to filter packets generated on the local link with forged source IPaddresses.

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

A more drastic technique to prevent all NDP attacks is based on isolation of all hosts with specificconfigurations. In such a scenario, hosts (i.e., all nodes that are not routers) are unable to senddata-link layer frames to other hosts; therefore, no host-to-host attacks can happen. This specificsetup can be established on some switches or Wi-Fi access points. This is not always feasiblewhen hosts need to communicate with other hosts in the same subnet, e.g., for access to fileshares.

2.3.2.4. NDP Recommendations It is still recommended that RA-Guard and SAVI be employed as a first line of defense againstcommon attack vectors, including misconfigured hosts. This recommendation also applies whenDHCPv6 is used, as RA messages are used to discover the default router(s) and for on-link prefixdetermination. This line of defense is most effective when incomplete fragments are dropped byrouters and L2 switches, as described in Section 2.2.3. The generated log should also be analyzedto identify and act on violations.

Network operators should be aware that RA-Guard and SAVI do not work as expected or couldeven be harmful in specific network configurations (notably when there could be multiplerouters).

Enabling RA-Guard by default in managed networks (e.g., Wi-Fi networks, enterprise campusnetworks, etc.) should be strongly considered except for specific use cases, such as in thepresence of homenet devices emitting router advertisements.

[RFC6620]

2.3.3. Securing DHCP

The Dynamic Host Configuration Protocol for IPv6 (DHCPv6), as described in , enablesDHCP servers to pass configuration parameters, such as IPv6 network addresses and otherconfiguration information, to IPv6 nodes. DHCP plays an important role in most large networksby providing robust stateful configuration in the context of automated system provisioning.

The two most common threats to DHCP clients come from malicious (a.k.a. rogue) orunintentionally misconfigured DHCP servers. In these scenarios, a malicious DHCP server isestablished with the intent of providing incorrect configuration information to the clients tocause a denial-of-service attack or to mount an on-path attack. While unintentional, amisconfigured DHCP server can have the same impact. Additional threats against DHCP arediscussed in the security considerations section of .

[RFC8415]

[RFC8415]



2.3.5. Impact of Multicast Traffic

IPv6 uses multicast extensively for signaling messages on the local link to avoid broadcastmessages for on-the-wire efficiency.

The use of multicast has some side effects on wireless networks, such as a negative impact onbattery life of smartphones and other battery-operated devices that are connected to suchnetworks. and (for specific wireless networks) discuss methods to rate-limitRAs and other ND messages on wireless networks in order to address this issue.

The use of link-layer multicast addresses (e.g., ff02::1 for the all nodes link-local multicastaddress) could also be misused for an amplification attack. Imagine a hostile node sending anICMPv6 ECHO_REQUEST to ff02::1 with a spoofed source address, then all link-local nodes willreply with ICMPv6 ECHO_REPLY packets to the source address. This could be a DoS attack for theaddress owner. This attack is purely local to the L2 network, as packets with a link-localdestination are never forwarded by an IPv6 router.

specifies a mechanism for protecting connected DHCPv6 clients againstrogue DHCPv6 servers. This mechanism is based on DHCPv6 packet filtering at the L2 device, i.e.,the administrator specifies the interfaces connected to DHCPv6 servers. However, extensionheaders could be leveraged to bypass DHCPv6-Shield unless is enforced.

It is recommended to use DHCPv6-Shield and to analyze the corresponding log messages.

DHCPv6-Shield [RFC7610]

[RFC7112]

2.3.4. 3GPP Link-Layer Security

The 3GPP link is a point-to-point-like link that has no link-layer address. This implies there canonly be one end host (the mobile handset) and the first-hop router (i.e., a Gateway GPRS SupportNode (GGSN) or a Packet Data Network Gateway (PGW)) on that link. The GGSN/PGW neverconfigures a non-link-local address on the link using the advertised /64 prefix on it; see Section2.1.8. The advertised prefix must not be used for on-link determination. There is no need foraddress resolution on the 3GPP link, since there are no link-layer addresses. Furthermore, theGGSN/PGW assigns a prefix that is unique within each 3GPP link that uses IPv6 Stateless AddressAutoconfiguration. This avoids the necessity to perform DAD at the network level for everyaddress generated by the mobile host. The GGSN/PGW always provides an IID to the cellular hostfor the purpose of configuring the link-local address and ensures the uniqueness of the IID on thelink (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, theGGSN/PGW only needs to route all traffic to the mobile host that falls under the prefix assigned toit. As there is also a single host on the 3GPP link, there is no need to defend that IPv6 address.

See for a more detailed discussion on the 3GPP link model, NDP, and theaddress configuration details. In some mobile networks, DHCPv6 and DHCP Prefix Delegation(DHCP-PD) are also used.

Section 5 of [RFC6459]

[RFC7772] [RFC6775]



https://www.rfc-editor.org/rfc/rfc6459#section-5

This is the reason why large Wi-Fi network deployments often limit the use of link-layermulticast, either from or to the uplink of the Wi-Fi access point, i.e., Wi-Fi stations are preventedto send link-local multicast to their direct neighboring Wi-Fi stations; this policy also blocksservice discovery via Multicast DNS (mDNS) and Link-Local Multicast NameResolution (LLMNR) .

[RFC6762][RFC4795]

2.3.6. SEND and CGA

SEcure Neighbor Discovery (SEND), as described in , is a mechanism that was designedto secure ND messages. This approach involves the use of new NDP options to carry public-key-based signatures. Cryptographically Generated Addresses (CGA), as described in , areused to ensure that the sender of a Neighbor Discovery message is the actual "owner" of theclaimed IPv6 address. A new NDP option, the CGA option, was introduced and is used to carry thepublic key and associated parameters. Another NDP option, the RSA Signature option, is used toprotect all messages relating to neighbor and router discovery.

SEND protects against:

Neighbor Solicitation/Advertisement Spoofing Neighbor Unreachability Detection Failure Duplicate Address Detection DoS Attack Router Solicitation and Advertisement Attacks Replay Attacks Neighbor Discovery DoS Attacks

SEND does NOT:

protect statically configured addresses protect addresses configured using fixed identifiers (i.e., EUI-64) provide confidentiality for NDP communications compensate for an unsecured link -- SEND does not require that the addresses on the linkand Neighbor Advertisements correspond

However, at this time and over a decade since their original specifications, CGA and SEND do nothave support from widely deployed IPv6 devices; hence, their usefulness is limited and shouldnot be relied upon.

[RFC3971]

[RFC3972]

• • • • • •

• • • •

2.4. Control Plane Security defines the router control plane and provides detailed guidance to secure it for IPv4

and IPv6 networks. This definition is repeated here for the reader's convenience. Please note thatthe definition is completely protocol-version agnostic (most of this section applies to IPv6 in thesame way as to IPv4).

[RFC6192]



Preamble: IPv6 control plane security is vastly congruent with its IPv4 equivalent,with the exception of OSPFv3 authentication (Section 2.4.1) and some packetexceptions (see Section 2.4.3) that are specific to IPv6.

Modern router architecture design maintains a strict separation of forwarding and routercontrol plane hardware and software. The router control plane supports routing andmanagement functions. It is generally described as the router architecture hardware andsoftware components for handling packets destined to the device itself as well as building andsending packets originated locally on the device. The forwarding plane is typically described asthe router architecture hardware and software components responsible for receiving a packeton an incoming interface, performing a lookup to identify the packet's IP next hop and bestoutgoing interface towards the destination, and forwarding the packet through the appropriateoutgoing interface.

While the forwarding plane is usually implemented in high-speed hardware, the control plane isimplemented by a generic processor (referred to as the routing processor (RP)) and cannotprocess packets at a high rate. Hence, this processor can be attacked by flooding its input queuewith more packets than it can process. The control plane processor is then unable to processvalid control packets and the router can lose IGP or BGP adjacencies, which can cause a severenetwork disruption.

provides detailed guidance to protect the router control plane in IPv6 networks. Therest 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-specificprotection should also be done (for example, a spoofed OSPFv3 packet could trigger theexecution of the Dijkstra algorithm; therefore, the frequency of Dijkstra calculations shouldalso 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 FlowInformation Export (IPFIX), etc.

Packet exceptions:normal data packets that require a specific processing, such as generating a packet-too-bigICMP message or processing the hop-by-hop options header

[RFC6192]

•

•



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 RPshould 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 impossibleon some routers that are unable to parse the IPsec ESP or AH extension headersduring ACL classification.

Rate-limiting of the valid packets should be done; see for a side benefit for OSPv3. Theexact configuration will depend on the available resources of the router (CPU, Ternary Content-Addressable Memory (TCAM), etc.).

•

• •

[RFC8541]

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 securityperimeter or by using specific features of the platform) should be configured for packets destinedto the RP, such as:

drop packets destined to the routers, except those belonging to protocols that are used (forexample, 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 SSHconnections should only be originated from the Network Operation Center (NOC), then theACL 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 theavailable router resources.

•

•

2.4.3. Packet Exceptions

This class covers multiple cases where a data plane packet is punted to the route processorbecause it requires specific processing:

generation of an ICMP packet-too-big message when a data plane packet cannot beforwarded 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 beforwarded 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 beforwarded for any reason; processing of the hop-by-hop options header; new implementations follow

where this processing is optional; or more specific to some router implementations, an oversized extension header chain thatcannot 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 thatrequires some packets to be 'punted' to the generic RP. This could include, for example, theprocessing of a long extension header chain in order to apply an ACL based on Layer 4information. and more generally highlight the security implications ofoversized extension header chains on routers and update the original IPv6 specifications

such that the first fragment of a packet is required to contain the entire IPv6 headerchain. Those changes are incorporated in the IPv6 standard .

An ingress ACL cannot mitigate a control plane attack using these packet exceptions. The onlyprotection for the RP is to rate-limit those packet exceptions that are forwarded to the RP. Thismeans that some data plane packets will be dropped without an ICMP message sent to thesource, which may delay Path MTU Discovery and cause drops.

In addition to limiting the rate of data plane packets queued to the RP, it is also important to rate-limit the generation of ICMP messages. This is important both to preserve RP resources and alsoto prevent an amplification attack using the router as a reflector. It is worth noting that someplatforms implement this rate-limiting in hardware. Of course, a consequence of not generatingan ICMP message will break some IPv6 mechanisms, such as Path MTU Discovery or a simpletraceroute.

•

• Section 4.3 of[RFC8200]

•

[RFC6980] [RFC7112]

[RFC2460][RFC8200]

2.5. Routing Security

Preamble: IPv6 routing security is congruent with IPv4 routing security, with theexception of OSPv3 neighbor authentication (see Section 2.5.2).

Routing security in general can be broadly divided into three sections:

authenticating neighbors/peers securing routing updates between peers route filtering

is also applicable to IPv6 and can ensure that routing protocol packets are comingfrom 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 isrequired.

1. 2. 3.

[RFC5082]




2.5.1. BGP Security

As BGP is identical for IPv4 and IPv6 and as covers all the security aspects for BGP indetail, is also applicable to IPv6.

[RFC7454][RFC7454]

2.5.2. Authenticating OSPFv3 Neighbors

OSPFv3 can rely on IPsec to fulfill the authentication function. Operators should note that IPsecsupport is not standard on all routing platforms. In some cases, this requires specializedhardware that offloads crypto over to dedicated Application-Specific Integrated Circuits (ASICs)or enhanced software images (both of which often come with added financial cost) to providesuch functionality. An added detail is to determine whether OSPFv3 IPsec implementations useAH or ESP-NULL for integrity protection. In early implementations, all OSPFv3 IPsecconfigurations relied on AH since the details weren't specified in . However, thedocument that specifically describes how IPsec should be implemented for OSPFv3 states that "implementations support ESP[-NULL] and support AH" since it follows theoverall IPsec standards wording. OSPFv3 can also use normal ESP to encrypt the OSPFv3 payloadto provide confidentiality for the routing information.

changes OSPFv3 reliance on IPsec by appending an authentication trailer to the end ofthe OSPFv3 packets. It does not authenticate the specific originator of an OSPFv3 packet; rather, itallows a router to confirm that the packet has been issued by a router that had access to theshared authentication key.

With all authentication mechanisms, operators should confirm that implementations cansupport rekeying mechanisms that do not cause outages. There have been instances where anyrekeying causes outages; therefore, the trade-off between utilizing this functionality needs to beweighed against the protection it provides. documents some guidelines for crypto keysmanagement.

[RFC5340][RFC4552]

MUST MAY

[RFC7166]

[RFC4107]

2.5.3. Securing Routing Updates

IPv6 initially mandated the provisioning of IPsec capability in all nodes. However, in the updatedIPv6 Nodes Requirement standard , IPsec is a ' ' and not a ' 'implementation. Theoretically, it is possible that all communication between two IPv6 nodes,especially routers exchanging routing information, is encrypted using IPsec. However, inpractice, deploying IPsec is not always feasible given hardware and software limitations of thevarious platforms deployed.

Many routing protocols support the use of cryptography to protect the routing updates; the use ofthis protection is recommended. is a YANG data model for key chains that includesrekeying functionality.

[RFC8504] SHOULD MUST

[RFC8177]



2.5.4. Route Filtering

Route filtering policies will be different depending on whether they pertain to edge routefiltering or internal route filtering. At a minimum, the IPv6 routing policy, as it pertains torouting between different administrative domains, should aim to maintain parity with IPv4 froma policy perspective, for example:

filter internal-use IPv6 addresses that are not globally routable at the perimeter; discard routes for bogon and reserved space (see ); and configure ingress route filters that validate route origin, prefix ownership, etc., through theuse of various routing databases, e.g., . formally validates the originAutonomous Systems (ASes) of BGP announcements.

Some good guidance can be found at .

A valid routing table can also be used to apply network ingress filtering (see ).

• • [CYMRU] [RFC8190]•

[RADB] [RFC8210]

[RFC7454]

[RFC2827]

2.6. Logging/Monitoring In order to perform forensic research in the cases of a security incident or detecting abnormalbehavior, network operators should log multiple pieces of information. In some cases, thisrequires a frequent poll of devices via a Network Management Station.

This logging should include but is not limited to:

logs of all applications using the network (including user space and kernel space) whenavailable (for example, web servers that the network operator manages); data from , also known as IPFIX; data from various SNMP or YANG data via or

; historical data of Neighbor Cache entries;

lease cache, especially when a is used; 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

accounting records.

Please note that there are privacy issues or regulations related to how these logs are collected,stored, used, and safely discarded. Operators are urged to check their country legislation (e.g.,General Data Protection Regulation in the European Union).

All those pieces of information can be used for:

investigations: who did what and when?

•

• IP Flow Information Export [RFC7011]• MIBs [RFC4293] RESTCONF [RFC8040]

NETCONF [RFC6241]• • stateful DHCPv6 [RFC8415] relay agent [RFC6221]• Source Address Validation Improvement (SAVI) [RFC7039]

• • • RADIUS [RFC2866]

[GDPR]

• forensic (Section 2.6.2.1)



: which IP addresses were used by a specific node (assuming theuse of )?

: which IPv6 nodes are on my network? : 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.).

• correlation (Section 2.6.2.3)privacy extensions addresses [RFC8981]

• inventory (Section 2.6.2.2)• abnormal behavior detection (Section 2.6.2.4)

2.6.1. Data Sources

This section lists the most important sources of data that are useful for operational security.

2.6.1.1. Application Logs Those logs are usually text files where the remote IPv6 address is stored in cleartext (not binary).This can complicate the processing since one IPv6 address, for example, 2001:db8::1, can bewritten 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).

explains this problem in detail and recommends the use of a single canonical format.This document recommends the use of for IPv6 addresses in allpossible cases. If the existing application cannot log using the canonical format, then it isrecommended to use an external post-processing program in order to canonicalize all IPv6addresses.

2.6.1.2. IP Flow Information Export by IPv6 Routers 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 .

Moreover, IPFIX is very efficient in terms of data handling and transport. It can also aggregateflows by a key, such as sourceMacAddress, in order to have aggregated data associated with aspecific sourceMacAddress. This memo recommends the use of IPFIX and aggregation onnextHeaderIPv6, sourceIPv6Address, and sourceMacAddress.

• • •

[RFC5952]canonical format [RFC5952]

IPFIX [RFC7012]

• •

[IANA-IPFIX]

2.6.1.3. SNMP MIB and NETCONF/RESTCONF YANG Modules Data by IPv6 Routers 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

[RFC4293]

•



ipNetToPhysicalTable table, which is the content of the Neighbor Cache, i.e., the mappingbetween IPv6 and data-link layer addresses.

There are also YANG modules relating to the two IP address families and that can be used with and . This memo recommends the use of:

interfaces-state/interface/statistics from , whichcontains counters for interfaces, and ipv6/neighbor from , which is the content of the NeighborCache, i.e., the mapping between IPv6 and data-link layer addresses.

•

[RFC6241] [RFC8040]

• [email protected] [RFC8343]

• [email protected] [RFC8344]

2.6.1.4. Neighbor Cache of IPv6 Routers The Neighbor Cache of routers contains all mappings between IPv6 addresses and data-link layeraddresses. There are multiple ways to collect the current entries in the Neighbor Cache, notably,but not limited to:

using the , as explained above; using streaming telemetry or and to collect theoperational state of the Neighbor Cache; and connecting over a secure management channel (such as SSH) and explicitly requesting aNeighbor Cache dump via the Command-Line Interface (CLI) or another monitoringmechanism.

The Neighbor Cache is highly dynamic, as mappings are added when a new IPv6 address appearson the network. This could be quite frequently with orwhen they are removed when the state goes from UNREACH to removed (the default time for aremoval per algorithm is 38 seconds for a hostusing Windows 7). This means that the content of the Neighbor Cache must be fetchedperiodically at an interval that does not exhaust the router resources and still provides valuableinformation (the suggested value is 30 seconds, but this should be verified in the actualdeployment) and stored for later use.

This is an important source of information because it is trivial (on a switch not using the algorithm) to defeat the mapping between data-link layer address and an IPv6

address. Put another way, having access to the current and past content of the Neighbor Cachehas a paramount value for the forensic and audit trails. It should also be noted that, in certainthreat 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 theallocated prefixes when combined with strict source address prefix enforcement on the routersand L2 switches to prevent IPv6 spoofing.

• SNMP MIB (Section 2.6.1.3)• NETCONF [RFC6241] RESTCONF [RFC8040]

•

privacy extension addresses [RFC8981]

Neighbor Unreachability Detection [RFC4861]

SAVI[RFC7039]



2.6.1.7. Other Data Sources There are other data sources for log information that must be collected (as currently collected inIPv4 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.1.5. Stateful DHCPv6 Lease In some networks, IPv6 addresses/prefixes are managed by a stateful that leases IPv6 addresses/prefixes to clients. It is indeed quite similar to DHCP for IPv4, so it canbe tempting to use this DHCP lease file to discover the mapping between IPv6 addresses/prefixesand data-link layer addresses, as is commonly used in IPv4 networking.

It is not so easy in the IPv6 networks, because not all nodes will use DHCPv6 (there are nodes thatcan only do stateless autoconfiguration) and also because DHCPv6 clients are identified not bytheir hardware-client address, as in IPv4, but by a DHCP Unique Identifier (DUID). The DUID canhave several formats: the data-link layer address, the data-link layer address prepended withtime information, or even an opaque number that requires correlation with another data sourceto be usable for operational security. Moreover, when the DUID is based on the data-link address,this address can be of any client interface (such as the wireless interface, while the client actuallyuses its wired interface to connect to the network).

If a is used in a L2 switch, then the DHCP servers alsoreceive the interface ID information, which could be saved in order to identify the interface onwhich the switch received a specific leased IPv6 address. Also, if a 'normal' (not lightweight) relayagent adds the data-link layer address in the option for Relay Agent Remote-ID

, then the DHCPv6 server can keep track of the data-link and leased IPv6 addresses.

In short, the DHCPv6 lease file is less interesting than lease files for IPv4 networks. If possible, itis recommended to use DHCPv6 servers that keep the relayed data-link layer address in additionto the DUID in the lease file, as those servers have the equivalent information to IPv4 DHCPservers.

The mapping between the data-link layer address and the IPv6 address can be secured bydeploying switches implementing the mechanisms. Of course, this also requiresthat the data-link layer address be protected by using a L2 mechanism, such as .

DHCPv6 server [RFC8415]

lightweight DHCP relay agent [RFC6221]

[RFC4649][RFC6939]

SAVI [RFC7513][IEEE-802.1X]

2.6.1.6. RADIUS Accounting Log For interfaces where the user is authenticated via a server, and if RADIUSaccounting is enabled, then the RADIUS server receives accounting Acct-Status-Type records atthe start and at the end of the connection, which include all IPv6 (and IPv4) addresses used bythe user. This technique can be used notably for Wi-Fi networks with Wi-Fi Protected Access(WPA) or other wired interfaces on an Ethernet switch.

RADIUS [RFC2866]

IEEE 802.1X [IEEE-802.1X]

• •



2.6.2. Use of Collected Data

This section leverages the data collected, as described in Section 2.6.1, in order to achieve severalsecurity benefits. contains more details about host tracking.Section 9.1 of [RFC7934]

2.6.2.1. Forensic and User Accountability The forensic use case is when the network operator must locate an IPv6 address (and theassociated port, access point/switch, or VPN tunnel) that was present in the network at a certaintime or is currently in the network.

To locate an IPv6 address in an enterprise network where the operator has control over allresources, the source of information can be the Neighbor Cache, or, if not found, the DHCP leasefile. Then, the procedure is:

based on the IPv6 prefix of the IPv6 address; find one or more routers that are used to reachthis prefix (assuming that anti-spoofing mechanisms are used), perhaps based on an IPAM. based on this limited set of routers, on the incident time, and on the IPv6 address; retrievethe data-link address from the live Neighbor Cache, from the historical Neighbor Cache data,or from SAVI events, or retrieve the data-link address from the DHCP lease file (Section2.6.1.5). based on the data-link layer address; look up the switch interface associated with the data-link layer address. In the case of wireless LAN with RADIUS accounting (see Section 2.6.1.6),the RADIUS log has the mapping between the user identification and the MAC address. If aConfiguration Management Database (CMDB) is used, then it can be used to map the data-link layer address to a switch port.

At the end of the process, the interface of the host originating or the subscriber identityassociated with the activity in question has been determined.

To identify the subscriber of an IPv6 address in a residential Internet Service Provider, thestarting point is the DHCP-PD leased prefix covering the IPv6 address; this prefix can often belinked to a subscriber via the RADIUS log. Alternatively, the Forwarding Information Base (FIB)of the Cable Modem Termination System (CMTS) or Broadband Network Gateway (BNG) indicatesthe Customer Premises Equipment (CPE) of the subscriber and the RADIUS log can be used toretrieve the actual subscriber.

More generally, a mix of the above techniques can be used in most, if not all, networks.

1.

2.

3.

2.6.2.2. Inventory describes the difficulties for an attacker to scan an IPv6 network due to the vast

number of IPv6 addresses per link (and why in some cases it can still be done). While the hugeaddressing space can sometimes be perceived as a 'protection', it also makes the inventory taskdifficult in an IPv6 network while it was trivial to do in an IPv4 network (a simple enumerationof all IPv4 addresses, followed by a ping and a TCP/UDP port scan). Getting an inventory of allconnected devices is of prime importance for a secure network operation.

[RFC7707]




There are many ways to do an inventory of an IPv6 network.

The first technique is to use passive inspection, such as IPFIX. Using exported IPFIX informationand extracting the list of all IPv6 source addresses allows finding all IPv6 nodes that sent packetsthrough a router. This is very efficient but, alas, will not discover silent nodes that nevertransmitted packets traversing the IPFIX target router. Also, it must be noted that link-localaddresses will never be discovered by this means.

The second way is again to use the collected Neighbor Cache content to find all IPv6 addresses inthe cache. This process will also discover all link-local addresses. See Section 2.6.1.4.

Another way that works only for a local network consists of sending an ICMP ECHO_REQUEST tothe link-local multicast address ff02::1, which addresses all IPv6 nodes on the network. All nodesshould reply to this ECHO_REQUEST, per .

Other techniques involve obtaining data from DNS, parsing log files, and leveraging servicediscovery, such as mDNS .

Enumerating DNS zones, especially looking at reverse DNS records and CNAMEs, is anothercommon method employed by various tools. As already mentioned in , this allows anattacker to prune the IPv6 reverse DNS tree and hence enumerate it in a feasible time.Furthermore, authoritative servers that allow zone transfers (i.e., Authoritative Transfers(AXFRs)) may be a further information source. An interesting research paper has analyzed theentropy in various IPv6 addresses: see .

[RFC4443]

[RFC6762] [RFC6763]

[RFC7707]

[ENTROPYIP]

2.6.2.3. Correlation In an IPv4 network, it is easy to correlate multiple logs, for example, to find events related to aspecific IPv4 address. A simple Unix grep command is enough to scan through multiple text-based files and extract all lines relevant to a specific IPv4 address.

In an IPv6 network, this is slightly more difficult because different character strings can expressthe same IPv6 address. Therefore, the simple Unix grep command cannot be used. Moreover, anIPv6 node can have multiple IPv6 addresses.

In order to do correlation in IPv6-related logs, it is advised to have all logs in a format with onlycanonical IPv6 addresses . Then, the current (or historical) Neighbor Cache data setmust be searched to find the data-link layer address of the IPv6 address. Next, the current andhistorical Neighbor Cache data sets must be searched for all IPv6 addresses associated with thisdata-link layer address to derive the search set. The last step is to search in all log files(containing only IPv6 addresses in canonical format) for any IPv6 addresses in the search set.

Moreover, recommends using multiple IPv6 addresses per prefix, so the correlationmust also be done among those multiple IPv6 addresses, for example, by discovering all IPv6addresses associated with the same MAC address and interface in the .

[RFC5952]

[RFC7934]

NDP cache (Section 2.6.1.4)



2.6.3. Summary

While some data sources (IPFIX, MIB, switch Content Addressable Memory (CAM) tables, logs,etc.) used in IPv4 are also used in the secure operation of an IPv6 network, the DHCPv6 lease fileis less reliable and the Neighbor Cache is of prime importance.

The fact that there are multiple ways to express the same IPv6 address in a character stringrenders the use of filters mandatory when correlation must be done.

2.6.2.4. Abnormal Behavior Detection Abnormal behavior (such as network scanning, spamming, DoS) can be detected in the same wayas in an IPv4 network:

a sudden increase of traffic detected by interface counter (SNMP) or by aggregated trafficfrom , rapid growth of ND cache size, or change in traffic pattern (number of connections per second, number of connections perhost, etc.) observed with the use of .

• IPFIX records [RFC7012]

• •

IPFIX [RFC7012]

2.7. Transition/Coexistence Technologies As it is expected that some networks will not run in a pure IPv6-only mode, the differenttransition mechanisms must be deployed and operated in a secure way. This section proposesoperational guidelines for the most-known and deployed transition techniques. alsocontains security considerations for transition or coexistence scenarios.

[RFC4942]

2.7.1. Dual Stack

Dual stack is often the first deployment choice for network operators. Dual stacking the networkoffers some advantages over other transition mechanisms. Firstly, the impact on existing IPv4operations is reduced. Secondly, in the absence of tunnels or address translation, the IPv4 andIPv6 traffic are native (easier to observe and secure) and should have the same networkprocessing (network path, quality of service, etc.). Dual stack enables a gradual termination ofthe IPv4 operations when the IPv6 network is ready for prime time. On the other hand, theoperators have to manage two network stacks with the added complexities.

From an operational security perspective, this now means that the network operator has twicethe exposure. One needs to think about protecting both protocols now. At a minimum, the IPv6portion of a dual-stacked network should be consistent with IPv4 from a security policy point ofview. Typically, the following methods are employed to protect IPv4 networks at the edge orsecurity perimeter:

ACLs to permit or deny traffic, firewalls with stateful packet inspection, and application firewalls inspecting the application flows.

• • •



It is recommended that these ACLs and/or firewalls be additionally configured to protect IPv6communications. The enforced IPv6 security must be congruent with the IPv4 security policy;otherwise, the attacker will use the protocol version that has the more relaxed security policy.Maintaining the congruence between security policies can be challenging (especially over time);it is recommended to use a firewall or an ACL manager that is dual stack, i.e., a system that canapply a single ACL entry to a mixed group of IPv4 and IPv6 addresses.

Application firewalls work at the application layer and are oblivious to the IP version, i.e., theywork as well for IPv6 as for IPv4 and the same application security policy will work for bothprotocol versions.

Also, given the end-to-end connectivity that IPv6 provides, it is recommended that hosts befortified against threats. General device hardening guidelines are provided in Section 2.8.

For many years, all host operating systems have IPv6 enabled by default, so it is possible even inan 'IPv4-only' network to attack L2-adjacent victims via their IPv6 link-local address or via aglobal IPv6 address when the attacker provides rogue RAs or a rogue DHCPv6 service.

discusses the security implications of native IPv6 support and IPv6 transition/coexistence technologies on 'IPv4-only' networks and describes possible mitigations for theaforementioned issues.

[RFC7123]

2.7.2. Encapsulation Mechanisms

There are many tunnels used for specific use cases. Except when protected by oralternative tunnel encryption methods, all those tunnels have a number of security issues, asdescribed in :

tunnel injection:A malevolent actor knowing a few pieces of information (for example, the tunnel endpointsand the encapsulation protocol) can forge a packet that looks like a legitimate and validencapsulated packet that will gladly be accepted by the destination tunnel endpoint. This is aspecific case of spoofing.

traffic interception:No confidentiality is provided by the tunnel protocols (without the use of IPsec or alternativeencryption methods); therefore, anybody on the tunnel path can intercept the traffic and haveaccess to the cleartext IPv6 packet. Combined with the absence of authentication, an on-pathattack can also be mounted.

service theft:As there is no authorization, even an unauthorized user can use a tunnel relay for free (this isa specific case of tunnel injection).

IPsec [RFC4301]

[RFC6169]



IP protocol 41:

IP protocol 47:

UDP port 3544:

reflection attack:Another specific use case of tunnel injection where the attacker injects packets with an IPv4destination address not matching the IPv6 address causing the first tunnel endpoint to re-encapsulate the packet to the destination. Hence, the final IPv4 destination will not see theoriginal IPv4 address but only the IPv4 address of the relay router.

bypassing security policy:If a firewall or an Intrusion Prevention System (IPS) is on the path of the tunnel, then it mayneither inspect nor detect malevolent IPv6 traffic transmitted over the tunnel.

To mitigate the bypassing of security policies, it is often recommended to block all automatictunnels in default OS configuration (if they are not required) by denying IPv4 packets matching:

This will block Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)(Section 2.7.2.2), 6to4 (Section 2.7.2.7), 6rd (Section 2.7.2.3), and 6in4 (Section 2.7.2.1) tunnels.

This will block GRE (Section 2.7.2.1) tunnels.

This will block the default encapsulation of Teredo (Section 2.7.2.8) tunnels.

should also be applied on all tunnel endpoints, if applicable, toprevent IPv6 address spoofing.

The reflection attack cited above should also be prevented by using an IPv6 ACL preventing thehair pinning of the traffic.

As several of the tunnel techniques share the same encapsulation (i.e., IPv4 protocol 41) andembed the IPv4 address in the IPv6 address, there are a set of well-known looping attacksdescribed in . This RFC also proposes mitigation techniques.

Ingress filtering [RFC2827]

[RFC6324]

2.7.2.1. Site-to-Site Static Tunnels Site-to-site static tunnels are described in and in . As the IPv4 endpointsare statically configured and are not dynamic, they are slightly more secure (bidirectionalservice theft is mostly impossible), but traffic interception and tunnel injection are still possible.Therefore, the use of in transport mode to protect the encapsulated IPv4 packetsis recommended for those tunnels. Alternatively, IPsec in tunnel mode can be used to transportIPv6 traffic over an untrusted IPv4 network.

[RFC2529] GRE [RFC2784]

IPsec [RFC4301]

2.7.2.2. ISATAP ISATAP tunnels are mainly used within a single administrative domain and to connecta single IPv6 host to the IPv6 network. This often implies that those systems are usually managedby a single entity; therefore, audit trail and strict anti-spoofing are usually possible, and thisraises the overall security. Even if ISATAP is no more often used, its security issues are relevant,per .

Special care must be taken to avoid a looping attack by implementing the measures of and (especially in Section 3.6).

[RFC5214]

[KRISTOFF]

[RFC6324][RFC6964]




in transport or tunnel mode can be used to secure the IPv4 ISATAP traffic toprovide IPv6 traffic confidentiality and prevent service theft.IPsec [RFC4301]

2.7.2.3. 6rd While 6rd tunnels share the same encapsulation as , they aredesigned to be used within a single SP domain; in other words, they are deployed in a moreconstrained environment (e.g., anti-spoofing, protocol 41 filtering at the edge) than 6to4 tunnelsand have few security issues other than lack of confidentiality. The security considerations in

describes how to secure 6rd tunnels.

for the transported IPv6 traffic can be used if confidentiality is important.

6to4 tunnels (Section 2.7.2.7)

Section 12 of [RFC5969]

IPsec [RFC4301]

2.7.2.4. 6PE, 6VPE, and LDPv6 Organizations using MPLS in their core can also use IPv6 Provider Edge (6PE) and IPv6Virtual Private Extension (6VPE) to enable IPv6 access over MPLS. As 6PE and 6VPEare really similar to BGP/MPLS IP VPNs described in , the security properties of thesenetworks are also similar to those described in (please note that this RFC mayresemble a published IETF work, but it is not based on an IETF review and the IETF disclaimsany 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 thecase of 6PE and 6VPE, link-local addresses (see ) can be used, and, as theseaddresses cannot be reached from outside of the link, the security of 6PE and 6VPE is evenhigher than an IPv4 BGP/MPLS IP VPN.

LDPv6 itself does not induce new risks; see .

[RFC4798][RFC4659]

[RFC4364][RFC4381]

• • •

[RFC7404]

[RFC7552]

2.7.2.5. DS-Lite Dual-Stack Lite (DS-Lite) is also a translation mechanism and is therefore analyzed

in this document, as it includes IPv4 NAPT.further

(Section 2.7.3.3)

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 and MAP-T -- the access network is purely an IPv6network, and MAP protocols are used to provide IPv4 hosts on the subscriber network access toIPv4 hosts on the Internet. The subscriber router does stateful operations in order to map allinternal IPv4 addresses and Layer 4 ports to the IPv4 address and the set of Layer 4 portsreceived through the MAP configuration process. The SP equipment always does statelessoperations (either decapsulation or stateless translation). Therefore, as opposed to Section 2.7.3.3,there is no state exhaustion DoS attack against the SP equipment because there is no state andthere is no operation caused by a new Layer 4 connection (no logging operation).

[RFC7597] [RFC7599]




The SP MAP equipment should implement all the security considerations of , notablyensuring that the mapping of the IPv4 address and port are consistent with the configuration. AsMAP has a predictable IPv4 address and port mapping, the audit logs are easier to use, as there isa clear mapping between the IPv6 address and the IPv4 address and ports.

[RFC7597]

2.7.2.7. 6to4 In , 6to4 tunnels require a public-routable IPv4 address in order to work correctly.They can be used to provide either single IPv6 host connectivity to the IPv6 Internet or multipleIPv6 networks connectivity to the IPv6 Internet. The 6to4 relay was historically the anycastaddress defined in , which has been deprecated by and is no longer used byrecent Operating Systems. Some security considerations are explained in .

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 ofthose servers and relays) at which security mechanisms may be applied. Client usage of 6to4 bydefault is now discouraged, and significant precautions are needed to avoid operationalproblems.

[RFC3056]

[RFC3068] [RFC7526][RFC3964]

[RFC6343]

2.7.2.8. Teredo Teredo tunnels are mainly used in a residential environment because Teredo easilytraverses an IPv4 NAPT device thanks to its UDP encapsulation. Teredo tunnels connect a singlehost to the IPv6 Internet. Teredo shares the same issues as other tunnels: no authentication, noconfidentiality, possible spoofing, and reflection attacks.

for the transported IPv6 traffic is recommended.

The biggest threat to Teredo is probably for an IPv4-only network, as Teredo has been designedto easily traverse IPv4 NAT-PT devices, which are quite often co-located with a stateful firewall.Therefore, if the stateful IPv4 firewall allows unrestricted UDP outbound and accepts the returnUDP traffic, then Teredo actually punches a hole in this firewall for all IPv6 traffic to and fromthe Internet. Host policies can be deployed to block Teredo in an IPv4-only network in order toavoid this firewall bypass. On the IPv4 firewall, all outbound UDPs should be blocked except forthe commonly used services (e.g., port 53 for DNS, port 123 for NTP, port 443 for QUIC, port 500for Internet Key Exchange Protocol (IKE), port 3478 for Session Traversal Utilities for NAT (STUN),etc.).

Teredo is now hardly ever used and no longer enabled by default in most environments so it isless of a threat; however, special consideration must be made in cases when devices with olderor operating systems that have not been updated may be present and by default were runningTeredo.

[RFC4380]

IPsec [RFC4301]



2.7.3. Translation Mechanisms

Translation mechanisms between IPv4 and IPv6 networks are alternate coexistence strategieswhile networks transition to IPv6. While a framework is described in , the specificsecurity considerations are documented with each individual mechanism. For the most part, theyspecifically mention interference with IPsec or DNSSEC deployments, how to mitigate spoofedtraffic, and what some effective filtering strategies may be.

While not really a transition mechanism to IPv6, this section also includes the discussion aboutthe use of heavy IPv4-to-IPv4 network addresses and port translation to prolong the life of IPv4-only networks.

[RFC6144]

2.7.3.1. Carrier-Grade NAT (CGN) Carrier-Grade NAT (CGN), also called NAT444 CGN or Large-Scale NAT (LSN) or SP NAT, isdescribed in and is utilized as an interim measure to extend the use of IPv4 in a largeservice provider network until the provider can deploy an effective IPv6 solution. requested a specific IANA-allocated /10 IPv4 address block to be used as address space shared byall access networks using CGN. This has been allocated as 100.64.0.0/10.

lists some specific security-related issues caused by large-scale addresssharing. The Security Considerations section of also lists some specific mitigationtechniques for potential misuse of shared address space. Some law enforcement agencies haveidentified CGN as impeding their cybercrime investigations (for example, see the

). Many translation techniques (NAT64, DS-Lite, etc.) have the samesecurity issues as CGN when one part of the connection is IPv4 only.

has recommendations for Internet-facing servers to also log the source TCP or UDPports of incoming connections in an attempt to help identify the users behind such a CGN.

suggests the use of deterministic address mapping in order to reduce loggingrequirements for CGN. The idea is to have a known algorithm for mapping the internalsubscriber to/from public TCP and UDP ports.

lists common requirements for CGNs. analyzes some solutions to enforcepolicies on misbehaving nodes when address sharing is used. also updates the NATbehavioral requirements.

[RFC6264][RFC6598]

Section 13 of [RFC6269][RFC6598]

Europol pressrelease on CGN [europol-cgn]

[RFC6302]

[RFC7422]

[RFC6888] [RFC6967][RFC7857]

2.7.3.2. NAT64/DNS64 and 464XLAT Stateful NAT64 translation allows IPv6-only clients to contact IPv4 servers usingunicast UDP, TCP, or ICMP. It can be used in conjunction with DNS64 , a mechanism thatsynthesizes AAAA records from existing A records. There is also a stateless NAT64 ,which has similar security aspects but with the added benefit of being stateless and is therebyless prone to a state exhaustion attack.

[RFC6146][RFC6147]

[RFC7915]




The Security Consideration sections of and list the comprehensive issues; in , there are some considerations on the interaction between NAT64 and

DNSSEC. A specific issue with the use of NAT64 is that it will interfere with most IPsecdeployments unless UDP encapsulation is used.

Another translation mechanism relying on a combination of stateful and stateless translation,464XLAT , can be used to do a host-local translation from IPv4 to IPv6 and a networkprovider translation from IPv6 to IPv4, i.e., giving IPv4-only application access to an IPv4-onlyserver over an IPv6-only network. 464XLAT shares the same security considerations as NAT64and DNS64; however, it can be used without DNS64, avoiding the DNSSEC implications.

[RFC6146] [RFC6147]Section 8 of [RFC6147]

[RFC6877]

2.7.3.3. DS-Lite Dual-Stack Lite (DS-Lite) is a transition technique that enables a service provider toshare IPv4 addresses among customers by combining two well-known technologies: IP in IP(IPv4-in-IPv6) and IPv4 NAPT.

Security considerations, with respect to DS-Lite, mainly revolve around logging data, preventingDoS attacks from rogue devices (as the Address Family Translation Router (AFTR) function is stateful), and restricting service offered by the AFTR only to registered customers.

and describe important security issues associatedwith this technology.

[RFC6333]

[RFC6333]

Section 11 of [RFC6333] Section 2 of [RFC7785]

2.8. General Device Hardening With almost all devices being IPv6 enabled by default and with many endpoints having IPv6connectivity to the Internet, it is critical to also harden those devices against attacks over IPv6.

The same techniques used to protect devices against attacks over IPv4 should be used for IPv6and should include but are not limited to:

restricting device access to authorized individuals; monitoring and auditing access to the device; turning off any unused services on the end node understanding which IPv6 addresses are being used to source traffic and changing defaults ifnecessary; using cryptographically protected protocols for device management (Secure Copy Protocol(SCP), SNMPv3, SSH, TLS, etc.); using host firewall capabilities to control traffic that gets processed by upper-layer protocols;applying firmware, OS, and application patches/upgrades to the devices in a timely manner; using multifactor credentials to authenticate to devices; and using virus scanners to detect malicious programs.

• • • •

•

• • • •






3. Enterprises-Specific Security Considerations Enterprises generally have robust network security policies in place to protect existingIPv4 networks. These policies have been distilled from years of experiential knowledge ofsecuring IPv4 networks. At the very least, it is recommended that enterprise networks haveparity between their security policies for both protocol versions. This section also applies to theenterprise part of all SP networks, i.e., the part of the network where the SP employees areconnected.

Security considerations in the enterprise can be broadly categorized into two groups: externaland internal.

[RFC7381]

3.1. External Security Considerations The external aspect deals with providing security at the edge or perimeter of the enterprisenetwork where it meets the service provider's network. This is commonly achieved by enforcinga security policy, either by implementing dedicated firewalls with stateful packet inspection or arouter with ACLs. A common default IPv4 policy on firewalls that could easily be ported to IPv6 isto allow all traffic outbound while only allowing specific traffic, such as established sessions,inbound (see ). also provides similar recommendations.

Here are a few more things that could enhance the default policy:

Filter internal-use IPv6 addresses at the perimeter; this will also mitigate the vulnerabilitieslisted in . Discard packets from and to bogon and reserved space; see and . Accept certain ICMPv6 messages to allow proper operation of ND and Path MTU Discovery(PMTUD); see or for hosts. Based on the use of the network, filter specific extension headers by accepting only therequired ones (permit list approach), such as ESP, AH, and not forgetting the requiredtransport layers: ICMP, TCP, UDP, etc. This filtering should be done where applicable at theedge and possibly inside the perimeter; see . Filter packets having an illegal IPv6 header chain at the perimeter (and, if possible, insidethe 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

and . Implement appropriate rate-limiters and control plane policers based on traffic baselines.

Having global IPv6 addresses on all the enterprise sites is different than in IPv4, where addresses are often used internally and not routed over the Internet. and

explain that without careful design, there could be IPv6 leakages from Layer 3VPNs.

[RFC6092] Section 3.2 of [RFC7381]

• [RFC7359]

• [CYMRU] [RFC8190]•

[RFC4890] [REY_PF]•

[IPV6-EH-FILTERING]•

• •

[RFC2827] [RFC3704]•

[RFC1918][RFC7359]

[WEBER_VPN]




3.2. Internal Security Considerations The internal aspect deals with providing security inside the perimeter of the network, includingend hosts. Internal networks of enterprises are often different, e.g., University campus, wirelessguest access, etc., so there is no "one size fits all" recommendation.

The most significant concerns here are related to Neighbor Discovery. At the network level, it isrecommended that all security considerations discussed in Section 2.3 be reviewed carefully andthe recommendations be considered in-depth as well. also providessome recommendations.

As mentioned in Section 2.7.2, care must be taken when running automated IPv6-in-IPv4 tunnels.

When site-to-site VPNs are used, it should be kept in mind that, given the global scope of IPv6global addresses as opposed to the common use of IPv4 private address space , sitesmight be able to communicate with each other over the Internet even when the VPN mechanismis not available. Hence, no traffic encryption is performed and traffic could be injected from theInternet into the site; see . It is recommended to filter at Internet connection(s)packets having a source or destination address belonging to the site internal prefix or prefixes;this should be done for ingress and egress traffic.

Hosts need to be hardened directly through security policy to protect against security threats.The host firewall default capabilities have to be clearly understood. In some cases, third-partyfirewalls have no IPv6 support, whereas the native firewall installed by default has IPv6 support.General device hardening guidelines are provided in Section 2.8.

It should also be noted that many hosts still use IPv4 for transporting logs for RADIUS,DIAMETER, TACACS+, syslog, etc. Operators cannot rely on an IPv6-only security policy to securesuch protocols that are still using IPv4.

Section 4.1 of [RFC7381]

[RFC1918]

[WEBER_VPN]

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 ; bogon AS filtering; see ; and prefix filtering.

These are explained in more detail in Section 2.5. Also, the recommendations of should be considered.

• • [RFC5082]• [CYMRU]•

[RFC7454]




4.1.1. Remote Triggered Black Hole Filtering

A Remote Triggered Black Hole (RTBH) works identically in IPv4 and IPv6. IANA hasallocated the 100::/64 prefix to be used as the discard prefix .

[RFC5635][RFC6666]

4.2. Transition/Coexistence Mechanism SPs will typically use transition mechanisms, such as 6rd, 6PE, MAP, and NAT64, which have beenanalyzed in the transition and coexistence (Section 2.7).

4.3. Lawful Intercept The lawful intercept requirements are similar for IPv6 and IPv4 architectures and will be subjectto the laws enforced in different geographic regions. The local issues with each jurisdiction canmake this challenging and both corporate legal and privacy personnel should be involved indiscussions pertaining to what information gets logged and with regard to the respective logretention policies for this information.

The target of interception will usually be a residential subscriber (e.g., his/her PPP session,physical line, or CPE MAC address). In the absence of IPv6 NAT on the CPE, IPv6 has thepossibility to allow for intercepting the traffic from a single host (i.e., a /128 target) rather thanthe whole set of hosts of a subscriber (which could be a /48, /60, or /64).

In contrast, in mobile environments, since the 3GPP specifications allocate a /64 per device, itmay be sufficient to intercept traffic from the /64 rather than specific /128s (since each time thedevice establishes a data connection, it gets a new IID).

5. Residential Users Security Considerations The IETF Home Networking (homenet) Working Group is working on standards and guidelinesfor IPv6 residential networks; this obviously includes operational security considerations, butthis is still a work in progress. is an interesting approach on how firewalls couldretrieve and apply specific security policies to some residential devices.

Some residential users have less experience and knowledge about security or networking thanexperimented operators. As most of the recent hosts (e.g., smartphones and tablets) have IPv6enabled by default, IPv6 security is important for those users. Even with an IPv4-only ISP, thoseusers can get IPv6 Internet access with the help of tunnels. Several peer-to-peer programs support IPv6, and those programs can initiate a Teredo tunnel through an IPv4residential gateway, with the consequence of making the internal host reachable from any IPv6host on the Internet. Therefore, it is recommended that all host security products (includingpersonal firewalls) are configured with a dual-stack security policy.

If the residential CPE has IPv6 connectivity, defines the requirements of an IPv6 CPEand does not take a position on the debate of default IPv6 security policy, as defined in

:

[RFC8520]

Teredo (Section 2.7.2.8)

[RFC7084]

[RFC6092]



[RFC2119]

[RFC8174]

6. Further Reading There are several documents that describe in more detail the security of an IPv6 network; thesedocuments are not written by the IETF and some of them are dated but are listed here for thereader's convenience:

Guidelines for the Secure Deployment of IPv6 North American IPv6 Task Force Technology Report - IPv6 Security Technology Paper

IPv6 Security

9. References

9.1. Normative References

, , , , , March 1997, .

, , , , , May 2017,

.

outbound only:Allowing all internally initiated connections and blocking all externally initiated ones, whichis a common default security policy enforced by IPv4 residential gateway doing NAPT, but italso breaks the end-to-end reachability promise of IPv6. lists severalrecommendations to design such a CPE.

open/transparent:Allowing all internally and externally initiated connections, therefore, restoring the end-to-end nature of the Internet for IPv6 traffic but having a different security policy for IPv6 thanfor IPv4.

REC-49 states that a choice must be given to the user to select one of those two policies .

[RFC6092]

[RFC6092]

• [NIST]•

[NAv6TF_Security]• [IPv6_Security_Book]

7. Security Considerations This memo attempts to give an overview of security considerations of operating an IPv6 networkboth for an IPv6-only network and for networks utilizing the most widely deployed IPv4/IPv6coexistence strategies.

8. IANA Considerations This document has no IANA actions.

Bradner, S. "Key words for use in RFCs to Indicate Requirement Levels" BCP 14RFC 2119 DOI 10.17487/RFC2119 <https://www.rfc-editor.org/info/rfc2119>

Leiba, B. "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words" BCP14 RFC 8174 DOI 10.17487/RFC8174 <https://www.rfc-editor.org/info/rfc8174>







[RFC8200]

[CYMRU]

[ENTROPYIP]

[europol-cgn]

[GDPR]

[IANA-IPFIX]

[IEEE-802.1X]

[IPV6-EH-FILTERING]

[IPV6-EH-PARSING]

[IPv6_Security_Book]

[KRISTOFF]

and , , , , , July 2017,

.

9.2. Informative References

, , .

, , and , , November 2016, .

, ,

October 2017,

.

,

, , April 2016,

.

, , .

, , , February 2020.

and , , ,

, 3 June 2021, .

, , ,

, 5 August 2014, .

and , , , , December 2008.

, , , and , , March 2021,

.

Deering, S. R. Hinden "Internet Protocol, Version 6 (IPv6) Specification" STD86 RFC 8200 DOI 10.17487/RFC8200 <https://www.rfc-editor.org/info/rfc8200>

Team Cymru "The Bogon Reference" <https://team-cymru.com/community-services/bogon-reference/>

Foremski, P. Plonka, D. A. Berger "Entropy/IP: Uncovering Structure inIPv6 Addresses" <http://www.entropy-ip.com/>

Europol "Are you sharing the same IP address as a criminal? Law enforcementcall for the end of Carrier Grade Nat (CGN) to increase accountability online"

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

European Union "Regulation (EU) 2016/679 of the European Parliament and ofthe Council of 27 April 2016 on the protection of natural persons with regard tothe processing of personal data and on the free movement of such data, andrepealing Directive 95/46/EC (General Data Protection Regulation)" OfficialJournal of the European Union <https://eur-lex.europa.eu/eli/reg/2016/679/oj>

IANA "IP Flow Information Export (IPFIX) Entities" <http://www.iana.org/assignments/ipfix>

IEEE "IEEE Standard for Local and Metropolitan Area Networks--Port-BasedNetwork Access Control" IEEE Std 802.1X-2020

Gont, F. W. Liu "Recommendations on the Filtering of IPv6 PacketsContaining IPv6 Extension Headers at Transit Routers" Work in ProgressInternet-Draft, draft-ietf-opsec-ipv6-eh-filtering-08 <https://datatracker.ietf.org/doc/html/draft-ietf-opsec-ipv6-eh-filtering-08>

Kampanakis, P. "Implementation Guidelines for parsing IPv6 ExtensionHeaders" Work in Progress Internet-Draft, draft-kampanakis-6man-ipv6-eh-parsing-01 <https://datatracker.ietf.org/doc/html/draft-kampanakis-6man-ipv6-eh-parsing-01>

Hogg, S. É. Vyncke "IPv6 Security" CiscoPress ISBN 1587055945

Kristoff, J. Ghasemisharif, M. Kanich, C. J. Polakis "Plight at the End of theTunnel: Legacy IPv6 Transition Mechanisms in the Wild" <https://dataplane.org/jtk/publications/kgkp-pam-21.pdf>





https://team-cymru.com/community-services/bogon-reference/

https://team-cymru.com/community-services/bogon-reference/

http://www.entropy-ip.com/

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



https://eur-lex.europa.eu/eli/reg/2016/679/oj

https://eur-lex.europa.eu/eli/reg/2016/679/oj

http://www.iana.org/assignments/ipfix

http://www.iana.org/assignments/ipfix

https://datatracker.ietf.org/doc/html/draft-ietf-opsec-ipv6-eh-filtering-08

https://datatracker.ietf.org/doc/html/draft-ietf-opsec-ipv6-eh-filtering-08

https://datatracker.ietf.org/doc/html/draft-kampanakis-6man-ipv6-eh-parsing-01

https://datatracker.ietf.org/doc/html/draft-kampanakis-6man-ipv6-eh-parsing-01

https://dataplane.org/jtk/publications/kgkp-pam-21.pdf

https://dataplane.org/jtk/publications/kgkp-pam-21.pdf

[NAv6TF_Security]

[NIST]

[RADB]

[REY_PF]

[RFC0826]

[RFC1918]

[RFC2131]

[RFC2460]

[RFC2529]

[RFC2663]

[RFC2784]

[RFC2827]

[RFC2866]

, , , and , , July 2006,

.

, , , and , , December 2010,

.

, , .

, , July 2017, .

,

, , , , November 1982, .

, , , , and , , , , ,

February 1996, .

, , , , March 1997, .

and , , , , December 1998,

.

and , , , , March 1999,

.

and , , , , August

1999, .

, , , , and , , , , March 2000,

.

and , , , ,

, May 2000, .

, , , , June 2000, .

Kaeo, M. Green, D. Bound, J. Y. Pouffary "North American IPv6 TaskForce (NAv6TF) Technology Report "IPv6 Security Technology Paper"<http://www.ipv6forum.com/dl/white/NAv6TF_Security_Report.pdf>

Frankel, S. Graveman, R. Pearce, J. M. Rooks "Guidelines for the SecureDeployment of IPv6" <http://csrc.nist.gov/publications/nistpubs/800-119/sp800-119.pdf>

Merit Network, Inc. "RADb: The Internet Routing Registry" <https://www.radb.net/>

Rey, E. "Local Packet Filtering with IPv6" <https://labs.ripe.net/Members/enno_rey/local-packet-filtering-with-ipv6>

Plummer, D. "An Ethernet Address Resolution Protocol: Or Converting NetworkProtocol Addresses to 48.bit Ethernet Address for Transmission on EthernetHardware" STD 37 RFC 826 DOI 10.17487/RFC0826 <https://www.rfc-editor.org/info/rfc826>

Rekhter, Y. Moskowitz, B. Karrenberg, D. de Groot, G. J. E. Lear "AddressAllocation for Private Internets" BCP 5 RFC 1918 DOI 10.17487/RFC1918

<https://www.rfc-editor.org/info/rfc1918>

Droms, R. "Dynamic Host Configuration Protocol" RFC 2131 DOI 10.17487/RFC2131 <https://www.rfc-editor.org/info/rfc2131>

Deering, S. R. Hinden "Internet Protocol, Version 6 (IPv6) Specification" RFC2460 DOI 10.17487/RFC2460 <https://www.rfc-editor.org/info/rfc2460>

Carpenter, B. C. Jung "Transmission of IPv6 over IPv4 Domains withoutExplicit Tunnels" RFC 2529 DOI 10.17487/RFC2529 <https://www.rfc-editor.org/info/rfc2529>

Srisuresh, P. M. Holdrege "IP Network Address Translator (NAT)Terminology and Considerations" RFC 2663 DOI 10.17487/RFC2663


Farinacci, D. Li, T. Hanks, S. Meyer, D. P. Traina "Generic RoutingEncapsulation (GRE)" RFC 2784 DOI 10.17487/RFC2784 <https://www.rfc-editor.org/info/rfc2784>

Ferguson, P. D. Senie "Network Ingress Filtering: Defeating Denial of ServiceAttacks which employ IP Source Address Spoofing" BCP 38 RFC 2827 DOI10.17487/RFC2827 <https://www.rfc-editor.org/info/rfc2827>

Rigney, C. "RADIUS Accounting" RFC 2866 DOI 10.17487/RFC2866<https://www.rfc-editor.org/info/rfc2866>



http://www.ipv6forum.com/dl/white/NAv6TF_Security_Report.pdf

http://csrc.nist.gov/publications/nistpubs/800-119/sp800-119.pdf

http://csrc.nist.gov/publications/nistpubs/800-119/sp800-119.pdf

https://www.radb.net/

https://www.radb.net/

https://labs.ripe.net/Members/enno_rey/local-packet-filtering-with-ipv6

https://labs.ripe.net/Members/enno_rey/local-packet-filtering-with-ipv6














[RFC3056]

[RFC3068]

[RFC3627]

[RFC3704]

[RFC3756]

[RFC3964]

[RFC3971]

[RFC3972]

[RFC4033]

[RFC4107]

[RFC4193]

[RFC4293]

[RFC4301]

[RFC4302]

and , , , , February 2001,

.

, , , , June 2001, .

, , , , September 2003,

.

and , , , , , March 2004, .

, , and , , , , May 2004,

.

and , , , , December 2004, .

, , , and , , , , March 2005,

.

, , , , March 2005, .

, , , , and , , , , March 2005,

.

and , , , , , June 2005,

.

and , , , , October 2005, .

, , , , April 2006, .


.

, , , , December2005, .

Carpenter, B. K. Moore "Connection of IPv6 Domains via IPv4 Clouds" RFC3056 DOI 10.17487/RFC3056 <https://www.rfc-editor.org/info/rfc3056>

Huitema, C. "An Anycast Prefix for 6to4 Relay Routers" RFC 3068 DOI 10.17487/RFC3068 <https://www.rfc-editor.org/info/rfc3068>

Savola, P. "Use of /127 Prefix Length Between Routers Considered Harmful" RFC3627 DOI 10.17487/RFC3627 <https://www.rfc-editor.org/info/rfc3627>

Baker, F. P. Savola "Ingress Filtering for Multihomed Networks" BCP 84RFC 3704 DOI 10.17487/RFC3704 <https://www.rfc-editor.org/info/rfc3704>

Nikander, P., Ed. Kempf, J. E. Nordmark "IPv6 Neighbor Discovery (ND)Trust Models and Threats" RFC 3756 DOI 10.17487/RFC3756 <https://www.rfc-editor.org/info/rfc3756>

Savola, P. C. Patel "Security Considerations for 6to4" RFC 3964 DOI10.17487/RFC3964 <https://www.rfc-editor.org/info/rfc3964>

Arkko, J., Ed. Kempf, J. Zill, B. P. Nikander "SEcure Neighbor Discovery(SEND)" RFC 3971 DOI 10.17487/RFC3971 <https://www.rfc-editor.org/info/rfc3971>

Aura, T. "Cryptographically Generated Addresses (CGA)" RFC 3972 DOI10.17487/RFC3972 <https://www.rfc-editor.org/info/rfc3972>

Arends, R. Austein, R. Larson, M. Massey, D. S. Rose "DNS SecurityIntroduction and Requirements" RFC 4033 DOI 10.17487/RFC4033<https://www.rfc-editor.org/info/rfc4033>

Bellovin, S. R. Housley "Guidelines for Cryptographic Key Management"BCP 107 RFC 4107 DOI 10.17487/RFC4107 <https://www.rfc-editor.org/info/rfc4107>

Hinden, R. B. Haberman "Unique Local IPv6 Unicast Addresses" RFC 4193DOI 10.17487/RFC4193 <https://www.rfc-editor.org/info/rfc4193>

Routhier, S., Ed. "Management Information Base for the Internet Protocol (IP)"RFC 4293 DOI 10.17487/RFC4293 <https://www.rfc-editor.org/info/rfc4293>

Kent, S. K. Seo "Security Architecture for the Internet Protocol" RFC 4301DOI 10.17487/RFC4301 <https://www.rfc-editor.org/info/rfc4301>

Kent, S. "IP Authentication Header" RFC 4302 DOI 10.17487/RFC4302<https://www.rfc-editor.org/info/rfc4302>

























[RFC4303]

[RFC4364]

[RFC4380]

[RFC4381]

[RFC4443]

[RFC4552]

[RFC4649]

[RFC4659]

[RFC4795]

[RFC4798]

[RFC4861]

[RFC4864]

[RFC4890]

, , , , December 2005, .


.

, , , , February 2006,

.

, , , , February 2006,

.

, , and , , ,

, , March 2006, .

and , , , , June 2006, .

, , , , August 2006,

.

, , , and , , ,

, September 2006, .

, , and , , , , January 2007,

.

, , , and , , ,

, February 2007, .

, , , and , , , , September 2007,

.

, , , , and , , , , May 2007,

.

and , , , , May 2007,

.

Kent, S. "IP Encapsulating Security Payload (ESP)" RFC 4303 DOI 10.17487/RFC4303 <https://www.rfc-editor.org/info/rfc4303>

Rosen, E. Y. Rekhter "BGP/MPLS IP Virtual Private Networks (VPNs)" RFC4364 DOI 10.17487/RFC4364 <https://www.rfc-editor.org/info/rfc4364>

Huitema, C. "Teredo: Tunneling IPv6 over UDP through Network AddressTranslations (NATs)" RFC 4380 DOI 10.17487/RFC4380 <https://www.rfc-editor.org/info/rfc4380>

Behringer, M. "Analysis of the Security of BGP/MPLS IP Virtual Private Networks(VPNs)" RFC 4381 DOI 10.17487/RFC4381 <https://www.rfc-editor.org/info/rfc4381>

Conta, A. Deering, S. M. Gupta, Ed. "Internet Control Message Protocol(ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification" STD 89 RFC4443 DOI 10.17487/RFC4443 <https://www.rfc-editor.org/info/rfc4443>

Gupta, M. N. Melam "Authentication/Confidentiality for OSPFv3" RFC 4552DOI 10.17487/RFC4552 <https://www.rfc-editor.org/info/rfc4552>

Volz, B. "Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay AgentRemote-ID Option" RFC 4649 DOI 10.17487/RFC4649 <https://www.rfc-editor.org/info/rfc4649>

De Clercq, J. Ooms, D. Carugi, M. F. Le Faucheur "BGP-MPLS IP VirtualPrivate Network (VPN) Extension for IPv6 VPN" RFC 4659 DOI 10.17487/RFC4659 <https://www.rfc-editor.org/info/rfc4659>

Aboba, B. Thaler, D. L. Esibov "Link-local Multicast Name Resolution(LLMNR)" RFC 4795 DOI 10.17487/RFC4795 <https://www.rfc-editor.org/info/rfc4795>

De Clercq, J. Ooms, D. Prevost, S. F. Le Faucheur "Connecting IPv6 Islandsover IPv4 MPLS Using IPv6 Provider Edge Routers (6PE)" RFC 4798 DOI10.17487/RFC4798 <https://www.rfc-editor.org/info/rfc4798>

Narten, T. Nordmark, E. Simpson, W. H. Soliman "Neighbor Discovery forIP version 6 (IPv6)" RFC 4861 DOI 10.17487/RFC4861 <https://www.rfc-editor.org/info/rfc4861>

Van de Velde, G. Hain, T. Droms, R. Carpenter, B. E. Klein "Local NetworkProtection for IPv6" RFC 4864 DOI 10.17487/RFC4864 <https://www.rfc-editor.org/info/rfc4864>

Davies, E. J. Mohacsi "Recommendations for Filtering ICMPv6 Messages inFirewalls" RFC 4890 DOI 10.17487/RFC4890 <https://www.rfc-editor.org/info/rfc4890>

























[RFC4942]

[RFC5082]

[RFC5214]

[RFC5340]

[RFC5635]

[RFC5952]

[RFC5969]

[RFC6092]

[RFC6104]

[RFC6105]

[RFC6144]

[RFC6146]

, , and , , , , September 2007,

.

, , , , and , , , , October

2007, .

, , and , , , , March 2008,

.

, , , and , , , , July 2008, .

and , , , ,

August 2009, .

and , , , , August 2010,

.

and , , , , August 2010,

.

, ,

, , January 2011, .


.

, , , and , , , , February 2011,

.

, , , and , , , , April 2011,

.

, , and , , ,

, April 2011, .

Davies, E. Krishnan, S. P. Savola "IPv6 Transition/Co-existence SecurityConsiderations" RFC 4942 DOI 10.17487/RFC4942 <https://www.rfc-editor.org/info/rfc4942>

Gill, V. Heasley, J. Meyer, D. Savola, P., Ed. C. Pignataro "The GeneralizedTTL Security Mechanism (GTSM)" RFC 5082 DOI 10.17487/RFC5082


Templin, F. Gleeson, T. D. Thaler "Intra-Site Automatic Tunnel AddressingProtocol (ISATAP)" RFC 5214 DOI 10.17487/RFC5214 <https://www.rfc-editor.org/info/rfc5214>

Coltun, R. Ferguson, D. Moy, J. A. Lindem "OSPF for IPv6" RFC 5340 DOI10.17487/RFC5340 <https://www.rfc-editor.org/info/rfc5340>

Kumari, W. D. McPherson "Remote Triggered Black Hole Filtering withUnicast Reverse Path Forwarding (uRPF)" RFC 5635 DOI 10.17487/RFC5635


Kawamura, S. M. Kawashima "A Recommendation for IPv6 Address TextRepresentation" RFC 5952 DOI 10.17487/RFC5952 <https://www.rfc-editor.org/info/rfc5952>

Townsley, W. O. Troan "IPv6 Rapid Deployment on IPv4 Infrastructures(6rd) -- Protocol Specification" RFC 5969 DOI 10.17487/RFC5969<https://www.rfc-editor.org/info/rfc5969>

Woodyatt, J., Ed. "Recommended Simple Security Capabilities in CustomerPremises Equipment (CPE) for Providing Residential IPv6 Internet Service" RFC6092 DOI 10.17487/RFC6092 <https://www.rfc-editor.org/info/rfc6092>

Chown, T. S. Venaas "Rogue IPv6 Router Advertisement ProblemStatement" RFC 6104 DOI 10.17487/RFC6104 <https://www.rfc-editor.org/info/rfc6104>

Levy-Abegnoli, E. Van de Velde, G. Popoviciu, C. J. Mohacsi "IPv6 RouterAdvertisement Guard" RFC 6105 DOI 10.17487/RFC6105<https://www.rfc-editor.org/info/rfc6105>

Baker, F. Li, X. Bao, C. K. Yin "Framework for IPv4/IPv6 Translation" RFC6144 DOI 10.17487/RFC6144 <https://www.rfc-editor.org/info/rfc6144>

Bagnulo, M. Matthews, P. I. van Beijnum "Stateful NAT64: NetworkAddress and Protocol Translation from IPv6 Clients to IPv4 Servers" RFC 6146DOI 10.17487/RFC6146 <https://www.rfc-editor.org/info/rfc6146>





















[RFC6147]

[RFC6164]

[RFC6169]

[RFC6177]

[RFC6192]

[RFC6221]

[RFC6241]

[RFC6264]

[RFC6269]

[RFC6296]

[RFC6302]

[RFC6324]

, , , and , ,

, , April 2011, .

, , , , , and , , , ,

April 2011, .

, , and , , , , April 2011, .

, , and , , , , , March 2011,

.

, , and , , , , March 2011,

.

, , , , and , , , , May 2011,

.

, , , and , , , ,

June 2011, .

, , and , , , , June 2011,

.

, , , , and , , , , June 2011,

.

and , , , , June 2011,

.

, , , and , , , , , June

2011, .

and , , , ,

August 2011, .

Bagnulo, M. Sullivan, A. Matthews, P. I. van Beijnum "DNS64: DNSExtensions for Network Address Translation from IPv6 Clients to IPv4 Servers"RFC 6147 DOI 10.17487/RFC6147 <https://www.rfc-editor.org/info/rfc6147>

Kohno, M. Nitzan, B. Bush, R. Matsuzaki, Y. Colitti, L. T. Narten "Using127-Bit IPv6 Prefixes on Inter-Router Links" RFC 6164 DOI 10.17487/RFC6164


Krishnan, S. Thaler, D. J. Hoagland "Security Concerns with IP Tunneling"RFC 6169 DOI 10.17487/RFC6169 <https://www.rfc-editor.org/info/rfc6169>

Narten, T. Huston, G. L. Roberts "IPv6 Address Assignment to End Sites"BCP 157 RFC 6177 DOI 10.17487/RFC6177 <https://www.rfc-editor.org/info/rfc6177>

Dugal, D. Pignataro, C. R. Dunn "Protecting the Router Control Plane" RFC6192 DOI 10.17487/RFC6192 <https://www.rfc-editor.org/info/rfc6192>

Miles, D., Ed. Ooghe, S. Dec, W. Krishnan, S. A. Kavanagh "LightweightDHCPv6 Relay Agent" RFC 6221 DOI 10.17487/RFC6221 <https://www.rfc-editor.org/info/rfc6221>

Enns, R., Ed. Bjorklund, M., Ed. Schoenwaelder, J., Ed. A. Bierman, Ed."Network Configuration Protocol (NETCONF)" RFC 6241 DOI 10.17487/RFC6241


Jiang, S. Guo, D. B. Carpenter "An Incremental Carrier-Grade NAT (CGN)for IPv6 Transition" RFC 6264 DOI 10.17487/RFC6264 <https://www.rfc-editor.org/info/rfc6264>

Ford, M., Ed. Boucadair, M. Durand, A. Levis, P. P. Roberts "Issues with IPAddress Sharing" RFC 6269 DOI 10.17487/RFC6269 <https://www.rfc-editor.org/info/rfc6269>

Wasserman, M. F. Baker "IPv6-to-IPv6 Network Prefix Translation" RFC6296 DOI 10.17487/RFC6296 <https://www.rfc-editor.org/info/rfc6296>

Durand, A. Gashinsky, I. Lee, D. S. Sheppard "Logging Recommendationsfor Internet-Facing Servers" BCP 162 RFC 6302 DOI 10.17487/RFC6302


Nakibly, G. F. Templin "Routing Loop Attack Using IPv6 Automatic Tunnels:Problem Statement and Proposed Mitigations" RFC 6324 DOI 10.17487/RFC6324
























[RFC6333]

[RFC6343]

[RFC6434]

[RFC6459]

[RFC6547]

[RFC6564]

[RFC6583]

[RFC6598]

[RFC6620]

[RFC6666]

[RFC6762]

[RFC6763]

[RFC6775]

, , , and , , , ,

August 2011, .

, , , , August 2011, .

, , and , , , , December 2011,

.

, , , , , and ,

, , , January 2012, .

, , , , February 2012, .

, , , , and , , , , April

2012, .

, , and , , , , March 2012,

.

, , , , and , , , ,

, April 2012, .

, , and ,

, , , May 2012, .

and , , , , August 2012, .

and , , , ,February 2013, .

and , , , , February 2013, .

, , , and ,

, , , November 2012, .

Durand, A. Droms, R. Woodyatt, J. Y. Lee "Dual-Stack Lite BroadbandDeployments Following IPv4 Exhaustion" RFC 6333 DOI 10.17487/RFC6333


Carpenter, B. "Advisory Guidelines for 6to4 Deployment" RFC 6343 DOI10.17487/RFC6343 <https://www.rfc-editor.org/info/rfc6343>

Jankiewicz, E. Loughney, J. T. Narten "IPv6 Node Requirements" RFC 6434DOI 10.17487/RFC6434 <https://www.rfc-editor.org/info/rfc6434>

Korhonen, J., Ed. Soininen, J. Patil, B. Savolainen, T. Bajko, G. K. Iisakkila"IPv6 in 3rd Generation Partnership Project (3GPP) Evolved Packet System(EPS)" RFC 6459 DOI 10.17487/RFC6459 <https://www.rfc-editor.org/info/rfc6459>

George, W. "RFC 3627 to Historic Status" RFC 6547 DOI 10.17487/RFC6547<https://www.rfc-editor.org/info/rfc6547>

Krishnan, S. Woodyatt, J. Kline, E. Hoagland, J. M. Bhatia "A UniformFormat for IPv6 Extension Headers" RFC 6564 DOI 10.17487/RFC6564


Gashinsky, I. Jaeggli, J. W. Kumari "Operational Neighbor DiscoveryProblems" RFC 6583 DOI 10.17487/RFC6583 <https://www.rfc-editor.org/info/rfc6583>

Weil, J. Kuarsingh, V. Donley, C. Liljenstolpe, C. M. Azinger "IANA-Reserved IPv4 Prefix for Shared Address Space" BCP 153 RFC 6598 DOI10.17487/RFC6598 <https://www.rfc-editor.org/info/rfc6598>

Nordmark, E. Bagnulo, M. E. Levy-Abegnoli "FCFS SAVI: First-Come, First-Served Source Address Validation Improvement for Locally Assigned IPv6Addresses" RFC 6620 DOI 10.17487/RFC6620 <https://www.rfc-editor.org/info/rfc6620>

Hilliard, N. D. Freedman "A Discard Prefix for IPv6" RFC 6666 DOI10.17487/RFC6666 <https://www.rfc-editor.org/info/rfc6666>

Cheshire, S. M. Krochmal "Multicast DNS" RFC 6762 DOI 10.17487/RFC6762<https://www.rfc-editor.org/info/rfc6762>

Cheshire, S. M. Krochmal "DNS-Based Service Discovery" RFC 6763 DOI10.17487/RFC6763 <https://www.rfc-editor.org/info/rfc6763>

Shelby, Z., Ed. Chakrabarti, S. Nordmark, E. C. Bormann "NeighborDiscovery Optimization for IPv6 over Low-Power Wireless Personal AreaNetworks (6LoWPANs)" RFC 6775 DOI 10.17487/RFC6775<https://www.rfc-editor.org/info/rfc6775>




















[RFC6877]

[RFC6888]

[RFC6939]

[RFC6964]

[RFC6967]

[RFC6980]

[RFC7010]

[RFC7011]

[RFC7012]

[RFC7039]

[RFC7045]

[RFC7084]

, , and , , , , April 2013,

.

, , , , and , , , ,

, April 2013, .

, , and , , , , May 2013,

.

, , ,

, May 2013, .

, , , and , ,

, , June 2013, .

, , , , August 2013,

.

, , , , and , , , , September 2013,

.

, , and , ,

, , , September 2013, .

and , , , , September 2013,

.

, , , , and , , , , October

2013, .


.

, , , and , , , , November 2013,

.

Mawatari, M. Kawashima, M. C. Byrne "464XLAT: Combination of Statefuland Stateless Translation" RFC 6877 DOI 10.17487/RFC6877 <https://www.rfc-editor.org/info/rfc6877>

Perreault, S., Ed. Yamagata, I. Miyakawa, S. Nakagawa, A. H. Ashida"Common Requirements for Carrier-Grade NATs (CGNs)" BCP 127 RFC 6888DOI 10.17487/RFC6888 <https://www.rfc-editor.org/info/rfc6888>

Halwasia, G. Bhandari, S. W. Dec "Client Link-Layer Address Option inDHCPv6" RFC 6939 DOI 10.17487/RFC6939 <https://www.rfc-editor.org/info/rfc6939>

Templin, F. "Operational Guidance for IPv6 Deployment in IPv4 Sites Using theIntra-Site Automatic Tunnel Addressing Protocol (ISATAP)" RFC 6964 DOI10.17487/RFC6964 <https://www.rfc-editor.org/info/rfc6964>

Boucadair, M. Touch, J. Levis, P. R. Penno "Analysis of Potential Solutionsfor Revealing a Host Identifier (HOST_ID) in Shared Address Deployments" RFC6967 DOI 10.17487/RFC6967 <https://www.rfc-editor.org/info/rfc6967>

Gont, F. "Security Implications of IPv6 Fragmentation with IPv6 NeighborDiscovery" RFC 6980 DOI 10.17487/RFC6980 <https://www.rfc-editor.org/info/rfc6980>

Liu, B. Jiang, S. Carpenter, B. Venaas, S. W. George "IPv6 SiteRenumbering Gap Analysis" RFC 7010 DOI 10.17487/RFC7010<https://www.rfc-editor.org/info/rfc7010>

Claise, B., Ed. Trammell, B., Ed. P. Aitken "Specification of the IP FlowInformation Export (IPFIX) Protocol for the Exchange of Flow Information" STD77 RFC 7011 DOI 10.17487/RFC7011 <https://www.rfc-editor.org/info/rfc7011>

Claise, B., Ed. B. Trammell, Ed. "Information Model for IP Flow InformationExport (IPFIX)" RFC 7012 DOI 10.17487/RFC7012 <https://www.rfc-editor.org/info/rfc7012>

Wu, J. Bi, J. Bagnulo, M. Baker, F. C. Vogt, Ed. "Source Address ValidationImprovement (SAVI) Framework" RFC 7039 DOI 10.17487/RFC7039


Carpenter, B. S. Jiang "Transmission and Processing of IPv6 ExtensionHeaders" RFC 7045 DOI 10.17487/RFC7045 <https://www.rfc-editor.org/info/rfc7045>

Singh, H. Beebee, W. Donley, C. B. Stark "Basic Requirements for IPv6Customer Edge Routers" RFC 7084 DOI 10.17487/RFC7084<https://www.rfc-editor.org/info/rfc7084>






















[RFC7112]

[RFC7113]

[RFC7123]

[RFC7166]

[RFC7217]

[RFC7359]

[RFC7381]

[RFC7404]

[RFC7422]

[RFC7454]

[RFC7513]

[RFC7526]

, , and , , , , January 2014,

.

, , , , February 2014,

.


.

, , and , , , , March 2014,

.

, , ,

, April 2014, .

, , , , August 2014,

.

, , , , , and , , ,

, October 2014, .

and , , , , November 2014,

.

, , , , and ,

, , , December 2014, .

, , and , , ,, , February 2015,

.

, , , and , , , , May 2015,

.

and , , , , , May 2015,

.

Gont, F. Manral, V. R. Bonica "Implications of Oversized IPv6 HeaderChains" RFC 7112 DOI 10.17487/RFC7112 <https://www.rfc-editor.org/info/rfc7112>

Gont, F. "Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)" RFC 7113 DOI 10.17487/RFC7113 <https://www.rfc-editor.org/info/rfc7113>

Gont, F. W. Liu "Security Implications of IPv6 on IPv4 Networks" RFC 7123DOI 10.17487/RFC7123 <https://www.rfc-editor.org/info/rfc7123>

Bhatia, M. Manral, V. A. Lindem "Supporting Authentication Trailer forOSPFv3" RFC 7166 DOI 10.17487/RFC7166 <https://www.rfc-editor.org/info/rfc7166>

Gont, F. "A Method for Generating Semantically Opaque Interface Identifierswith IPv6 Stateless Address Autoconfiguration (SLAAC)" RFC 7217 DOI10.17487/RFC7217 <https://www.rfc-editor.org/info/rfc7217>

Gont, F. "Layer 3 Virtual Private Network (VPN) Tunnel Traffic Leakages inDual-Stack Hosts/Networks" RFC 7359 DOI 10.17487/RFC7359<https://www.rfc-editor.org/info/rfc7359>

Chittimaneni, K. Chown, T. Howard, L. Kuarsingh, V. Pouffary, Y. E.Vyncke "Enterprise IPv6 Deployment Guidelines" RFC 7381 DOI 10.17487/RFC7381 <https://www.rfc-editor.org/info/rfc7381>

Behringer, M. E. Vyncke "Using Only Link-Local Addressing inside an IPv6Network" RFC 7404 DOI 10.17487/RFC7404 <https://www.rfc-editor.org/info/rfc7404>

Donley, C. Grundemann, C. Sarawat, V. Sundaresan, K. O. Vautrin"Deterministic Address Mapping to Reduce Logging in Carrier-Grade NATDeployments" RFC 7422 DOI 10.17487/RFC7422 <https://www.rfc-editor.org/info/rfc7422>

Durand, J. Pepelnjak, I. G. Doering "BGP Operations and Security" BCP 194RFC 7454 DOI 10.17487/RFC7454 <https://www.rfc-editor.org/info/rfc7454>

Bi, J. Wu, J. Yao, G. F. Baker "Source Address Validation Improvement(SAVI) Solution for DHCP" RFC 7513 DOI 10.17487/RFC7513 <https://www.rfc-editor.org/info/rfc7513>

Troan, O. B. Carpenter, Ed. "Deprecating the Anycast Prefix for 6to4 RelayRouters" BCP 196 RFC 7526 DOI 10.17487/RFC7526 <https://www.rfc-editor.org/info/rfc7526>
























[RFC7552]

[RFC7597]

[RFC7599]

[RFC7610]

[RFC7707]

[RFC7721]

[RFC7772]

[RFC7785]

[RFC7824]

[RFC7844]

[RFC7857]

[RFC7872]

, , , , and , , , , June 2015,

.

, , , , , , and , , ,

, July 2015, .

, , , , , and , , ,

, July 2015, .

, , and , , , , , August 2015,

.

and , , , , March 2016, .

, , and , , , , March

2016, .

and , , , , , February 2016,

.

and , , , , February

2016, .

, , and , , , , May 2016, .

, , and , , , , May 2016,

.

, , , , and , , ,

, , April 2016, .

, , , and , , ,

, June 2016, .

Asati, R. Pignataro, C. Raza, K. Manral, V. R. Papneja "Updates to LDP forIPv6" RFC 7552 DOI 10.17487/RFC7552 <https://www.rfc-editor.org/info/rfc7552>

Troan, O., Ed. Dec, W. Li, X. Bao, C. Matsushima, S. Murakami, T. T. Taylor,Ed. "Mapping of Address and Port with Encapsulation (MAP-E)" RFC 7597 DOI10.17487/RFC7597 <https://www.rfc-editor.org/info/rfc7597>

Li, X. Bao, C. Dec, W., Ed. Troan, O. Matsushima, S. T. Murakami "Mappingof Address and Port using Translation (MAP-T)" RFC 7599 DOI 10.17487/RFC7599 <https://www.rfc-editor.org/info/rfc7599>

Gont, F. Liu, W. G. Van de Velde "DHCPv6-Shield: Protecting against RogueDHCPv6 Servers" BCP 199 RFC 7610 DOI 10.17487/RFC7610<https://www.rfc-editor.org/info/rfc7610>

Gont, F. T. Chown "Network Reconnaissance in IPv6 Networks" RFC 7707DOI 10.17487/RFC7707 <https://www.rfc-editor.org/info/rfc7707>

Cooper, A. Gont, F. D. Thaler "Security and Privacy Considerations for IPv6Address Generation Mechanisms" RFC 7721 DOI 10.17487/RFC7721


Yourtchenko, A. L. Colitti "Reducing Energy Consumption of RouterAdvertisements" BCP 202 RFC 7772 DOI 10.17487/RFC7772<https://www.rfc-editor.org/info/rfc7772>

Vinapamula, S. M. Boucadair "Recommendations for Prefix Binding in theContext of Softwire Dual-Stack Lite" RFC 7785 DOI 10.17487/RFC7785


Krishnan, S. Mrugalski, T. S. Jiang "Privacy Considerations for DHCPv6"RFC 7824 DOI 10.17487/RFC7824 <https://www.rfc-editor.org/info/rfc7824>

Huitema, C. Mrugalski, T. S. Krishnan "Anonymity Profiles for DHCPClients" RFC 7844 DOI 10.17487/RFC7844 <https://www.rfc-editor.org/info/rfc7844>

Penno, R. Perreault, S. Boucadair, M., Ed. Sivakumar, S. K. Naito "Updatesto Network Address Translation (NAT) Behavioral Requirements" BCP 127 RFC7857 DOI 10.17487/RFC7857 <https://www.rfc-editor.org/info/rfc7857>

Gont, F. Linkova, J. Chown, T. W. Liu "Observations on the Dropping ofPackets with IPv6 Extension Headers in the Real World" RFC 7872 DOI10.17487/RFC7872 <https://www.rfc-editor.org/info/rfc7872>



















[RFC7915]

[RFC7934]

[RFC8040]

[RFC8064]

[RFC8177]

[RFC8190]

[RFC8210]

[RFC8273]

[RFC8343]

[RFC8344]

[RFC8415]

[RFC8504]

[RFC8520]

, , , , and , , , , June 2016,

.

, , , and , , , , , July 2016,

.

, , and , , , , January 2017, .

, , , and , , , , February 2017,

.

, , , , and , , , , June 2017,

.

, , , and , , , , , June

2017, .

and , , , , September 2017,

.

and , , , , December 2017, .

, , , , March 2018, .

, , , , March 2018, .

, , , , , , , and , , , , November 2018,

.

, , and , , , , , January 2019,

.

, , and , , , , March 2019,

.

Bao, C. Li, X. Baker, F. Anderson, T. F. Gont "IP/ICMP TranslationAlgorithm" RFC 7915 DOI 10.17487/RFC7915 <https://www.rfc-editor.org/info/rfc7915>

Colitti, L. Cerf, V. Cheshire, S. D. Schinazi "Host Address AvailabilityRecommendations" BCP 204 RFC 7934 DOI 10.17487/RFC7934<https://www.rfc-editor.org/info/rfc7934>

Bierman, A. Bjorklund, M. K. Watsen "RESTCONF Protocol" RFC 8040 DOI10.17487/RFC8040 <https://www.rfc-editor.org/info/rfc8040>

Gont, F. Cooper, A. Thaler, D. W. Liu "Recommendation on Stable IPv6Interface Identifiers" RFC 8064 DOI 10.17487/RFC8064 <https://www.rfc-editor.org/info/rfc8064>

Lindem, A., Ed. Qu, Y. Yeung, D. Chen, I. J. Zhang "YANG Data Model forKey Chains" RFC 8177 DOI 10.17487/RFC8177 <https://www.rfc-editor.org/info/rfc8177>

Bonica, R. Cotton, M. Haberman, B. L. Vegoda "Updates to the Special-Purpose IP Address Registries" BCP 153 RFC 8190 DOI 10.17487/RFC8190


Bush, R. R. Austein "The Resource Public Key Infrastructure (RPKI) toRouter Protocol, Version 1" RFC 8210 DOI 10.17487/RFC8210<https://www.rfc-editor.org/info/rfc8210>

Brzozowski, J. G. Van de Velde "Unique IPv6 Prefix per Host" RFC 8273 DOI10.17487/RFC8273 <https://www.rfc-editor.org/info/rfc8273>

Bjorklund, M. "A YANG Data Model for Interface Management" RFC 8343 DOI10.17487/RFC8343 <https://www.rfc-editor.org/info/rfc8343>

Bjorklund, M. "A YANG Data Model for IP Management" RFC 8344 DOI10.17487/RFC8344 <https://www.rfc-editor.org/info/rfc8344>

Mrugalski, T. Siodelski, M. Volz, B. Yourtchenko, A. Richardson, M. Jiang, S.Lemon, T. T. Winters "Dynamic Host Configuration Protocol for IPv6(DHCPv6)" RFC 8415 DOI 10.17487/RFC8415 <https://www.rfc-editor.org/info/rfc8415>

Chown, T. Loughney, J. T. Winters "IPv6 Node Requirements" BCP 220 RFC8504 DOI 10.17487/RFC8504 <https://www.rfc-editor.org/info/rfc8504>

Lear, E. Droms, R. D. Romascanu "Manufacturer Usage DescriptionSpecification" RFC 8520 DOI 10.17487/RFC8520 <https://www.rfc-editor.org/info/rfc8520>






















[RFC8541]

[RFC8981]

[SCANNING]

[WEBER_VPN]

, , and , , ,

, March 2019, .

, , , and , , ,

, February 2021, .

, , and , , February 2012,

.

, , March 2018,

.

Litkowski, S. Decraene, B. M. Horneffer "Impact of Shortest Path First (SPF)Trigger and Delay Strategies on IGP Micro-loops" RFC 8541 DOI 10.17487/RFC8541 <https://www.rfc-editor.org/info/rfc8541>

Gont, F. Krishnan, S. Narten, T. R. Draves "Temporary Address Extensionsfor Stateless Address Autoconfiguration in IPv6" RFC 8981 DOI 10.17487/RFC8981 <https://www.rfc-editor.org/info/rfc8981>

Barnes, R. Altmann, R. D. Kerr "Mapping the Great Void - Smarter scanningfor IPv6" <http://www.caida.org/workshops/isma/1202/slides/aims1202_rbarnes.pdf>

Weber, J. "Dynamic IPv6 Prefix - Problems and VPNs" <https://blog.webernetz.net/wp-content/uploads/2018/03/TR18-Johannes-Weber-Dynamic-IPv6-Prefix-Problems-and-VPNs.pdf>

Acknowledgements The authors would like to thank the following people for their useful comments (in alphabeticalorder): , , , ,

, , , (IESG Review), , (IESG review), , , , ,

(IESG review), , , , (IESG review), , , (and his detailed nits), (and her detailed

review), (the Document Shepherd), , (IESG review), (IESG review), , , , , and

.

Mikael Abrahamsson Fred Baker Mustafa Suha Botsali Mohamed Boucadair BrianCarpenter Tim Chown Lorenzo Colitti Roman Danyliw Markus de Bruen LarsEggert Tobias Fiebig Fernando Gont Jeffry Handal Lee Howard Benjamin Kaduk

Panos Kampanakis Erik Kline Jouni Korhonen Warren KumariTed Lemon Mark Lentczner Acee Lindem Jen Linkova

Gyan S. Mishra Jordi Palet Alvaro RetanaZaheduzzaman Sarker Bob Sleigh Donald Smith Tarko Tikan Ole TroanBernie Volz

Authors' Addresses Éric VynckeCiscoDe Kleetlaan 6a

1831 DiegemBelgium

+32 2 778 4677 Phone: [email protected] Email:

Kiran Kumar Chittimaneni [email protected] Email:





http://www.caida.org/workshops/isma/1202/slides/aims1202_rbarnes.pdf

http://www.caida.org/workshops/isma/1202/slides/aims1202_rbarnes.pdf

https://blog.webernetz.net/wp-content/uploads/2018/03/TR18-Johannes-Weber-Dynamic-IPv6-Prefix-Problems-and-VPNs.pdf



tel:+32%202%20778%204677

mailto:[email protected]


Merike KaeoDouble Shot Security3518 Fremont Ave N 363

, Seattle 98103United States of America

+12066696394 Phone: [email protected] Email:

Enno ReyERNWCarl-Bosch-Str. 4

69115 Heidelberg Baden-WuertembergGermany

+49 6221 480390 Phone: [email protected] Email:



tel:+12066696394


tel:+49%206221%20480390
