idnits 2.17.1 draft-ietf-opsec-v6-24.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 905: '... 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 (February 12, 2021) is 1141 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-10) exists of draft-ietf-opsec-ipv6-eh-filtering-07 -- 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 4941 (Obsoleted by RFC 8981) Summary: 2 errors (**), 0 flaws (~~), 3 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: August 16, 2021 WeWork 6 M. Kaeo 7 Double Shot Security 8 E. Rey 9 ERNW 10 February 12, 2021 12 Operational Security Considerations for IPv6 Networks 13 draft-ietf-opsec-v6-24 15 Abstract 17 Knowledge and experience on how to operate IPv4 securely is 18 available: whether it is the Internet or an enterprise internal 19 network. However, IPv6 presents some new security challenges. RFC 20 4942 describes the security issues in the protocol, but network 21 managers also need a more practical, operations-minded document to 22 enumerate advantages and/or disadvantages of certain choices. 24 This document analyzes the operational security issues associated 25 with several types of network and proposes technical and procedural 26 mitigation techniques. This document is only applicable to managed 27 networks, such as enterprise building networks. The recommendations 28 in this document are not applicable to residential user cases, even 29 in cases where a Service Provider may be managing the home gateway. 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 August 16, 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 Architecture . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . 5 73 2.1.5. Temporary Addresses for SLAAC . . . . . . . . . . . . 6 74 2.1.6. DHCP and DNS Considerations . . . . . . . . . . . . . 7 75 2.1.7. Using a /64 per host . . . . . . . . . . . . . . . . 8 76 2.1.8. Privacy consideration of Addresses . . . . . . . . . 8 77 2.2. Extension Headers . . . . . . . . . . . . . . . . . . . . 8 78 2.2.1. Order and Repetition of Extension Headers . . . . . . 9 79 2.2.2. Hop-by-Hop Options Header . . . . . . . . . . . . . . 9 80 2.2.3. Fragment Header . . . . . . . . . . . . . . . . . . . 10 81 2.2.4. IP Security Extension Header . . . . . . . . . . . . 10 82 2.3. Link-Layer Security . . . . . . . . . . . . . . . . . . . 10 83 2.3.1. Neighbor Solicitation Rate Limiting . . . . . . . . . 10 84 2.3.2. Router and Neighbor Advertisements Filtering . . . . 11 85 2.3.3. Securing DHCP . . . . . . . . . . . . . . . . . . . . 13 86 2.3.4. 3GPP Link-Layer Security . . . . . . . . . . . . . . 13 87 2.3.5. Impact of Multicast Traffic . . . . . . . . . . . . . 14 88 2.3.6. SeND and CGA . . . . . . . . . . . . . . . . . . . . 14 89 2.4. Control Plane Security . . . . . . . . . . . . . . . . . 15 90 2.4.1. Control Protocols . . . . . . . . . . . . . . . . . . 17 91 2.4.2. Management Protocols . . . . . . . . . . . . . . . . 17 92 2.4.3. Packet Exceptions . . . . . . . . . . . . . . . . . . 18 93 2.5. Routing Security . . . . . . . . . . . . . . . . . . . . 19 94 2.5.1. BGP Security . . . . . . . . . . . . . . . . . . . . 19 95 2.5.2. Authenticating OSPFv3 Neighbors . . . . . . . . . . . 19 96 2.5.3. Securing Routing Updates . . . . . . . . . . . . . . 20 97 2.5.4. Route Filtering . . . . . . . . . . . . . . . . . . . 20 98 2.6. Logging/Monitoring . . . . . . . . . . . . . . . . . . . 21 99 2.6.1. Data Sources . . . . . . . . . . . . . . . . . . . . 22 100 2.6.2. Use of Collected Data . . . . . . . . . . . . . . . . 26 101 2.6.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 29 102 2.7. Transition/Coexistence Technologies . . . . . . . . . . . 29 103 2.7.1. Dual Stack . . . . . . . . . . . . . . . . . . . . . 29 104 2.7.2. Encapsulation Mechanisms . . . . . . . . . . . . . . 30 105 2.7.3. Translation Mechanisms . . . . . . . . . . . . . . . 34 106 2.8. General Device Hardening . . . . . . . . . . . . . . . . 36 107 3. Enterprises Specific Security Considerations . . . . . . . . 37 108 3.1. External Security Considerations . . . . . . . . . . . . 37 109 3.2. Internal Security Considerations . . . . . . . . . . . . 38 110 4. Service Providers Security Considerations . . . . . . . . . . 39 111 4.1. BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 112 4.1.1. Remote Triggered Black Hole Filtering . . . . . . . . 39 113 4.2. Transition/Coexistence Mechanism . . . . . . . . . . . . 39 114 4.3. Lawful Intercept . . . . . . . . . . . . . . . . . . . . 39 115 5. Residential Users Security Considerations . . . . . . . . . . 40 116 6. Further Reading . . . . . . . . . . . . . . . . . . . . . . . 41 117 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 41 118 8. Security Considerations . . . . . . . . . . . . . . . . . . . 41 119 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 41 120 9.1. Normative References . . . . . . . . . . . . . . . . . . 41 121 9.2. Informative References . . . . . . . . . . . . . . . . . 42 122 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 56 124 1. Introduction 126 Running an IPv6 network is new for most operators not only because 127 they are not yet used to large-scale IPv6 networks but also because 128 there are subtle but critical and important differences between IPv4 129 and IPv6, especially with respect to security. For example, all 130 layer-2 interactions are now done using Neighbor Discovery Protocol 131 [RFC4861] rather than using Address Resolution Protocol [RFC0826]. 132 Also, there is no Network Address Port Translation (NAPT) defined in 133 [RFC2663] for IPv6 even if [RFC6296] specifies a Network Prefix 134 Translation for IPv6 (NPTv6) which is a 1-to-1 mapping of IPv6 135 addresses. 137 IPv6 networks are deployed using a variety of techniques, each of 138 which have their own specific security concerns. 140 This document complements [RFC4942] by listing all security issues 141 when operating a network (including various transition technologies). 142 It also provides more recent operational deployment experiences where 143 warranted. 145 1.1. Applicability Statement 147 This document is applicable to managed networks, i.e., when the 148 network is operated by the user organization itself. Indeed, many of 149 the recommended mitigation techniques must be configured with the 150 detailed knowledge of the network (which are the default router, 151 which are the switch trunk ports, etc.). This covers Service 152 Provider (SP), enterprise networks and some knowledgeable-home-user- 153 managed residential network. This applicability statement especially 154 applies to Section 2.3 and Section 2.5.4. 156 For example, an exception to the generic recommendations of this 157 document is when a residential or enterprise network is multi-homed. 159 2. Generic Security Considerations 161 2.1. Addressing Architecture 163 IPv6 address allocations and overall architecture are an important 164 part of securing IPv6. Initial designs, even if intended to be 165 temporary, tend to last much longer than expected. Although 166 initially IPv6 was thought to make renumbering easy, in practice it 167 may be extremely difficult to renumber without a proper IP Address 168 Management (IPAM) system. [RFC7010] introduces the mechanisms that 169 could be utilized for IPv6 site renumbering and tries to cover most 170 of the explicit issues and requirements associated with IPv6 171 renumbering. 173 A key task for a successful IPv6 deployment is to prepare an 174 addressing plan. Because an abundance of address space is available, 175 structuring an address plan around both services and geographic 176 locations allow address space to become a basis for more structured 177 security policies to permit or deny services between geographic 178 regions. [RFC6177] documents some operational considerations of 179 using different prefix size for address assignments to end sites. 181 A common question is whether companies should use Provider 182 Independent (PI) vs Provider Allocated (PA) space [RFC7381], but from 183 a security perspective there is little difference. However, one 184 aspect to keep in mind is who has administrative ownership of the 185 address space and who is technically responsible if/when there is a 186 need to enforce restrictions on routability of the space, e.g., due 187 to malicious criminal activity originating from it. Relying on PA 188 address may also force the use of NPTv6 and therefore 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). Having by default multiple 197 IPv6 addresses per interface is a major change compared to the unique 198 IPv4 address per interface for hosts (secondary IPv4 addresses are 199 not common); especially for audits (see section Section 2.6.2.3). 201 2.1.1. Use of ULAs 203 Unique Local Addresses (ULAs) [RFC4193] are intended for scenarios 204 where interfaces are not globally reachable, despite being routed 205 within a domain. They formally have global scope, but [RFC4193] 206 specifies that they must be filtered at domain boundaries. ULAs are 207 different from [RFC1918] addresses and have different use cases. One 208 use of ULA is described in [RFC4864], another one is for internal 209 communication stability in networks where external connectivity may 210 came and go (e.g., some ISPs provide ULAs in home networks connected 211 via a cable modem). 213 2.1.2. Point-to-Point Links 215 [RFC6164] in section 5.1 specifies the rationale of using /127 for 216 inter-router point-to-point links; a /127 prevents the ping-pong 217 attack between routers not correctly implementing [RFC4443] and also 218 prevents a DoS attack on the neighbor cache. The previous 219 recommendation of [RFC3627] has been obsoleted and marked Historic by 220 [RFC6547]). 222 Some environments are also using link-local addressing for point-to- 223 point links. While this practice could further reduce the attack 224 surface of infrastructure devices, the operational disadvantages also 225 need to be carefully considered; see also [RFC7404]. 227 2.1.3. Loopback Addresses 229 Many operators reserve a /64 block for all loopback addresses in 230 their infrastructure and allocate a /128 out of this reserved /64 231 prefix for each loopback interface. This practice facilitates 232 configuration of Access Control List (ACL) rules to enforce a 233 security policy for those loopback addresses 235 2.1.4. Stable Addresses 237 When considering how to assign stable addresses (either by static 238 configuration or by pre-provisioned DHCPv6 lease Section 2.1.6), it 239 is necessary to take into consideration the effectiveness of 240 perimeter security in a given environment. 242 There is a trade-off between ease of operation (where some portions 243 of the IPv6 address could be easily recognizable for operational 244 debugging and troubleshooting) versus the risk of trivial scanning 245 used for reconnaissance. [SCANNING] shows that there are 246 scientifically based mechanisms that make scanning for IPv6 reachable 247 nodes more feasible than expected; see also [RFC7707]. 249 Stable addresses also allow easy enforcement of a security policy at 250 the perimeter based on IPv6 addresses. [RFC8520] is a mechanism 251 where the perimeter defense can retrieve security policy template 252 based on the type of internal device. 254 The use of well-known IPv6 addresses (such as ff02::1 for all link- 255 local nodes) or the use of commonly repeated addresses could make it 256 easy to figure out which devices are name servers, routers, or other 257 critical devices; even a simple traceroute will expose most of the 258 routers on a path. There are many scanning techniques possible and 259 operators should not rely on the 'impossible to find because my 260 address is random' paradigm (a.k.a. "security by obscurity"), even if 261 it is common practice to have the stable addresses randomly 262 distributed across /64 subnets and to always use DNS (as IPv6 263 addresses are hard to remember for the human brains). 265 While in some environments obfuscating addresses could be considered 266 an added benefit, it does not preclude enforcement of perimeter rules 267 and that stable addresses follow some logical allocation scheme for 268 ease of operation (as simplicity always helps security). 270 Typical deployments will have a mix of stable and non-stable 271 addresses; the stable addresses being either predicatable (e.g., ::25 272 for a mail server) or obfuscated (i.e., appearing as a random 64-bit 273 number). 275 2.1.5. Temporary Addresses for SLAAC 277 Historically, stateless address autoconfiguration (SLAAC) makes up 278 the globally unique IPv6 address based on an automatically generated 279 64-bit interface identifier (IID) based on the EUI-64 MAC address 280 combined with the /64 prefix (received in the Prefix Information 281 Option (PIO) of the Router Advertisement (RA)). The EUI-64 address 282 is generated from the stable 48-bit MAC address and does not change 283 even if the host moves to another network; this is of course bad for 284 privacy as a host (and its associated user) can be traced from 285 network (home) to network (office or Wi-Fi in hotels)... [RFC8064] 286 recommends against the use of EUI-64 addresses and it must be noted 287 that most host operating systems do not use EUI-64 addresses anymore 288 and rely on either [RFC4941] or [RFC8064]. 290 Randomly generating an interface ID, as described in [RFC4941], is 291 part of SLAAC with so-called privacy extension addresses and is used 292 to address some privacy concerns. Privacy extension addresses, 293 a.k.a., temporary addresses may help to mitigate the correlation of 294 activities of a node within the same network and may also reduce the 295 attack exposure window. But using [RFC4941] privacy extension 296 addresses might prevent the operator from building host specific 297 access control lists (ACLs). The [RFC4941] privacy extension 298 addresses could also be used to obfuscate some malevolent activities 299 and specific user attribution/accountability procedures should be put 300 in place as described in Section 2.6. 302 [RFC8064] combined with the address generation mechanism of [RFC7217] 303 specifies another way to generate an address while still keeping the 304 same IID for each network prefix; this allows SLAAC nodes to always 305 have the same stable IPv6 address on a specific network while having 306 different IPv6 addresses on different networks. 308 In some specific use cases where user accountability is more 309 important than user privacy, network operators may consider disabling 310 SLAAC and relying only on DHCPv6; but not all operating systems 311 support DHCPv6 so some hosts will not get any IPv6 connectivity. 312 Disabling SLAAC and privacy extension addresses can be done for most 313 operating systems by sending RA messages with a hint to get addresses 314 via DHCPv6 by setting the M-bit but also disabling SLAAC by resetting 315 all A-bits in all prefix information options. However, attackers 316 could still find ways to bypass this mechanism if not enforced at the 317 switch/router level. 319 However, in scenarios where anonymity is a strong desire (protecting 320 user privacy is more important than user attribution), privacy 321 extension addresses should be used. When [RFC8064] is available, the 322 stable privacy address is probably a good balance between privacy 323 (among different networks) and security/user attribution (within a 324 network). 326 2.1.6. DHCP and DNS Considerations 328 Even if the use of DHCP is not mandated by [RFC8504], some 329 environments use DHCPv6 to provision addresses and other parameters 330 in order to ensure auditability and traceability (see 331 Section 2.6.1.5) for the limitations of DHCPv6 for auditability. 333 A main security concern is the ability to detect and counteract rogue 334 DHCP servers (Section 2.3.3). It must be noted that as opposed to 335 DHCPv4, DHCPv6 can lease several IPv6 addresses per client. For 336 DHCPv4, the lease is bond to the 'client identifier', which may 337 contain a hardware address, or it may contain another type of 338 identifier, such as a DNS name. For DHCPv6, the lease is bound to 339 the client DHCP Unique ID (DUID) which is also not always bound to 340 the client link-layer address. [RFC7824] describes the privacy 341 issues associated with the use of DHCPv6 by Internet users. The 342 anonymity profiles [RFC7844] are designed for clients that wish to 343 remain anonymous to the visited network. [RFC7707] recommends that 344 DHCPv6 servers issue addresses randomly from a large pool. 346 While there are no fundamental differences with IPv4 and IPv6 DNS 347 security concerns, there are specific considerations in DNS64 348 [RFC6147] environments that need to be understood. Specifically, the 349 interactions and the potential of interference with DNSSEC 350 ([RFC4033]) implementation need to be understood - these are pointed 351 out in more detail in Section 2.7.3.2. 353 2.1.7. Using a /64 per host 355 An interesting approach is using a /64 per host as proposed in 356 [RFC8273] especially in a shared environment. This allows for easier 357 user attribution (typically based on the host MAC address) as its /64 358 prefix is stable even if applications within the host can change 359 their IPv6 address within this /64 prefix. 361 2.1.8. Privacy consideration of Addresses 363 Beside the security aspects of IPv6 addresses, there are also privacy 364 considerations: mainly because they are of global scope and visible 365 globally. [RFC7721] goes into more detail on the privacy 366 considerations for IPv6 addresses by comparing the manually 367 configured IPv6 address, DHCPv6 or SLAAC. 369 2.2. Extension Headers 371 Extension headers are an important difference between IPv4 and IPv6. 372 In IPv4-based packets, it's trivial to find the upper layer protocol 373 type and protocol header, while in IPv6 it is more complex since the 374 extension header chain must be parsed completely (even if not 375 processed) in order to find the upper layer protocol header. IANA 376 has closed the existing empty "Next Header Types" registry to new 377 entries and is redirecting its users to a new "IPv6 Extension Header 378 Types" registry per [RFC7045]. 380 Extension headers have also become a very controversial topic since 381 forwarding nodes that discard packets containing extension headers 382 are known to cause connectivity failures and deployment problems 383 [RFC7872]. Understanding the role of varying extension headers is 384 important and this section enumerates the ones that need careful 385 consideration. 387 A clarification on how intermediate nodes should handle packets with 388 existing or future extension headers is found in [RFC7045]. The 389 uniform TLV format to be used for defining future extension headers 390 is described in [RFC6564]. Sections 5.2 and 5.3 of [RFC8504] provide 391 more information on the processing of extension headers by IPv6 392 nodes. 394 It must also be noted that there is no indication in the IPv6 packet 395 as to whether the Next Protocol field points to an extension header 396 or to a transport header. This may confuse some filtering rules. 398 There is IETF work in progress regarding filtering rules for those 399 extension headers: [I-D.ietf-opsec-ipv6-eh-filtering] for transit 400 routers. 402 2.2.1. Order and Repetition of Extension Headers 404 While [RFC8200] recommends the order and the maximum repetition of 405 extension headers, there are still IPv6 implementations, at the time 406 of writing, which support a non-recommended order of headers (such as 407 ESP before routing) or an illegal repetition of headers (such as 408 multiple routing headers). The same applies for options contained in 409 the extension headers (see [I-D.kampanakis-6man-ipv6-eh-parsing]). 410 In some cases, it has led to nodes crashing when receiving or 411 forwarding wrongly formatted packets. 413 A firewall or edge device should be used to enforce the recommended 414 order and the maximum of occurrences of extension headers. 416 2.2.2. Hop-by-Hop Options Header 418 In the previous IPv6 specification [RFC2460], the hop-by-hop options 419 header, when present in an IPv6 packet, forced all nodes to inspect 420 and possibly process this header. This enabled denial-of-service 421 attacks as most, if not all, routers can not process this kind of 422 packet in hardware but have to process this packet in software hence 423 competing with other software tasks such as handling the control and 424 management planes. 426 Section 4.3 of the current Internet Standard for IPv6, [RFC8200], has 427 taken this attack vector into account and made the processing of hop- 428 by-hop options header by intermediate routers explicitly 429 configurable. 431 2.2.3. Fragment Header 433 The fragment header is used by the source (and only the source) when 434 it has to fragment packets. [RFC7112] and section 4.5 of [RFC8200] 435 explain why it is important that: 437 Firewall and security devices should drop first fragments that do 438 not contain the entire ipv6 header chain (including the transport- 439 layer header); 441 Destination nodes should discard first fragments that do not 442 contain the entire ipv6 header chain (including the transport- 443 layer header). 445 If those requirements are not met, stateless filtering could be 446 bypassed by a hostile party. [RFC6980] applies a stricter rule to 447 Neighbor Discovery Protocol (NDP) by enforcing the drop of fragmented 448 NDP packets. [RFC7113] describes how the RA-guard function described 449 in [RFC6105] should behave in the presence of fragmented RA packets. 451 2.2.4. IP Security Extension Header 453 The IPsec [RFC4301] [RFC4301] extension headers (AH [RFC4302] and ESP 454 [RFC4303]) are required if IPsec is to be utilized for network level 455 security. But IPsec is no more required for normal IPv6 nodes: in 456 the updated IPv6 Nodes Requirement standard 457 IPsec is a 'SHOULD' and not a 'MUST' implement. 459 2.3. Link-Layer Security 461 IPv6 relies heavily on NDP [RFC4861] to perform a variety of link 462 operations such as discovering other nodes on the link, resolving 463 their link-layer addresses, and finding routers on the link. If not 464 secured, NDP is vulnerable to various attacks such as router/neighbor 465 message spoofing, redirect attacks, Duplicate Address Detection (DAD) 466 DoS attacks, etc. Many of these security threats to NDP have been 467 documented in IPv6 ND Trust Models and Threats [RFC3756] and in 468 [RFC6583]. 470 NDP has even issues when the attacker is off-link see the section 471 below Section 2.3.1; but, most of the issues are only when the 472 attacker is on the same link. 474 2.3.1. Neighbor Solicitation Rate Limiting 476 Neighbor Discovery Protocol (NDP) can be vulnerable to remote denial 477 of service (DoS) attacks; for example, when a router is forced to 478 perform address resolution for a large number of unassigned 479 addresses, i.e., a neighbor cache exhaustion attack. This can keep 480 new devices from joining the network or render the last hop router 481 ineffective due to high CPU usage. Easy mitigative steps include 482 rate limiting Neighbor Solicitations, restricting the amount of state 483 reserved for unresolved solicitations, and clever cache/timer 484 management. 486 [RFC6583] discusses the potential for off-link DoS in detail and 487 suggests implementation improvements and operational mitigation 488 techniques that may be used to mitigate or alleviate the impact of 489 such attacks. Here are some feasible mitigation options that can be 490 employed by network operators today: 492 o Ingress filtering of unused addresses by ACL. These require 493 stable configuration of the addresses; for example, allocating the 494 addresses out of a /120 and using a specific ACL to only allow 495 traffic to this /120 (of course, the actual hosts are configured 496 with a /64 prefix for the link). 498 o Tuning of NDP process (where supported). 500 o Using /127 on point-to-point link per [RFC6164]. 502 o Using link-local addresses only on links where there are only 503 routers see [RFC7404] 505 2.3.2. Router and Neighbor Advertisements Filtering 507 2.3.2.1. Router Advertisement Filtering 509 Router Advertisement spoofing is a well-known on-link attack vector 510 and has been extensively documented. The presence of rogue RAs, 511 either unintentional or malicious, can cause partial or complete 512 failure of operation of hosts on an IPv6 link. For example, a host 513 can select an incorrect router address which can be used as on-path 514 attack or can assume wrong prefixes to be used for SLAAC. [RFC6104] 515 summarizes the scenarios in which rogue RAs may be observed and 516 presents a list of possible solutions to the problem. [RFC6105] (RA- 517 Guard) describes a solution framework for the rogue RA problem where 518 network segments are designed around switching devices that are 519 capable of identifying invalid RAs and blocking them before the 520 attack packets actually reach the target nodes. 522 However, several evasion techniques that circumvent the protection 523 provided by RA-Guard have surfaced. A key challenge to this 524 mitigation technique is introduced by IPv6 fragmentation. Attacker 525 can conceal their attack by fragmenting their packets into multiple 526 fragments such that the switching device that is responsible for 527 blocking invalid RAs cannot find all the necessary information to 528 perform packet filtering of the same packet. [RFC7113] describes 529 such evasion techniques and provides advice to RA-Guard implementers 530 such that the aforementioned evasion vectors can be eliminated. 532 Given that the IPv6 Fragmentation Header can be leveraged to 533 circumvent current implementations of RA-Guard, [RFC6980] updates 534 [RFC4861] such that use of the IPv6 Fragmentation Header is forbidden 535 in all Neighbor Discovery messages except "Certification Path 536 Advertisement", thus allowing for simple and effective measures to 537 counter fragmented NDP attacks. 539 2.3.2.2. Neighbor Advertisement Filtering 541 The Source Address Validation Improvements (SAVI) working group has 542 worked on other ways to mitigate the effects of such attacks. 543 [RFC7513] helps in creating bindings between a DHCPv4 [RFC2131] 544 /DHCPv6 [RFC8415] assigned source IP address and a binding anchor 545 [RFC7039] on a SAVI device. Also, [RFC6620] describes how to glean 546 similar bindings when DHCP is not used. The bindings can be used to 547 filter packets generated on the local link with forged source IP 548 addresses. 550 2.3.2.3. Host Isolation 552 Isolating hosts for the NDP traffic canbe done by using a /64 per 553 host Section 2.1.7 as NDP is only relevant within a /64 on-link 554 prefix; 3GPP Section 2.3.4 uses a similar mechanism. 556 A more drastic technique to prevent all NDP attacks is based on 557 isolation of all hosts with specific configurations. Hosts (i.e., 558 all nodes that are not routers) are unable to send data-link layer 559 frames to other hosts, therefore, no host-to-host attacks can happen. 560 This specific setup can be established on some switches or Wi-Fi 561 access points. Of course, this is not always feasible when hosts 562 need to communicate with other hosts. 564 2.3.2.4. NDP Recommendations 566 It is still recommended that RA-Guard and SAVI be employed as a first 567 line of defense against common attack vectors including misconfigured 568 hosts. This recommendation also applies when DHCPv6 is used as RA 569 are used to discover the default router(s) and for on-link prefix 570 determination. This line of defense is most effective when 571 incomplete fragments are dropped by routers and switches as described 572 in Section 2.2.3. The generated log should also be analyzed to 573 identify and act on violations. Network operators should be aware 574 that RA-Guard and SAVI do not work or could even be harmful in 575 specific network configurations (notably when there could be multiple 576 routers). Only trivial cases (e.g., a Wi-Fi network having the 577 routers on the uplink interfaces of the As) should have RA-guard and 578 SAVI enabled by default. 580 2.3.3. Securing DHCP 582 Dynamic Host Configuration Protocol for IPv6 (DHCPv6), as described 583 in [RFC8415], enables DHCP servers to pass configuration parameters 584 such as IPv6 network addresses and other configuration information to 585 IPv6 nodes such as an hostile recursive DNS server. DHCP plays an 586 important role in most large networks by providing robust stateful 587 configuration in the context of automated system provisioning. 589 The two most common threats to DHCP clients come from malicious 590 (a.k.a., rogue) or unintentionally misconfigured DHCP servers. A 591 malicious DHCP server is established with the intent of providing 592 incorrect configuration information to the clients to cause a denial 593 of service attack or to mount on path attack. While unintentional, a 594 misconfigured DHCP server can have the same impact. Additional 595 threats against DHCP are discussed in the security considerations 596 section of [RFC8415]. 598 DHCPv6-Shield, [RFC7610], specifies a mechanism for protecting 599 connected DHCPv6 clients against rogue DHCPv6 servers. This 600 mechanism is based on DHCPv6 packet-filtering at the layer-2 device; 601 i.e., the administrator specifies the interfaces connected to DHCPv6 602 servers. However, extension headers could be leveraged to bypass 603 DHCPv6-Shield unless [RFC7112] is enforced. 605 It is recommended to use DHCPv6-Shield and to analyze the 606 corresponding log messages. 608 2.3.4. 3GPP Link-Layer Security 610 The 3GPP link is a point-to-point like link that has no link-layer 611 address. This implies there can only be an end host (the mobile 612 hand-set) and the first-hop router (i.e., a GPRS Gateway Support Node 613 (GGSN) or a Packet Gateway (PGW)) on that link. The GGSN/PGW never 614 configures a non link-local address on the link using the advertised 615 /64 prefix on it; see Section 2.1.7. The advertised prefix must not 616 be used for on-link determination. There is no need for address 617 resolution on the 3GPP link, since there are no link-layer addresses. 618 Furthermore, the GGSN/PGW assigns a prefix that is unique within each 619 3GPP link that uses IPv6 stateless address autoconfiguration. This 620 avoids the necessity to perform DAD at the network level for every 621 address built by the mobile host. The GGSN/PGW always provides an 622 IID to the cellular host for the purpose of configuring the link- 623 local address and ensures the uniqueness of the IID on the link 624 (i.e., no collisions between its own link-local address and the 625 mobile host's address). 627 The 3GPP link model itself mitigates most of the known NDP-related 628 Denial-of-Service attacks. In practice, the GGSN/PGW only needs to 629 route all traffic to the mobile host that falls under the prefix 630 assigned to it. As there is also a single host on the 3GPP link, 631 there is no need to defend that IPv6 address. 633 See Section 5 of [RFC6459] for a more detailed discussion on the 3GPP 634 link model, NDP on it and the address configuration details. In some 635 mobile network, DHCPv6 and DHCP-PD are also used. 637 2.3.5. Impact of Multicast Traffic 639 IPv6 uses multicast extensively for signaling messages on the local 640 link to avoid broadcast messages for on-the-wire efficiency. 642 The use of multicast has some side effects on wireless networks, such 643 as a negative impact on battery life of smartphones and other 644 battery-operated devices that are connected to such networks. 645 [RFC7772], [RFC6775] (for specific wireless networks) are discussing 646 methods to rate limit RAs and other ND messages on wireless networks 647 in order to address this issue. 649 The use of link-layer multicast addresses (e.g., ff02::1 for the all 650 nodes link-local multicast address) could also be mis-used for an 651 amplification attack. Image, a hostile node sending an ICMPv6 652 ECHO_REQUEST to ff02::1 with a spoofed source address, then, all 653 link-local nodes will reply with ICMPv6 ECHO_REPLY packets to the 654 source address. This could be a DoS for the victim. This attack is 655 purely local to the layer-2 network as packets with a link-local 656 destination are never forwarded by an IPv6 router. 658 This is the reason why large Wi-Fi network deployments limit the use 659 of link-layer multicast either from or to the uplink of the Wi-Fi 660 access point; i.e., Wi-Fi stations cannot send link-local multicast 661 to their direct neighboring Wi-Fi stations. 663 2.3.6. SeND and CGA 665 SEcure Neighbor Discovery (SeND), as described in [RFC3971], is a 666 mechanism that was designed to secure ND messages. This approach 667 involves the use of new NDP options to carry public key-based 668 signatures. Cryptographically Generated Addresses (CGA), as 669 described in [RFC3972], are used to ensure that the sender of a 670 Neighbor Discovery message is the actual "owner" of the claimed IPv6 671 address. A new NDP option, the CGA option, was introduced and is 672 used to carry the public key and associated parameters. Another NDP 673 option, the RSA Signature option, is used to protect all messages 674 relating to neighbor and Router discovery. 676 SeND protects against: 678 o Neighbor Solicitation/Advertisement Spoofing 680 o Neighbor Unreachability Detection Failure 682 o Duplicate Address Detection DoS Attack 684 o Router Solicitation and Advertisement Attacks 686 o Replay Attacks 688 o Neighbor Discovery DoS Attacks 690 SeND does NOT: 692 o Protect statically configured addresses 694 o Protect addresses configured using fixed identifiers (i.e., EUI- 695 64) 697 o Provide confidentiality for NDP communications 699 o Compensate for an unsecured link - SEND does not require that the 700 addresses on the link and Neighbor Advertisements correspond. 702 However, at this time and over a decade since their original 703 specifications, CGA and SeND do not have wide support from widely 704 used end points; hence, their usefulness is limited and should not be 705 relied upon. 707 2.4. Control Plane Security 709 [RFC6192] defines the router control plane and provides detailed 710 guidance to secure it for IPv4 and IPv6 networks. This definition is 711 repeated here for the reader's convenience. Please note that the 712 definition is completely protocol-version agnostic (most of this 713 section applies to IPv6 in the same way as to IPv4). 715 Preamble: IPv6 control plane security is vastly congruent with its 716 IPv4 equivalent with the exception of OSPFv3 authentication 717 (Section 2.4.1) and some packet exceptions (see Section 2.4.3) that 718 are specific to IPv6. 720 Modern router architecture design maintains a strict separation of 721 forwarding and router control plane hardware and software. The 722 router control plane supports routing and management functions. It 723 is generally described as the router architecture hardware and 724 software components for handling packets destined to the device 725 itself, as well as, building and sending packets originated locally 726 on the device. The forwarding plane is typically described as the 727 router architecture hardware and software components responsible for 728 receiving a packet on an incoming interface, performing a lookup to 729 identify the packet's IP next hop and best outgoing interface towards 730 the destination, and forwarding the packet through the appropriate 731 outgoing interface. 733 While the forwarding plane is usually implemented in high-speed 734 hardware, the control plane is implemented by a generic processor 735 (referred to as the router processor (RP)) and cannot process packets 736 at a high rate. Hence, this processor can be attacked by flooding 737 its input queue with more packets than it can process. The control 738 plane processor is then unable to process valid control packets and 739 the router can lose OSPF or BGP adjacencies which can cause a severe 740 network disruption. 742 [RFC6192] provides detailed guidance to protect the router control 743 plane in IPv6 networks. The rest of this section contains simplified 744 guidance. 746 The mitigation techniques are: 748 o To drop non-legit control packet before they are queued to the RP 749 (this can be done by a forwarding plane ACL) and 751 o To rate limit the remaining packets to a rate that the RP can 752 sustain. Protocol specific protection should also be done (for 753 example, a spoofed OSPFv3 packet could trigger the execution of 754 the Dijkstra algorithm, therefore, the frequency of Dijsktra 755 calculations should be also rate limited). 757 This section will consider several classes of control packets: 759 o Control protocols: routing protocols: such as OSPFv3, BGP and by 760 extension Neighbor Discovery and ICMP 762 o Management protocols: SSH, SNMP, NETCONF, RESTCONF, IPFIX, etc 764 o Packet exceptions: normal data packets which requires a specific 765 processing such as generating a packet-too-big ICMP message or 766 processing the hop-by-hop options header. 768 2.4.1. Control Protocols 770 This class includes OSPFv3, BGP, NDP, ICMP. 772 An ingress ACL to be applied on all the router interfaces for packets 773 to be processed by the RP should be configured so as to: 775 o drop OSPFv3 (identified by Next-Header being 89) and RIPng 776 (identified by UDP port 521) packets from a non link-local address 777 (except for OSPFv3 virtual links) 779 o allow BGP (identified by TCP port 179) packets from all BGP 780 neighbors and drop the others 782 o allow all ICMP packets (transit and to the router interfaces) 784 Note: dropping OSPFv3 packets which are authenticated by IPsec could 785 be impossible on some routers whose ACL are unable to parse the IPsec 786 ESP or AH extension headers. 788 Rate limiting of the valid packets should be done. The exact 789 configuration will depend on the available resources of the router 790 (CPU, TCAM, ...). 792 2.4.2. Management Protocols 794 This class includes: SSH, SNMP, RESTCONF, NETCONF, gRPC, syslog, NTP, 795 etc. 797 An ingress ACL to be applied on all the router interfaces (or at 798 ingress interfaces of the security perimeter or by using specific 799 features of the platform) should be configured for packets destined 800 to the RP such as: 802 o Drop packets destined to the routers except those belonging to 803 protocols which are used (for example, permit TCP 22 and drop all 804 when only SSH is used); 806 o Drop packets where the source does not match the security policy, 807 for example if SSH connections should only be originated from the 808 NOC, then the ACL should permit TCP port 22 packets only from the 809 NOC prefix. 811 Rate limiting of the valid packets should be done. The exact 812 configuration will depend on the available resources of the router. 814 2.4.3. Packet Exceptions 816 This class covers multiple cases where a data plane packet is punted 817 to the route processor because it requires specific processing: 819 o generation of an ICMP packet-too-big message when a data plane 820 packet cannot be forwarded because it is too large (required to 821 discover the Path MTU); 823 o generation of an ICMP hop-limit-expired message when a data plane 824 packet cannot be forwarded because its hop-limit field has reached 825 0 (also used by the traceroute utility); 827 o generation of an ICMP destination-unreachable message when a data 828 plane packet cannot be forwarded for any reason; 830 o processing of the hop-by-hop options header, new implementations 831 follow section 4.3 of [RFC8200] where this processing is optional; 833 o or more specific to some router implementation: an oversized 834 extension header chain which cannot be processed by the hardware 835 and force the packet to be punted to the RP. 837 On some routers, not everything can be done by the specialized data 838 plane hardware which requires some packets to be 'punted' to the 839 generic RP. This could include for example the processing of a long 840 extension header chain in order to apply an ACL based on layer-4 841 information. [RFC6980] and more generally [RFC7112] highlight the 842 security implications of oversized extension header chains on routers 843 and updates the original IPv6 specifications, [RFC2460], such that 844 the first fragment of a packet is required to contain the entire IPv6 845 header chain. Those changes are incorporated in the IPv6 standard 846 [RFC8200] 848 An ingress ACL cannot mitigate a control plane attack using these 849 packet exceptions. The only protection for the RP is to limit the 850 rate of those packet exceptions forwarded to the RP, this means that 851 some data plane packets will be dropped without an ICMP message sent 852 to the source which may delay Path MTU discovery and cause drops. 854 In addition to limiting the rate of data plane packets queued to the 855 RP, it is also important to limit the generation rate of ICMP 856 messages. This is important both to preserve RP resources and also 857 to prevent an amplification attack using the router as a reflector. 858 It is worth noting that some platforms implement this rate limiting 859 in hardware. Of course, a consequence of not generating an ICMP 860 message will break some IPv6 mechanisms such as Path MTU discovery or 861 a simple traceroute. 863 2.5. Routing Security 865 Preamble: IPv6 routing security is congruent with IPv4 routing 866 security at the exception of OSPv3 neighbor authentication (see 867 Section 2.5.2). 869 Routing security in general can be broadly divided into three 870 sections: 872 1. Authenticating neighbors/peers 874 2. Securing routing updates between peers 876 3. Route filtering 878 [RFC5082] is also applicable to IPv6 and can ensure that routing 879 protocol packets are coming from the local network; it must also be 880 noted that in IPv6 all interior gateway protocols use link-local 881 addresses. 883 As for IPv4, it is recommended to enable a routing protocol only on 884 interface where it is required. 886 2.5.1. BGP Security 888 As BGP is identical for IPv4 and IPv6 and as [RFC7454] covers all the 889 security aspects for BGP in detail, [RFC7454] is also applicable to 890 IPv6. 892 2.5.2. Authenticating OSPFv3 Neighbors 894 OSPFv3 can rely on IPsec to fulfill the authentication function. 895 However, it should be noted that IPsec support is not standard on all 896 routing platforms. In some cases, this requires specialized hardware 897 that offloads crypto over to dedicated ASICs or enhanced software 898 images (both of which often come with added financial cost) to 899 provide such functionality. An added detail is to determine whether 900 OSPFv3 IPsec implementations use AH or ESP-Null for integrity 901 protection. In early implementations, all OSPFv3 IPsec 902 configurations relied on AH since the details weren't specified in 903 [RFC5340]. However, the document which specifically describes how 904 IPsec should be implemented for OSPFv3 [RFC4552] specifically states 905 that "ESP-Null MUST and AH MAY be implemented" since it follows the 906 overall IPsec standards wording. OSPFv3 can also use normal ESP to 907 encrypt the OSPFv3 payload to provide confidentiality for the routing 908 information. 910 [RFC7166] changes OSPFv3 reliance on IPsec by appending an 911 authentication trailer to the end of the OSPFv3 packets; it does not 912 specifically authenticate the specific originator of an OSPFv3 913 packet; rather, it allows a router to confirm that the packet has 914 been issued by a router that had access to the shared authentication 915 key. 917 With all authentication mechanisms, operators should confirm that 918 implementations can support re-keying mechanisms that do not cause 919 outages. There have been instances where any re-keying cause outages 920 and therefore, the tradeoff between utilizing this functionality 921 needs to be weighed against the protection it provides. 923 2.5.3. Securing Routing Updates 925 IPv6 initially mandated the provisioning of IPsec capability in all 926 nodes. However, in the updated IPv6 Nodes Requirement standard 927 [RFC8504] is a 'SHOULD' and not a 'MUST' implement. Theoretically it 928 is possible that communication between two IPv6 nodes, especially 929 routers exchanging routing information be encrypted using IPsec. In 930 practice however, deploying IPsec is not always feasible given 931 hardware and software limitations of various platforms deployed. 933 2.5.4. Route Filtering 935 Route filtering policies will be different depending on whether they 936 pertain to edge route filtering vs internal route filtering. At a 937 minimum, IPv6 routing policy as it pertains to routing between 938 different administrative domains should aim to maintain parity with 939 IPv4 from a policy perspective, e.g., 941 o Filter internal-use, non-globally routable IPv6 addresses at the 942 perimeter; 944 o Discard routes for bogon [CYMRU] and reserved space (see 945 [RFC8190]); 947 o Configure ingress route filters that validate route origin, prefix 948 ownership, etc. through the use of various routing databases, 949 e.g., [RADB]. There is additional work being done in this area to 950 formally validate the origin ASs of BGP announcements in 951 [RFC8210]. 953 Some good guidance can be found at [RFC7454]. 955 A valid routing table can also be used apply network ingress 956 filtering (see [RFC2827]). 958 2.6. Logging/Monitoring 960 In order to perform forensic research in the cases of a security 961 incidents or detection abnormal behavior, network operators should 962 log multiple pieces of information in some cases this requires a 963 frequent poll of devices via a Network Management Station. 965 This logging should include: 967 o logs of all applications using the network (including user space 968 and kernel space) when available (for example web servers); 970 o data from IP Flow Information Export [RFC7011] also known as 971 IPFIX; 973 o data from various SNMP MIBs [RFC4293] or YANG data via RESTCONF 974 [RFC8040] or NETCONF [RFC6241]; 976 o historical data of Neighbor Cache entries; 978 o stateful DHCPv6 [RFC8415] lease cache, especially when a relay 979 agent [RFC6221] is used; 981 o Source Address Validation Improvement (SAVI) [RFC7039] events, 982 especially the binding of an IPv6 address to a MAC address and a 983 specific switch or router interface; 985 o RADIUS [RFC2866] accounting records. 987 Please note that there are privacy issues or regulations related to 988 how these logs are collected, stored, and safely discarded. 989 Operators are urged to check their country legislation (e.g., General 990 Data Protection Regulation GDPR [GDPR] in the European Union). 992 All those pieces of information can be used for: 994 o forensic (Section 2.6.2.1) investigations such as who did what and 995 when? 997 o correlation (Section 2.6.2.3): which IP addresses were used by a 998 specific node (assuming the use of privacy extensions addresses 999 [RFC4941]) 1001 o inventory (Section 2.6.2.2): which IPv6 nodes are on my network? 1003 o abnormal behavior detection (Section 2.6.2.4): unusual traffic 1004 patterns are often the symptoms of an abnormal behavior which is 1005 in turn a potential attack (denial of service, network scan, a 1006 node being part of a botnet, etc.) 1008 2.6.1. Data Sources 1010 This section lists the most important sources of data that are useful 1011 for operational security. 1013 2.6.1.1. Application Logs 1015 Those logs are usually text files where the remote IPv6 address is 1016 stored in clear text (not binary). This can complicate the 1017 processing since one IPv6 address, for example 2001:db8::1 can be 1018 written in multiple ways, such as: 1020 o 2001:DB8::1 (in uppercase) 1022 o 2001:0db8::0001 (with leading 0) 1024 o and many other ways including the reverse DNS mapping into a FQDN 1025 (which should not be trusted). 1027 [RFC5952] explains this problem in detail and recommends the use of a 1028 single canonical format. This document recommends the use of 1029 canonical format [RFC5952] for IPv6 addresses in all possible cases. 1030 If the existing application cannot log under the canonical format, 1031 then it is recommended to use an external program in order to 1032 canonicalize all IPv6 addresses. 1034 For example, this perl script can be used: 1036 1038 #!/usr/bin/perl -w 1039 use strict ; 1040 use warnings ; 1041 use Socket ; 1042 use Socket6 ; 1044 my (@words, $word, $binary_address) ; 1046 ## go through the file one line at a time 1047 while (my $line = ) { 1048 chomp $line; 1049 foreach my $word (split /[\s+]/, $line) { 1050 $binary_address = inet_pton AF_INET6, $word ; 1051 if ($binary_address) { 1052 print inet_ntop AF_INET6, $binary_address ; 1053 } else { 1054 print $word ; 1055 } 1056 print " " ; 1057 } 1058 print "\n" ; 1059 } 1061 1063 2.6.1.2. IP Flow Information Export by IPv6 Routers 1065 IPFIX [RFC7012] defines some data elements that are useful for 1066 security: 1068 o in section 5.4 (IP Header fields): nextHeaderIPv6 and 1069 sourceIPv6Address; 1071 o in section 5.6 (Sub-IP fields) sourceMacAddress. 1073 The IP version is the ipVersion element defined in [IANA-IPFIX]. 1075 Moreover, IPFIX is very efficient in terms of data handling and 1076 transport. It can also aggregate flows by a key such as 1077 sourceMacAddress in order to have aggregated data associated with a 1078 specific sourceMacAddress. This memo recommends the use of IPFIX and 1079 aggregation on nextHeaderIPv6, sourceIPv6Address, and 1080 sourceMacAddress. 1082 2.6.1.3. SNMP MIB and NETCONF/RESTCONF YANG Modules data by IPv6 1083 Routers 1085 RFC 4293 [RFC4293] defines a Management Information Base (MIB) for 1086 the two address families of IP. This memo recommends the use of: 1088 o ipIfStatsTable table which collects traffic counters per 1089 interface; 1091 o ipNetToPhysicalTable table which is the content of the Neighbor 1092 cache, i.e., the mapping between IPv6 and data-link layer 1093 addresses. 1095 There are also YANG modules about the two IP addresses families and 1096 can be used with [RFC6241] and [RFC8040]. This memo recommends the 1097 use of: 1099 o interfaces-state/interface/statistics from ietf- 1100 interfaces@2018-02-20.yang [RFC8343] which contains counters for 1101 interface . 1103 o ipv6/neighbor from ietf-ip@2018-02-22.yang [RFC8344] which is the 1104 content of the Neighbor cache, i.e., the mapping between IPv6 and 1105 data-link layer addresses. 1107 2.6.1.4. Neighbor Cache of IPv6 Routers 1109 The neighbor cache of routers contains all mappings between IPv6 1110 addresses and data-link layer addresses. There are multiple ways to 1111 collect the current entries in the Neighbor Cache, notably but not 1112 limited to: 1114 o the SNMP MIB (Section 2.6.1.3) as explained above; 1116 o using streaming telemetry or NETCONF [RFC6241] and [RFC8040] to 1117 collect the operational state of the neighbor cache; 1119 o also by connecting over a secure management channel (such as SSH) 1120 and explicitly requesting a neighbor cache dump via the Command 1121 Line Interface or another monitoring mechanism. 1123 The neighbor cache is highly dynamic as mappings are added when a new 1124 IPv6 address appears on the network. This could be quite frequently 1125 with privacy extension addresses [RFC4941] or when they are removed 1126 when the state goes from UNREACH to removed (the default time for a 1127 removal per Neighbor Unreachability Detection [RFC4861] algorithm is 1128 38 seconds for a host using Windows 7). This means that the content 1129 of the neighbor cache must periodically be fetched at an interval 1130 which does not exhaust the router resources and still provides 1131 valuable information (suggested value is 30 seconds but to be checked 1132 in the actual setup) and stored for later use. 1134 This is an important source of information because it is trivial (on 1135 a switch not using the SAVI [RFC7039] algorithm) to defeat the 1136 mapping between data-link layer address and IPv6 address. Let us 1137 rephrase the previous statement: having access to the current and 1138 past content of the neighbor cache has a paramount value for forensic 1139 and audit trail. 1141 When using one /64 per host (Section 2.1.7) or DHCP-PD, it is 1142 sufficient to keep the history of the allocated prefixes when 1143 combined with strict source address prefix enforcement on the routers 1144 and layer-2 switches to prevent IPv6 spoofing. 1146 2.6.1.5. Stateful DHCPv6 Lease 1148 In some networks, IPv6 addresses/prefixes are managed by a stateful 1149 DHCPv6 server [RFC8415] that leases IPv6 addresses/prefixes to 1150 clients. It is indeed quite similar to DHCP for IPv4 so it can be 1151 tempting to use this DHCP lease file to discover the mapping between 1152 IPv6 addresses/prefixes and data-link layer addresses as is commonly 1153 used in IPv4 networking . 1155 It is not so easy in the IPv6 networks because not all nodes will use 1156 DHCPv6 (there are nodes which can only do stateless 1157 autoconfiguration) but also because DHCPv6 clients are identified not 1158 by their hardware-client address as in IPv4 but by a DHCP Unique ID 1159 (DUID) which can have several formats: some being the data-link layer 1160 address, some being data-link layer address prepended with time 1161 information, or even an opaque number which is useless for 1162 operational security. Moreover, when the DUID is based on the data- 1163 link address, this address can be of any client interface (such as 1164 the wireless interface while the client actually uses its wired 1165 interface to connect to the network). 1167 If a lightweight DHCP relay agent [RFC6221] is used in a layer-2 1168 switche, then the DHCP servers also receives the Interface-ID 1169 information which could be saved in order to identify the interface 1170 on which the switch received a specific leased IPv6 address. Also, 1171 if a 'normal' (not lightweight) relay agent adds the data-link layer 1172 address in the option for Relay Agent Remote-ID [RFC4649] or 1173 [RFC6939], then the DHCPv6 server can keep track of the data-link and 1174 leased IPv6 addresses. 1176 In short, the DHCPv6 lease file is less interesting than for IPv4 1177 networks. If possible, it is recommended to use DHCPv6 servers that 1178 keep the relayed data-link layer address in addition to the DUID in 1179 the lease file as those servers have the equivalent information to 1180 IPv4 DHCP servers. 1182 The mapping between data-link layer address and the IPv6 address can 1183 be secured by deploying switches implementing the SAVI [RFC7513] 1184 mechanisms. Of course, this also requires that the data-link layer 1185 address is protected by using a layer-2 mechanism such as 1186 [IEEE-802.1X]. 1188 2.6.1.6. RADIUS Accounting Log 1190 For interfaces where the user is authenticated via a RADIUS [RFC2866] 1191 server, and if RADIUS accounting is enabled, then the RADIUS server 1192 receives accounting Acct-Status-Type records at the start and at the 1193 end of the connection which include all IPv6 (and IPv4) addresses 1194 used by the user. This technique can be used notably for Wi-Fi 1195 networks with Wi-Fi Protected Address (WPA) or any other IEEE 802.1X 1196 [IEEE-802.1X] wired interface on an Ethernet switch. 1198 2.6.1.7. Other Data Sources 1200 There are other data sources for log information that must be 1201 collected (as currently collected as in the IPv4 networks): 1203 o historical mapping of IPv6 addresses to users of remote access 1204 VPN; 1206 o historical mappings of MAC addresses to switch interface in a 1207 wired network. 1209 2.6.2. Use of Collected Data 1211 This section leverages the data collected as described before 1212 (Section 2.6.1) in order to achieve several security benefits. 1213 Section 9.1 of [RFC7934] contains more details about host tracking. 1215 2.6.2.1. Forensic and User Accountability 1217 The forensic use case is when the network operator must locate an 1218 IPv6 address that was present in the network at a certain time or is 1219 still currently in the network. 1221 To locate an IPv6 address in an enterprise network where the operator 1222 has control over all resources, the source of information can be the 1223 neighbor cache, or, if not found, the DHCP lease file. Then, the 1224 procedure is: 1226 1. Based on the IPv6 prefix of the IPv6 address, find the router(s) 1227 which is(are) used to reach this prefix (assuming that anti- 1228 spoofing mechanisms are used). 1230 2. Based on this limited set of routers, on the incident time and on 1231 the IPv6 address, retrieve the data-link address from the live 1232 neighbor cache, from the historical neighbor cache data, or from 1233 SAVI events, or retrieve the data-link address from the DHCP 1234 lease file (Section 2.6.1.5). 1236 3. Based on the data-link layer address, look-up the switch 1237 interface associated with the data-link layer address. In the 1238 case of wireless LAN with RADIUS accounting (see 1239 Section 2.6.1.6), the RADIUS log has the mapping between the user 1240 identification and the MAC address. If a Configuration 1241 Management Data Base (CMDB) is used, then it can be used to map 1242 the data-link layer address to a switch port. 1244 At the end of the process, the interface of the host originating 1245 malicious activity or the username perpetrating the malicious 1246 activity has been determined. 1248 To identify the subscriber of an IPv6 address in a residential 1249 Internet Service Provider, the starting point is the DHCP-PD leased 1250 prefix covering the IPv6 address; this prefix can often be linked to 1251 a subscriber via the RADIUS log. Alternatively, the Forwarding 1252 Information Base of the CMTS or BNG indicates the CPE of the 1253 subscriber and the RADIUS log can be used to retrieve the actual 1254 subscriber. 1256 More generally, a mix of the above techniques can be used in most, if 1257 not all, networks. 1259 2.6.2.2. Inventory 1261 RFC 7707 [RFC7707] describes the difficulties for an attacker to scan 1262 an IPv6 network due to the vast number of IPv6 addresses per link 1263 (and why in some cases it can still be done). While the huge 1264 addressing space can sometimes be perceived as a 'protection', it 1265 also makes the inventory task difficult in an IPv6 network while it 1266 was trivial to do in an IPv4 network (a simple enumeration of all 1267 IPv4 addresses, followed by a ping and a TCP/UDP port scan). Getting 1268 an inventory of all connected devices is of prime importance for a 1269 secure network operation. 1271 There are many ways to do an inventory of an IPv6 network. 1273 The first technique is to use the IPFIX information and extract the 1274 list of all IPv6 source addresses to find all IPv6 nodes that sent 1275 packets through a router. This is very efficient but, alas, will not 1276 discover silent nodes that never transmitted packets traversing the 1277 the IPFIX target router. Also, it must be noted that link-local 1278 addresses will never be discovered by this means. 1280 The second way is again to use the collected neighbor cache content 1281 to find all IPv6 addresses in the cache. This process will also 1282 discover all link-local addresses. See Section 2.6.1.4. 1284 Another way that works only for local network, consists in sending a 1285 ICMP ECHO_REQUEST to the link-local multicast address ff02::1 which 1286 addresses all IPv6 nodes on the network. All nodes should reply to 1287 this ECHO_REQUEST per [RFC4443]. 1289 Other techniques involve obtaining data from DNS, parsing log files, 1290 leveraging service discovery such as mDNS [RFC6762] and [RFC6763]. 1292 Enumerating DNS zones, especially looking at reverse DNS records and 1293 CNAMES, is another common method employed by various tools. As 1294 already mentioned in [RFC7707], this allows an attacker to prune the 1295 IPv6 reverse DNS tree, and hence enumerate it in a feasible time. 1296 Furthermore, authoritative servers that allow zone transfers (AXFR) 1297 may be a further information source. 1299 2.6.2.3. Correlation 1301 In an IPv4 network, it is easy to correlate multiple logs, for 1302 example to find events related to a specific IPv4 address. A simple 1303 Unix grep command is enough to scan through multiple text-based files 1304 and extract all lines relevant to a specific IPv4 address. 1306 In an IPv6 network, this is slightly more difficult because different 1307 character strings can express the same IPv6 address. Therefore, the 1308 simple Unix grep command cannot be used. Moreover, an IPv6 node can 1309 have multiple IPv6 addresses. 1311 In order to do correlation in IPv6-related logs, it is advised to 1312 have all logs in a format with only canonical IPv6 addresses 1313 [RFC5952]. Then, the neighbor cache current (or historical) data set 1314 must be searched to find the data-link layer address of the IPv6 1315 address. Then, the current and historical neighbor cache data sets 1316 must be searched for all IPv6 addresses associated to this data-link 1317 layer address to derive the search set. The last step is to search 1318 in all log files (containing only IPv6 address in canonical format) 1319 for any IPv6 addresses in the search set. 1321 Moreover, [RFC7934] recommends using multiple IPv6 addresses per 1322 prefix, so, the correlation must also be done among those multiple 1323 IPv6 addresses, for example by discovering in the NDP cache 1324 (Section 2.6.1.4) all IPv6 addresses associated with the same MAC 1325 address and interface. 1327 2.6.2.4. Abnormal Behavior Detection 1329 Abnormal behavior (such as network scanning, spamming, denial of 1330 service) can be detected in the same way as in an IPv4 network. 1332 o Sudden increase of traffic detected by interface counter (SNMP) or 1333 by aggregated traffic from IPFIX records [RFC7012]. 1335 o Change in traffic pattern (number of connections per second, 1336 number of connection per host...) with the use of IPFIX [RFC7012]. 1338 2.6.3. Summary 1340 While some data sources (IPFIX, MIB, switch CAM tables, logs, ...) 1341 used in IPv4 are also used in the secure operation of an IPv6 1342 network, the DHCPv6 lease file is less reliable and the neighbor 1343 cache is of prime importance. 1345 The fact that there are multiple ways to express the same IPv6 1346 address in a character string renders the use of filters mandatory 1347 when correlation must be done. 1349 2.7. Transition/Coexistence Technologies 1351 As it is expected that some networks will not run in a pure IPv6-only 1352 mode, the different transition mechanisms must be deployed and 1353 operated in a secure way. This section proposes operational 1354 guidelines for the most known and deployed transition techniques. 1356 2.7.1. Dual Stack 1358 Dual stack is often the first deployment choice for network 1359 operators. Dual stacking the network offers some advantages over 1360 other transition mechanisms. Firstly, the impact on existing IPv4 1361 operations is reduced. Secondly, in the absence of tunnels or 1362 address translation, the IPv4 and IPv6 traffics are native (easier to 1363 observe and secure) and should have the same network processing 1364 (network path, quality of service, ...). Dual stack enables a 1365 gradual termination of the IPv4 operations when the IPv6 network is 1366 ready for prime time. On the other hand, the operators have to 1367 manage two network stacks with the added complexities. 1369 From an operational security perspective, this now means that the 1370 network operator has twice the exposure. One needs to think about 1371 protecting both protocols now. At a minimum, the IPv6 portion of a 1372 dual-stacked network should be consistent with IPv4 from a security 1373 policy point of view. Typically, the following methods are employed 1374 to protect IPv4 networks at the edge or security perimeter: 1376 o ACLs to permit or deny traffic; 1378 o Firewalls with stateful packet inspection. 1380 It is recommended that these ACLs and/or firewalls be additionally 1381 configured to protect IPv6 communications. The enforced IPv6 1382 security must be congruent with the IPv4 security policy, otherwise 1383 the attacker will use the protocol version having the more relaxed 1384 security policy. Maintaining the congruence between security 1385 policies can be challenging (especially over time); it is recommended 1386 to use a firewall or an ACL manager that is dual-stack, i.e., a 1387 system that can apply a single ACL entry to a mixed group of IPv4 and 1388 IPv6 addresses. 1390 Also, given the end-to-end connectivity that IPv6 provides, it is 1391 recommended that hosts be fortified against threats. General device 1392 hardening guidelines are provided in Section 2.8. 1394 For many years, all host operating systems have IPv6 enabled by 1395 default, so, it is possible even in an 'IPv4-only' network to attack 1396 layer-2 adjacent victims via their IPv6 link-local address or via a 1397 global IPv6 address when the attacker provides rogue RAs or a rogue 1398 DHCPv6 service. 1400 [RFC7123] discusses the security implications of native IPv6 support 1401 and IPv6 transition/coexistence technologies on "IPv4-only" networks 1402 and describes possible mitigations for the aforementioned issues. 1404 2.7.2. Encapsulation Mechanisms 1406 There are many tunnels used for specific use cases. Except when 1407 protected by IPsec [RFC4301], all those tunnels have a couple of 1408 security issues as described in RFC 6169 [RFC6169]; 1410 o tunnel injection: a malevolent person knowing a few pieces of 1411 information (for example the tunnel endpoints and the 1412 encapsulation protocol) can forge a packet which looks like a 1413 legit and valid encapsulated packet that will gladly be accepted 1414 by the destination tunnel endpoint, this is a specific case of 1415 spoofing; 1417 o traffic interception: no confidentiality is provided by the tunnel 1418 protocols (without the use of IPsec or alternative encryption 1419 methods), therefore anybody on the tunnel path can intercept the 1420 traffic and have access to the clear-text IPv6 packet; combined 1421 with the absence of authentication, a on-path attack can also be 1422 mounted; 1424 o service theft: as there is no authorization, even a non-authorized 1425 user can use a tunnel relay for free (this is a specific case of 1426 tunnel injection); 1428 o reflection attack: another specific use case of tunnel injection 1429 where the attacker injects packets with an IPv4 destination 1430 address not matching the IPv6 address causing the first tunnel 1431 endpoint to re-encapsulate the packet to the destination... Hence, 1432 the final IPv4 destination will not see the original IPv4 address 1433 but only the IPv4 address of the relay router. 1435 o bypassing security policy: if a firewall or an IPS is on the path 1436 of the tunnel, then it may neither inspect nor detect a malevolent 1437 IPv6 traffic transmitted over the tunnel. 1439 To mitigate the bypassing of security policies, it is recommended to 1440 block all default configuration tunnels by denying IPv4 packets 1441 matching: 1443 o IP protocol 41: this will block ISATAP (Section 2.7.2.2), 6to4 1444 (Section 2.7.2.7), 6rd (Section 2.7.2.3) as well as 6in4 1445 (Section 2.7.2.1) tunnels; 1447 o IP protocol 47: this will block GRE (Section 2.7.2.1) tunnels; 1449 o UDP protocol 3544: this will block the default encapsulation of 1450 Teredo (Section 2.7.2.8) tunnels. 1452 Ingress filtering [RFC2827] should also be applied on all tunnel 1453 endpoints if applicable to prevent IPv6 address spoofing. 1455 As several of the tunnel techniques share the same encapsulation 1456 (i.e., IPv4 protocol 41) and embed the IPv4 address in the IPv6 1457 address, there are a set of well-known looping attacks described in 1458 RFC 6324 [RFC6324], this RFC also proposes mitigation techniques. 1460 2.7.2.1. Site-to-Site Static Tunnels 1462 Site-to-site static tunnels are described in RFC 2529 [RFC2529] and 1463 in GRE [RFC2784]. As the IPv4 endpoints are statically configured 1464 and are not dynamic they are slightly more secure (bi-directional 1465 service theft is mostly impossible) but traffic interception and 1466 tunnel injection are still possible. Therefore, the use of IPsec 1467 [RFC4301] in transport mode and protecting the encapsulated IPv4 1468 packets is recommended for those tunnels. Alternatively, IPsec in 1469 tunnel mode can be used to transport IPv6 traffic over a non-trusted 1470 IPv4 network. 1472 2.7.2.2. ISATAP 1474 ISATAP tunnels [RFC5214] are mainly used within a single 1475 administrative domain and to connect a single IPv6 host to the IPv6 1476 network. This often implies that those systems are usually managed 1477 by a single entity; therefore, audit trail and strict anti-spoofing 1478 are usually possible and this raises the overall security. 1480 Special care must be taken to avoid a looping attack by implementing 1481 the measures of RFC 6324 [RFC6324] and of [RFC6964]. 1483 IPsec [RFC4301] in transport or tunnel mode can be used to secure the 1484 IPv4 ISATAP traffic to provide IPv6 traffic confidentiality and 1485 prevent service theft. 1487 2.7.2.3. 6rd 1489 While 6rd tunnels share the same encapsulation as 6to4 tunnels 1490 (Section 2.7.2.7), they are designed to be used within a single SP 1491 domain, in other words they are deployed in a more constrained 1492 environment than 6to4 tunnels and have few security issues other than 1493 lack of confidentiality. The security considerations (Section 12) of 1494 [RFC5969] describes how to secure 6rd tunnels. 1496 IPsec [RFC4301] for the transported IPv6 traffic can be used if 1497 confidentiality is important. 1499 2.7.2.4. 6PE, 6VPE, and LDPv6 1501 Organizations using MPLS in their core can also use 6PE [RFC4798] and 1502 6VPE [RFC4659] to enable IPv6 access over MPLS. As 6PE and 6VPE are 1503 really similar to BGP/MPLS IP VPN described in [RFC4364], the 1504 security properties of these networks are also similar to those 1505 described in [RFC4381]. It relies on: 1507 o Address space, routing and traffic separation with the help of 1508 VRFs (only applicable to 6VPE); 1510 o Hiding the IPv4 core, hence removing all attacks against 1511 P-routers; 1513 o Securing the routing protocol between CE and PE; in the case of 1514 6PE and 6VPE, link-local addresses (see [RFC7404]) can be used and 1515 as these addresses cannot be reached from outside of the link, the 1516 security of 6PE and 6VPE is even higher than the IPv4 BGP/MPLS IP 1517 VPN. 1519 LDPv6 itself does not induce new risks, see also [RFC7552]. 1521 2.7.2.5. DS-Lite 1523 DS-lite is also a translation mechanism and is therefore analyzed 1524 further (Section 2.7.3.3) in this document as it includes IPv4 NAPT. 1526 2.7.2.6. Mapping of Address and Port 1528 With the encapsulation and translation versions of mapping of Address 1529 and Port (MAP) (MAP-E [RFC7597] and MAP-T [RFC7599]), the access 1530 network is purely an IPv6 network and MAP protocols are used to 1531 connect IPv4 hosts on the subscriber network access to IPv4 hosts on 1532 the Internet. The subscriber router does stateful operations in 1533 order to map all internal IPv4 addresses and layer-4 ports to the 1534 IPv4 address and the set of layer-4 ports received through MAP 1535 configuration process. The SP equipment always does stateless 1536 operations (either decapsulation or stateless translation). 1537 Therefore, as opposed to Section 2.7.3.3 there is no state-exhaustion 1538 DoS attack against the SP equipment because there is no state and 1539 there is no operation caused by a new layer-4 connection (no logging 1540 operation). 1542 The SP MAP equipment should implement all the security considerations 1543 of [RFC7597]; notably, ensuring that the mapping of the IPv4 address 1544 and port are consistent with the configuration. As MAP has a 1545 predictable IPv4 address and port mapping, the audit logs are easier 1546 to manage. 1548 2.7.2.7. 6to4 1550 6to4 tunnels [RFC3056] require a public routable IPv4 address in 1551 order to work correctly. They can be used to provide either single 1552 IPv6 host connectivity to the IPv6 Internet or multiple IPv6 networks 1553 connectivity to the IPv6 Internet. The 6to4 relay was historically 1554 the anycast address defined in [RFC3068] which has been deprecated by 1555 [RFC7526] and is no longer used by recent Operating Systems. Some 1556 security considerations are explained in [RFC3964]. 1558 [RFC6343] points out that if an operator provides well-managed 1559 servers and relays for 6to4, non-encapsulated IPv6 packets will pass 1560 through well-defined points (the native IPv6 interfaces of those 1561 servers and relays) at which security mechanisms may be applied. 1562 Client usage of 6to4 by default is now discouraged, and significant 1563 precautions are needed to avoid operational problems. 1565 2.7.2.8. Teredo 1567 Teredo tunnels [RFC4380] are mainly used in a residential environment 1568 because Teredo easily traverses an IPv4 NAPT device thanks to its UDP 1569 encapsulation. Teredo tunnels connect a single host to the IPv6 1570 Internet. Teredo shares the same issues as other tunnels: no 1571 authentication, no confidentiality, possible spoofing and reflection 1572 attacks. 1574 IPsec [RFC4301] for the transported IPv6 traffic is recommended. 1576 The biggest threat to Teredo is probably for an IPv4-only network as 1577 Teredo has been designed to easily traverse IPV4 NAT-PT devices which 1578 are quite often co-located with a stateful firewall. Therefore, if 1579 the stateful IPv4 firewall allows unrestricted UDP outbound and 1580 accepts the return UDP traffic, then Teredo actually punches a hole 1581 in this firewall for all IPv6 traffic to the Internet and from the 1582 Internet. While host policies can be deployed to block Teredo in an 1583 IPv4-only network in order to avoid this firewall bypass, it would be 1584 enough to block all UDP outbound traffic at the IPv4 firewall if 1585 deemed possible (of course, at least port 53 should be left open for 1586 DNS traffic, port 443 for QUIC, port 500 for IKE, port 3478 for STUN, 1587 i.e., filter judiciously). 1589 Teredo is now hardly never used and no longer enabled by default in 1590 most environments, so, it is less of a threat, however, special 1591 consideration must be taken in case of devices with older or non- 1592 updated operating systems may be present and by default were running 1593 Teredo. 1595 2.7.3. Translation Mechanisms 1597 Translation mechanisms between IPv4 and IPv6 networks are alternate 1598 coexistence strategies while networks transition to IPv6. While a 1599 framework is described in [RFC6144], the specific security 1600 considerations are documented in each individual mechanism. For the 1601 most part, they specifically mention interference with IPsec or 1602 DNSSEC deployments, how to mitigate spoofed traffic, and what some 1603 effective filtering strategies may be. 1605 While not really a transition mechanism to IPv6, this section also 1606 includes the discussion about the use of heavy IPv4-to-IPv4 network 1607 address and port translation to prolong the life of IPv4-only 1608 networks. 1610 2.7.3.1. Carrier-Grade NAT (CGN) 1612 Carrier-Grade NAT (CGN), also called NAT444 CGN or Large Scale NAT 1613 (LSN) or SP NAT is described in [RFC6264] and is utilized as an 1614 interim measure to extend the use of IPv4 in a large service provider 1615 network until the provider can deploy an effective IPv6 solution. 1616 [RFC6598] requested a specific IANA allocated /10 IPv4 address block 1617 to be used as address space shared by all access networks using CGN. 1618 This has been allocated as 100.64.0.0/10. 1620 Section 13 of [RFC6269] lists some specific security-related issues 1621 caused by large scale address sharing. The Security Considerations 1622 section of [RFC6598] also lists some specific mitigation techniques 1623 for potential misuse of shared address space. Some Law Enforcement 1624 Agencies have identified CGN as impeding their cyber-crime 1625 investigations (for example Europol press release on CGN 1626 [europol-cgn]). Many translation techniques (NAT64, DS-lite, ...) 1627 have the same security issues as CGN when one part of the connection 1628 is IPv4-only. 1630 [RFC6302] has recommendations for Internet-facing servers to also log 1631 the source TCP or UDP ports of incoming connections in an attempt to 1632 help identify the users behind such a CGN. 1634 [RFC7422] suggests the use of deterministic address mapping in order 1635 to reduce logging requirements for CGN. The idea is to have a known 1636 algorithm for mapping the internal subscriber to/from public TCP and 1637 UDP ports. 1639 [RFC6888] lists common requirements for CGNs. [RFC6967] analyzes 1640 some solutions to enforce policies on misbehaving nodes when address 1641 sharing is used. [RFC7857] also updates the NAT behavioral 1642 requirements. 1644 2.7.3.2. NAT64/DNS64 and 464XLAT 1646 Stateful NAT64 translation [RFC6146] allows IPv6-only clients to 1647 contact IPv4 servers using unicast UDP, TCP, or ICMP. It can be used 1648 in conjunction with DNS64 [RFC6147], a mechanism which synthesizes 1649 AAAA records from existing A records. There is also a stateless 1650 NAT64 [RFC7915] which is similar for the security aspects with the 1651 added benefit of being stateless, so, less prone to a state 1652 exhaustion attack. 1654 The Security Consideration sections of [RFC6146] and [RFC6147] list 1655 the comprehensive issues. A specific issue with the use of NAT64 is 1656 that it will interfere with most IPsec deployments unless UDP 1657 encapsulation is used. DNSSEC has an impact on DNS64 see section 3.1 1658 of [RFC7050]. 1660 Another translation mechanism relying on a combination of stateful 1661 and stateless translation, 464XLAT [RFC6877], can be used to do host 1662 local translation from IPv4 to IPv6 and a network provider 1663 translation from IPv6 to IPv4, i.e., giving IPv4-only application 1664 access to an IPv4-only server over an IPv6-only network. 464XLAT 1665 shares the same security considerations as NAT64 and DNS64, however 1666 it can be used without DNS64, avoiding the DNSSEC implications. 1668 2.7.3.3. DS-Lite 1670 Dual-Stack Lite (DS-Lite) [RFC6333] is a transition technique that 1671 enables a service provider to share IPv4 addresses among customers by 1672 combining two well-known technologies: IP in IP (IPv4-in-IPv6) and 1673 IPv4 NAPT. 1675 Security considerations with respect to DS-Lite mainly revolve around 1676 logging data, preventing DoS attacks from rogue devices (as the 1677 Address Family Translation Router (AFTR) [RFC6333] function is 1678 stateful and restricting service offered by the AFTR only to 1679 registered customers. 1681 Section 11 of [RFC6333] and section 2 of [RFC7785] describe important 1682 security issues associated with this technology. 1684 2.8. General Device Hardening 1686 With almost all devices being IPv6 enabled by default and with many 1687 end points having IPv6 connectivity to the Internet, it is critical 1688 to also harden those devices against attacks over IPv6. 1690 The following guidelines should be used to ensure appropriate 1691 hardening of the host, be it an individual computer or router, 1692 firewall, load-balancer, server, etc. device. 1694 o Restrict device access to authorized individuals 1696 o Monitor and audit access to the device 1698 o Turn off any unused services on the end node 1700 o Understand which IPv6 addresses are being used to source traffic 1701 and change defaults if necessary 1703 o Use cryptographically protected protocols for device management if 1704 possible (SCP, SNMPv3, SSH, TLS, etc.) 1706 o Use host firewall capabilities to control traffic that gets 1707 processed by upper layer protocols 1709 o Use virus scanners to detect malicious programs 1711 3. Enterprises Specific Security Considerations 1713 Enterprises [RFC7381] generally have robust network security policies 1714 in place to protect existing IPv4 networks. These policies have been 1715 distilled from years of experiential knowledge of securing IPv4 1716 networks. At the very least, it is recommended that enterprise 1717 networks have parity between their security policies for both 1718 protocol versions. This section also applies to the enterprise part 1719 of all SP networs, i.e., the part of the network where the SP 1720 employees are connected. 1722 Security considerations in the enterprise can be broadly categorized 1723 into two sections - External and Internal. 1725 3.1. External Security Considerations 1727 The external aspect deals with providing security at the edge or 1728 perimeter of the enterprise network where it meets the service 1729 providers network. This is commonly achieved by enforcing a security 1730 policy either by implementing dedicated firewalls with stateful 1731 packet inspection or a router with ACLs. A common default IPv4 1732 policy on firewalls that could easily be ported to IPv6 is to allow 1733 all traffic outbound while only allowing specific traffic, such as 1734 established sessions, inbound (see also [RFC6092]). Section 3.2 of 1735 [RFC7381] also provides similar recommendations. 1737 Here are a few more things that could enhance the default policy: 1739 o Filter internal-use IPv6 addresses at the perimeter this will also 1740 mitigate the vulnerabilities listed in [RFC7359] 1742 o Discard packets from and to bogon and reserved space, see also 1743 [CYMRU] and [RFC8190] 1745 o Accept certain ICMPv6 messages to allow proper operation of ND and 1746 PMTUD, see also [RFC4890] or [REY_PF] for hosts 1748 o Filter specific extension headers by accepting only the required 1749 ones (permit list approach) such as ESP, AH (not forgetting the 1750 required transport layers: ICMP, TCP, UDP, ...), where possible at 1751 the edge and possibly inside the perimeter; see also 1752 [I-D.ietf-opsec-ipv6-eh-filtering] 1754 o Filter packets having an illegal IPv6 headers chain at the 1755 perimeter (and if possible, inside the network as well), see 1756 Section 2.2 1758 o Filter unneeded services at the perimeter 1760 o Implement ingress and egress anti-spoofing in the forwarding and 1761 control planes, see [RFC2827] and [RFC3704] 1763 o Implement appropriate rate limiters and control-plane policers 1765 Having global IPv6 address on all the enterprises sites is different 1766 than in IPv4 where [RFC1918] addresses are used internally and not 1767 routed usually over the Internet. [RFC7359] and [WEBER_VPN] explain 1768 that without careful design, there could be IPv6 leakages out of 1769 layer-3 VPN. 1771 3.2. Internal Security Considerations 1773 The internal aspect deals with providing security inside the 1774 perimeter of the network, including end hosts. Internal networks of 1775 enterprises are often different: University campus, wireless guest 1776 access, ... so there is no "one size fits all" recommendations. 1778 The most significant concerns here are related to Neighbor Discovery. 1779 At the network level, it is recommended that all security 1780 considerations discussed in Section 2.3 be reviewed carefully and the 1781 recommendations be considered in-depth as well. Section 4.1 of 1782 [RFC7381] also provides some recommendations. 1784 As mentioned in Section 2.7.2, care must be taken when running 1785 automated IPv6-in-IPv4 tunnels. 1787 When site-to-site VPNs are used it should be kept in mind that, given 1788 the global scope of IPv6 global addresses as opposed to the common 1789 use of IPv4 private address space [RFC1918], sites might be able to 1790 communicate with each other over the Internet even when the VPN 1791 mechanism is not available and hence no traffic encryption is 1792 performed and traffic could be injected from the Internet into the 1793 site, see [WEBER_VPN]. It is recommended to filter at the Internet 1794 connection(s) packets having a source or destination address 1795 belonging to the site internal prefix(es); this should be done for 1796 ingress and egress traffic. 1798 Hosts need to be hardened directly through security policy to protect 1799 against security threats. The host firewall default capabilities 1800 have to be clearly understood. In some cases, 3rd party firewalls 1801 have no IPv6 support whereas the native firewall installed by default 1802 has IPv6 support. General device hardening guidelines are provided 1803 in Section 2.8. 1805 It should also be noted that many hosts still use IPv4 for 1806 transporting logs for RADIUS, DIAMETER, TACACS+, SYSLOG, etc. 1807 Operators cannot rely on an IPv6-only security policy to secure such 1808 protocols that are still using IPv4. 1810 4. Service Providers Security Considerations 1812 4.1. BGP 1814 The threats and mitigation techniques are identical between IPv4 and 1815 IPv6. Broadly speaking they are: 1817 o Authenticating the TCP session; 1819 o TTL security (which becomes hop-limit security in IPv6) as 1820 [RFC5082]; 1822 o bogon AS filtering, see [CYMRU]; 1824 o Prefix filtering. 1826 These are explained in more detail in Section 2.5. Also, the 1827 recommendations of [RFC7454] should be considered. 1829 4.1.1. Remote Triggered Black Hole Filtering 1831 RTBH [RFC5635] works identically in IPv4 and IPv6. IANA has 1832 allocated the 100::/64 prefix to be used as the discard prefix 1833 [RFC6666]. 1835 4.2. Transition/Coexistence Mechanism 1837 SP will typically use transition mechanisms such as 6rd, 6PE, MAP, 1838 NAT64 which have been analyzed in the transition and coexistence 1839 Section 2.7 section. 1841 4.3. Lawful Intercept 1843 The Lawful Intercept requirements are similar for IPv6 and IPv4 1844 architectures and will be subject to the laws enforced in varying 1845 geographic regions. The local issues with each jurisdiction can make 1846 this challenging and both corporate legal and privacy personnel 1847 should be involved in discussions pertaining to what information gets 1848 logged and what the logging retention policies will be. 1850 The target of interception will usually be a residential subscriber 1851 (e.g., his/her PPP session or physical line or CPE MAC address). 1852 With the absence of IPv6 NAT on the CPE, IPv6 has the possibility to 1853 allow for intercepting the traffic from a single host (a /128 target) 1854 rather than the whole set of hosts of a subscriber (which could be a 1855 /48, a /60 or /64). 1857 In contrast, in mobile environments, since the 3GPP specifications 1858 allocate a /64 per device, it may be sufficient to intercept traffic 1859 from the /64 rather than specific /128's (since each time the device 1860 establishes a data connection it gets a new IID). 1862 A sample architecture which was written for informational purposes is 1863 found in [RFC3924]. 1865 5. Residential Users Security Considerations 1867 The IETF Homenet working group is working standards and guidelines 1868 for IPv6 residential networks; this obviously includes operational 1869 security considerations; but this is still work in progress in early 1870 2020. [RFC8520] is an interesting approach on how firewalls could 1871 retrieve and apply specific security policies to some residential 1872 devices. 1874 Some residential users have less experience and knowledge about 1875 security or networking. As most of the recent hosts (e.g., 1876 smartphones, tablets) all have IPv6 enabled by default, IPv6 security 1877 is important for those users. Even with an IPv4-only ISP, those 1878 users can get IPv6 Internet access with the help of Teredo 1879 (Section 2.7.2.8) tunnels. Several peer-to-peer programs support 1880 IPv6 and those programs can initiate a Teredo tunnel through an IPv4 1881 residential gateway, with the consequence of making the internal host 1882 reachable from any IPv6 host on the Internet. It is therefore 1883 recommended that all host security products (including personal 1884 firewalls) are configured with a dual-stack security policy. 1886 If the residential CPE has IPv6 connectivity, [RFC7084] defines the 1887 requirements of an IPv6 CPE and does not take position on the debate 1888 of default IPv6 security policy as defined in [RFC6092]: 1890 o outbound only: allowing all internally initiated connections and 1891 block all externally initiated ones, which is a common default 1892 security policy enforced by IPv4 Residential Gateway doing NAPT 1893 but it also breaks the end-to-end reachability promise of IPv6. 1894 [RFC6092] lists several recommendations to design such a CPE; 1896 o open/transparent: allowing all internally and externally initiated 1897 connections, therefore restoring the end-to-end nature of the 1898 Internet for the IPv6 traffic but having a different security 1899 policy for IPv6 than for IPv4. 1901 [RFC6092] REC-49 states that a choice must be given to the user to 1902 select one of those two policies. 1904 6. Further Reading 1906 There are several documents that describe in more details the 1907 security of an IPv6 network; these documents are not written by the 1908 IETF and some of them are dated but are listed here for the reader's 1909 convenience: 1911 1. Guidelines for the Secure Deployment of IPv6 [NIST] 1913 2. North American IPv6 Task Force Technology Report - IPv6 Security 1914 Technology Paper [NAv6TF_Security] 1916 3. IPv6 Security [IPv6_Security_Book] 1918 7. Acknowledgements 1920 The authors would like to thank the following people for their useful 1921 comments: Mikael Abrahamsson, Fred Baker, Mustafa Suha Botsali, 1922 Mohamed Boucadair, Brian Carpenter, Tim Chown, Lorenzo Colitti, 1923 Markus de Bruen, Tobias Fiebig, Fernando Gont, Jeffry Handal, Lee 1924 Howard, Panos Kampanakis, Erik Kline, Jouni Korhonen, Warren Kumari, 1925 Ted Lemon, Mark Lentczner, Jen Linkova (and her detailed review), 1926 Gyan S. Mishra, Jordi Palet, Bob Sleigh, Donald Smith, Tarko Tikan, 1927 Ole Troan, Bernie Volz (by alphabetical order). 1929 8. Security Considerations 1931 This memo attempts to give an overview of security considerations of 1932 operating an IPv6 network both for an IPv6-only network and for 1933 networks utilizing the most widely deployed IPv4/IPv6 coexistence 1934 strategies. 1936 9. References 1938 9.1. Normative References 1940 [IANA-IPFIX] 1941 IANA, "IP Flow Information Export (IPFIX) Entities", 1942 . 1944 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1945 (IPv6) Specification", STD 86, RFC 8200, 1946 DOI 10.17487/RFC8200, July 2017, 1947 . 1949 9.2. Informative References 1951 [CYMRU] Team, C., "The Bogon Reference", Existing in 2021, 1952 . 1955 [europol-cgn] 1956 Europol, "ARE YOU SHARING THE SAME IP ADDRESS AS A 1957 CRIMINAL? LAW ENFORCEMENT CALL FOR THE END OF CARRIER 1958 GRADE NAT (CGN) TO INCREASE ACCOUNTABILITY ONLINE", 1959 October 2017, 1960 . 1965 [GDPR] Union, O. J. O. T. E., "Regulation (EU) 2016/679 of the 1966 European Parliament and of the Council of 27 April 2016 on 1967 the protection of natural persons with regard to the 1968 processing of personal data and on the free movement of 1969 such data, and repealing Directive 95/46/EC (General Data 1970 Protection Regulation)", April 2016, 1971 . 1973 [I-D.ietf-opsec-ipv6-eh-filtering] 1974 Gont, F. and W. LIU, "Recommendations on the Filtering of 1975 IPv6 Packets Containing IPv6 Extension Headers at Transit 1976 Routers", draft-ietf-opsec-ipv6-eh-filtering-07 (work in 1977 progress), January 2021. 1979 [I-D.kampanakis-6man-ipv6-eh-parsing] 1980 Kampanakis, P., "Implementation Guidelines for parsing 1981 IPv6 Extension Headers", draft-kampanakis-6man-ipv6-eh- 1982 parsing-01 (work in progress), August 2014. 1984 [IEEE-802.1X] 1985 IEEE, "IEEE Standard for Local and metropolitan area 1986 networks - Port-Based Network Access Control", IEEE Std 1987 802.1X-2010, February 2010. 1989 [IPv6_Security_Book] 1990 Hogg, S. and E. Vyncke, "IPv6 Security", 1991 ISBN 1-58705-594-5, Publisher CiscoPress, December 2008. 1993 [NAv6TF_Security] 1994 Kaeo, M., Green, D., Bound, J., and Y. Pouffary, "North 1995 American IPv6 Task Force Technology Report - IPv6 Security 1996 Technology Paper", 2006, 1997 . 2000 [NIST] Frankel, S., Graveman, R., Pearce, J., and M. Rooks, 2001 "Guidelines for the Secure Deployment of IPv6", 2010, 2002 . 2005 [RADB] INC., M. N., "RADb The Internet Routing Registry", 2006 Existing in 2021, . 2008 [REY_PF] Rey, E., "Local Packet Filtering with IPv6", July 2017, 2009 . 2012 [RFC0826] Plummer, D., "An Ethernet Address Resolution Protocol: Or 2013 Converting Network Protocol Addresses to 48.bit Ethernet 2014 Address for Transmission on Ethernet Hardware", STD 37, 2015 RFC 826, DOI 10.17487/RFC0826, November 1982, 2016 . 2018 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 2019 and E. Lear, "Address Allocation for Private Internets", 2020 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 2021 . 2023 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 2024 RFC 2131, DOI 10.17487/RFC2131, March 1997, 2025 . 2027 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 2028 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 2029 December 1998, . 2031 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 2032 Domains without Explicit Tunnels", RFC 2529, 2033 DOI 10.17487/RFC2529, March 1999, 2034 . 2036 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 2037 Translator (NAT) Terminology and Considerations", 2038 RFC 2663, DOI 10.17487/RFC2663, August 1999, 2039 . 2041 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 2042 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 2043 DOI 10.17487/RFC2784, March 2000, 2044 . 2046 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 2047 Defeating Denial of Service Attacks which employ IP Source 2048 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 2049 May 2000, . 2051 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, 2052 DOI 10.17487/RFC2866, June 2000, 2053 . 2055 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 2056 via IPv4 Clouds", RFC 3056, DOI 10.17487/RFC3056, February 2057 2001, . 2059 [RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", 2060 RFC 3068, DOI 10.17487/RFC3068, June 2001, 2061 . 2063 [RFC3627] Savola, P., "Use of /127 Prefix Length Between Routers 2064 Considered Harmful", RFC 3627, DOI 10.17487/RFC3627, 2065 September 2003, . 2067 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 2068 Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March 2069 2004, . 2071 [RFC3756] Nikander, P., Ed., Kempf, J., and E. Nordmark, "IPv6 2072 Neighbor Discovery (ND) Trust Models and Threats", 2073 RFC 3756, DOI 10.17487/RFC3756, May 2004, 2074 . 2076 [RFC3924] Baker, F., Foster, B., and C. Sharp, "Cisco Architecture 2077 for Lawful Intercept in IP Networks", RFC 3924, 2078 DOI 10.17487/RFC3924, October 2004, 2079 . 2081 [RFC3964] Savola, P. and C. Patel, "Security Considerations for 2082 6to4", RFC 3964, DOI 10.17487/RFC3964, December 2004, 2083 . 2085 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 2086 "SEcure Neighbor Discovery (SEND)", RFC 3971, 2087 DOI 10.17487/RFC3971, March 2005, 2088 . 2090 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 2091 RFC 3972, DOI 10.17487/RFC3972, March 2005, 2092 . 2094 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 2095 Rose, "DNS Security Introduction and Requirements", 2096 RFC 4033, DOI 10.17487/RFC4033, March 2005, 2097 . 2099 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 2100 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 2101 . 2103 [RFC4293] Routhier, S., Ed., "Management Information Base for the 2104 Internet Protocol (IP)", RFC 4293, DOI 10.17487/RFC4293, 2105 April 2006, . 2107 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 2108 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 2109 December 2005, . 2111 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 2112 DOI 10.17487/RFC4302, December 2005, 2113 . 2115 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 2116 RFC 4303, DOI 10.17487/RFC4303, December 2005, 2117 . 2119 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 2120 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2121 2006, . 2123 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 2124 Network Address Translations (NATs)", RFC 4380, 2125 DOI 10.17487/RFC4380, February 2006, 2126 . 2128 [RFC4381] Behringer, M., "Analysis of the Security of BGP/MPLS IP 2129 Virtual Private Networks (VPNs)", RFC 4381, 2130 DOI 10.17487/RFC4381, February 2006, 2131 . 2133 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 2134 Control Message Protocol (ICMPv6) for the Internet 2135 Protocol Version 6 (IPv6) Specification", STD 89, 2136 RFC 4443, DOI 10.17487/RFC4443, March 2006, 2137 . 2139 [RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality 2140 for OSPFv3", RFC 4552, DOI 10.17487/RFC4552, June 2006, 2141 . 2143 [RFC4649] Volz, B., "Dynamic Host Configuration Protocol for IPv6 2144 (DHCPv6) Relay Agent Remote-ID Option", RFC 4649, 2145 DOI 10.17487/RFC4649, August 2006, 2146 . 2148 [RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur, 2149 "BGP-MPLS IP Virtual Private Network (VPN) Extension for 2150 IPv6 VPN", RFC 4659, DOI 10.17487/RFC4659, September 2006, 2151 . 2153 [RFC4798] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur, 2154 "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 2155 Provider Edge Routers (6PE)", RFC 4798, 2156 DOI 10.17487/RFC4798, February 2007, 2157 . 2159 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 2160 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 2161 DOI 10.17487/RFC4861, September 2007, 2162 . 2164 [RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and 2165 E. Klein, "Local Network Protection for IPv6", RFC 4864, 2166 DOI 10.17487/RFC4864, May 2007, 2167 . 2169 [RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering 2170 ICMPv6 Messages in Firewalls", RFC 4890, 2171 DOI 10.17487/RFC4890, May 2007, 2172 . 2174 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 2175 Extensions for Stateless Address Autoconfiguration in 2176 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 2177 . 2179 [RFC4942] Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/ 2180 Co-existence Security Considerations", RFC 4942, 2181 DOI 10.17487/RFC4942, September 2007, 2182 . 2184 [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. 2185 Pignataro, "The Generalized TTL Security Mechanism 2186 (GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007, 2187 . 2189 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 2190 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 2191 DOI 10.17487/RFC5214, March 2008, 2192 . 2194 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 2195 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 2196 . 2198 [RFC5635] Kumari, W. and D. McPherson, "Remote Triggered Black Hole 2199 Filtering with Unicast Reverse Path Forwarding (uRPF)", 2200 RFC 5635, DOI 10.17487/RFC5635, August 2009, 2201 . 2203 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 2204 Address Text Representation", RFC 5952, 2205 DOI 10.17487/RFC5952, August 2010, 2206 . 2208 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 2209 Infrastructures (6rd) -- Protocol Specification", 2210 RFC 5969, DOI 10.17487/RFC5969, August 2010, 2211 . 2213 [RFC6092] Woodyatt, J., Ed., "Recommended Simple Security 2214 Capabilities in Customer Premises Equipment (CPE) for 2215 Providing Residential IPv6 Internet Service", RFC 6092, 2216 DOI 10.17487/RFC6092, January 2011, 2217 . 2219 [RFC6104] Chown, T. and S. Venaas, "Rogue IPv6 Router Advertisement 2220 Problem Statement", RFC 6104, DOI 10.17487/RFC6104, 2221 February 2011, . 2223 [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. 2224 Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, 2225 DOI 10.17487/RFC6105, February 2011, 2226 . 2228 [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 2229 IPv4/IPv6 Translation", RFC 6144, DOI 10.17487/RFC6144, 2230 April 2011, . 2232 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 2233 NAT64: Network Address and Protocol Translation from IPv6 2234 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 2235 April 2011, . 2237 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 2238 Beijnum, "DNS64: DNS Extensions for Network Address 2239 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 2240 DOI 10.17487/RFC6147, April 2011, 2241 . 2243 [RFC6164] Kohno, M., Nitzan, B., Bush, R., Matsuzaki, Y., Colitti, 2244 L., and T. Narten, "Using 127-Bit IPv6 Prefixes on Inter- 2245 Router Links", RFC 6164, DOI 10.17487/RFC6164, April 2011, 2246 . 2248 [RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, "Security 2249 Concerns with IP Tunneling", RFC 6169, 2250 DOI 10.17487/RFC6169, April 2011, 2251 . 2253 [RFC6177] Narten, T., Huston, G., and L. Roberts, "IPv6 Address 2254 Assignment to End Sites", BCP 157, RFC 6177, 2255 DOI 10.17487/RFC6177, March 2011, 2256 . 2258 [RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the 2259 Router Control Plane", RFC 6192, DOI 10.17487/RFC6192, 2260 March 2011, . 2262 [RFC6221] Miles, D., Ed., Ooghe, S., Dec, W., Krishnan, S., and A. 2263 Kavanagh, "Lightweight DHCPv6 Relay Agent", RFC 6221, 2264 DOI 10.17487/RFC6221, May 2011, 2265 . 2267 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 2268 and A. Bierman, Ed., "Network Configuration Protocol 2269 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 2270 . 2272 [RFC6264] Jiang, S., Guo, D., and B. Carpenter, "An Incremental 2273 Carrier-Grade NAT (CGN) for IPv6 Transition", RFC 6264, 2274 DOI 10.17487/RFC6264, June 2011, 2275 . 2277 [RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and 2278 P. Roberts, "Issues with IP Address Sharing", RFC 6269, 2279 DOI 10.17487/RFC6269, June 2011, 2280 . 2282 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 2283 Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011, 2284 . 2286 [RFC6302] Durand, A., Gashinsky, I., Lee, D., and S. Sheppard, 2287 "Logging Recommendations for Internet-Facing Servers", 2288 BCP 162, RFC 6302, DOI 10.17487/RFC6302, June 2011, 2289 . 2291 [RFC6324] Nakibly, G. and F. Templin, "Routing Loop Attack Using 2292 IPv6 Automatic Tunnels: Problem Statement and Proposed 2293 Mitigations", RFC 6324, DOI 10.17487/RFC6324, August 2011, 2294 . 2296 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 2297 Stack Lite Broadband Deployments Following IPv4 2298 Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011, 2299 . 2301 [RFC6343] Carpenter, B., "Advisory Guidelines for 6to4 Deployment", 2302 RFC 6343, DOI 10.17487/RFC6343, August 2011, 2303 . 2305 [RFC6459] Korhonen, J., Ed., Soininen, J., Patil, B., Savolainen, 2306 T., Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation 2307 Partnership Project (3GPP) Evolved Packet System (EPS)", 2308 RFC 6459, DOI 10.17487/RFC6459, January 2012, 2309 . 2311 [RFC6547] George, W., "RFC 3627 to Historic Status", RFC 6547, 2312 DOI 10.17487/RFC6547, February 2012, 2313 . 2315 [RFC6564] Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and 2316 M. Bhatia, "A Uniform Format for IPv6 Extension Headers", 2317 RFC 6564, DOI 10.17487/RFC6564, April 2012, 2318 . 2320 [RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational 2321 Neighbor Discovery Problems", RFC 6583, 2322 DOI 10.17487/RFC6583, March 2012, 2323 . 2325 [RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and 2326 M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address 2327 Space", BCP 153, RFC 6598, DOI 10.17487/RFC6598, April 2328 2012, . 2330 [RFC6620] Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS 2331 SAVI: First-Come, First-Served Source Address Validation 2332 Improvement for Locally Assigned IPv6 Addresses", 2333 RFC 6620, DOI 10.17487/RFC6620, May 2012, 2334 . 2336 [RFC6666] Hilliard, N. and D. Freedman, "A Discard Prefix for IPv6", 2337 RFC 6666, DOI 10.17487/RFC6666, August 2012, 2338 . 2340 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 2341 DOI 10.17487/RFC6762, February 2013, 2342 . 2344 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 2345 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 2346 . 2348 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 2349 Bormann, "Neighbor Discovery Optimization for IPv6 over 2350 Low-Power Wireless Personal Area Networks (6LoWPANs)", 2351 RFC 6775, DOI 10.17487/RFC6775, November 2012, 2352 . 2354 [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: 2355 Combination of Stateful and Stateless Translation", 2356 RFC 6877, DOI 10.17487/RFC6877, April 2013, 2357 . 2359 [RFC6888] Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa, 2360 A., and H. Ashida, "Common Requirements for Carrier-Grade 2361 NATs (CGNs)", BCP 127, RFC 6888, DOI 10.17487/RFC6888, 2362 April 2013, . 2364 [RFC6939] Halwasia, G., Bhandari, S., and W. Dec, "Client Link-Layer 2365 Address Option in DHCPv6", RFC 6939, DOI 10.17487/RFC6939, 2366 May 2013, . 2368 [RFC6964] Templin, F., "Operational Guidance for IPv6 Deployment in 2369 IPv4 Sites Using the Intra-Site Automatic Tunnel 2370 Addressing Protocol (ISATAP)", RFC 6964, 2371 DOI 10.17487/RFC6964, May 2013, 2372 . 2374 [RFC6967] Boucadair, M., Touch, J., Levis, P., and R. Penno, 2375 "Analysis of Potential Solutions for Revealing a Host 2376 Identifier (HOST_ID) in Shared Address Deployments", 2377 RFC 6967, DOI 10.17487/RFC6967, June 2013, 2378 . 2380 [RFC6980] Gont, F., "Security Implications of IPv6 Fragmentation 2381 with IPv6 Neighbor Discovery", RFC 6980, 2382 DOI 10.17487/RFC6980, August 2013, 2383 . 2385 [RFC7010] Liu, B., Jiang, S., Carpenter, B., Venaas, S., and W. 2386 George, "IPv6 Site Renumbering Gap Analysis", RFC 7010, 2387 DOI 10.17487/RFC7010, September 2013, 2388 . 2390 [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, 2391 "Specification of the IP Flow Information Export (IPFIX) 2392 Protocol for the Exchange of Flow Information", STD 77, 2393 RFC 7011, DOI 10.17487/RFC7011, September 2013, 2394 . 2396 [RFC7012] Claise, B., Ed. and B. Trammell, Ed., "Information Model 2397 for IP Flow Information Export (IPFIX)", RFC 7012, 2398 DOI 10.17487/RFC7012, September 2013, 2399 . 2401 [RFC7039] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, Ed., 2402 "Source Address Validation Improvement (SAVI) Framework", 2403 RFC 7039, DOI 10.17487/RFC7039, October 2013, 2404 . 2406 [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing 2407 of IPv6 Extension Headers", RFC 7045, 2408 DOI 10.17487/RFC7045, December 2013, 2409 . 2411 [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of 2412 the IPv6 Prefix Used for IPv6 Address Synthesis", 2413 RFC 7050, DOI 10.17487/RFC7050, November 2013, 2414 . 2416 [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic 2417 Requirements for IPv6 Customer Edge Routers", RFC 7084, 2418 DOI 10.17487/RFC7084, November 2013, 2419 . 2421 [RFC7112] Gont, F., Manral, V., and R. Bonica, "Implications of 2422 Oversized IPv6 Header Chains", RFC 7112, 2423 DOI 10.17487/RFC7112, January 2014, 2424 . 2426 [RFC7113] Gont, F., "Implementation Advice for IPv6 Router 2427 Advertisement Guard (RA-Guard)", RFC 7113, 2428 DOI 10.17487/RFC7113, February 2014, 2429 . 2431 [RFC7123] Gont, F. and W. Liu, "Security Implications of IPv6 on 2432 IPv4 Networks", RFC 7123, DOI 10.17487/RFC7123, February 2433 2014, . 2435 [RFC7166] Bhatia, M., Manral, V., and A. Lindem, "Supporting 2436 Authentication Trailer for OSPFv3", RFC 7166, 2437 DOI 10.17487/RFC7166, March 2014, 2438 . 2440 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 2441 Interface Identifiers with IPv6 Stateless Address 2442 Autoconfiguration (SLAAC)", RFC 7217, 2443 DOI 10.17487/RFC7217, April 2014, 2444 . 2446 [RFC7359] Gont, F., "Layer 3 Virtual Private Network (VPN) Tunnel 2447 Traffic Leakages in Dual-Stack Hosts/Networks", RFC 7359, 2448 DOI 10.17487/RFC7359, August 2014, 2449 . 2451 [RFC7381] Chittimaneni, K., Chown, T., Howard, L., Kuarsingh, V., 2452 Pouffary, Y., and E. Vyncke, "Enterprise IPv6 Deployment 2453 Guidelines", RFC 7381, DOI 10.17487/RFC7381, October 2014, 2454 . 2456 [RFC7404] Behringer, M. and E. Vyncke, "Using Only Link-Local 2457 Addressing inside an IPv6 Network", RFC 7404, 2458 DOI 10.17487/RFC7404, November 2014, 2459 . 2461 [RFC7422] Donley, C., Grundemann, C., Sarawat, V., Sundaresan, K., 2462 and O. Vautrin, "Deterministic Address Mapping to Reduce 2463 Logging in Carrier-Grade NAT Deployments", RFC 7422, 2464 DOI 10.17487/RFC7422, December 2014, 2465 . 2467 [RFC7454] Durand, J., Pepelnjak, I., and G. Doering, "BGP Operations 2468 and Security", BCP 194, RFC 7454, DOI 10.17487/RFC7454, 2469 February 2015, . 2471 [RFC7513] Bi, J., Wu, J., Yao, G., and F. Baker, "Source Address 2472 Validation Improvement (SAVI) Solution for DHCP", 2473 RFC 7513, DOI 10.17487/RFC7513, May 2015, 2474 . 2476 [RFC7526] Troan, O. and B. Carpenter, Ed., "Deprecating the Anycast 2477 Prefix for 6to4 Relay Routers", BCP 196, RFC 7526, 2478 DOI 10.17487/RFC7526, May 2015, 2479 . 2481 [RFC7552] Asati, R., Pignataro, C., Raza, K., Manral, V., and R. 2482 Papneja, "Updates to LDP for IPv6", RFC 7552, 2483 DOI 10.17487/RFC7552, June 2015, 2484 . 2486 [RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S., 2487 Murakami, T., and T. Taylor, Ed., "Mapping of Address and 2488 Port with Encapsulation (MAP-E)", RFC 7597, 2489 DOI 10.17487/RFC7597, July 2015, 2490 . 2492 [RFC7599] Li, X., Bao, C., Dec, W., Ed., Troan, O., Matsushima, S., 2493 and T. Murakami, "Mapping of Address and Port using 2494 Translation (MAP-T)", RFC 7599, DOI 10.17487/RFC7599, July 2495 2015, . 2497 [RFC7610] Gont, F., Liu, W., and G. Van de Velde, "DHCPv6-Shield: 2498 Protecting against Rogue DHCPv6 Servers", BCP 199, 2499 RFC 7610, DOI 10.17487/RFC7610, August 2015, 2500 . 2502 [RFC7707] Gont, F. and T. Chown, "Network Reconnaissance in IPv6 2503 Networks", RFC 7707, DOI 10.17487/RFC7707, March 2016, 2504 . 2506 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 2507 Considerations for IPv6 Address Generation Mechanisms", 2508 RFC 7721, DOI 10.17487/RFC7721, March 2016, 2509 . 2511 [RFC7772] Yourtchenko, A. and L. Colitti, "Reducing Energy 2512 Consumption of Router Advertisements", BCP 202, RFC 7772, 2513 DOI 10.17487/RFC7772, February 2016, 2514 . 2516 [RFC7785] Vinapamula, S. and M. Boucadair, "Recommendations for 2517 Prefix Binding in the Context of Softwire Dual-Stack 2518 Lite", RFC 7785, DOI 10.17487/RFC7785, February 2016, 2519 . 2521 [RFC7824] Krishnan, S., Mrugalski, T., and S. Jiang, "Privacy 2522 Considerations for DHCPv6", RFC 7824, 2523 DOI 10.17487/RFC7824, May 2016, 2524 . 2526 [RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity 2527 Profiles for DHCP Clients", RFC 7844, 2528 DOI 10.17487/RFC7844, May 2016, 2529 . 2531 [RFC7857] Penno, R., Perreault, S., Boucadair, M., Ed., Sivakumar, 2532 S., and K. Naito, "Updates to Network Address Translation 2533 (NAT) Behavioral Requirements", BCP 127, RFC 7857, 2534 DOI 10.17487/RFC7857, April 2016, 2535 . 2537 [RFC7872] Gont, F., Linkova, J., Chown, T., and W. Liu, 2538 "Observations on the Dropping of Packets with IPv6 2539 Extension Headers in the Real World", RFC 7872, 2540 DOI 10.17487/RFC7872, June 2016, 2541 . 2543 [RFC7915] Bao, C., Li, X., Baker, F., Anderson, T., and F. Gont, 2544 "IP/ICMP Translation Algorithm", RFC 7915, 2545 DOI 10.17487/RFC7915, June 2016, 2546 . 2548 [RFC7934] Colitti, L., Cerf, V., Cheshire, S., and D. Schinazi, 2549 "Host Address Availability Recommendations", BCP 204, 2550 RFC 7934, DOI 10.17487/RFC7934, July 2016, 2551 . 2553 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 2554 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 2555 . 2557 [RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu, 2558 "Recommendation on Stable IPv6 Interface Identifiers", 2559 RFC 8064, DOI 10.17487/RFC8064, February 2017, 2560 . 2562 [RFC8190] Bonica, R., Cotton, M., Haberman, B., and L. Vegoda, 2563 "Updates to the Special-Purpose IP Address Registries", 2564 BCP 153, RFC 8190, DOI 10.17487/RFC8190, June 2017, 2565 . 2567 [RFC8210] Bush, R. and R. Austein, "The Resource Public Key 2568 Infrastructure (RPKI) to Router Protocol, Version 1", 2569 RFC 8210, DOI 10.17487/RFC8210, September 2017, 2570 . 2572 [RFC8273] Brzozowski, J. and G. Van de Velde, "Unique IPv6 Prefix 2573 per Host", RFC 8273, DOI 10.17487/RFC8273, December 2017, 2574 . 2576 [RFC8343] Bjorklund, M., "A YANG Data Model for Interface 2577 Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, 2578 . 2580 [RFC8344] Bjorklund, M., "A YANG Data Model for IP Management", 2581 RFC 8344, DOI 10.17487/RFC8344, March 2018, 2582 . 2584 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 2585 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 2586 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 2587 RFC 8415, DOI 10.17487/RFC8415, November 2018, 2588 . 2590 [RFC8504] Chown, T., Loughney, J., and T. Winters, "IPv6 Node 2591 Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504, 2592 January 2019, . 2594 [RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage 2595 Description Specification", RFC 8520, 2596 DOI 10.17487/RFC8520, March 2019, 2597 . 2599 [SCANNING] 2600 Barnes, R., Altmann, R., and D. Kerr, "Mapping the Great 2601 Void - Smarter scanning for IPv6", February 2012, 2602 . 2605 [WEBER_VPN] 2606 Weber, J., "Dynamic IPv6 Prefix - Problems and VPNs", 2607 March 2018, . 2611 Authors' Addresses 2613 Eric Vyncke 2614 Cisco 2615 De Kleetlaan 6a 2616 Diegem 1831 2617 Belgium 2619 Phone: +32 2 778 4677 2620 Email: evyncke@cisco.com 2622 Kiran Kumar 2623 WeWork 2624 415 Mission St. 2625 San Francisco 94105 2626 United States of America 2628 Email: kk.chittimaneni@gmail.com 2630 Merike Kaeo 2631 Double Shot Security 2632 3518 Fremont Ave N 363 2633 Seattle 98103 2634 United States of America 2636 Phone: +12066696394 2637 Email: merike@doubleshotsecurity.com 2639 Enno Rey 2640 ERNW 2641 Carl-Bosch-Str. 4 2642 Heidelberg, Baden-Wuertemberg 69115 2643 Germany 2645 Phone: +49 6221 480390 2646 Email: erey@ernw.de