idnits 2.17.1 draft-ietf-opsec-v6-27.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 215: '...::/8 space (L=1) MUST be generated wit...' RFC 2119 keyword, line 474: '... architecture [RFC4301] a SHOULD for all IPv6 nodes which is also...' RFC 2119 keyword, line 931: '... that "ESP-Null MUST and AH MAY be im...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 6, 2021) is 642 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3924' is defined on line 2130, but no explicit reference was found in the text == Unused Reference: 'RFC7050' is defined on line 2473, but no explicit reference was found in the text == Outdated reference: draft-ietf-opsec-ipv6-eh-filtering has been published as RFC 9288 -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 3068 (Obsoleted by RFC 7526) -- Obsolete informational reference (is this intentional?): RFC 3627 (Obsoleted by RFC 6547) -- Obsolete informational reference (is this intentional?): RFC 6434 (Obsoleted by RFC 8504) Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OPSEC E. Vyncke 3 Internet-Draft Cisco 4 Intended status: Informational K. Chittimaneni 5 Expires: November 7, 2021 Square 6 M. Kaeo 7 Double Shot Security 8 E. Rey 9 ERNW 10 May 6, 2021 12 Operational Security Considerations for IPv6 Networks 13 draft-ietf-opsec-v6-27 15 Abstract 17 Knowledge and experience on how to operate IPv4 networks securely is 18 available: whether it is an Internet Service Provider or an 19 enterprise internal network. However, IPv6 presents some new 20 security challenges. RFC 4942 describes security issues in the 21 protocol, but network managers also need a more practical, 22 operations-minded document to enumerate advantages and/or 23 disadvantages of certain choices. 25 This document analyzes the operational security issues associated 26 with several types of network and proposes technical and procedural 27 mitigation techniques. This document is only applicable to managed 28 networks, such as enterprise networks, service provider networks, or 29 managed residential networks. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on November 7, 2021. 48 Copyright Notice 50 Copyright (c) 2021 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 1.1. Applicability Statement . . . . . . . . . . . . . . . . . 4 67 2. Generic Security Considerations . . . . . . . . . . . . . . . 4 68 2.1. Addressing . . . . . . . . . . . . . . . . . . . . . . . 4 69 2.1.1. Use of ULAs . . . . . . . . . . . . . . . . . . . . . 5 70 2.1.2. Point-to-Point Links . . . . . . . . . . . . . . . . 5 71 2.1.3. Loopback Addresses . . . . . . . . . . . . . . . . . 5 72 2.1.4. Stable Addresses . . . . . . . . . . . . . . . . . . 6 73 2.1.5. Temporary Addresses for SLAAC . . . . . . . . . . . . 6 74 2.1.6. DHCP Considerations . . . . . . . . . . . . . . . . . 8 75 2.1.7. DNS Considerations . . . . . . . . . . . . . . . . . 8 76 2.1.8. Using a /64 per host . . . . . . . . . . . . . . . . 8 77 2.1.9. Privacy consideration of Addresses . . . . . . . . . 8 78 2.2. Extension Headers . . . . . . . . . . . . . . . . . . . . 9 79 2.2.1. Order and Repetition of Extension Headers . . . . . . 9 80 2.2.2. Hop-by-Hop Options Header . . . . . . . . . . . . . . 10 81 2.2.3. Fragment Header . . . . . . . . . . . . . . . . . . . 10 82 2.2.4. IP Security Extension Header . . . . . . . . . . . . 10 83 2.3. Link-Layer Security . . . . . . . . . . . . . . . . . . . 11 84 2.3.1. Neighbor Solicitation Rate-Limiting . . . . . . . . . 11 85 2.3.2. Router and Neighbor Advertisements Filtering . . . . 12 86 2.3.3. Securing DHCP . . . . . . . . . . . . . . . . . . . . 13 87 2.3.4. 3GPP Link-Layer Security . . . . . . . . . . . . . . 14 88 2.3.5. Impact of Multicast Traffic . . . . . . . . . . . . . 15 89 2.3.6. SeND and CGA . . . . . . . . . . . . . . . . . . . . 15 90 2.4. Control Plane Security . . . . . . . . . . . . . . . . . 16 91 2.4.1. Control Protocols . . . . . . . . . . . . . . . . . . 17 92 2.4.2. Management Protocols . . . . . . . . . . . . . . . . 18 93 2.4.3. Packet Exceptions . . . . . . . . . . . . . . . . . . 18 94 2.5. Routing Security . . . . . . . . . . . . . . . . . . . . 19 95 2.5.1. BGP Security . . . . . . . . . . . . . . . . . . . . 20 96 2.5.2. Authenticating OSPFv3 Neighbors . . . . . . . . . . . 20 97 2.5.3. Securing Routing Updates . . . . . . . . . . . . . . 21 98 2.5.4. Route Filtering . . . . . . . . . . . . . . . . . . . 21 99 2.6. Logging/Monitoring . . . . . . . . . . . . . . . . . . . 21 100 2.6.1. Data Sources . . . . . . . . . . . . . . . . . . . . 23 101 2.6.2. Use of Collected Data . . . . . . . . . . . . . . . . 26 102 2.6.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 29 103 2.7. Transition/Coexistence Technologies . . . . . . . . . . . 29 104 2.7.1. Dual Stack . . . . . . . . . . . . . . . . . . . . . 30 105 2.7.2. Encapsulation Mechanisms . . . . . . . . . . . . . . 31 106 2.7.3. Translation Mechanisms . . . . . . . . . . . . . . . 35 107 2.8. General Device Hardening . . . . . . . . . . . . . . . . 37 108 3. Enterprises Specific Security Considerations . . . . . . . . 37 109 3.1. External Security Considerations . . . . . . . . . . . . 38 110 3.2. Internal Security Considerations . . . . . . . . . . . . 39 111 4. Service Providers Security Considerations . . . . . . . . . . 40 112 4.1. BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 113 4.1.1. Remote Triggered Black Hole Filtering (RTBH) . . . . 40 114 4.2. Transition/Coexistence Mechanism . . . . . . . . . . . . 40 115 4.3. Lawful Intercept . . . . . . . . . . . . . . . . . . . . 40 116 5. Residential Users Security Considerations . . . . . . . . . . 41 117 6. Further Reading . . . . . . . . . . . . . . . . . . . . . . . 41 118 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 42 119 8. Security Considerations . . . . . . . . . . . . . . . . . . . 42 120 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 42 121 9.1. Normative References . . . . . . . . . . . . . . . . . . 42 122 9.2. Informative References . . . . . . . . . . . . . . . . . 42 123 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 57 125 1. Introduction 127 Running an IPv6 network is new for most operators not only because 128 they are not yet used to large-scale IPv6 networks but also because 129 there are subtle but critical and important differences between IPv4 130 and IPv6, especially with respect to security. For example, all 131 layer-2 interactions are now done using Neighbor Discovery Protocol 132 [RFC4861] rather than using Address Resolution Protocol [RFC0826]. 133 Also, there is no Network Address Port Translation (NAPT) defined in 134 [RFC2663] for IPv6 even if [RFC6296] specifies a Network Prefix 135 Translation for IPv6 (NPTv6) which is a 1-to-1 mapping of IPv6 136 addresses. Another important difference is that IPv6 is extensible 137 with the use of extension headers. 139 IPv6 networks are deployed using a variety of techniques, each of 140 which have their own specific security concerns. 142 This document complements [RFC4942] by listing security issues when 143 operating a network (including various transition technologies). It 144 also provides more recent operational deployment experiences where 145 warranted. 147 1.1. Applicability Statement 149 This document is applicable to managed networks, i.e., when the 150 network is operated by the user organization itself. Indeed, many of 151 the recommended mitigation techniques must be configured with 152 detailed knowledge of the network (which are the default routers, the 153 switch trunk ports, etc.). This covers Service Provider (SP), 154 enterprise networks and some knowledgeable-home-user-managed 155 residential networks. This applicability statement especially 156 applies to Section 2.3 and Section 2.5.4. 158 2. Generic Security Considerations 160 2.1. Addressing 162 IPv6 address allocations and overall architecture are an important 163 part of securing IPv6. Initial designs, even if intended to be 164 temporary, tend to last much longer than expected. Although 165 initially IPv6 was thought to make renumbering easy, in practice it 166 may be extremely difficult to renumber without a proper IP Address 167 Management (IPAM) system. [RFC7010] introduces the mechanisms that 168 could be utilized for IPv6 site renumbering and tries to cover most 169 of the explicit issues and requirements associated with IPv6 170 renumbering. 172 A key task for a successful IPv6 deployment is to prepare an 173 addressing plan. Because an abundance of address space is available, 174 structuring an address plan around both services and geographic 175 locations allows address space to become a basis for more structured 176 security policies to permit or deny services between geographic 177 regions. [RFC6177] documents some operational considerations of 178 using different prefix sizes for address assignments at end sites. 180 A common question is whether companies should use Provider 181 Independent (PI) vs. Provider Allocated (PA) space [RFC7381], but 182 from a security perspective there is little difference. However, one 183 aspect to keep in mind is who has administrative ownership of the 184 address space and who is technically responsible if/when there is a 185 need to enforce restrictions on routability of the space, e.g., due 186 to malicious criminal activity originating from it. Relying on PA 187 address space may also increase the perceived need for address 188 translation techniques such as NPTv6 and thereby augmenting the 189 complexity of the operations including the security operations. 191 In [RFC7934], it is recommended that IPv6 network deployments provide 192 multiple IPv6 addresses from each prefix to general-purpose hosts and 193 it specifically does not recommend limiting a host to only one IPv6 194 address per prefix. It also recommends that the network give the 195 host the ability to use new addresses without requiring explicit 196 requests (for example by using SLAAC). Privacy Extensions as of 197 [RFC8981] constitute one of the main scenarios where hosts are 198 expected to generate multiple addresses from the same prefix and 199 having multiple IPv6 addresses per interface is a major change 200 compared to the unique IPv4 address per interface for hosts 201 (secondary IPv4 addresses are not common); especially for audits (see 202 section Section 2.6.2.3). 204 2.1.1. Use of ULAs 206 Unique Local Addresses (ULAs) [RFC4193] are intended for scenarios 207 where interfaces are not globally reachable, despite being routed 208 within a domain. They formally have global scope, but [RFC4193] 209 specifies that they must be filtered at domain boundaries. ULAs are 210 different from [RFC1918] addresses and have different use cases. One 211 use of ULA is described in [RFC4864], another one is for internal 212 communication stability in networks where external connectivity may 213 come and go (e.g., some ISPs provide ULAs in home networks connected 214 via a cable modem). It should further be kept in mind that ULA /48s 215 from the fd00::/8 space (L=1) MUST be generated with a pseudo-random 216 algorithm, per [RFC4193] section 3.2.1. 218 2.1.2. Point-to-Point Links 220 [RFC6164] in section 5.1 specifies the rationale of using /127 for 221 inter-router point-to-point links to prevent the ping-pong issue 222 between routers not correctly implementing [RFC4443] and also 223 prevents a DoS attack on the neighbor cache. The previous 224 recommendation of [RFC3627] has been obsoleted and marked Historic by 225 [RFC6547]). 227 Some environments are also using link-local addressing for point-to- 228 point links. While this practice could further reduce the attack 229 surface of infrastructure devices, the operational disadvantages also 230 need to be carefully considered; see also [RFC7404]. 232 2.1.3. Loopback Addresses 234 Many operators reserve a /64 block for all loopback addresses in 235 their infrastructure and allocate a /128 out of this reserved /64 236 prefix for each loopback interface. This practice facilitates 237 configuration of Access Control List (ACL) rules to enforce a 238 security policy for those loopback addresses. 240 2.1.4. Stable Addresses 242 When considering how to assign stable addresses for nodes (either by 243 static configuration or by pre-provisioned DHCPv6 lease 244 Section 2.1.6), it is necessary to take into consideration the 245 effectiveness of perimeter security in a given environment. 247 There is a trade-off between ease of operation (where some portions 248 of the IPv6 address could be easily recognizable for operational 249 debugging and troubleshooting) versus the risk of trivial scanning 250 used for reconnaissance. [SCANNING] shows that there are 251 scientifically based mechanisms that make scanning for IPv6 reachable 252 nodes more feasible than expected; see also [RFC7707]. 254 Stable addresses also allow easy enforcement of a security policy at 255 the perimeter based on IPv6 addresses. E.g., Manufacturer Usage 256 Description (MUD) [RFC8520] is a mechanism where the perimeter 257 defense can retrieve security policy template based on the type of 258 internal device and apply the right security policy based on the 259 device IPv6 address. 261 The use of well-known IPv6 addresses (such as ff02::1 for all link- 262 local nodes) or the use of commonly repeated addresses could make it 263 easy to figure out which devices are name servers, routers, or other 264 critical devices; even a simple traceroute will expose most of the 265 routers on a path. There are many scanning techniques possible and 266 operators should not rely on the 'impossible to find because my 267 address is random' paradigm (a.k.a. "security by obscurity"), even if 268 it is common practice to have the stable addresses randomly 269 distributed across /64 subnets and to always use DNS (as IPv6 270 addresses are hard for human brains to remember). 272 While in some environments obfuscating addresses could be considered 273 an added benefit, it should not preclude enforcement of perimeter 274 rules. Stable addresses following some logical allocation scheme may 275 ease the operation (as simplicity always helps security). 277 Typical deployments will have a mix of stable and non-stable 278 addresses; the stable addresses being either predictable (e.g., ::25 279 for a mail server) or obfuscated (i.e., appearing as a random 64-bit 280 number). 282 2.1.5. Temporary Addresses for SLAAC 284 Historically, stateless address autoconfiguration (SLAAC) makes up 285 the globally unique IPv6 address based on an automatically generated 286 64-bit interface identifier (IID) based on the EUI-64 MAC address 287 combined with the /64 prefix (received in the Prefix Information 288 Option (PIO) of the Router Advertisement (RA)). The EUI-64 address 289 is generated from the stable 48-bit MAC address and does not change 290 even if the host moves to another network; this is of course bad for 291 privacy as a host can be traced from network (home) to network 292 (office or Wi-Fi in hotels). [RFC8064] recommends against the use of 293 EUI-64 addresses; and it must be noted that most host operating 294 systems do not use EUI-64 addresses anymore and rely on either 295 [RFC8981] or [RFC8064]. 297 Randomly generating an interface ID, as described in [RFC8981], is 298 part of SLAAC with so-called privacy extension addresses and is used 299 to address some privacy concerns. Privacy extension addresses, 300 a.k.a., temporary addresses may help to mitigate the correlation of 301 activities of a node within the same network and may also reduce the 302 attack exposure window. But using [RFC8981] privacy extension 303 addresses might prevent the operator from building host specific 304 access control lists (ACLs). The [RFC8981] privacy extension 305 addresses could also be used to obfuscate some malevolent activities 306 and specific user attribution/accountability procedures should be put 307 in place as described in Section 2.6. 309 [RFC8064] combined with the address generation mechanism of [RFC7217] 310 specifies another way to generate an address while still keeping the 311 same IID for each network prefix; this allows SLAAC nodes to always 312 have the same stable IPv6 address on a specific network while having 313 different IPv6 addresses on different networks. 315 In some specific use cases where user accountability is more 316 important than user privacy, network operators may consider disabling 317 SLAAC and relying only on DHCPv6; but not all operating systems 318 support DHCPv6 so some hosts will not get any IPv6 connectivity. 319 Disabling SLAAC and privacy extension addresses can be done for most 320 operating systems by sending RA messages with a hint to get addresses 321 via DHCPv6 by setting the M-bit and disabling SLAAC by resetting all 322 A-bits in all prefix information options. However, attackers could 323 still find ways to bypass this mechanism if not enforced at the 324 switch/router level. 326 However, in scenarios where anonymity is a strong desire (protecting 327 user privacy is more important than user attribution), privacy 328 extension addresses should be used. When mechanisms recommended by 329 [RFC8064] are available, the stable privacy address is probably a 330 good balance between privacy (among different networks) and security/ 331 user attribution (within a network). 333 2.1.6. DHCP Considerations 335 Some environments use DHCPv6 to provision addresses and other 336 parameters in order to ensure auditability and traceability (see 337 Section 2.6.1.5 for the limitations of DHCPv6 for auditability). 339 A main security concern is the ability to detect and counteract rogue 340 DHCP servers (Section 2.3.3). It must be noted that as opposed to 341 DHCPv4, DHCPv6 can lease several IPv6 addresses per client. For 342 DHCPv4, the lease is bound to the 'client identifier', which may 343 contain a hardware address, or it may contain another type of 344 identifier, such as a DNS name. For DHCPv6, the lease is bound to 345 the client DHCP Unique ID (DUID), which may, or may not, be bound to 346 the client link-layer address. [RFC7824] describes the privacy 347 issues associated with the use of DHCPv6 by Internet users. The 348 anonymity profiles [RFC7844] are designed for clients that wish to 349 remain anonymous to the visited network. [RFC7707] recommends that 350 DHCPv6 servers issue addresses randomly from a large pool. 352 2.1.7. DNS Considerations 354 While the security concerns of DNS are not fundamentally different 355 between IPv4 and IPv6, there are specific considerations in DNS64 356 [RFC6147] environments that need to be understood. Specifically, the 357 interactions and the potential of interference with DNSSEC 358 ([RFC4033]) implementation need to be understood - these are pointed 359 out in more detail in Section 2.7.3.2. 361 2.1.8. Using a /64 per host 363 An interesting approach is using a /64 per host as proposed in 364 [RFC8273] especially in a shared environment. This allows for easier 365 user attribution (typically based on the host MAC address) as its /64 366 prefix is stable even if applications within the host can change 367 their IPv6 address within this /64 prefix. 369 This can also be useful for the generation of ACLs once individual 370 systems (e.g. admin workstations) have their own prefixes. 372 2.1.9. Privacy consideration of Addresses 374 Beside the security aspects of IPv6 addresses, there are also privacy 375 considerations: mainly because they are of global scope and visible 376 globally. [RFC7721] goes into more detail on the privacy 377 considerations for IPv6 addresses by comparing the manually 378 configured IPv6 address, DHCPv6, and SLAAC. 380 2.2. Extension Headers 382 Extension headers are an important difference between IPv4 and IPv6. 383 In IPv4-based packets, it's trivial to find the upper-layer protocol 384 type and protocol header, while in IPv6 it is more complex since the 385 extension header chain must be parsed completely (even if not 386 processed) in order to find the upper-layer protocol header. IANA 387 has closed the existing empty "Next Header Types" registry to new 388 entries and is redirecting its users to a new "IPv6 Extension Header 389 Types" registry per [RFC7045]. 391 Extension headers have also become a very controversial topic since 392 forwarding nodes that discard packets containing extension headers 393 are known to cause connectivity failures and deployment problems 394 [RFC7872]. Understanding the role of various extension headers is 395 important and this section enumerates the ones that need careful 396 consideration. 398 A clarification on how intermediate nodes should handle packets with 399 existing or future extension headers is found in [RFC7045]. The 400 uniform TLV format to be used for defining future extension headers 401 is described in [RFC6564]. Sections 5.2 and 5.3 of [RFC8504] provide 402 more information on the processing of extension headers by IPv6 403 nodes. 405 Vendors of filtering solutions and operations personnel responsible 406 for implementing packet filtering rules should be aware that the 407 'Next Header' field in an IPv6 header can both point to an IPv6 408 extension header or to an upper layer protocol header. This has to 409 be considered when designing the user interface of filtering 410 solutions or during the creation of filtering rule sets. 412 There is IETF work in progress regarding filtering rules for those 413 extension headers: [I-D.ietf-opsec-ipv6-eh-filtering] for transit 414 routers. 416 2.2.1. Order and Repetition of Extension Headers 418 While [RFC8200] recommends the order and the maximum repetition of 419 extension headers, there are still IPv6 implementations, at the time 420 of writing, which support a non-recommended order of headers (such as 421 ESP before routing) or an illegal repetition of headers (such as 422 multiple routing headers). The same applies for options contained in 423 the extension headers (see [I-D.kampanakis-6man-ipv6-eh-parsing]). 424 In some cases, it has led to nodes crashing when receiving or 425 forwarding wrongly formatted packets. 427 A firewall or edge device should be used to enforce the recommended 428 order and the maximum occurrences of extension headers by dropping 429 non-conforming packets. 431 2.2.2. Hop-by-Hop Options Header 433 In the previous IPv6 specification [RFC2460], the hop-by-hop options 434 header, when present in an IPv6 packet, forced all nodes to inspect 435 and possibly process this header. This enabled denial-of-service 436 attacks as most, if not all, routers cannot process this type of 437 packet in hardware but have to process these packets in software and 438 hence compete with other software tasks, such as handling the control 439 and management plane processing. 441 Section 4.3 of the current Internet Standard for IPv6, [RFC8200], has 442 taken this attack vector into account and made the processing of hop- 443 by-hop options headers by intermediate routers explicitly 444 configurable. 446 2.2.3. Fragment Header 448 The fragment header is used by the source (and only the source) when 449 it has to fragment packets. [RFC7112] and section 4.5 of [RFC8200] 450 explain why it is important that: 452 Firewall and security devices should drop first fragments that do 453 not contain the entire IPv6 header chain (including the transport- 454 layer header). 456 Destination nodes should discard first fragments that do not 457 contain the entire IPv6 header chain (including the transport- 458 layer header). 460 If those requirements are not met, stateless filtering could be 461 bypassed by a hostile party. [RFC6980] applies a stricter rule to 462 Neighbor Discovery Protocol (NDP) by enforcing the drop of fragmented 463 NDP packets (except for "Certification Path Advertisement" messages 464 as noted in section Section 2.3.2.1). [RFC7113] describes how the 465 RA-guard function described in [RFC6105] should behave in the 466 presence of fragmented RA packets. 468 2.2.4. IP Security Extension Header 470 The IPsec [RFC4301] extension headers (AH [RFC4302] and ESP 471 [RFC4303]) are required if IPsec is to be utilized for network level 472 security. Previously, IPv6 mandated implementation of IPsec but 473 [RFC6434] updated that recommendation by making support of the IPsec 474 architecture [RFC4301] a SHOULD for all IPv6 nodes which is also 475 retained in the latest IPv6 Nodes Requirement standard [RFC8504]. 477 2.3. Link-Layer Security 479 IPv6 relies heavily on NDP [RFC4861] to perform a variety of link 480 operations such as discovering other nodes on the link, resolving 481 their link-layer addresses, and finding routers on the link. If not 482 secured, NDP is vulnerable to various attacks, such as router/ 483 neighbor message spoofing, redirect attacks, Duplicate Address 484 Detection (DAD) DoS attacks, etc. Many of these security threats to 485 NDP have been documented in IPv6 ND Trust Models and Threats 486 [RFC3756] and in [RFC6583]. 488 Most of the issues are only applicable when the attacker is on the 489 same link but NDP also has security issues when the attacker is off- 490 link, see the section below Section 2.3.1. 492 2.3.1. Neighbor Solicitation Rate-Limiting 494 NDP can be vulnerable to remote denial of service (DoS) attacks; for 495 example, when a router is forced to perform address resolution for a 496 large number of unassigned addresses, i.e., when a prefix is scanned 497 by an attacker in a fast manner. This can keep new devices from 498 joining the network or render the last-hop router ineffective due to 499 high CPU usage. Easy mitigative steps include rate-limiting Neighbor 500 Solicitations, restricting the amount of state reserved for 501 unresolved solicitations, and clever cache/timer management. 503 [RFC6583] discusses the potential for off-link DoS in detail and 504 suggests implementation improvements and operational mitigation 505 techniques that may be used to mitigate or alleviate the impact of 506 such attacks. Here are some feasible mitigation options that can be 507 employed by network operators today: 509 o Ingress filtering of unused addresses by ACL. These require 510 stable configuration of the addresses; for example, allocating the 511 addresses out of a /120 and using a specific ACL to only allow 512 traffic to this /120 (of course, the actual hosts are configured 513 with a /64 prefix for the link). 515 o Tuning of NDP process (where supported), e.g., enforcing limits on 516 data structures such as the number of neighbor cache entries in 517 'incomplete' state (e.g., 256 incomplete entries per interface) or 518 the rate of NA per interface (e.g., 100 NA per second). 520 o Using a /127 on a point-to-point link, per [RFC6164]. 522 o Using only link-local addresses on links where there are only 523 routers, see [RFC7404] 525 2.3.2. Router and Neighbor Advertisements Filtering 527 2.3.2.1. Router Advertisement Filtering 529 Router Advertisement spoofing is a well-known on-link attack vector 530 and has been extensively documented. The presence of rogue RAs, 531 either unintentional or malicious, can cause partial or complete 532 failure of operation of hosts on an IPv6 link. For example, a node 533 can select an incorrect router address which can then be used for an 534 on-path attack or the node can assume wrong prefixes to be used for 535 SLAAC. [RFC6104] summarizes the scenarios in which rogue RAs may be 536 observed and presents a list of possible solutions to the problem. 537 [RFC6105] (RA-Guard) describes a solution framework for the rogue RA 538 problem where network segments are designed around switching devices 539 that are capable of identifying invalid RAs and blocking them before 540 the attack packets actually reach the target nodes. 542 However, several evasion techniques that circumvent the protection 543 provided by RA-Guard have surfaced. A key challenge to this 544 mitigation technique is introduced by IPv6 fragmentation. Attackers 545 can conceal their attack by fragmenting their packets into multiple 546 fragments such that the switching device that is responsible for 547 blocking invalid RAs cannot find all the necessary information to 548 perform packet filtering of the same packet. [RFC7113] describes 549 such evasion techniques and provides advice to RA-Guard implementers 550 such that the aforementioned evasion vectors can be eliminated. 552 Given that the IPv6 Fragmentation Header can be leveraged to 553 circumvent some implementations of RA-Guard, [RFC6980] updates 554 [RFC4861] such that use of the IPv6 Fragmentation Header is forbidden 555 in all Neighbor Discovery messages except "Certification Path 556 Advertisement", thus allowing for simple and effective measures to 557 counter fragmented NDP attacks. 559 2.3.2.2. Neighbor Advertisement Filtering 561 The Source Address Validation Improvements (SAVI) working group has 562 worked on other ways to mitigate the effects of such attacks. 563 [RFC7513] helps in creating bindings between a DHCPv4 [RFC2131] 564 /DHCPv6 [RFC8415] assigned source IP address and a binding anchor 565 [RFC7039] on a SAVI device. Also, [RFC6620] describes how to glean 566 similar bindings when DHCP is not used. The bindings can be used to 567 filter packets generated on the local link with forged source IP 568 addresses. 570 2.3.2.3. Host Isolation 572 Isolating hosts for the NDP traffic can be done by using a /64 per 573 host, refer to Section 2.1.8, as NDP is only relevant within a /64 574 on-link prefix; 3GPP Section 2.3.4 uses a similar mechanism. 576 A more drastic technique to prevent all NDP attacks is based on 577 isolation of all hosts with specific configurations. In such a 578 scenario, hosts (i.e., all nodes that are not routers) are unable to 579 send data-link layer frames to other hosts, therefore, no host-to- 580 host attacks can happen. This specific setup can be established on 581 some switches or Wi-Fi access points. This is not always feasible 582 when hosts need to communicate with other hosts in the same subnet, 583 e.g., for access to file shares. 585 2.3.2.4. NDP Recommendations 587 It is still recommended that RA-Guard and SAVI be employed as a first 588 line of defense against common attack vectors including misconfigured 589 hosts. This recommendation also applies when DHCPv6 is used, as RA 590 messages are used to discover the default router(s) and for on-link 591 prefix determination. This line of defense is most effective when 592 incomplete fragments are dropped by routers and switches as described 593 in Section 2.2.3. The generated log should also be analyzed to 594 identify and act on violations. 596 Network operators should be aware that RA-Guard and SAVI do not work 597 as expected or could even be harmful in specific network 598 configurations (notably when there could be multiple routers). 600 Enabling RA-Guard by default in managed networks (e.g., Wi-Fi 601 networks, enterprise campus networks, etc.) should be strongly 602 considered except for specific use cases such as the presence of 603 homenet devices emitting router advertisements. 605 2.3.3. Securing DHCP 607 The Dynamic Host Configuration Protocol for IPv6 (DHCPv6), as 608 described in [RFC8415], enables DHCP servers to pass configuration 609 parameters, such as IPv6 network addresses and other configuration 610 information, to IPv6 nodes. DHCP plays an important role in most 611 large networks by providing robust stateful configuration in the 612 context of automated system provisioning. 614 The two most common threats to DHCP clients come from malicious 615 (a.k.a., rogue) or unintentionally misconfigured DHCP servers. in 616 these scenarios, a malicious DHCP server is established with the 617 intent of providing incorrect configuration information to the 618 clients to cause a denial-of-service attack or to mount on-path 619 attack. While unintentional, a misconfigured DHCP server can have 620 the same impact. Additional threats against DHCP are discussed in 621 the security considerations section of [RFC8415]. 623 DHCPv6-Shield, [RFC7610], specifies a mechanism for protecting 624 connected DHCPv6 clients against rogue DHCPv6 servers. This 625 mechanism is based on DHCPv6 packet-filtering at the layer-2 device, 626 i.e., the administrator specifies the interfaces connected to DHCPv6 627 servers. However, extension headers could be leveraged to bypass 628 DHCPv6-Shield unless [RFC7112] is enforced. 630 It is recommended to use DHCPv6-Shield and to analyze the 631 corresponding log messages. 633 2.3.4. 3GPP Link-Layer Security 635 The 3GPP link is a point-to-point like link that has no link-layer 636 address. This implies there can only be one end host (the mobile 637 hand-set) and the first-hop router (i.e., a GPRS Gateway Support Node 638 (GGSN) or a Packet Gateway (PGW)) on that link. The GGSN/PGW never 639 configures a non link-local address on the link using the advertised 640 /64 prefix on it; see Section 2.1.8. The advertised prefix must not 641 be used for on-link determination. There is no need for address 642 resolution on the 3GPP link, since there are no link-layer addresses. 643 Furthermore, the GGSN/PGW assigns a prefix that is unique within each 644 3GPP link that uses IPv6 stateless address autoconfiguration. This 645 avoids the necessity to perform DAD at the network level for every 646 address generated by the mobile host. The GGSN/PGW always provides 647 an IID to the cellular host for the purpose of configuring the link- 648 local address and ensures the uniqueness of the IID on the link 649 (i.e., no collisions between its own link-local address and the 650 mobile host's address). 652 The 3GPP link model itself mitigates most of the known NDP-related 653 Denial-of-Service attacks. In practice, the GGSN/PGW only needs to 654 route all traffic to the mobile host that falls under the prefix 655 assigned to it. As there is also a single host on the 3GPP link, 656 there is no need to defend that IPv6 address. 658 See Section 5 of [RFC6459] for a more detailed discussion on the 3GPP 659 link model, NDP, and the address configuration details. In some 660 mobile networks, DHCPv6 and DHCP-PD are also used. 662 2.3.5. Impact of Multicast Traffic 664 IPv6 uses multicast extensively for signaling messages on the local 665 link to avoid broadcast messages for on-the-wire efficiency. 667 The use of multicast has some side effects on wireless networks, such 668 as a negative impact on battery life of smartphones and other 669 battery-operated devices that are connected to such networks. 670 [RFC7772] and [RFC6775] (for specific wireless networks) discuss 671 methods to rate-limit RAs and other ND messages on wireless networks 672 in order to address this issue. 674 The use of link-layer multicast addresses (e.g., ff02::1 for the all 675 nodes link-local multicast address) could also be misused for an 676 amplification attack. Imagine, a hostile node sending an ICMPv6 677 ECHO_REQUEST to ff02::1 with a spoofed source address, then, all 678 link-local nodes will reply with ICMPv6 ECHO_REPLY packets to the 679 source address. This could be a DoS attack for the address owner. 680 This attack is purely local to the layer-2 network as packets with a 681 link-local destination are never forwarded by an IPv6 router. 683 This is the reason why large Wi-Fi network deployments often limit 684 the use of link-layer multicast either from or to the uplink of the 685 Wi-Fi access point, i.e., Wi-Fi stations are prevented to send link- 686 local multicast to their direct neighboring Wi-Fi stations; this 687 policy also blocks service discovery via mDNS ([RFC6762]) and LLMNR 688 ([RFC4795]). 690 2.3.6. SeND and CGA 692 SEcure Neighbor Discovery (SeND), as described in [RFC3971], is a 693 mechanism that was designed to secure ND messages. This approach 694 involves the use of new NDP options to carry public key-based 695 signatures. Cryptographically Generated Addresses (CGA), as 696 described in [RFC3972], are used to ensure that the sender of a 697 Neighbor Discovery message is the actual "owner" of the claimed IPv6 698 address. A new NDP option, the CGA option, was introduced and is 699 used to carry the public key and associated parameters. Another NDP 700 option, the RSA Signature option, is used to protect all messages 701 relating to neighbor and Router discovery. 703 SeND protects against: 705 o Neighbor Solicitation/Advertisement Spoofing 707 o Neighbor Unreachability Detection Failure 709 o Duplicate Address Detection DoS Attack 710 o Router Solicitation and Advertisement Attacks 712 o Replay Attacks 714 o Neighbor Discovery DoS Attacks 716 SeND does NOT: 718 o Protect statically configured addresses 720 o Protect addresses configured using fixed identifiers (i.e., EUI- 721 64) 723 o Provide confidentiality for NDP communications 725 o Compensate for an unsecured link - SeND does not require that the 726 addresses on the link and Neighbor Advertisements correspond. 728 However, at this time and over a decade since their original 729 specifications, CGA and SeND do not have support from widely deployed 730 IPv6 devices; hence, their usefulness is limited and should not be 731 relied upon. 733 2.4. Control Plane Security 735 [RFC6192] defines the router control plane and provides detailed 736 guidance to secure it for IPv4 and IPv6 networks. This definition is 737 repeated here for the reader's convenience. Please note that the 738 definition is completely protocol-version agnostic (most of this 739 section applies to IPv6 in the same way as to IPv4). 741 Preamble: IPv6 control plane security is vastly congruent with its 742 IPv4 equivalent with the exception of OSPFv3 authentication 743 (Section 2.4.1) and some packet exceptions (see Section 2.4.3) that 744 are specific to IPv6. 746 Modern router architecture design maintains a strict separation of 747 forwarding and router control plane hardware and software. The 748 router control plane supports routing and management functions. It 749 is generally described as the router architecture hardware and 750 software components for handling packets destined to the device 751 itself, as well as, building and sending packets originated locally 752 on the device. The forwarding plane is typically described as the 753 router architecture hardware and software components responsible for 754 receiving a packet on an incoming interface, performing a lookup to 755 identify the packet's IP next hop and best outgoing interface towards 756 the destination, and forwarding the packet through the appropriate 757 outgoing interface. 759 While the forwarding plane is usually implemented in high-speed 760 hardware, the control plane is implemented by a generic processor 761 (referred to as the route processor (RP)) and cannot process packets 762 at a high rate. Hence, this processor can be attacked by flooding 763 its input queue with more packets than it can process. The control 764 plane processor is then unable to process valid control packets and 765 the router can lose IGP or BGP adjacencies which can cause a severe 766 network disruption. 768 [RFC6192] provides detailed guidance to protect the router control 769 plane in IPv6 networks. The rest of this section contains simplified 770 guidance. 772 The mitigation techniques are: 774 o To drop non-legit or potentially harmful control packets before 775 they are queued to the RP (this can be done by a forwarding plane 776 ACL) and 778 o To rate-limit the remaining packets to a rate that the RP can 779 sustain. Protocol-specific protection should also be done (for 780 example, a spoofed OSPFv3 packet could trigger the execution of 781 the Dijkstra algorithm, therefore, the frequency of Dijsktra 782 calculations should be also rate-limited). 784 This section will consider several classes of control packets: 786 o Control protocols: routing protocols: such as OSPFv3, BGP, RIPng, 787 and by extension NDP and ICMP 789 o Management protocols: SSH, SNMP, NETCONF, RESTCONF, IPFIX, etc. 791 o Packet exceptions: normal data packets that require a specific 792 processing such as generating a packet-too-big ICMP message or 793 processing the hop-by-hop options header. 795 2.4.1. Control Protocols 797 This class includes OSPFv3, BGP, NDP, ICMP. 799 An ingress ACL to be applied on all the router interfaces for packets 800 to be processed by the RP should be configured to: 802 o drop OSPFv3 (identified by Next-Header being 89) and RIPng 803 (identified by UDP port 521) packets from a non link-local address 804 (except for OSPFv3 virtual links) 806 o allow BGP (identified by TCP port 179) packets from all BGP 807 neighbors and drop the others 809 o allow all ICMP packets (transit and to the router interfaces) 811 Note: dropping OSPFv3 packets which are authenticated by IPsec could 812 be impossible on some routers that are unable to parse the IPsec ESP 813 or AH extension headers during ACL classification. 815 Rate-limiting of the valid packets should be done, see also [RFC8541] 816 for a side benefit for OSPv3. The exact configuration will depend on 817 the available resources of the router (CPU, TCAM, ...). 819 2.4.2. Management Protocols 821 This class includes: SSH, SNMP, RESTCONF, NETCONF, gRPC, syslog, NTP, 822 etc. 824 An ingress ACL to be applied on all the router interfaces (or at 825 ingress interfaces of the security perimeter or by using specific 826 features of the platform) should be configured for packets destined 827 to the RP such as: 829 o Drop packets destined to the routers except those belonging to 830 protocols which are used (for example, permit TCP 22 and drop all 831 others when only SSH is used); 833 o Drop packets where the source does not match the security policy, 834 for example, if SSH connections should only be originated from the 835 Network Operation Center (NOC), then the ACL should permit TCP 836 port 22 packets only from the NOC prefix. 838 Rate-limiting of valid packets should be done. The exact 839 configuration will depend on the available router resources. 841 2.4.3. Packet Exceptions 843 This class covers multiple cases where a data plane packet is punted 844 to the route processor because it requires specific processing: 846 o generation of an ICMP packet-too-big message when a data plane 847 packet cannot be forwarded because it is too large (required to 848 discover the Path MTU); 850 o generation of an ICMP hop-limit-expired message when a data plane 851 packet cannot be forwarded because its hop-limit field has reached 852 0 (also used by the traceroute utility); 854 o generation of an ICMP destination-unreachable message when a data 855 plane packet cannot be forwarded for any reason; 857 o processing of the hop-by-hop options header, new implementations 858 follow section 4.3 of [RFC8200] where this processing is optional; 860 o or more specific to some router implementation: an oversized 861 extension header chain which cannot be processed by the hardware 862 and force the packet to be punted to the RP. 864 On some routers, not everything can be done by the specialized data 865 plane hardware which requires some packets to be 'punted' to the 866 generic RP. This could include for example the processing of a long 867 extension header chain in order to apply an ACL based on layer-4 868 information. [RFC6980] and more generally [RFC7112] highlight the 869 security implications of oversized extension header chains on routers 870 and updates the original IPv6 specifications, [RFC2460], such that 871 the first fragment of a packet is required to contain the entire IPv6 872 header chain. Those changes are incorporated in the IPv6 standard 873 [RFC8200] 875 An ingress ACL cannot mitigate a control plane attack using these 876 packet exceptions. The only protection for the RP is to rate-limit 877 those packet exceptions that are forwarded to the RP, this means that 878 some data plane packets will be dropped without an ICMP message sent 879 to the source which may delay Path MTU discovery and cause drops. 881 In addition to limiting the rate of data plane packets queued to the 882 RP, it is also important to rate-limit the generation of ICMP 883 messages. This is important both to preserve RP resources and also 884 to prevent an amplification attack using the router as a reflector. 885 It is worth noting that some platforms implement this rate-limiting 886 in hardware. Of course, a consequence of not generating an ICMP 887 message will break some IPv6 mechanisms such as Path MTU discovery or 888 a simple traceroute. 890 2.5. Routing Security 892 Preamble: IPv6 routing security is congruent with IPv4 routing 893 security with the exception of OSPv3 neighbor authentication (see 894 Section 2.5.2). 896 Routing security in general can be broadly divided into three 897 sections: 899 1. Authenticating neighbors/peers 901 2. Securing routing updates between peers 902 3. Route filtering 904 [RFC5082] is also applicable to IPv6 and can ensure that routing 905 protocol packets are coming from the local network; it must also be 906 noted that in IPv6 all interior gateway protocols use link-local 907 addresses. 909 As for IPv4, it is recommended to enable a routing protocol only on 910 interfaces where it is required. 912 2.5.1. BGP Security 914 As BGP is identical for IPv4 and IPv6 and as [RFC7454] covers all the 915 security aspects for BGP in detail, [RFC7454] is also applicable to 916 IPv6. 918 2.5.2. Authenticating OSPFv3 Neighbors 920 OSPFv3 can rely on IPsec to fulfill the authentication function. 921 Operators should note that IPsec support is not standard on all 922 routing platforms. In some cases, this requires specialized hardware 923 that offloads crypto over to dedicated ASICs or enhanced software 924 images (both of which often come with added financial cost) to 925 provide such functionality. An added detail is to determine whether 926 OSPFv3 IPsec implementations use AH or ESP-Null for integrity 927 protection. In early implementations, all OSPFv3 IPsec 928 configurations relied on AH since the details weren't specified in 929 [RFC5340]. However, the document which specifically describes how 930 IPsec should be implemented for OSPFv3 [RFC4552] specifically states 931 that "ESP-Null MUST and AH MAY be implemented" since it follows the 932 overall IPsec standards wording. OSPFv3 can also use normal ESP to 933 encrypt the OSPFv3 payload to provide confidentiality for the routing 934 information. 936 [RFC7166] changes OSPFv3 reliance on IPsec by appending an 937 authentication trailer to the end of the OSPFv3 packets; it does not 938 specifically authenticate the specific originator of an OSPFv3 939 packet; rather, it allows a router to confirm that the packet has 940 been issued by a router that had access to the shared authentication 941 key. 943 With all authentication mechanisms, operators should confirm that 944 implementations can support re-keying mechanisms that do not cause 945 outages. There have been instances where any re-keying causes 946 outages and therefore, the tradeoff between utilizing this 947 functionality needs to be weighed against the protection it provides. 948 [RFC4107] documents some guidelines for crypto keys management. 950 2.5.3. Securing Routing Updates 952 IPv6 initially mandated the provisioning of IPsec capability in all 953 nodes. However, in the updated IPv6 Nodes Requirement standard 954 [RFC8504], IPsec is a 'SHOULD' and not a 'MUST' implement. 955 Theoretically, it is possible that all communication between two IPv6 956 nodes, especially routers exchanging routing information, is 957 encrypted using IPsec. In practice however, deploying IPsec is not 958 always feasible given hardware and software limitations of the 959 various platforms deployed. 961 Many routing protocols support the use of cryptography to protect the 962 routing updates, the use of this protection is recommended; [RFC8177] 963 is a YANG data model for key chains that includes re-keying 964 functionality. 966 2.5.4. Route Filtering 968 Route filtering policies will be different depending on whether they 969 pertain to edge route filtering vs. internal route filtering. At a 970 minimum, IPv6 routing policy as it pertains to routing between 971 different administrative domains should aim to maintain parity with 972 IPv4 from a policy perspective, e.g., 974 o Filter internal-use, non-globally routable IPv6 addresses at the 975 perimeter; 977 o Discard routes for bogon [CYMRU] and reserved space (see 978 [RFC8190]); 980 o Configure ingress route filters that validate route origin, prefix 981 ownership, etc. through the use of various routing databases, 982 e.g., [RADB]. [RFC8210] formally validates the origin ASs of BGP 983 announcements. 985 Some good guidance can be found at [RFC7454]. 987 A valid routing table can also be used to apply network ingress 988 filtering (see [RFC2827]). 990 2.6. Logging/Monitoring 992 In order to perform forensic research in the cases of a security 993 incident or detecting abnormal behavior, network operators should log 994 multiple pieces of information. In some cases, this requires a 995 frequent poll of devices via a Network Management Station. 997 This logging should include, but not limited to: 999 o logs of all applications using the network (including user space 1000 and kernel space) when available (for example web servers that the 1001 network operator manages); 1003 o data from IP Flow Information Export [RFC7011] also known as 1004 IPFIX; 1006 o data from various SNMP MIBs [RFC4293] or YANG data via RESTCONF 1007 [RFC8040] or NETCONF [RFC6241]; 1009 o historical data of Neighbor Cache entries; 1011 o stateful DHCPv6 [RFC8415] lease cache, especially when a relay 1012 agent [RFC6221] is used; 1014 o Source Address Validation Improvement (SAVI) [RFC7039] events, 1015 especially the binding of an IPv6 address to a MAC address and a 1016 specific switch or router interface; 1018 o firewall ACL log; 1020 o authentication server log; 1022 o RADIUS [RFC2866] accounting records. 1024 Please note that there are privacy issues or regulations related to 1025 how these logs are collected, stored, used, and safely discarded. 1026 Operators are urged to check their country legislation (e.g., General 1027 Data Protection Regulation GDPR [GDPR] in the European Union). 1029 All those pieces of information can be used for: 1031 o forensic (Section 2.6.2.1) investigations such as who did what and 1032 when? 1034 o correlation (Section 2.6.2.3): which IP addresses were used by a 1035 specific node (assuming the use of privacy extensions addresses 1036 [RFC8981]) 1038 o inventory (Section 2.6.2.2): which IPv6 nodes are on my network? 1040 o abnormal behavior detection (Section 2.6.2.4): unusual traffic 1041 patterns are often the symptoms of an abnormal behavior which is 1042 in turn a potential attack (denial-of-service, network scan, a 1043 node being part of a botnet, etc.) 1045 2.6.1. Data Sources 1047 This section lists the most important sources of data that are useful 1048 for operational security. 1050 2.6.1.1. Application Logs 1052 Those logs are usually text files where the remote IPv6 address is 1053 stored in clear text (not binary). This can complicate the 1054 processing since one IPv6 address, for example 2001:db8::1 can be 1055 written in multiple ways, such as: 1057 o 2001:DB8::1 (in uppercase) 1059 o 2001:0db8::0001 (with leading 0) 1061 o and many other ways including the reverse DNS mapping into a FQDN 1062 (which should not be trusted). 1064 [RFC5952] explains this problem in detail and recommends the use of a 1065 single canonical format. This document recommends the use of 1066 canonical format [RFC5952] for IPv6 addresses in all possible cases. 1067 If the existing application cannot log using the canonical format, 1068 then it is recommended to use an external post-processing program in 1069 order to canonicalize all IPv6 addresses. 1071 2.6.1.2. IP Flow Information Export by IPv6 Routers 1073 IPFIX [RFC7012] defines some data elements that are useful for 1074 security: 1076 o nextHeaderIPv6, sourceIPv6Address, and destinationIPv6Address; 1078 o sourceMacAddress and destinationMacAddress. 1080 The IP version is the ipVersion element defined in [IANA-IPFIX]. 1082 Moreover, IPFIX is very efficient in terms of data handling and 1083 transport. It can also aggregate flows by a key such as 1084 sourceMacAddress in order to have aggregated data associated with a 1085 specific sourceMacAddress. This memo recommends the use of IPFIX and 1086 aggregation on nextHeaderIPv6, sourceIPv6Address, and 1087 sourceMacAddress. 1089 2.6.1.3. SNMP MIB and NETCONF/RESTCONF YANG Modules data by IPv6 1090 Routers 1092 RFC 4293 [RFC4293] defines a Management Information Base (MIB) for 1093 the two address families of IP. This memo recommends the use of: 1095 o ipIfStatsTable table which collects traffic counters per 1096 interface; 1098 o ipNetToPhysicalTable table which is the content of the Neighbor 1099 cache, i.e., the mapping between IPv6 and data-link layer 1100 addresses. 1102 There are also YANG modules relating to the two IP addresses families 1103 and can be used with [RFC6241] and [RFC8040]. This memo recommends 1104 the use of: 1106 o interfaces-state/interface/statistics from ietf- 1107 interfaces@2018-02-20.yang [RFC8343] which contains counters for 1108 interfaces. 1110 o ipv6/neighbor from ietf-ip@2018-02-22.yang [RFC8344] which is the 1111 content of the Neighbor cache, i.e., the mapping between IPv6 and 1112 data-link layer addresses. 1114 2.6.1.4. Neighbor Cache of IPv6 Routers 1116 The neighbor cache of routers contains all mappings between IPv6 1117 addresses and data-link layer addresses. There are multiple ways to 1118 collect the current entries in the Neighbor Cache, notably but not 1119 limited to: 1121 o the SNMP MIB (Section 2.6.1.3) as explained above; 1123 o using streaming telemetry or NETCONF [RFC6241] and RESTCONF 1124 [RFC8040] to collect the operational state of the neighbor cache; 1126 o also, by connecting over a secure management channel (such as SSH) 1127 and explicitly requesting a neighbor cache dump via the Command 1128 Line Interface (CLI) or another monitoring mechanism. 1130 The neighbor cache is highly dynamic as mappings are added when a new 1131 IPv6 address appears on the network. This could be quite frequently 1132 with privacy extension addresses [RFC8981] or when they are removed 1133 when the state goes from UNREACH to removed (the default time for a 1134 removal per Neighbor Unreachability Detection [RFC4861] algorithm is 1135 38 seconds for a host using Windows 7). This means that the content 1136 of the neighbor cache must periodically be fetched at an interval 1137 which does not exhaust the router resources and still provides 1138 valuable information (suggested value is 30 seconds but this should 1139 be verified in the actual deployment) and stored for later use. 1141 This is an important source of information because it is trivial (on 1142 a switch not using the SAVI [RFC7039] algorithm) to defeat the 1143 mapping between data-link layer address and IPv6 address. Let us 1144 rephrase the previous statement: having access to the current and 1145 past content of the neighbor cache has a paramount value for the 1146 forensic and audit trail. It should also be noted that in certain 1147 threat models this information is also deemed valuable and could 1148 itself be a target. 1150 When using one /64 per host (Section 2.1.8) or DHCP-PD, it is 1151 sufficient to keep the history of the allocated prefixes when 1152 combined with strict source address prefix enforcement on the routers 1153 and layer-2 switches to prevent IPv6 spoofing. 1155 2.6.1.5. Stateful DHCPv6 Lease 1157 In some networks, IPv6 addresses/prefixes are managed by a stateful 1158 DHCPv6 server [RFC8415] that leases IPv6 addresses/prefixes to 1159 clients. It is indeed quite similar to DHCP for IPv4, so it can be 1160 tempting to use this DHCP lease file to discover the mapping between 1161 IPv6 addresses/prefixes and data-link layer addresses as is commonly 1162 used in IPv4 networking. 1164 It is not so easy in the IPv6 networks, because not all nodes will 1165 use DHCPv6 (there are nodes which can only do stateless 1166 autoconfiguration) but also because DHCPv6 clients are identified not 1167 by their hardware-client address as in IPv4 but by a DHCP Unique ID 1168 (DUID), which can have several formats: some being the data-link 1169 layer address, some being data-link layer address prepended with time 1170 information, or even an opaque number that requires correlation with 1171 another data source to be usable for operational security. Moreover, 1172 when the DUID is based on the data-link address, this address can be 1173 of any client interface (such as the wireless interface while the 1174 client actually uses its wired interface to connect to the network). 1176 If a lightweight DHCP relay agent [RFC6221] is used in a layer-2 1177 switch, then the DHCP servers also receive the Interface-ID 1178 information which could be saved in order to identify the interface 1179 on which the switch received a specific leased IPv6 address. Also, 1180 if a 'normal' (not lightweight) relay agent adds the data-link layer 1181 address in the option for Relay Agent Remote-ID [RFC4649] or 1182 [RFC6939], then the DHCPv6 server can keep track of the data-link and 1183 leased IPv6 addresses. 1185 In short, the DHCPv6 lease file is less interesting than for IPv4 1186 networks. If possible, it is recommended to use DHCPv6 servers that 1187 keep the relayed data-link layer address in addition to the DUID in 1188 the lease file as those servers have the equivalent information to 1189 IPv4 DHCP servers. 1191 The mapping between data-link layer address and the IPv6 address can 1192 be secured by deploying switches implementing the SAVI [RFC7513] 1193 mechanisms. Of course, this also requires that the data-link layer 1194 address is protected by using a layer-2 mechanism such as 1195 [IEEE-802.1X]. 1197 2.6.1.6. RADIUS Accounting Log 1199 For interfaces where the user is authenticated via a RADIUS [RFC2866] 1200 server, and if RADIUS accounting is enabled, then the RADIUS server 1201 receives accounting Acct-Status-Type records at the start and at the 1202 end of the connection which include all IPv6 (and IPv4) addresses 1203 used by the user. This technique can be used notably for Wi-Fi 1204 networks with Wi-Fi Protected Address (WPA) or other IEEE 802.1X 1205 [IEEE-802.1X] wired interface on an Ethernet switch. 1207 2.6.1.7. Other Data Sources 1209 There are other data sources for log information that must be 1210 collected (as currently collected in IPv4 networks): 1212 o historical mapping of IPv6 addresses to users of remote access 1213 VPN; 1215 o historical mappings of MAC addresses to switch ports in a wired 1216 network. 1218 2.6.2. Use of Collected Data 1220 This section leverages the data collected as described before 1221 (Section 2.6.1) in order to achieve several security benefits. 1222 Section 9.1 of [RFC7934] contains more details about host tracking. 1224 2.6.2.1. Forensic and User Accountability 1226 The forensic use case is when the network operator must locate an 1227 IPv6 address (and the assocated port, access point/switch, or VPN 1228 tunnel) that was present in the network at a certain time or is 1229 currently in the network. 1231 To locate an IPv6 address in an enterprise network where the operator 1232 has control over all resources, the source of information can be the 1233 neighbor cache, or, if not found, the DHCP lease file. Then, the 1234 procedure is: 1236 1. Based on the IPv6 prefix of the IPv6 address, find the router(s) 1237 which is(are) used to reach this prefix (assuming that anti- 1238 spoofing mechanisms are used) perhaps based on an IPAM. 1240 2. Based on this limited set of routers, on the incident time and on 1241 the IPv6 address, retrieve the data-link address from the live 1242 neighbor cache, from the historical neighbor cache data, or from 1243 SAVI events, or retrieve the data-link address from the DHCP 1244 lease file (Section 2.6.1.5). 1246 3. Based on the data-link layer address, look-up the switch 1247 interface associated with the data-link layer address. In the 1248 case of wireless LAN with RADIUS accounting (see 1249 Section 2.6.1.6), the RADIUS log has the mapping between the user 1250 identification and the MAC address. If a Configuration 1251 Management Data Base (CMDB) is used, then it can be used to map 1252 the data-link layer address to a switch port. 1254 At the end of the process, the interface of the host originating, or 1255 the subscriber identity associated with, the activity in question has 1256 been determined. 1258 To identify the subscriber of an IPv6 address in a residential 1259 Internet Service Provider, the starting point is the DHCP-PD leased 1260 prefix covering the IPv6 address; this prefix can often be linked to 1261 a subscriber via the RADIUS log. Alternatively, the Forwarding 1262 Information Base (FIB) of the Cable Modem Termination System (CMTS) 1263 or Broadband Network Gateway (BNG) indicates the CPE of the 1264 subscriber and the RADIUS log can be used to retrieve the actual 1265 subscriber. 1267 More generally, a mix of the above techniques can be used in most, if 1268 not all, networks. 1270 2.6.2.2. Inventory 1272 RFC 7707 [RFC7707] describes the difficulties for an attacker to scan 1273 an IPv6 network due to the vast number of IPv6 addresses per link 1274 (and why in some cases it can still be done). While the huge 1275 addressing space can sometimes be perceived as a 'protection', it 1276 also makes the inventory task difficult in an IPv6 network while it 1277 was trivial to do in an IPv4 network (a simple enumeration of all 1278 IPv4 addresses, followed by a ping and a TCP/UDP port scan). Getting 1279 an inventory of all connected devices is of prime importance for a 1280 secure network operation. 1282 There are many ways to do an inventory of an IPv6 network. 1284 The first technique is to use passive inspection such as IPFIX. 1285 Using exported IPFIX information and extracting the list of all IPv6 1286 source addresses allows finding all IPv6 nodes that sent packets 1287 through a router. This is very efficient but, alas, will not 1288 discover silent nodes that never transmitted packets traversing the 1289 IPFIX target router. Also, it must be noted that link-local 1290 addresses will never be discovered by this means. 1292 The second way is again to use the collected neighbor cache content 1293 to find all IPv6 addresses in the cache. This process will also 1294 discover all link-local addresses. See Section 2.6.1.4. 1296 Another way that works only for a local network, consists of sending 1297 a ICMP ECHO_REQUEST to the link-local multicast address ff02::1 which 1298 addresses all IPv6 nodes on the network. All nodes should reply to 1299 this ECHO_REQUEST per [RFC4443]. 1301 Other techniques involve obtaining data from DNS, parsing log files, 1302 leveraging service discovery such as mDNS [RFC6762] and [RFC6763]. 1304 Enumerating DNS zones, especially looking at reverse DNS records and 1305 CNAMES, is another common method employed by various tools. As 1306 already mentioned in [RFC7707], this allows an attacker to prune the 1307 IPv6 reverse DNS tree, and hence enumerate it in a feasible time. 1308 Furthermore, authoritative servers that allow zone transfers (AXFR) 1309 may be a further information source. An interesting research paper 1310 has analysed the entropy in various IPv6 addresses: see [ENTROPYIP]. 1312 2.6.2.3. Correlation 1314 In an IPv4 network, it is easy to correlate multiple logs, for 1315 example to find events related to a specific IPv4 address. A simple 1316 Unix grep command is enough to scan through multiple text-based files 1317 and extract all lines relevant to a specific IPv4 address. 1319 In an IPv6 network, this is slightly more difficult because different 1320 character strings can express the same IPv6 address. Therefore, the 1321 simple Unix grep command cannot be used. Moreover, an IPv6 node can 1322 have multiple IPv6 addresses. 1324 In order to do correlation in IPv6-related logs, it is advised to 1325 have all logs in a format with only canonical IPv6 addresses 1326 [RFC5952]. Then, the neighbor cache current (or historical) data set 1327 must be searched to find the data-link layer address of the IPv6 1328 address. Then, the current and historical neighbor cache data sets 1329 must be searched for all IPv6 addresses associated with this data- 1330 link layer address to derive the search set. The last step is to 1331 search in all log files (containing only IPv6 addresses in canonical 1332 format) for any IPv6 addresses in the search set. 1334 Moreover, [RFC7934] recommends using multiple IPv6 addresses per 1335 prefix, so, the correlation must also be done among those multiple 1336 IPv6 addresses, for example by discovering in the NDP cache 1337 (Section 2.6.1.4) all IPv6 addresses associated with the same MAC 1338 address and interface. 1340 2.6.2.4. Abnormal Behavior Detection 1342 Abnormal behavior (such as network scanning, spamming, denial-of- 1343 service) can be detected in the same way as in an IPv4 network. 1345 o Sudden increase of traffic detected by interface counter (SNMP) or 1346 by aggregated traffic from IPFIX records [RFC7012]. 1348 o Rapid growth of ND cache size. 1350 o Change in traffic pattern (number of connections per second, 1351 number of connections per host...) observed with the use of IPFIX 1352 [RFC7012]. 1354 2.6.3. Summary 1356 While some data sources (IPFIX, MIB, switch CAM tables, logs, ...) 1357 used in IPv4 are also used in the secure operation of an IPv6 1358 network, the DHCPv6 lease file is less reliable and the neighbor 1359 cache is of prime importance. 1361 The fact that there are multiple ways to express the same IPv6 1362 address in a character string renders the use of filters mandatory 1363 when correlation must be done. 1365 2.7. Transition/Coexistence Technologies 1367 As it is expected that some networks will not run in a pure IPv6-only 1368 mode, the different transition mechanisms must be deployed and 1369 operated in a secure way. This section proposes operational 1370 guidelines for the most known and deployed transition techniques. 1371 [RFC4942] also contains security considerations for transition or 1372 coexistence scenarios. 1374 2.7.1. Dual Stack 1376 Dual stack is often the first deployment choice for network 1377 operators. Dual stacking the network offers some advantages over 1378 other transition mechanisms. Firstly, the impact on existing IPv4 1379 operations is reduced. Secondly, in the absence of tunnels or 1380 address translation, the IPv4 and IPv6 traffic are native (easier to 1381 observe and secure) and should have the same network processing 1382 (network path, quality of service, ...). Dual stack enables a 1383 gradual termination of the IPv4 operations when the IPv6 network is 1384 ready for prime time. On the other hand, the operators have to 1385 manage two network stacks with the added complexities. 1387 From an operational security perspective, this now means that the 1388 network operator has twice the exposure. One needs to think about 1389 protecting both protocols now. At a minimum, the IPv6 portion of a 1390 dual-stacked network should be consistent with IPv4 from a security 1391 policy point of view. Typically, the following methods are employed 1392 to protect IPv4 networks at the edge or security perimeter: 1394 o ACLs to permit or deny traffic; 1396 o Firewalls with stateful packet inspection; 1398 o Application firewalls inspecting the application flows. 1400 It is recommended that these ACLs and/or firewalls be additionally 1401 configured to protect IPv6 communications. The enforced IPv6 1402 security must be congruent with the IPv4 security policy, otherwise 1403 the attacker will use the protocol version having the more relaxed 1404 security policy. Maintaining the congruence between security 1405 policies can be challenging (especially over time); it is recommended 1406 to use a firewall or an ACL manager that is dual-stack, i.e., a 1407 system that can apply a single ACL entry to a mixed group of IPv4 and 1408 IPv6 addresses. 1410 Application firewalls work at the application layer and are oblivious 1411 to the IP version, i.e., they work as well for IPv6 as for IPv4 and 1412 the same application security policy will work for both protocol 1413 versions. 1415 Also, given the end-to-end connectivity that IPv6 provides, it is 1416 recommended that hosts be fortified against threats. General device 1417 hardening guidelines are provided in Section 2.8. 1419 For many years, all host operating systems have IPv6 enabled by 1420 default, so, it is possible even in an 'IPv4-only' network to attack 1421 layer-2 adjacent victims via their IPv6 link-local address or via a 1422 global IPv6 address when the attacker provides rogue RAs or a rogue 1423 DHCPv6 service. 1425 [RFC7123] discusses the security implications of native IPv6 support 1426 and IPv6 transition/coexistence technologies on "IPv4-only" networks 1427 and describes possible mitigations for the aforementioned issues. 1429 2.7.2. Encapsulation Mechanisms 1431 There are many tunnels used for specific use cases. Except when 1432 protected by IPsec [RFC4301] or alternative tunnel encryption 1433 methods, all those tunnels have a number of security issues as 1434 described in RFC 6169 [RFC6169]; 1436 o tunnel injection: a malevolent actor knowing a few pieces of 1437 information (for example the tunnel endpoints and the 1438 encapsulation protocol) can forge a packet which looks like a 1439 legitimate and valid encapsulated packet that will gladly be 1440 accepted by the destination tunnel endpoint. This is a specific 1441 case of spoofing; 1443 o traffic interception: no confidentiality is provided by the tunnel 1444 protocols (without the use of IPsec or alternative encryption 1445 methods), therefore anybody on the tunnel path can intercept the 1446 traffic and have access to the clear-text IPv6 packet; combined 1447 with the absence of authentication, an on-path attack can also be 1448 mounted; 1450 o service theft: as there is no authorization, even a non-authorized 1451 user can use a tunnel relay for free (this is a specific case of 1452 tunnel injection); 1454 o reflection attack: another specific use case of tunnel injection 1455 where the attacker injects packets with an IPv4 destination 1456 address not matching the IPv6 address causing the first tunnel 1457 endpoint to re-encapsulate the packet to the destination... Hence, 1458 the final IPv4 destination will not see the original IPv4 address 1459 but only the IPv4 address of the relay router. 1461 o bypassing security policy: if a firewall or an Intrusion 1462 Prevention System (IPS) is on the path of the tunnel, then it may 1463 neither inspect nor detect malevolent IPv6 traffic transmitted 1464 over the tunnel. 1466 To mitigate the bypassing of security policies, it is often 1467 recommended to block all automatic tunnels in default OS 1468 configuration (if they are not required) by denying IPv4 packets 1469 matching: 1471 o IP protocol 41: this will block ISATAP (Section 2.7.2.2), 6to4 1472 (Section 2.7.2.7), 6rd (Section 2.7.2.3), as well as, 6in4 1473 (Section 2.7.2.1) tunnels; 1475 o IP protocol 47: this will block GRE (Section 2.7.2.1) tunnels; 1477 o UDP port 3544: this will block the default encapsulation of Teredo 1478 (Section 2.7.2.8) tunnels. 1480 Ingress filtering [RFC2827] should also be applied on all tunnel 1481 endpoints if applicable to prevent IPv6 address spoofing. 1483 The reflection attack cited above should also be prevented by using 1484 an IPv6 ACL preventing the hair pinning of the traffic. 1486 As several of the tunnel techniques share the same encapsulation 1487 (i.e., IPv4 protocol 41) and embed the IPv4 address in the IPv6 1488 address, there are a set of well-known looping attacks described in 1489 RFC 6324 [RFC6324]. This RFC also proposes mitigation techniques. 1491 2.7.2.1. Site-to-Site Static Tunnels 1493 Site-to-site static tunnels are described in RFC 2529 [RFC2529] and 1494 in GRE [RFC2784]. As the IPv4 endpoints are statically configured 1495 and are not dynamic, they are slightly more secure (bi-directional 1496 service theft is mostly impossible) but traffic interception and 1497 tunnel injection are still possible. Therefore, the use of IPsec 1498 [RFC4301] in transport mode to protect the encapsulated IPv4 packets 1499 is recommended for those tunnels. Alternatively, IPsec in tunnel 1500 mode can be used to transport IPv6 traffic over a non-trusted IPv4 1501 network. 1503 2.7.2.2. ISATAP 1505 ISATAP tunnels [RFC5214] are mainly used within a single 1506 administrative domain and to connect a single IPv6 host to the IPv6 1507 network. This often implies that those systems are usually managed 1508 by a single entity; therefore, audit trail and strict anti-spoofing 1509 are usually possible and this raises the overall security. Even if 1510 ISATAP is no more often used, its security issues are relevant per 1511 [KRISTOFF]. 1513 Special care must be taken to avoid a looping attack by implementing 1514 the measures of [RFC6324] and [RFC6964] (especially the section 3.6). 1516 IPsec [RFC4301] in transport or tunnel mode can be used to secure the 1517 IPv4 ISATAP traffic to provide IPv6 traffic confidentiality and 1518 prevent service theft. 1520 2.7.2.3. 6rd 1522 While 6rd tunnels share the same encapsulation as 6to4 tunnels 1523 (Section 2.7.2.7), they are designed to be used within a single SP 1524 domain, in other words, they are deployed in a more constrained 1525 environment (e.g., anti-spoofing, protocol 41 filtering at the edge) 1526 than 6to4 tunnels and have few security issues other than lack of 1527 confidentiality. The security considerations (Section 12) of 1528 [RFC5969] describes how to secure 6rd tunnels. 1530 IPsec [RFC4301] for the transported IPv6 traffic can be used if 1531 confidentiality is important. 1533 2.7.2.4. 6PE, 6VPE, and LDPv6 1535 Organizations using MPLS in their core can also use 6PE [RFC4798] and 1536 6VPE [RFC4659] to enable IPv6 access over MPLS. As 6PE and 6VPE are 1537 really similar to BGP/MPLS IP VPNs described in [RFC4364], the 1538 security properties of these networks are also similar to those 1539 described in [RFC4381] (please note that this RFC may resemble a 1540 published IETF work but it is not based on an IETF review and the 1541 IETF disclaims any knowledge of the fitness of this RFC for any 1542 purpose). They rely on: 1544 o Address space, routing, and traffic separation with the help of 1545 VRFs (only applicable to 6VPE); 1547 o Hiding the IPv4 core, hence removing all attacks against 1548 P-routers; 1550 o Securing the routing protocol between CE and PE; in the case of 1551 6PE and 6VPE, link-local addresses (see [RFC7404]) can be used and 1552 as these addresses cannot be reached from outside of the link, the 1553 security of 6PE and 6VPE is even higher than an IPv4 BGP/MPLS IP 1554 VPN. 1556 LDPv6 itself does not induce new risks, see also [RFC7552]. 1558 2.7.2.5. DS-Lite 1560 DS-lite is also a translation mechanism and is therefore analyzed 1561 further (Section 2.7.3.3) in this document as it includes IPv4 NAPT. 1563 2.7.2.6. Mapping of Address and Port 1565 With the encapsulation and translation versions of mapping of Address 1566 and Port (MAP) (MAP-E [RFC7597] and MAP-T [RFC7599]), the access 1567 network is purely an IPv6 network and MAP protocols are used to 1568 provide IPv4 hosts on the subscriber network access to IPv4 hosts on 1569 the Internet. The subscriber router does stateful operations in 1570 order to map all internal IPv4 addresses and layer-4 ports to the 1571 IPv4 address and the set of layer-4 ports received through the MAP 1572 configuration process. The SP equipment always does stateless 1573 operations (either decapsulation or stateless translation). 1574 Therefore, as opposed to Section 2.7.3.3, there is no state- 1575 exhaustion DoS attack against the SP equipment because there is no 1576 state and there is no operation caused by a new layer-4 connection 1577 (no logging operation). 1579 The SP MAP equipment should implement all the security considerations 1580 of [RFC7597]; notably, ensuring that the mapping of the IPv4 address 1581 and port are consistent with the configuration. As MAP has a 1582 predictable IPv4 address and port mapping, the audit logs are easier 1583 to use as there is a clear mapping between the IPv6 address and the 1584 IPv4 address and ports. 1586 2.7.2.7. 6to4 1588 In [RFC3056]; 6to4 tunnels require a public routable IPv4 address in 1589 order to work correctly. They can be used to provide either single 1590 IPv6 host connectivity to the IPv6 Internet or multiple IPv6 networks 1591 connectivity to the IPv6 Internet. The 6to4 relay was historically 1592 the anycast address defined in [RFC3068] which has been deprecated by 1593 [RFC7526] and is no longer used by recent Operating Systems. Some 1594 security considerations are explained in [RFC3964]. 1596 [RFC6343] points out that if an operator provides well-managed 1597 servers and relays for 6to4, non-encapsulated IPv6 packets will pass 1598 through well-defined points (the native IPv6 interfaces of those 1599 servers and relays) at which security mechanisms may be applied. 1600 Client usage of 6to4 by default is now discouraged, and significant 1601 precautions are needed to avoid operational problems. 1603 2.7.2.8. Teredo 1605 Teredo tunnels [RFC4380] are mainly used in a residential environment 1606 because Teredo easily traverses an IPv4 NAPT device thanks to its UDP 1607 encapsulation. Teredo tunnels connect a single host to the IPv6 1608 Internet. Teredo shares the same issues as other tunnels: no 1609 authentication, no confidentiality, possible spoofing and reflection 1610 attacks. 1612 IPsec [RFC4301] for the transported IPv6 traffic is recommended. 1614 The biggest threat to Teredo is probably for an IPv4-only network as 1615 Teredo has been designed to easily traverse IPv4 NAT-PT devices which 1616 are quite often co-located with a stateful firewall. Therefore, if 1617 the stateful IPv4 firewall allows unrestricted UDP outbound and 1618 accepts the return UDP traffic, then Teredo actually punches a hole 1619 in this firewall for all IPv6 traffic to the Internet and from the 1620 Internet. Host policies can be deployed to block Teredo in an 1621 IPv4-only network in order to avoid this firewall bypass. On the 1622 IPv4 firewall all outbound UDP should be blocked except for the 1623 commonly used services (e.g., port 53 for DNS, port 123 for NTP, port 1624 443 for QUIC, port 500 for IKE, port 3478 for STUN, etc.). 1626 Teredo is now hardly ever used and no longer enabled by default in 1627 most environments, so it is less of a threat, however, special 1628 consideration must be taken in cases when devices with older or non- 1629 updated operating systems may be present and by default were running 1630 Teredo. 1632 2.7.3. Translation Mechanisms 1634 Translation mechanisms between IPv4 and IPv6 networks are alternate 1635 coexistence strategies while networks transition to IPv6. While a 1636 framework is described in [RFC6144], the specific security 1637 considerations are documented with each individual mechanism. For 1638 the most part, they specifically mention interference with IPsec or 1639 DNSSEC deployments, how to mitigate spoofed traffic, and what some 1640 effective filtering strategies may be. 1642 While not really a transition mechanism to IPv6, this section also 1643 includes the discussion about the use of heavy IPv4-to-IPv4 network 1644 address and port translation to prolong the life of IPv4-only 1645 networks. 1647 2.7.3.1. Carrier-Grade NAT (CGN) 1649 Carrier-Grade NAT (CGN), also called NAT444 CGN or Large Scale NAT 1650 (LSN) or SP NAT is described in [RFC6264] and is utilized as an 1651 interim measure to extend the use of IPv4 in a large service provider 1652 network until the provider can deploy an effective IPv6 solution. 1653 [RFC6598] requested a specific IANA allocated /10 IPv4 address block 1654 to be used as address space shared by all access networks using CGN. 1655 This has been allocated as 100.64.0.0/10. 1657 Section 13 of [RFC6269] lists some specific security-related issues 1658 caused by large scale address sharing. The Security Considerations 1659 section of [RFC6598] also lists some specific mitigation techniques 1660 for potential misuse of shared address space. Some Law Enforcement 1661 Agencies have identified CGN as impeding their cyber-crime 1662 investigations (for example Europol press release on CGN 1663 [europol-cgn]). Many translation techniques (NAT64, DS-lite, ...) 1664 have the same security issues as CGN when one part of the connection 1665 is IPv4-only. 1667 [RFC6302] has recommendations for Internet-facing servers to also log 1668 the source TCP or UDP ports of incoming connections in an attempt to 1669 help identify the users behind such a CGN. 1671 [RFC7422] suggests the use of deterministic address mapping in order 1672 to reduce logging requirements for CGN. The idea is to have a known 1673 algorithm for mapping the internal subscriber to/from public TCP and 1674 UDP ports. 1676 [RFC6888] lists common requirements for CGNs. [RFC6967] analyzes 1677 some solutions to enforce policies on misbehaving nodes when address 1678 sharing is used. [RFC7857] also updates the NAT behavioral 1679 requirements. 1681 2.7.3.2. NAT64/DNS64 and 464XLAT 1683 Stateful NAT64 translation [RFC6146] allows IPv6-only clients to 1684 contact IPv4 servers using unicast UDP, TCP, or ICMP. It can be used 1685 in conjunction with DNS64 [RFC6147], a mechanism which synthesizes 1686 AAAA records from existing A records. There is also a stateless 1687 NAT64 [RFC7915], which has similar security aspects but with the 1688 added benefit of being stateless, so, less prone to a state 1689 exhaustion attack. 1691 The Security Consideration sections of [RFC6146] and [RFC6147] list 1692 the comprehensive issues; in section 8 of [RFC6147] there are some 1693 considerations on the interaction between NAT64 and DNSSEC. A 1694 specific issue with the use of NAT64 is that it will interfere with 1695 most IPsec deployments unless UDP encapsulation is used. 1697 Another translation mechanism relying on a combination of stateful 1698 and stateless translation, 464XLAT [RFC6877], can be used to do host 1699 local translation from IPv4 to IPv6 and a network provider 1700 translation from IPv6 to IPv4, i.e., giving IPv4-only application 1701 access to an IPv4-only server over an IPv6-only network. 464XLAT 1702 shares the same security considerations as NAT64 and DNS64, however 1703 it can be used without DNS64, avoiding the DNSSEC implications. 1705 2.7.3.3. DS-Lite 1707 Dual-Stack Lite (DS-Lite) [RFC6333] is a transition technique that 1708 enables a service provider to share IPv4 addresses among customers by 1709 combining two well-known technologies: IP in IP (IPv4-in-IPv6) and 1710 IPv4 NAPT. 1712 Security considerations with respect to DS-Lite mainly revolve around 1713 logging data, preventing DoS attacks from rogue devices (as the 1714 Address Family Translation Router (AFTR) [RFC6333] function is 1715 stateful) and restricting service offered by the AFTR only to 1716 registered customers. 1718 Section 11 of [RFC6333] and section 2 of [RFC7785] describe important 1719 security issues associated with this technology. 1721 2.8. General Device Hardening 1723 With almost all devices being IPv6 enabled by default and with many 1724 end points having IPv6 connectivity to the Internet, it is critical 1725 to also harden those devices against attacks over IPv6. 1727 The ame techniques used to protect devices against attack over IPv4 1728 should be used for IPv6 and should include, but not limited to: 1730 o Restrict device access to authorized individuals 1732 o Monitor and audit access to the device 1734 o Turn off any unused services on the end node 1736 o Understand which IPv6 addresses are being used to source traffic 1737 and change defaults if necessary 1739 o Use cryptographically protected protocols for device management 1740 (SCP, SNMPv3, SSH, TLS, etc.) 1742 o Use host firewall capabilities to control traffic that gets 1743 processed by upper-layer protocols 1745 o apply firmware, OS and application patches/upgrades to the devices 1746 in a timely manner 1748 o use multi-factor credentials to authenticate to devices 1750 o Use virus scanners to detect malicious programs 1752 3. Enterprises Specific Security Considerations 1754 Enterprises [RFC7381] generally have robust network security policies 1755 in place to protect existing IPv4 networks. These policies have been 1756 distilled from years of experiential knowledge of securing IPv4 1757 networks. At the very least, it is recommended that enterprise 1758 networks have parity between their security policies for both 1759 protocol versions. This section also applies to the enterprise part 1760 of all SP networks, i.e., the part of the network where the SP 1761 employees are connected. 1763 Security considerations in the enterprise can be broadly categorized 1764 into two groups: External and Internal. 1766 3.1. External Security Considerations 1768 The external aspect deals with providing security at the edge or 1769 perimeter of the enterprise network where it meets the service 1770 provider's network. This is commonly achieved by enforcing a 1771 security policy either by implementing dedicated firewalls with 1772 stateful packet inspection or a router with ACLs. A common default 1773 IPv4 policy on firewalls that could easily be ported to IPv6 is to 1774 allow all traffic outbound while only allowing specific traffic, such 1775 as established sessions, inbound (see also [RFC6092]). Section 3.2 1776 of [RFC7381] also provides similar recommendations. 1778 Here are a few more things that could enhance the default policy: 1780 o Filter internal-use IPv6 addresses at the perimeter, this will 1781 also mitigate the vulnerabilities listed in [RFC7359] 1783 o Discard packets from and to bogon and reserved space, see also 1784 [CYMRU] and [RFC8190] 1786 o Accept certain ICMPv6 messages to allow proper operation of ND and 1787 PMTUD, see also [RFC4890] or [REY_PF] for hosts 1789 o Based on the use of the network, filter specific extension headers 1790 by accepting only the required ones (permit list approach) such as 1791 ESP, AH, and not forgetting the required transport layers: ICMP, 1792 TCP, UDP, ... This filtering should be done where applicable at 1793 the edge and possibly inside the perimeter; see also 1794 [I-D.ietf-opsec-ipv6-eh-filtering] 1796 o Filter packets having an illegal IPv6 headers chain at the 1797 perimeter (and if possible, inside the network as well), see 1798 Section 2.2 1800 o Filter unneeded services at the perimeter 1802 o Implement ingress and egress anti-spoofing in the forwarding and 1803 control planes, see [RFC2827] and [RFC3704] 1805 o Implement appropriate rate-limiters and control-plane policers 1806 based on traffic baselines 1808 Having global IPv6 addresses on all the enterprise sites is different 1809 than in IPv4 where [RFC1918] addresses are often used internally and 1810 not routed over the Internet. [RFC7359] and [WEBER_VPN] explain that 1811 without careful design, there could be IPv6 leakages from layer-3 1812 VPNs. 1814 3.2. Internal Security Considerations 1816 The internal aspect deals with providing security inside the 1817 perimeter of the network, including end hosts. Internal networks of 1818 enterprises are often different: University campus, wireless guest 1819 access, ... so there is no "one size fits all" recommendation. 1821 The most significant concerns here are related to Neighbor Discovery. 1822 At the network level, it is recommended that all security 1823 considerations discussed in Section 2.3 be reviewed carefully and the 1824 recommendations be considered in-depth as well. Section 4.1 of 1825 [RFC7381] also provides some recommendations. 1827 As mentioned in Section 2.7.2, care must be taken when running 1828 automated IPv6-in-IPv4 tunnels. 1830 When site-to-site VPNs are used it should be kept in mind that, given 1831 the global scope of IPv6 global addresses as opposed to the common 1832 use of IPv4 private address space [RFC1918], sites might be able to 1833 communicate with each other over the Internet even when the VPN 1834 mechanism is not available and hence no traffic encryption is 1835 performed and traffic could be injected from the Internet into the 1836 site, see [WEBER_VPN]. It is recommended to filter at Internet 1837 connection(s) packets having a source or destination address 1838 belonging to the site internal prefix(es); this should be done for 1839 ingress and egress traffic. 1841 Hosts need to be hardened directly through security policy to protect 1842 against security threats. The host firewall default capabilities 1843 have to be clearly understood. In some cases, 3rd party firewalls 1844 have no IPv6 support whereas the native firewall installed by default 1845 has IPv6 support. General device hardening guidelines are provided 1846 in Section 2.8. 1848 It should also be noted that many hosts still use IPv4 for 1849 transporting logs for RADIUS, DIAMETER, TACACS+, SYSLOG, etc. 1850 Operators cannot rely on an IPv6-only security policy to secure such 1851 protocols that are still using IPv4. 1853 4. Service Providers Security Considerations 1855 4.1. BGP 1857 The threats and mitigation techniques are identical between IPv4 and 1858 IPv6. Broadly speaking they are: 1860 o Authenticating the TCP session; 1862 o TTL security (which becomes hop-limit security in IPv6) as 1863 [RFC5082]; 1865 o bogon AS filtering, see [CYMRU]; 1867 o Prefix filtering. 1869 These are explained in more detail in Section 2.5. Also, the 1870 recommendations of [RFC7454] should be considered. 1872 4.1.1. Remote Triggered Black Hole Filtering (RTBH) 1874 RTBH [RFC5635] works identically in IPv4 and IPv6. IANA has 1875 allocated the 100::/64 prefix to be used as the discard prefix 1876 [RFC6666] 1878 4.2. Transition/Coexistence Mechanism 1880 SPs will typically use transition mechanisms such as 6rd, 6PE, MAP, 1881 and NAT64 which have been analyzed in the transition and coexistence 1882 Section 2.7 section. 1884 4.3. Lawful Intercept 1886 The Lawful Intercept requirements are similar for IPv6 and IPv4 1887 architectures and will be subject to the laws enforced in different 1888 geographic regions. The local issues with each jurisdiction can make 1889 this challenging and both corporate legal and privacy personnel 1890 should be involved in discussions pertaining to what information gets 1891 logged and with regard to the respective log retention policies for 1892 this information. 1894 The target of interception will usually be a residential subscriber 1895 (e.g., his/her PPP session, physical line, or CPE MAC address). In 1896 the absence of IPv6 NAT on the CPE, IPv6 has the possibility to allow 1897 for intercepting the traffic from a single host (i.e., a /128 target) 1898 rather than the whole set of hosts of a subscriber (which could be a 1899 /48, /60, or /64). 1901 In contrast, in mobile environments, since the 3GPP specifications 1902 allocate a /64 per device, it may be sufficient to intercept traffic 1903 from the /64 rather than specific /128's (since each time the device 1904 establishes a data connection it gets a new IID). 1906 5. Residential Users Security Considerations 1908 The IETF Homenet working group is working on standards and guidelines 1909 for IPv6 residential networks; this obviously includes operational 1910 security considerations; but this is still work in progress. 1911 [RFC8520] is an interesting approach on how firewalls could retrieve 1912 and apply specific security policies to some residential devices. 1914 Some residential users have less experience and knowledge about 1915 security or networking than experimented operators. As most of the 1916 recent hosts (e.g., smartphones, tablets) have IPv6 enabled by 1917 default, IPv6 security is important for those users. Even with an 1918 IPv4-only ISP, those users can get IPv6 Internet access with the help 1919 of Teredo (Section 2.7.2.8) tunnels. Several peer-to-peer programs 1920 support IPv6 and those programs can initiate a Teredo tunnel through 1921 an IPv4 residential gateway, with the consequence of making the 1922 internal host reachable from any IPv6 host on the Internet. It is 1923 therefore recommended that all host security products (including 1924 personal firewalls) are configured with a dual-stack security policy. 1926 If the residential CPE has IPv6 connectivity, [RFC7084] defines the 1927 requirements of an IPv6 CPE and does not take a position on the 1928 debate of default IPv6 security policy as defined in [RFC6092]: 1930 o outbound only: allowing all internally initiated connections and 1931 block all externally initiated ones, which is a common default 1932 security policy enforced by IPv4 Residential Gateway doing NAPT 1933 but it also breaks the end-to-end reachability promise of IPv6. 1934 [RFC6092] lists several recommendations to design such a CPE; 1936 o open/transparent: allowing all internally and externally initiated 1937 connections, therefore restoring the end-to-end nature of the 1938 Internet for IPv6 traffic but having a different security policy 1939 for IPv6 than for IPv4. 1941 [RFC6092] REC-49 states that a choice must be given to the user to 1942 select one of those two policies. 1944 6. Further Reading 1946 There are several documents that describe in more detail the security 1947 of an IPv6 network; these documents are not written by the IETF and 1948 some of them are dated but are listed here for the reader's 1949 convenience: 1951 1. Guidelines for the Secure Deployment of IPv6 [NIST] 1953 2. North American IPv6 Task Force Technology Report - IPv6 Security 1954 Technology Paper [NAv6TF_Security] 1956 3. IPv6 Security [IPv6_Security_Book] 1958 7. Acknowledgements 1960 The authors would like to thank the following people for their useful 1961 comments: Mikael Abrahamsson, Fred Baker, Mustafa Suha Botsali, 1962 Mohamed Boucadair, Brian Carpenter, Tim Chown, Lorenzo Colitti, Roman 1963 Danyliw (IESG review), Markus de Bruen, Lars Eggert (IESG review), 1964 Tobias Fiebig, Fernando Gont, Jeffry Handal, Lee Howard, Benjamin 1965 Kaduk (IESG review), Panos Kampanakis, Erik Kline, Jouni Korhonen, 1966 Warren Kumari (IESG review), Ted Lemon, Mark Lentczner, Acee Lindem 1967 (and his detailed nits), Jen Linkova (and her detailed review), Gyan 1968 S. Mishra (the document shepherd), Jordi Palet, Alvaro Retana (IESG 1969 review), Zaheduzzaman Sarker (IESG review), Bob Sleigh, Donald Smith, 1970 Tarko Tikan, Ole Troan, Bernie Volz (by alphabetical order). 1972 8. Security Considerations 1974 This memo attempts to give an overview of security considerations of 1975 operating an IPv6 network both for an IPv6-only network and for 1976 networks utilizing the most widely deployed IPv4/IPv6 coexistence 1977 strategies. 1979 9. References 1981 9.1. Normative References 1983 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1984 (IPv6) Specification", STD 86, RFC 8200, 1985 DOI 10.17487/RFC8200, July 2017, 1986 . 1988 9.2. Informative References 1990 [CYMRU] Team, C., "The Bogon Reference", Existing in 2021, 1991 . 1994 [ENTROPYIP] 1995 Foremski, P., Plonka, D., and A. Berger, "Entropy/IP: 1996 Uncovering Structure in IPv6 Addresses", 1997 . 1999 [europol-cgn] 2000 Europol, "ARE YOU SHARING THE SAME IP ADDRESS AS A 2001 CRIMINAL? LAW ENFORCEMENT CALL FOR THE END OF CARRIER 2002 GRADE NAT (CGN) TO INCREASE ACCOUNTABILITY ONLINE", 2003 October 2017, 2004 . 2009 [GDPR] Union, O. J. O. T. E., "Regulation (EU) 2016/679 of the 2010 European Parliament and of the Council of 27 April 2016 on 2011 the protection of natural persons with regard to the 2012 processing of personal data and on the free movement of 2013 such data, and repealing Directive 95/46/EC (General Data 2014 Protection Regulation)", April 2016, 2015 . 2017 [I-D.ietf-opsec-ipv6-eh-filtering] 2018 Gont, F. and W. Liu, "Recommendations on the Filtering of 2019 IPv6 Packets Containing IPv6 Extension Headers at Transit 2020 Routers", draft-ietf-opsec-ipv6-eh-filtering-07 (work in 2021 progress), January 2021. 2023 [I-D.kampanakis-6man-ipv6-eh-parsing] 2024 Kampanakis, P., "Implementation Guidelines for parsing 2025 IPv6 Extension Headers", draft-kampanakis-6man-ipv6-eh- 2026 parsing-01 (work in progress), August 2014. 2028 [IANA-IPFIX] 2029 IANA, "IP Flow Information Export (IPFIX) Entities", 2030 . 2032 [IEEE-802.1X] 2033 IEEE, "IEEE Standard for Local and metropolitan area 2034 networks - Port-Based Network Access Control", IEEE Std 2035 802.1X-2010, February 2010. 2037 [IPv6_Security_Book] 2038 Hogg, S. and E. Vyncke, "IPv6 Security", 2039 ISBN 1-58705-594-5, Publisher CiscoPress, December 2008. 2041 [KRISTOFF] 2042 Kristoff, J., Ghasemisharif, M., Kanich, C., and J. 2043 Polakis, "Plight at the End of the Tunnel: Legacy IPv6 2044 Transition Mechanisms in the Wild", March 2021, 2045 . 2047 [NAv6TF_Security] 2048 Kaeo, M., Green, D., Bound, J., and Y. Pouffary, "North 2049 American IPv6 Task Force Technology Report - IPv6 Security 2050 Technology Paper", 2006, 2051 . 2054 [NIST] Frankel, S., Graveman, R., Pearce, J., and M. Rooks, 2055 "Guidelines for the Secure Deployment of IPv6", 2010, 2056 . 2059 [RADB] INC., M. N., "RADb The Internet Routing Registry", 2060 Existing in 2021, . 2062 [REY_PF] Rey, E., "Local Packet Filtering with IPv6", July 2017, 2063 . 2066 [RFC0826] Plummer, D., "An Ethernet Address Resolution Protocol: Or 2067 Converting Network Protocol Addresses to 48.bit Ethernet 2068 Address for Transmission on Ethernet Hardware", STD 37, 2069 RFC 826, DOI 10.17487/RFC0826, November 1982, 2070 . 2072 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 2073 and E. Lear, "Address Allocation for Private Internets", 2074 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 2075 . 2077 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 2078 RFC 2131, DOI 10.17487/RFC2131, March 1997, 2079 . 2081 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 2082 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 2083 December 1998, . 2085 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 2086 Domains without Explicit Tunnels", RFC 2529, 2087 DOI 10.17487/RFC2529, March 1999, 2088 . 2090 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 2091 Translator (NAT) Terminology and Considerations", 2092 RFC 2663, DOI 10.17487/RFC2663, August 1999, 2093 . 2095 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 2096 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 2097 DOI 10.17487/RFC2784, March 2000, 2098 . 2100 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 2101 Defeating Denial of Service Attacks which employ IP Source 2102 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 2103 May 2000, . 2105 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, 2106 DOI 10.17487/RFC2866, June 2000, 2107 . 2109 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 2110 via IPv4 Clouds", RFC 3056, DOI 10.17487/RFC3056, February 2111 2001, . 2113 [RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", 2114 RFC 3068, DOI 10.17487/RFC3068, June 2001, 2115 . 2117 [RFC3627] Savola, P., "Use of /127 Prefix Length Between Routers 2118 Considered Harmful", RFC 3627, DOI 10.17487/RFC3627, 2119 September 2003, . 2121 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 2122 Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March 2123 2004, . 2125 [RFC3756] Nikander, P., Ed., Kempf, J., and E. Nordmark, "IPv6 2126 Neighbor Discovery (ND) Trust Models and Threats", 2127 RFC 3756, DOI 10.17487/RFC3756, May 2004, 2128 . 2130 [RFC3924] Baker, F., Foster, B., and C. Sharp, "Cisco Architecture 2131 for Lawful Intercept in IP Networks", RFC 3924, 2132 DOI 10.17487/RFC3924, October 2004, 2133 . 2135 [RFC3964] Savola, P. and C. Patel, "Security Considerations for 2136 6to4", RFC 3964, DOI 10.17487/RFC3964, December 2004, 2137 . 2139 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 2140 "SEcure Neighbor Discovery (SEND)", RFC 3971, 2141 DOI 10.17487/RFC3971, March 2005, 2142 . 2144 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 2145 RFC 3972, DOI 10.17487/RFC3972, March 2005, 2146 . 2148 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 2149 Rose, "DNS Security Introduction and Requirements", 2150 RFC 4033, DOI 10.17487/RFC4033, March 2005, 2151 . 2153 [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic 2154 Key Management", BCP 107, RFC 4107, DOI 10.17487/RFC4107, 2155 June 2005, . 2157 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 2158 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 2159 . 2161 [RFC4293] Routhier, S., Ed., "Management Information Base for the 2162 Internet Protocol (IP)", RFC 4293, DOI 10.17487/RFC4293, 2163 April 2006, . 2165 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 2166 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 2167 December 2005, . 2169 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 2170 DOI 10.17487/RFC4302, December 2005, 2171 . 2173 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 2174 RFC 4303, DOI 10.17487/RFC4303, December 2005, 2175 . 2177 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 2178 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2179 2006, . 2181 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 2182 Network Address Translations (NATs)", RFC 4380, 2183 DOI 10.17487/RFC4380, February 2006, 2184 . 2186 [RFC4381] Behringer, M., "Analysis of the Security of BGP/MPLS IP 2187 Virtual Private Networks (VPNs)", RFC 4381, 2188 DOI 10.17487/RFC4381, February 2006, 2189 . 2191 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 2192 Control Message Protocol (ICMPv6) for the Internet 2193 Protocol Version 6 (IPv6) Specification", STD 89, 2194 RFC 4443, DOI 10.17487/RFC4443, March 2006, 2195 . 2197 [RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality 2198 for OSPFv3", RFC 4552, DOI 10.17487/RFC4552, June 2006, 2199 . 2201 [RFC4649] Volz, B., "Dynamic Host Configuration Protocol for IPv6 2202 (DHCPv6) Relay Agent Remote-ID Option", RFC 4649, 2203 DOI 10.17487/RFC4649, August 2006, 2204 . 2206 [RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur, 2207 "BGP-MPLS IP Virtual Private Network (VPN) Extension for 2208 IPv6 VPN", RFC 4659, DOI 10.17487/RFC4659, September 2006, 2209 . 2211 [RFC4795] Aboba, B., Thaler, D., and L. Esibov, "Link-local 2212 Multicast Name Resolution (LLMNR)", RFC 4795, 2213 DOI 10.17487/RFC4795, January 2007, 2214 . 2216 [RFC4798] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur, 2217 "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 2218 Provider Edge Routers (6PE)", RFC 4798, 2219 DOI 10.17487/RFC4798, February 2007, 2220 . 2222 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 2223 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 2224 DOI 10.17487/RFC4861, September 2007, 2225 . 2227 [RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and 2228 E. Klein, "Local Network Protection for IPv6", RFC 4864, 2229 DOI 10.17487/RFC4864, May 2007, 2230 . 2232 [RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering 2233 ICMPv6 Messages in Firewalls", RFC 4890, 2234 DOI 10.17487/RFC4890, May 2007, 2235 . 2237 [RFC4942] Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/ 2238 Co-existence Security Considerations", RFC 4942, 2239 DOI 10.17487/RFC4942, September 2007, 2240 . 2242 [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. 2243 Pignataro, "The Generalized TTL Security Mechanism 2244 (GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007, 2245 . 2247 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 2248 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 2249 DOI 10.17487/RFC5214, March 2008, 2250 . 2252 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 2253 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 2254 . 2256 [RFC5635] Kumari, W. and D. McPherson, "Remote Triggered Black Hole 2257 Filtering with Unicast Reverse Path Forwarding (uRPF)", 2258 RFC 5635, DOI 10.17487/RFC5635, August 2009, 2259 . 2261 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 2262 Address Text Representation", RFC 5952, 2263 DOI 10.17487/RFC5952, August 2010, 2264 . 2266 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 2267 Infrastructures (6rd) -- Protocol Specification", 2268 RFC 5969, DOI 10.17487/RFC5969, August 2010, 2269 . 2271 [RFC6092] Woodyatt, J., Ed., "Recommended Simple Security 2272 Capabilities in Customer Premises Equipment (CPE) for 2273 Providing Residential IPv6 Internet Service", RFC 6092, 2274 DOI 10.17487/RFC6092, January 2011, 2275 . 2277 [RFC6104] Chown, T. and S. Venaas, "Rogue IPv6 Router Advertisement 2278 Problem Statement", RFC 6104, DOI 10.17487/RFC6104, 2279 February 2011, . 2281 [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. 2282 Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, 2283 DOI 10.17487/RFC6105, February 2011, 2284 . 2286 [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 2287 IPv4/IPv6 Translation", RFC 6144, DOI 10.17487/RFC6144, 2288 April 2011, . 2290 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 2291 NAT64: Network Address and Protocol Translation from IPv6 2292 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 2293 April 2011, . 2295 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 2296 Beijnum, "DNS64: DNS Extensions for Network Address 2297 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 2298 DOI 10.17487/RFC6147, April 2011, 2299 . 2301 [RFC6164] Kohno, M., Nitzan, B., Bush, R., Matsuzaki, Y., Colitti, 2302 L., and T. Narten, "Using 127-Bit IPv6 Prefixes on Inter- 2303 Router Links", RFC 6164, DOI 10.17487/RFC6164, April 2011, 2304 . 2306 [RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, "Security 2307 Concerns with IP Tunneling", RFC 6169, 2308 DOI 10.17487/RFC6169, April 2011, 2309 . 2311 [RFC6177] Narten, T., Huston, G., and L. Roberts, "IPv6 Address 2312 Assignment to End Sites", BCP 157, RFC 6177, 2313 DOI 10.17487/RFC6177, March 2011, 2314 . 2316 [RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the 2317 Router Control Plane", RFC 6192, DOI 10.17487/RFC6192, 2318 March 2011, . 2320 [RFC6221] Miles, D., Ed., Ooghe, S., Dec, W., Krishnan, S., and A. 2321 Kavanagh, "Lightweight DHCPv6 Relay Agent", RFC 6221, 2322 DOI 10.17487/RFC6221, May 2011, 2323 . 2325 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 2326 and A. Bierman, Ed., "Network Configuration Protocol 2327 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 2328 . 2330 [RFC6264] Jiang, S., Guo, D., and B. Carpenter, "An Incremental 2331 Carrier-Grade NAT (CGN) for IPv6 Transition", RFC 6264, 2332 DOI 10.17487/RFC6264, June 2011, 2333 . 2335 [RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and 2336 P. Roberts, "Issues with IP Address Sharing", RFC 6269, 2337 DOI 10.17487/RFC6269, June 2011, 2338 . 2340 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 2341 Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011, 2342 . 2344 [RFC6302] Durand, A., Gashinsky, I., Lee, D., and S. Sheppard, 2345 "Logging Recommendations for Internet-Facing Servers", 2346 BCP 162, RFC 6302, DOI 10.17487/RFC6302, June 2011, 2347 . 2349 [RFC6324] Nakibly, G. and F. Templin, "Routing Loop Attack Using 2350 IPv6 Automatic Tunnels: Problem Statement and Proposed 2351 Mitigations", RFC 6324, DOI 10.17487/RFC6324, August 2011, 2352 . 2354 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 2355 Stack Lite Broadband Deployments Following IPv4 2356 Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011, 2357 . 2359 [RFC6343] Carpenter, B., "Advisory Guidelines for 6to4 Deployment", 2360 RFC 6343, DOI 10.17487/RFC6343, August 2011, 2361 . 2363 [RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node 2364 Requirements", RFC 6434, DOI 10.17487/RFC6434, December 2365 2011, . 2367 [RFC6459] Korhonen, J., Ed., Soininen, J., Patil, B., Savolainen, 2368 T., Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation 2369 Partnership Project (3GPP) Evolved Packet System (EPS)", 2370 RFC 6459, DOI 10.17487/RFC6459, January 2012, 2371 . 2373 [RFC6547] George, W., "RFC 3627 to Historic Status", RFC 6547, 2374 DOI 10.17487/RFC6547, February 2012, 2375 . 2377 [RFC6564] Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and 2378 M. Bhatia, "A Uniform Format for IPv6 Extension Headers", 2379 RFC 6564, DOI 10.17487/RFC6564, April 2012, 2380 . 2382 [RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational 2383 Neighbor Discovery Problems", RFC 6583, 2384 DOI 10.17487/RFC6583, March 2012, 2385 . 2387 [RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and 2388 M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address 2389 Space", BCP 153, RFC 6598, DOI 10.17487/RFC6598, April 2390 2012, . 2392 [RFC6620] Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS 2393 SAVI: First-Come, First-Served Source Address Validation 2394 Improvement for Locally Assigned IPv6 Addresses", 2395 RFC 6620, DOI 10.17487/RFC6620, May 2012, 2396 . 2398 [RFC6666] Hilliard, N. and D. Freedman, "A Discard Prefix for IPv6", 2399 RFC 6666, DOI 10.17487/RFC6666, August 2012, 2400 . 2402 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 2403 DOI 10.17487/RFC6762, February 2013, 2404 . 2406 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 2407 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 2408 . 2410 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 2411 Bormann, "Neighbor Discovery Optimization for IPv6 over 2412 Low-Power Wireless Personal Area Networks (6LoWPANs)", 2413 RFC 6775, DOI 10.17487/RFC6775, November 2012, 2414 . 2416 [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: 2417 Combination of Stateful and Stateless Translation", 2418 RFC 6877, DOI 10.17487/RFC6877, April 2013, 2419 . 2421 [RFC6888] Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa, 2422 A., and H. Ashida, "Common Requirements for Carrier-Grade 2423 NATs (CGNs)", BCP 127, RFC 6888, DOI 10.17487/RFC6888, 2424 April 2013, . 2426 [RFC6939] Halwasia, G., Bhandari, S., and W. Dec, "Client Link-Layer 2427 Address Option in DHCPv6", RFC 6939, DOI 10.17487/RFC6939, 2428 May 2013, . 2430 [RFC6964] Templin, F., "Operational Guidance for IPv6 Deployment in 2431 IPv4 Sites Using the Intra-Site Automatic Tunnel 2432 Addressing Protocol (ISATAP)", RFC 6964, 2433 DOI 10.17487/RFC6964, May 2013, 2434 . 2436 [RFC6967] Boucadair, M., Touch, J., Levis, P., and R. Penno, 2437 "Analysis of Potential Solutions for Revealing a Host 2438 Identifier (HOST_ID) in Shared Address Deployments", 2439 RFC 6967, DOI 10.17487/RFC6967, June 2013, 2440 . 2442 [RFC6980] Gont, F., "Security Implications of IPv6 Fragmentation 2443 with IPv6 Neighbor Discovery", RFC 6980, 2444 DOI 10.17487/RFC6980, August 2013, 2445 . 2447 [RFC7010] Liu, B., Jiang, S., Carpenter, B., Venaas, S., and W. 2448 George, "IPv6 Site Renumbering Gap Analysis", RFC 7010, 2449 DOI 10.17487/RFC7010, September 2013, 2450 . 2452 [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, 2453 "Specification of the IP Flow Information Export (IPFIX) 2454 Protocol for the Exchange of Flow Information", STD 77, 2455 RFC 7011, DOI 10.17487/RFC7011, September 2013, 2456 . 2458 [RFC7012] Claise, B., Ed. and B. Trammell, Ed., "Information Model 2459 for IP Flow Information Export (IPFIX)", RFC 7012, 2460 DOI 10.17487/RFC7012, September 2013, 2461 . 2463 [RFC7039] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, Ed., 2464 "Source Address Validation Improvement (SAVI) Framework", 2465 RFC 7039, DOI 10.17487/RFC7039, October 2013, 2466 . 2468 [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing 2469 of IPv6 Extension Headers", RFC 7045, 2470 DOI 10.17487/RFC7045, December 2013, 2471 . 2473 [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of 2474 the IPv6 Prefix Used for IPv6 Address Synthesis", 2475 RFC 7050, DOI 10.17487/RFC7050, November 2013, 2476 . 2478 [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic 2479 Requirements for IPv6 Customer Edge Routers", RFC 7084, 2480 DOI 10.17487/RFC7084, November 2013, 2481 . 2483 [RFC7112] Gont, F., Manral, V., and R. Bonica, "Implications of 2484 Oversized IPv6 Header Chains", RFC 7112, 2485 DOI 10.17487/RFC7112, January 2014, 2486 . 2488 [RFC7113] Gont, F., "Implementation Advice for IPv6 Router 2489 Advertisement Guard (RA-Guard)", RFC 7113, 2490 DOI 10.17487/RFC7113, February 2014, 2491 . 2493 [RFC7123] Gont, F. and W. Liu, "Security Implications of IPv6 on 2494 IPv4 Networks", RFC 7123, DOI 10.17487/RFC7123, February 2495 2014, . 2497 [RFC7166] Bhatia, M., Manral, V., and A. Lindem, "Supporting 2498 Authentication Trailer for OSPFv3", RFC 7166, 2499 DOI 10.17487/RFC7166, March 2014, 2500 . 2502 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 2503 Interface Identifiers with IPv6 Stateless Address 2504 Autoconfiguration (SLAAC)", RFC 7217, 2505 DOI 10.17487/RFC7217, April 2014, 2506 . 2508 [RFC7359] Gont, F., "Layer 3 Virtual Private Network (VPN) Tunnel 2509 Traffic Leakages in Dual-Stack Hosts/Networks", RFC 7359, 2510 DOI 10.17487/RFC7359, August 2014, 2511 . 2513 [RFC7381] Chittimaneni, K., Chown, T., Howard, L., Kuarsingh, V., 2514 Pouffary, Y., and E. Vyncke, "Enterprise IPv6 Deployment 2515 Guidelines", RFC 7381, DOI 10.17487/RFC7381, October 2014, 2516 . 2518 [RFC7404] Behringer, M. and E. Vyncke, "Using Only Link-Local 2519 Addressing inside an IPv6 Network", RFC 7404, 2520 DOI 10.17487/RFC7404, November 2014, 2521 . 2523 [RFC7422] Donley, C., Grundemann, C., Sarawat, V., Sundaresan, K., 2524 and O. Vautrin, "Deterministic Address Mapping to Reduce 2525 Logging in Carrier-Grade NAT Deployments", RFC 7422, 2526 DOI 10.17487/RFC7422, December 2014, 2527 . 2529 [RFC7454] Durand, J., Pepelnjak, I., and G. Doering, "BGP Operations 2530 and Security", BCP 194, RFC 7454, DOI 10.17487/RFC7454, 2531 February 2015, . 2533 [RFC7513] Bi, J., Wu, J., Yao, G., and F. Baker, "Source Address 2534 Validation Improvement (SAVI) Solution for DHCP", 2535 RFC 7513, DOI 10.17487/RFC7513, May 2015, 2536 . 2538 [RFC7526] Troan, O. and B. Carpenter, Ed., "Deprecating the Anycast 2539 Prefix for 6to4 Relay Routers", BCP 196, RFC 7526, 2540 DOI 10.17487/RFC7526, May 2015, 2541 . 2543 [RFC7552] Asati, R., Pignataro, C., Raza, K., Manral, V., and R. 2544 Papneja, "Updates to LDP for IPv6", RFC 7552, 2545 DOI 10.17487/RFC7552, June 2015, 2546 . 2548 [RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S., 2549 Murakami, T., and T. Taylor, Ed., "Mapping of Address and 2550 Port with Encapsulation (MAP-E)", RFC 7597, 2551 DOI 10.17487/RFC7597, July 2015, 2552 . 2554 [RFC7599] Li, X., Bao, C., Dec, W., Ed., Troan, O., Matsushima, S., 2555 and T. Murakami, "Mapping of Address and Port using 2556 Translation (MAP-T)", RFC 7599, DOI 10.17487/RFC7599, July 2557 2015, . 2559 [RFC7610] Gont, F., Liu, W., and G. Van de Velde, "DHCPv6-Shield: 2560 Protecting against Rogue DHCPv6 Servers", BCP 199, 2561 RFC 7610, DOI 10.17487/RFC7610, August 2015, 2562 . 2564 [RFC7707] Gont, F. and T. Chown, "Network Reconnaissance in IPv6 2565 Networks", RFC 7707, DOI 10.17487/RFC7707, March 2016, 2566 . 2568 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 2569 Considerations for IPv6 Address Generation Mechanisms", 2570 RFC 7721, DOI 10.17487/RFC7721, March 2016, 2571 . 2573 [RFC7772] Yourtchenko, A. and L. Colitti, "Reducing Energy 2574 Consumption of Router Advertisements", BCP 202, RFC 7772, 2575 DOI 10.17487/RFC7772, February 2016, 2576 . 2578 [RFC7785] Vinapamula, S. and M. Boucadair, "Recommendations for 2579 Prefix Binding in the Context of Softwire Dual-Stack 2580 Lite", RFC 7785, DOI 10.17487/RFC7785, February 2016, 2581 . 2583 [RFC7824] Krishnan, S., Mrugalski, T., and S. Jiang, "Privacy 2584 Considerations for DHCPv6", RFC 7824, 2585 DOI 10.17487/RFC7824, May 2016, 2586 . 2588 [RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity 2589 Profiles for DHCP Clients", RFC 7844, 2590 DOI 10.17487/RFC7844, May 2016, 2591 . 2593 [RFC7857] Penno, R., Perreault, S., Boucadair, M., Ed., Sivakumar, 2594 S., and K. Naito, "Updates to Network Address Translation 2595 (NAT) Behavioral Requirements", BCP 127, RFC 7857, 2596 DOI 10.17487/RFC7857, April 2016, 2597 . 2599 [RFC7872] Gont, F., Linkova, J., Chown, T., and W. Liu, 2600 "Observations on the Dropping of Packets with IPv6 2601 Extension Headers in the Real World", RFC 7872, 2602 DOI 10.17487/RFC7872, June 2016, 2603 . 2605 [RFC7915] Bao, C., Li, X., Baker, F., Anderson, T., and F. Gont, 2606 "IP/ICMP Translation Algorithm", RFC 7915, 2607 DOI 10.17487/RFC7915, June 2016, 2608 . 2610 [RFC7934] Colitti, L., Cerf, V., Cheshire, S., and D. Schinazi, 2611 "Host Address Availability Recommendations", BCP 204, 2612 RFC 7934, DOI 10.17487/RFC7934, July 2016, 2613 . 2615 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 2616 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 2617 . 2619 [RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu, 2620 "Recommendation on Stable IPv6 Interface Identifiers", 2621 RFC 8064, DOI 10.17487/RFC8064, February 2017, 2622 . 2624 [RFC8177] Lindem, A., Ed., Qu, Y., Yeung, D., Chen, I., and J. 2625 Zhang, "YANG Data Model for Key Chains", RFC 8177, 2626 DOI 10.17487/RFC8177, June 2017, 2627 . 2629 [RFC8190] Bonica, R., Cotton, M., Haberman, B., and L. Vegoda, 2630 "Updates to the Special-Purpose IP Address Registries", 2631 BCP 153, RFC 8190, DOI 10.17487/RFC8190, June 2017, 2632 . 2634 [RFC8210] Bush, R. and R. Austein, "The Resource Public Key 2635 Infrastructure (RPKI) to Router Protocol, Version 1", 2636 RFC 8210, DOI 10.17487/RFC8210, September 2017, 2637 . 2639 [RFC8273] Brzozowski, J. and G. Van de Velde, "Unique IPv6 Prefix 2640 per Host", RFC 8273, DOI 10.17487/RFC8273, December 2017, 2641 . 2643 [RFC8343] Bjorklund, M., "A YANG Data Model for Interface 2644 Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, 2645 . 2647 [RFC8344] Bjorklund, M., "A YANG Data Model for IP Management", 2648 RFC 8344, DOI 10.17487/RFC8344, March 2018, 2649 . 2651 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 2652 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 2653 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 2654 RFC 8415, DOI 10.17487/RFC8415, November 2018, 2655 . 2657 [RFC8504] Chown, T., Loughney, J., and T. Winters, "IPv6 Node 2658 Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504, 2659 January 2019, . 2661 [RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage 2662 Description Specification", RFC 8520, 2663 DOI 10.17487/RFC8520, March 2019, 2664 . 2666 [RFC8541] Litkowski, S., Decraene, B., and M. Horneffer, "Impact of 2667 Shortest Path First (SPF) Trigger and Delay Strategies on 2668 IGP Micro-loops", RFC 8541, DOI 10.17487/RFC8541, March 2669 2019, . 2671 [RFC8981] Gont, F., Krishnan, S., Narten, T., and R. Draves, 2672 "Temporary Address Extensions for Stateless Address 2673 Autoconfiguration in IPv6", RFC 8981, 2674 DOI 10.17487/RFC8981, February 2021, 2675 . 2677 [SCANNING] 2678 Barnes, R., Altmann, R., and D. Kerr, "Mapping the Great 2679 Void - Smarter scanning for IPv6", February 2012, 2680 . 2683 [WEBER_VPN] 2684 Weber, J., "Dynamic IPv6 Prefix - Problems and VPNs", 2685 March 2018, . 2689 Authors' Addresses 2691 Eric Vyncke 2692 Cisco 2693 De Kleetlaan 6a 2694 Diegem 1831 2695 Belgium 2697 Phone: +32 2 778 4677 2698 Email: evyncke@cisco.com 2699 Kiran Kumar 2700 Square 2701 1455 Market Street, Suite 600 2702 San Francisco 94103 2703 United States of America 2705 Email: kk.chittimaneni@gmail.com 2707 Merike Kaeo 2708 Double Shot Security 2709 3518 Fremont Ave N 363 2710 Seattle 98103 2711 United States of America 2713 Phone: +12066696394 2714 Email: merike@doubleshotsecurity.com 2716 Enno Rey 2717 ERNW 2718 Carl-Bosch-Str. 4 2719 Heidelberg, Baden-Wuertemberg 69115 2720 Germany 2722 Phone: +49 6221 480390 2723 Email: erey@ernw.de