idnits 2.17.1 draft-ietf-opsec-v6-19.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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 22, 2019) is 1676 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-v6ops-ula-usage-considerations' is defined on line 1826, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ietf-opsec-ipv6-eh-filtering-06 == Outdated reference: A later version (-03) exists of draft-ietf-v6ops-ula-usage-considerations-02 -- 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: 0 errors (**), 0 flaws (~~), 5 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OPSEC E. Vyncke, Ed. 3 Internet-Draft Cisco 4 Intended status: Informational K. Chittimaneni 5 Expires: March 25, 2020 WeWork 6 M. Kaeo 7 Double Shot Security 8 E. Rey 9 ERNW 10 September 22, 2019 12 Operational Security Considerations for IPv6 Networks 13 draft-ietf-opsec-v6-19 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 in several 25 places of a network (enterprises, service providers and residential 26 users) and proposes technical and procedural mitigations techniques. 27 Some very specific places of a network such as the Internet of Things 28 are not discussed in this document. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on March 25, 2020. 47 Copyright Notice 49 Copyright (c) 2019 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 66 2. Generic Security Considerations . . . . . . . . . . . . . . . 4 67 2.1. Addressing Architecture . . . . . . . . . . . . . . . . . 4 68 2.1.1. Use of ULAs . . . . . . . . . . . . . . . . . . . . . 4 69 2.1.2. Point-to-Point Links . . . . . . . . . . . . . . . . 5 70 2.1.3. Loopback Addresses . . . . . . . . . . . . . . . . . 5 71 2.1.4. Statically Configured Addresses . . . . . . . . . . . 5 72 2.1.5. Temporary Addresses - Privacy Extensions for SLAAC . 6 73 2.1.6. DHCP/DNS Considerations . . . . . . . . . . . . . . . 7 74 2.1.7. Using a /64 per host . . . . . . . . . . . . . . . . 7 75 2.1.8. Privacy consideration of Addresses . . . . . . . . . 7 76 2.2. Extension Headers . . . . . . . . . . . . . . . . . . . . 7 77 2.2.1. Order and Repetition of Extension Headers . . . . . . 8 78 2.2.2. Hop-by-Hop Options Header . . . . . . . . . . . . . . 8 79 2.2.3. Fragment Header . . . . . . . . . . . . . . . . . . . 9 80 2.2.4. IP Security Extension Header . . . . . . . . . . . . 9 81 2.3. Link-Layer Security . . . . . . . . . . . . . . . . . . . 9 82 2.3.1. ND/RA Rate Limiting . . . . . . . . . . . . . . . . . 9 83 2.3.2. RA/NA Filtering . . . . . . . . . . . . . . . . . . . 10 84 2.3.3. Securing DHCP . . . . . . . . . . . . . . . . . . . . 11 85 2.3.4. 3GPP Link-Layer Security . . . . . . . . . . . . . . 12 86 2.3.5. SeND and CGA . . . . . . . . . . . . . . . . . . . . 13 87 2.4. Control Plane Security . . . . . . . . . . . . . . . . . 14 88 2.4.1. Control Protocols . . . . . . . . . . . . . . . . . . 15 89 2.4.2. Management Protocols . . . . . . . . . . . . . . . . 15 90 2.4.3. Packet Exceptions . . . . . . . . . . . . . . . . . . 16 91 2.5. Routing Security . . . . . . . . . . . . . . . . . . . . 17 92 2.5.1. Authenticating Neighbors/Peers . . . . . . . . . . . 17 93 2.5.2. Securing Routing Updates Between Peers . . . . . . . 18 94 2.5.3. Route Filtering . . . . . . . . . . . . . . . . . . . 18 96 2.6. Logging/Monitoring . . . . . . . . . . . . . . . . . . . 19 97 2.6.1. Data Sources . . . . . . . . . . . . . . . . . . . . 20 98 2.6.2. Use of Collected Data . . . . . . . . . . . . . . . . 24 99 2.6.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 26 100 2.7. Transition/Coexistence Technologies . . . . . . . . . . . 27 101 2.7.1. Dual Stack . . . . . . . . . . . . . . . . . . . . . 27 102 2.7.2. Encapsulation Mechanisms . . . . . . . . . . . . . . 28 103 2.7.3. Translation Mechanisms . . . . . . . . . . . . . . . 32 104 2.8. General Device Hardening . . . . . . . . . . . . . . . . 33 105 3. Enterprises Specific Security Considerations . . . . . . . . 34 106 3.1. External Security Considerations: . . . . . . . . . . . . 34 107 3.2. Internal Security Considerations: . . . . . . . . . . . . 35 108 4. Service Providers Security Considerations . . . . . . . . . . 36 109 4.1. BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 110 4.1.1. Remote Triggered Black Hole Filtering . . . . . . . . 36 111 4.2. Transition Mechanism . . . . . . . . . . . . . . . . . . 36 112 4.3. Lawful Intercept . . . . . . . . . . . . . . . . . . . . 36 113 5. Residential Users Security Considerations . . . . . . . . . . 37 114 6. Further Reading . . . . . . . . . . . . . . . . . . . . . . . 38 115 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 38 116 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 117 9. Security Considerations . . . . . . . . . . . . . . . . . . . 38 118 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 119 10.1. Normative References . . . . . . . . . . . . . . . . . . 38 120 10.2. Informative References . . . . . . . . . . . . . . . . . 39 121 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51 123 1. Introduction 125 Running an IPv6 network is new for most operators not only because 126 they are not yet used to large scale IPv6 networks but also because 127 there are subtle differences between IPv4 and IPv6 especially with 128 respect to security. For example, all layer-2 interactions are now 129 done using Neighbor Discovery Protocol [RFC4861] rather than using 130 Address Resolution Protocol [RFC0826]. 132 IPv6 networks are deployed using a variety of techniques, each of 133 which have their own specific security concerns. 135 This document complements [RFC4942] by listing all security issues 136 when operating a network utilizing varying transition technologies 137 and updating with ones that have been standardized since 2007. It 138 also provides more recent operational deployment experiences where 139 warranted. 141 1.1. Requirements Language 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 145 "OPTIONAL" in this document are to be interpreted as described in BCP 146 14 [RFC2119] [RFC8174] when, and only when, they appear in all 147 capitals, as shown here. 149 2. Generic Security Considerations 151 2.1. Addressing Architecture 153 IPv6 address allocations and overall architecture are an important 154 part of securing IPv6. Initial designs, even if intended to be 155 temporary, tend to last much longer than expected. Although 156 initially IPv6 was thought to make renumbering easy, in practice, it 157 may be extremely difficult to renumber without a proper IP Addresses 158 Management (IPAM) system. 160 A key task before starting an IPv6 deployment, once the sufficient 161 knowledge has been acquired, is to prepare an addressing plan. With 162 the abundance of address space available, an addressing plan may be 163 structured around services along with geographic locations, which 164 then can be a basis for more structured security policies to permit 165 or deny services between geographic regions. 167 A common question is whether companies should use Provider 168 Independent (PI) vs Provider Allocated (PA) space [RFC7381], but from 169 a security perspective there is little difference. However, one 170 aspect to keep in mind is who has administrative ownership of the 171 address space and who is technically responsible if/when there is a 172 need to enforce restrictions on routability of the space e.g. due to 173 malicious criminal activity originating from it. 175 In [RFC7934], it is recommended that IPv6 network deployments provide 176 multiple IPv6 addresses from each prefix to general-purpose hosts and 177 it specifically does not recommend to limit a host to only one IPv6 178 address per prefix. It also recommends that the network give the 179 host the ability to use new addresses without requiring explicit 180 requests (for example by using SLAAC). 182 2.1.1. Use of ULAs 184 Unique Local Addresses (ULAs) [RFC4193] are intended for scenarios 185 where interfaces are not globally reachable, despite being routed 186 within a domain. They formally have global scope, but [RFC4193] 187 specifies that they must be filtered out at domain boundaries. ULAs 188 are different from [RFC1918] addresses and have different use cases. 189 One use of ULA is described in [RFC4864]. 191 2.1.2. Point-to-Point Links 193 [RFC6164] in section 5.1 documents the reasons why it can make sense 194 to use a /127 for inter-router point-to-point links; notably, a /127 195 prevents the ping-pong attack between routers not implementing 196 correctly [RFC4443] and also prevents a DoS attack on the neighbor 197 cache. The previous recommendation of [RFC3627] has been obsoleted 198 and marked Historic by [RFC6547]). 200 Some environments are also using link-local addressing for point-to- 201 point links. While this practice could further reduce the attack 202 surface against infrastructure devices, the operational disadvantages 203 need also to be carefully considered; see also [RFC7404]. 205 2.1.3. Loopback Addresses 207 Many operators reserve a /64 block for all loopback addresses in 208 their infrastructure and allocates a /128 out of this reserved /64 209 prefix for each loopback interface. This practice allows for easy to 210 write Access Control List to enforce a security policy about those 211 loopback addresses. 213 2.1.4. Statically Configured Addresses 215 When considering how to assign statically configured addresses it is 216 necessary to take into consideration the effectiveness of perimeter 217 security in a given environment. There is a trade-off between ease 218 of operation (where some portions of the IPv6 address could be easily 219 recognizable for operational debugging and troubleshooting) versus 220 the risk of trivial scanning used for reconnaissance. [SCANNING] 221 shows that there are scientifically based mechanisms that make 222 scanning for IPv6 reachable nodes more feasible than expected; see 223 also [RFC7707]. The use of well-known (such as ff02::1 for all link- 224 local nodes) or the use of commonly repeated addresses could make it 225 easy to figure out which devices are name servers, routers or other 226 critical devices; even a simple traceroute will expose most of the 227 routers on a path. There are many scanning techniques and more to 228 come possible, hence, operators should not rely on the 'impossible to 229 find because my address is random' paradigm, even if it is common 230 practice to have the statically configured addresses randomly 231 distributed across /64 subnets and to always use DNS. 233 While in some environments obfuscating addresses could be considered 234 an added benefit; it does not preclude that perimeter rules are 235 actively enforced and that statically configured addresses follow 236 some logical allocation scheme for ease of operation (as simplicity 237 always helps security). Typical deployments will have a mix of 238 static and non static addresses. 240 2.1.5. Temporary Addresses - Privacy Extensions for SLAAC 242 Historically stateless address autoconfiguration (SLAAC) relied on an 243 automatically generated 64-bit interface identifier (IID) based on 244 the EUI-64 MAC address, which together with the /64 prefix makes up 245 the globally unique IPv6 address. The EUI-64 address is generated 246 from the 48-bit stable MAC address. [RFC8064] recommends against the 247 use of EUI-64 addresses and it must be noted that most host operating 248 systems do not use EUI-64 addresses anymore and rely on either 249 [RFC4941] or [RFC8064]. 251 Randomly generating an interface ID, as described in [RFC4941], is 252 part of SLAAC with so-called privacy extension addresses and used to 253 address some privacy concerns. Privacy extension addresses a.k.a. 254 temporary addresses may help to mitigate the correlation of 255 activities of a node within the same network, and may also somehow 256 reduce the attack exposure window. 258 Using [RFC4941] privacy extension addresses might prevent the 259 operator from building host specific access control lists (ACLs). As 260 [RFC4941] privacy extension addresses could also be used to obfuscate 261 some malevolent activities (whether on purpose or not), specific user 262 attribution/accountability procedures should be put in place as 263 described in Section 2.6. 265 [RFC8064] specifies another way to generate an address while still 266 keeping the same IID for each network prefix; this allows SLAAC nodes 267 to always have the same stable IPv6 address on a specific network 268 while having different IPv6 address on different networks. 270 In some extreme use cases where user accountability is more important 271 than user privacy, network operators may consider to disable SLAAC 272 and rely only on DHCPv6; but, not all operating systems support 273 DHCPv6 so some hosts will not get any IPv6 connectivity. Disabling 274 SLAAC and privacy extensions addresses can be done for most OS and 275 for non-hacker users by sending RA messages with a hint to get 276 addresses via DHCPv6 by setting the M-bit but also disabling SLAAC by 277 resetting all A-bits in all prefix information options. However 278 attackers could still find ways to bypass this mechanism if not 279 enforced at the switch/ router level. 281 However, in scenarios where anonymity is a strong desire (protecting 282 user privacy is more important than user attribution), privacy 283 extension addresses should be used. When [RFC8064] is available, the 284 stable privacy address is probably a good balance between privacy 285 (among different networks) and security/user attribution (within a 286 network). 288 2.1.6. DHCP/DNS Considerations 290 Many environments use DHCPv6 to provision addresses and other 291 parameters in order to ensure audit-ability and traceability (but see 292 Section 2.6.1.5). A main security concern is the ability to detect 293 and counteract against rogue DHCP servers (Section 2.3.3). It must 294 be noted that as opposed to DHCPv4, DHCPv6 can lease several IPv6 295 addresses per client and the lease is not bound to the link-layer 296 address of the client but to the DHCP Unique ID (DUID) of the client 297 that is not always bound to the client link-layer address. 299 While there are no fundamental differences with IPv4 and IPv6 300 security concerns about DNS, there are specific consideration in 301 DNS64 [RFC6147] environments that need to be understood. 302 Specifically the interactions and the potential of interference with 303 DNSSEC implementation need to be understood - these are pointed out 304 in more detail in Section 2.7.3.2. 306 2.1.7. Using a /64 per host 308 An interesting approach is using a /64 per host as proposed in 309 [RFC8273]. This allows an easier user attribution (typically based 310 on the host MAC address) as its /64 prefix is stable even if 311 applications, containers within the host can change of IPv6 address 312 within this /64. 314 2.1.8. Privacy consideration of Addresses 316 The reader can learn more about privacy considerations for IPv6 317 addresses in [RFC7721]. 319 2.2. Extension Headers 321 The extension headers are an important difference between IPv4 and 322 IPv6. The packet structure does make a big difference. For 323 instance, it's trivial to find (in IPv4-based packets) the upper 324 layer protocol type and protocol header, while in IPv6 it actually 325 isn't as the extension header chain must be parsed completely. The 326 IANA has closed the existing empty "Next Header Types" registry to 327 new entries and is redirecting its users to a new "IPv6 Extension 328 Header Types" registry per [RFC7045]. 330 They have also become a very controversial topic since forwarding 331 nodes that discard packets containing extension headers are known to 332 cause connectivity failures and deployment problems [RFC7872]. 333 Understanding the role of varying extension headers is important and 334 this section enumerates the ones that need careful consideration. 336 A clarification on how intermediate nodes should handle existing 337 packets with extension headers and any extension headers that are 338 defined in the future is found in [RFC7045]. The uniform TLV format 339 to be used for defining future extension headers is described in 340 [RFC6564]. 342 It must also be noted that there is no indication in the packet 343 whether the Next Protocol field points to an extension header or to a 344 transport header. This may confuse some filtering rules. 346 There is work in progress at the IETF about filtering rules for those 347 extension headers: [I-D.ietf-opsec-ipv6-eh-filtering] for transit 348 routers. 350 2.2.1. Order and Repetition of Extension Headers 352 While [RFC8200] recommends the order and the maximum repetition of 353 extension headers, there are still IPv6 implementations at the time 354 of writing this document which support a non-recommended order of 355 headers (such as ESP before routing) or an illegal repetition of 356 headers (such as multiple routing headers). The same applies for 357 options contained in the extension headers (see 358 [I-D.kampanakis-6man-ipv6-eh-parsing]). In some cases, it has led to 359 nodes crashing when receiving or forwarding wrongly formatted 360 packets. 362 A firewall or any edge device should be used to enforce the 363 recommended order and number of occurrences of extension headers. 365 2.2.2. Hop-by-Hop Options Header 367 The hop-by-hop options header, when present in an IPv6 packet, forces 368 all nodes in the path to inspect this header in the original IPv6 369 specification [RFC2460]. This was of course a large avenue for a 370 denial of service as most if not all routers cannot process this kind 371 of packets in hardware but have to 'punt' this packet for software 372 processing. Section 4.3 of the current Internet Standard for IPv6, 373 [RFC8200], is more sensible to this respect as the processing of hop- 374 by-hop options header by intermediate routers is optional. 376 2.2.3. Fragment Header 378 The fragment header is used by the source (and only the source) when 379 it has to fragment packets. [RFC7112] and section 4.5 of [RFC8200] 380 explain why it is important to: 382 firewall and security devices should drop first fragments that do 383 not contain the entire ipv6 header chain (including the transport- 384 layer header); 386 destination nodes should discard first fragments that do not 387 contain the entire ipv6 header chain (including the transport- 388 layer header). 390 Else, stateless filtering could be bypassed by a hostile party. 391 [RFC6980] applies a stricter rule to NDP by enforcing the drop of 392 fragmented NDP packets. [RFC7113] describes how RA-guard function 393 described in [RFC6105] should behave in presence of fragmented RA 394 packets. 396 2.2.4. IP Security Extension Header 398 The IPsec [RFC4301] [RFC4301] extension headers (AH [RFC4302] and ESP 399 [RFC4303]) are required if IPsec is to be utilized for network level 400 security functionality. 402 2.3. Link-Layer Security 404 IPv6 relies heavily on the Neighbor Discovery protocol (NDP) 405 [RFC4861] to perform a variety of link operations such as discovering 406 other nodes on the link, resolving their link-layer addresses, and 407 finding routers on the link. If not secured, NDP is vulnerable to 408 various attacks such as router/neighbor message spoofing, redirect 409 attacks, Duplicate Address Detection (DAD) DoS attacks, etc. many of 410 these security threats to NDP have been documented in IPv6 ND Trust 411 Models and Threats [RFC3756] and in [RFC6583]. 413 2.3.1. ND/RA Rate Limiting 415 Neighbor Discovery (ND) can be vulnerable to denial of service (DoS) 416 attacks in which a router is forced to perform address resolution for 417 a large number of unassigned addresses. Possible side effects of 418 this attack preclude new devices from joining the network or even 419 worse rendering the last hop router ineffective due to high CPU 420 usage. Easy mitigative steps include rate limiting Neighbor 421 Solicitations, restricting the amount of state reserved for 422 unresolved solicitations, and clever cache/timer management. 424 [RFC6583] discusses the potential for DoS in detail and suggests 425 implementation improvements and operational mitigation techniques 426 that may be used to mitigate or alleviate the impact of such attacks. 427 Here are some feasible mitigation options that can be employed by 428 network operators today: 430 o Ingress filtering of unused addresses by ACL. These require 431 static configuration of the addresses; for example, allocating the 432 addresses out of a /120 and using a specific ACL to only allow 433 traffic to this /120 (of course, the actual hosts are configured 434 with a /64 prefix for the link). 436 o Tuning of NDP process (where supported). 438 o Using /127 on point-to-point link per [RFC6164]. 440 o Using link-local addresses only on links where there are only 441 routers see [RFC7404] 443 Additionally, IPv6 ND uses multicast extensively for signaling 444 messages on the local link to avoid broadcast messages for on-the- 445 wire efficiency. However, this has some side effects on wireless 446 networks, especially a negative impact on battery life of smartphones 447 and other battery operated devices that are connected to such 448 networks. The following drafts are actively discussing methods to 449 rate limit RAs and other ND messages on wifi networks in order to 450 address this issue: 452 o [I-D.thubert-savi-ra-throttler] 454 o [I-D.chakrabarti-nordmark-6man-efficient-nd] 456 2.3.2. RA/NA Filtering 458 Router Advertisement spoofing is a well-known attack vector and has 459 been extensively documented. The presence of rogue RAs, either 460 intentional or malicious, can cause partial or complete failure of 461 operation of hosts on an IPv6 link. For example, a host can select 462 an incorrect router address which can be used as a man-in-the-middle 463 (MITM) attack or can assume wrong prefixes to be used for stateless 464 address configuration (SLAAC). [RFC6104] summarizes the scenarios in 465 which rogue RAs may be observed and presents a list of possible 466 solutions to the problem. [RFC6105] (RA-Guard) describes a solution 467 framework for the rogue RA problem where network segments are 468 designed around switching devices that are capable of identifying 469 invalid RAs and blocking them before the attack packets actually 470 reach the target nodes. 472 However, several evasion techniques that circumvent the protection 473 provided by RA-Guard have surfaced. A key challenge to this 474 mitigation technique is introduced by IPv6 fragmentation. An 475 attacker can conceal the attack by fragmenting his packets into 476 multiple fragments such that the switching device that is responsible 477 for blocking invalid RAs cannot find all the necessary information to 478 perform packet filtering in the same packet. [RFC7113] describes 479 such evasion techniques, and provides advice to RA-Guard implementers 480 such that the aforementioned evasion vectors can be eliminated. 482 Given that the IPv6 Fragmentation Header can be leveraged to 483 circumvent current implementations of RA-Guard, [RFC6980] updates 484 [RFC4861] such that use of the IPv6 Fragmentation Header is forbidden 485 in all Neighbor Discovery messages except "Certification Path 486 Advertisement", thus allowing for simple and effective measures to 487 counter Neighbor Discovery attacks. 489 The Source Address Validation Improvements (SAVI) working group has 490 worked on other ways to mitigate the effects of such attacks. 491 [RFC7513] would help in creating bindings between a DHCPv4 [RFC2131] 492 /DHCPv6 [RFC8415] assigned source IP address and a binding anchor 493 [RFC7039] on a SAVI device. Also, [RFC6620] describes how to glean 494 similar bindings when DHCP is not used. The bindings can be used to 495 filter packets generated on the local link with forged source IP 496 address. 498 It is still recommended that RA-Guard and SAVI be employed as a first 499 line of defense against common attack vectors including misconfigured 500 hosts. This line of defense is fully effective when weird fragments 501 are dropped by routers and switches as described in Section 2.2.3. 502 The generated log should also be analyzed to act on violations. 504 A drastic technique to prevent all NDP attacks is based on isolation 505 of all hosts with specific configurations. Hosts (i.e. all nodes 506 that are not routers) are unable to send data-link layer frames to 507 other hosts, therefore no host to host attacks can happen. This 508 specific set-up can be established on some switches or wireless 509 access points. Of course, this is not always easily feasible when 510 hosts need to communicate with other hosts. 512 2.3.3. Securing DHCP 514 Dynamic Host Configuration Protocol for IPv6 (DHCPv6), as detailed in 515 [RFC8415], enables DHCP servers to pass configuration parameters such 516 as IPv6 network addresses and other configuration information to IPv6 517 nodes. DHCP plays an important role in most large networks by 518 providing robust stateful configuration and in the context of 519 automated system provisioning. 521 The two most common threats to DHCP clients come from malicious 522 (a.k.a. rogue) or unintentionally misconfigured DHCP servers. A 523 malicious DHCP server is established with the intent of providing 524 incorrect configuration information to the client to cause a denial 525 of service attack or to mount a-man-in-the-middle attack. While 526 unintentional, a misconfigured DHCP server can have the same impact. 527 Additional threats against DHCP are discussed in the security 528 considerations section of [RFC8415]. 530 [RFC7610], DHCPv6-Shield, specifies a mechanism for protecting 531 connected DHCPv6 clients against rogue DHCPv6 servers. This 532 mechanism is based on DHCPv6 packet-filtering at the layer-2 device; 533 the administrator specifies the interfaces connected to DHCPv6 534 servers. Furthermore, extension headers could be leveraged to bypass 535 DHCPv6-Shield unless [RFC7112] is enforced. 537 It is recommended to use DHCPv6-Shield and to analyze the 538 corresponding log messages. 540 2.3.4. 3GPP Link-Layer Security 542 The 3GPP link is a point-to-point like link that has no link-layer 543 address. This implies there can only be an end host (the mobile 544 hand-set) and the first-hop router (i.e., a GPRS Gateway Support Node 545 (GGSN) or a Packet Gateway (PGW)) on that link. The GGSN/PGW never 546 configures a non link-local address on the link using the advertised 547 /64 prefix on it. The advertised prefix must not be used for on-link 548 determination. There is no need for an address resolution on the 549 3GPP link, since there are no link-layer addresses. Furthermore, the 550 GGSN/PGW assigns a prefix that is unique within each 3GPP link that 551 uses IPv6 stateless address autoconfiguration. This avoids the 552 necessity to perform DAD at the network level for every address built 553 by the mobile host. The GGSN/PGW always provides an IID to the 554 cellular host for the purpose of configuring the link-local address 555 and ensures the uniqueness of the IID on the link (i.e., no 556 collisions between its own link-local address and the mobile host's 557 one). 559 The 3GPP link model itself mitigates most of the known NDP-related 560 Denial-of-Service attacks. In practice, the GGSN/PGW only needs to 561 route all traffic to the mobile host that falls under the prefix 562 assigned to it. As there is also a single host on the 3GPP link, 563 there is no need to defend that IPv6 address. 565 See Section 5 of [RFC6459] for a more detailed discussion on the 3GPP 566 link model, NDP on it and the address configuration details. In some 567 mobile network, DHCPv6 is also used including DHCP-PD. 569 2.3.5. SeND and CGA 571 SEcure Neighbor Discovery (SeND), as described in [RFC3971], is a 572 mechanism that was designed to secure ND messages. This approach 573 involves the use of new NDP options to carry public key based 574 signatures. Cryptographically Generated Addresses (CGA), as 575 described in [RFC3972], are used to ensure that the sender of a 576 Neighbor Discovery message is the actual "owner" of the claimed IPv6 577 address. A new NDP option, the CGA option, was introduced and is 578 used to carry the public key and associated parameters. Another NDP 579 option, the RSA Signature option, is used to protect all messages 580 relating to neighbor and Router discovery. 582 SeND protects against: 584 o Neighbor Solicitation/Advertisement Spoofing 586 o Neighbor Unreachability Detection Failure 588 o Duplicate Address Detection DoS Attack 590 o Router Solicitation and Advertisement Attacks 592 o Replay Attacks 594 o Neighbor Discovery DoS Attacks 596 SeND does NOT: 598 o Protect statically configured addresses 600 o Protect addresses configured using fixed identifiers (i.e. EUI- 601 64) 603 o Provide confidentiality for NDP communications 605 o Compensate for an unsecured link - SEND does not require that the 606 addresses on the link and Neighbor Advertisements correspond 608 However, at this time and after many years after their 609 specifications, CGA and SeND do not have wide support from generic 610 operating systems; hence, their usefulness is limited and should not 611 be relied upon. 613 2.4. Control Plane Security 615 [RFC6192] defines the router control plane. This definition is 616 repeated here for the reader's convenience. Please note that the 617 definition is completely protocol-version agnostic (most of this 618 section applies to IPv6 in the same way as to IPv4). 620 Modern router architecture design maintains a strict separation of 621 forwarding and router control plane hardware and software. The 622 router control plane supports routing and management functions. It 623 is generally described as the router architecture hardware and 624 software components for handling packets destined to the device 625 itself as well as building and sending packets originated locally on 626 the device. The forwarding plane is typically described as the 627 router architecture hardware and software components responsible for 628 receiving a packet on an incoming interface, performing a lookup to 629 identify the packet's IP next hop and determine the best outgoing 630 interface towards the destination, and forwarding the packet out 631 through the appropriate outgoing interface. 633 While the forwarding plane is usually implemented in high-speed 634 hardware, the control plane is implemented by a generic processor 635 (named router processor RP) and cannot process packets at a high 636 rate. Hence, this processor can be attacked by flooding its input 637 queue with more packets than it can process. The control plane 638 processor is then unable to process valid control packets and the 639 router can lose OSPF or BGP adjacencies which can cause a severe 640 network disruption. 642 The mitigation technique is: 644 o To drop non-legit control packet before they are queued to the RP 645 (this can be done by a forwarding plane ACL) and 647 o To rate limit the remaining packets to a rate that the RP can 648 sustain. Protocol specific protection should also be done (for 649 example, a spoofed OSPFv3 packet could trigger the execution of 650 the Dijkstra algorithm, therefore the number of Dijsktra execution 651 should be also rate limited). 653 This section will consider several classes of control packets: 655 o Control protocols: routing protocols: such as OSPFv3, BGP and by 656 extension Neighbor Discovery and ICMP 658 o Management protocols: SSH, SNMP, IPfix, etc 659 o Packet exceptions: which are normal data packets which requires a 660 specific processing such as generating a packet-too-big ICMP 661 message or having the hop-by-hop options header. 663 2.4.1. Control Protocols 665 This class includes OSPFv3, BGP, NDP, ICMP. 667 An ingress ACL to be applied on all the router interfaces SHOULD be 668 configured such as: 670 o drop OSPFv3 (identified by Next-Header being 89) and RIPng 671 (identified by UDP port 521) packets from a non link-local address 673 o allow BGP (identified by TCP port 179) packets from all BGP 674 neighbors and drop the others 676 o allow all ICMP packets (transit and to the router interfaces) 678 Note: dropping OSPFv3 packets which are authenticated by IPsec could 679 be impossible on some routers whose ACL are unable to parse the IPsec 680 ESP or AH extension headers. 682 Rate limiting of the valid packets SHOULD be done. The exact 683 configuration obviously depends on the available ressources of the 684 router (CPU, TCAM, ...). 686 2.4.2. Management Protocols 688 This class includes: SSH, SNMP, syslog, NTP, etc 690 An ingress ACL to be applied on all the router interfaces (or at 691 ingress interfaces of the security perimeter or by using specific 692 features of the platform) SHOULD be configured such as: 694 o Drop packets destined to the routers except those belonging to 695 protocols which are used (for example, permit TCP 22 and drop all 696 when only SSH is used); 698 o Drop packets where the source does not match the security policy, 699 for example if SSH connections should only be originated from the 700 NOC, then the ACL should permit TCP port 22 packets only from the 701 NOC prefix. 703 Rate limiting of the valid packets SHOULD be done. The exact 704 configuration obviously depends on the power of the Route Processor. 706 2.4.3. Packet Exceptions 708 This class covers multiple cases where a data plane packet is punted 709 to the route processor because it requires specific processing: 711 o generation of an ICMP packet-too-big message when a data plane 712 packet cannot be forwarded because it is too large; 714 o generation of an ICMP hop-limit-expired message when a data plane 715 packet cannot be forwarded because its hop-limit field has reached 716 0; 718 o generation of an ICMP destination-unreachable message when a data 719 plane packet cannot be forwarded for any reason; 721 o processing of the hop-by-hop options header, new implementations 722 follow section 4.3 of [RFC8200] where this processing is optional; 724 o or more specific to some router implementation: an oversized 725 extension header chain which cannot be processed by the hardware 726 and force the packet to be punted to the generic router CPU. 728 On some routers, not everything can be done by the specialized data 729 plane hardware which requires some packets to be 'punted' to the 730 generic RP. This could include for example the processing of a long 731 extension header chain in order to apply an ACL based on layer 4 732 information. [RFC6980] and more generally [RFC7112] highlights the 733 security implications of oversized extension header chains on routers 734 and updates the original IPv6 specifications, [RFC2460], such that 735 the first fragment of a packet is required to contain the entire IPv6 736 header chain. Those changes are incorporated in the IPv6 standard 737 [RFC8200] 739 An ingress ACL cannot help to mitigate a control plane attack using 740 those packet exceptions. The only protection for the RP is to limit 741 the rate of those packet exceptions forwarded to the RP, this means 742 that some data plane packets will be dropped without any ICMP 743 messages back to the source which may cause Path MTU holes. 745 In addition to limiting the rate of data plane packets queued to the 746 RP, it is also important to limit the generation rate of ICMP 747 messages both the save the RP but also to prevent an amplification 748 attack using the router as a reflector. It is worth noting that some 749 platforms implement this rate-limiting in hardware. Of course, a 750 consequence of not generating an ICMP message will break some IPv6 751 mechanisms such as Path MTU discovery or a simple traceroute. 753 2.5. Routing Security 755 Routing security in general can be broadly divided into three 756 sections: 758 1. Authenticating neighbors/peers 760 2. Securing routing updates between peers 762 3. Route filtering 764 [RFC7454] covers these sections specifically for BGP in detail. 766 [RFC5082] is also applicable to IPv6 and can ensure that routing 767 protocol packets are coming from the local network; it must also be 768 noted that in IPv6 all interior gateway protocols use link-local 769 addresses. 771 2.5.1. Authenticating Neighbors/Peers 773 A basic element of routing is the process of forming adjacencies, 774 neighbor, or peering relationships with other routers. From a 775 security perspective, it is very important to establish such 776 relationships only with routers and/or administrative domains that 777 one trusts. A traditional approach has been to use MD5 HMAC, which 778 allows routers to authenticate each other prior to establishing a 779 routing relationship. 781 OSPFv3 can rely on IPsec to fulfill the authentication function. 782 However, it should be noted that IPsec support is not standard on all 783 routing platforms. In some cases, this requires specialized hardware 784 that offloads crypto over to dedicated ASICs or enhanced software 785 images (both of which often come with added financial cost) to 786 provide such functionality. An added detail is to determine whether 787 OSPFv3 IPsec implementations use AH or ESP-Null for integrity 788 protection. In early implementations all OSPFv3 IPsec configurations 789 relied on AH since the details weren't specified in [RFC5340]. 790 However, the document which specifically describes how IPsec should 791 be implemented for OSPFv3 [RFC4552] specifically states that ESP-Null 792 MUST and AH MAY be implemented since it follows the overall IPsec 793 standards wordings. OSPFv3 can also use normal ESP to encrypt the 794 OSPFv3 payload to hide the routing information. 796 [RFC7166] changes OSPFv3 reliance on IPsec by appending an 797 authentication trailer to the end of the OSPFv3 packets; it does not 798 specifically authenticate the specific originator of an OSPFv3 799 packet; rather, it allows a router to confirm that the packet has 800 indeed been issued by a router that had access to the shared 801 authentication key. 803 With all authentication mechanisms, operators should confirm that 804 implementations can support re-keying mechanisms that do not cause 805 outages. There have been instances where any re-keying cause outages 806 and therefore the tradeoff between utilizing this functionality needs 807 to be weighed against the protection it provides. 809 As for IPv4, it is recommended to enable a routing protocol only on 810 interface where it is required. 812 2.5.2. Securing Routing Updates Between Peers 814 IPv6 initially mandated the provisioning of IPsec capability in all 815 nodes. However, in the updated IPv6 Nodes Requirement standard 816 [RFC8504] is a 'SHOULD' and no more a 'MUST' implement. 817 Theoretically it is possible that communication between two IPv6 818 nodes, especially routers exchanging routing information be encrypted 819 using IPsec. In practice however, deploying IPsec is not always 820 feasible given hardware and software limitations of various platforms 821 deployed, it has also an operational cost as described in the earlier 822 section. 824 2.5.3. Route Filtering 826 Route filtering policies will be different depending on whether they 827 pertain to edge route filtering vs internal route filtering. At a 828 minimum, IPv6 routing policy as it pertains to routing between 829 different administrative domains should aim to maintain parity with 830 IPv4 from a policy perspective e.g., 832 o Prevent IP source address spoofing when applicable by applying 833 [RFC2827]; 835 o Filter internal-use, non-globally routable IPv6 addresses at the 836 perimeter; 838 o Discard packets from and to bogon and reserved space (see [CYMRU] 839 and [RFC8190]); 841 o Configure ingress route filters that validate route origin, prefix 842 ownership, etc. through the use of various routing databases, 843 e.g., RADB. There is additional work being done in this area to 844 formally validate the origin ASs of BGP announcements in [RFC8210] 846 Some good recommendations for filtering can be found from Team CYMRU 847 at [CYMRU]. [RFC7454] is another valuable resource of guidance in 848 this space. 850 2.6. Logging/Monitoring 852 In order to perform forensic research in case of any security 853 incident or to detect abnormal behaviors, network operators should 854 log multiple pieces of information. 856 This includes: 858 o logs of all applications when available (for example web servers); 860 o use of IP Flow Information Export [RFC7011] also known as IPfix; 862 o use of SNMP MIB [RFC4293]; 864 o use of historical data of Neighbour Cache entries; 866 o use of stateful DHCPv6 [RFC8415] lease cache, especially when a 867 relay agent [RFC6221] is used; 869 o use of Source Address Validation Improvement (SAVI) [RFC7039] 870 events, especially the binding of an IPv6 address to a MAC address 871 and a specific switch or router interface; 873 o use of RADIUS [RFC2866] for accounting records. 875 Please note that there are privacy issues or regulations related to 876 how those logs are collected, kept and safely discarded. Operators 877 are urged to check their country legislation (e.g. GDPR in the 878 European Union). 880 All those pieces of information will be used for: 882 o forensic (Section 2.6.2.1) investigations such as who did what and 883 when? 885 o correlation (Section 2.6.2.3): which IP addresses were used by a 886 specific node (assuming the use of privacy extensions addresses 887 [RFC4941]) 889 o inventory (Section 2.6.2.2): which IPv6 nodes are on my network? 891 o abnormal behavior detection (Section 2.6.2.4): unusual traffic 892 patterns are often the symptoms of a abnormal behavior which is in 893 turn a potential attack (denial of services, network scan, a node 894 being part of a botnet, ...) 896 2.6.1. Data Sources 898 This section lists the most important sources of data that are useful 899 for operational security. 901 2.6.1.1. Logs of Applications 903 Those logs are usually text files where the remote IPv6 address is 904 stored in all characters (not binary). This can complicate the 905 processing since one IPv6 address, for example 2001:db8::1 can be 906 written in multiple ways such as: 908 o 2001:DB8::1 (in uppercase) 910 o 2001:0db8::0001 (with leading 0) 912 o and many other ways including the reverse DNS mapping into a FQDN 913 (which should not be trusted). 915 RFC 5952 [RFC5952] explains this problem in detail and recommends the 916 use of a single canonical format. This document recommends the use 917 of canonical format [RFC5952] for IPv6 addresses in all possible 918 cases. If the existing application cannot log under the canonical 919 format, then it is recommended to use an external program in order to 920 canonicalize all IPv6 addresses. 922 For example, this perl script can be used: 924 #!/usr/bin/perl -w 925 use strict ; 926 use warnings ; 927 use Socket ; 928 use Socket6 ; 930 my (@words, $word, $binary_address) ; 932 ## go through the file one line at a time 933 while (my $line = ) { 934 chomp $line; 935 foreach my $word (split /[\s+]/, $line) { 936 $binary_address = inet_pton AF_INET6, $word ; 937 if ($binary_address) { 938 print inet_ntop AF_INET6, $binary_address ; 939 } else { 940 print $word ; 941 } 942 print " " ; 943 } 944 print "\n" ; 945 } 947 2.6.1.2. IP Flow Information Export by IPv6 Routers 949 IPfix [RFC7012] defines some data elements that are useful for 950 security: 952 o in section 5.4 (IP Header fields): nextHeaderIPv6 and 953 sourceIPv6Address; 955 o in section 5.6 (Sub-IP fields) sourceMacAddress. 957 Moreover, IPfix is very efficient in terms of data handling and 958 transport. It can also aggregate flows by a key such as 959 sourceMacAddress in order to have aggregated data associated with a 960 specific sourceMacAddress. This memo recommends the use of IPfix and 961 aggregation on nextHeaderIPv6, sourceIPv6Address and 962 sourceMacAddress. 964 2.6.1.3. SNMP MIB by IPv6 Routers 966 RFC 4293 [RFC4293] defines a Management Information Base (MIB) for 967 the two address families of IP. This memo recommends the use of: 969 o ipIfStatsTable table which collects traffic counters per 970 interface; 972 o ipNetToPhysicalTable table which is the content of the Neighbor 973 cache, i.e. the mapping between IPv6 and data-link layer 974 addresses. 976 2.6.1.4. Neighbor Cache of IPv6 Routers 978 The neighbor cache of routers contains all mappings between IPv6 979 addresses and data-link layer addresses. There are multiple ways to 980 collect the current entries in the Neighbor Cache, notably but not 981 limited to: 983 o the SNMP MIB (Section 2.6.1.3) as explained above; 985 o using streaming telemetry or NETCONF [RFC6241] to collect the 986 state of the neighbor cache; 988 o also by connecting over a secure management channel (such as SSH) 989 and explicitly requesting a neighbor cache dump via the Command 990 Line Interface or any other monitoring mechanism. 992 The neighbor cache is highly dynamic as mappings are added when a new 993 IPv6 address appears on the network (could be quite often with 994 privacy extension addresses [RFC4941] or when they are removed when 995 the state goes from UNREACH to removed (the default time for a 996 removal per Neighbor Unreachability Detection [RFC4861] algorithm is 997 38 seconds for a typical host such as Windows 7). This means that 998 the content of the neighbor cache must periodically be fetched at an 999 interval which does not exhaust the router ressources and still 1000 provides valuable information (suggested value is 30 seconds but to 1001 be checked in the actual set-up) and stored for later use. 1003 This is an important source of information because it is trivial (on 1004 a switch not using the SAVI [RFC7039] algorithm) to defeat the 1005 mapping between data-link layer address and IPv6 address. Let us 1006 rephrase the previous statement: having access to the current and 1007 past content of the neighbor cache has a paramount value for forensic 1008 and audit trail. 1010 Using the approach of one /64 per host (Section 2.1.7) or DHCP-PD 1011 replace the neighbor cache dumps by a mere caching of the allocated 1012 /64 prefix when combined with strict enforcement rule on the router 1013 and switches to prevent IPv6 spoofing. 1015 2.6.1.5. Stateful DHCPv6 Lease 1017 In some networks, IPv6 addresses/prefixes are managed by stateful 1018 DHCPv6 server [RFC8415] that leases IPv6 addresses/prefixes to 1019 clients. It is indeed quite similar to DHCP for IPv4 so it can be 1020 tempting to use this DHCP lease file to discover the mapping between 1021 IPv6 addresses/prefixes and data-link layer addresses as it was 1022 usually done in the IPv4 era. 1024 It is not so easy in the IPv6 era because not all nodes will use 1025 DHCPv6 (there are nodes which can only do stateless 1026 autoconfiguration) but also because DHCPv6 clients are identified not 1027 by their hardware-client address as in IPv4 but by a DHCP Unique ID 1028 (DUID) which can have several formats: some being the data-link layer 1029 address, some being data-link layer address prepended with time 1030 information or even an opaque number which is useless for operation 1031 security. Moreover, when the DUID is based on the data-link address, 1032 this address can be of any interface of the client (such as the 1033 wireless interface while the client actually uses its wired interface 1034 to connect to the network). 1036 If a lightweight DHCP relay agent [RFC6221] is used in the layer-2 1037 switches, then the DHCP server also receives the Interface-ID 1038 information which could be save in order to identify the interface of 1039 the switches which received a specific leased IPv6 address. Also, if 1040 a 'normal' (not lightweight) relay agent adds the data-link layer 1041 address in the option for Relay Agent Remote-ID [RFC4649] or 1042 [RFC6939], then the DHCPv6 server can keep track of the data-link and 1043 leased IPv6 addresses. 1045 In short, the DHCPv6 lease file is less interesting than in the IPv4 1046 era. DHCPv6 servers that keep the relayed data-link layer address in 1047 addition to the DUID in the lease file do not suffer from this 1048 limitation. 1050 The mapping between data-link layer address and the IPv6 address can 1051 be secured by using switches implementing the SAVI [RFC7513] 1052 algorithms. Of course, this also requires that data-link layer 1053 address is protected by using layer-2 mechanism such as 1054 [IEEE-802.1X]. 1056 2.6.1.6. RADIUS Accounting Log 1058 For interfaces where the user is authenticated via a RADIUS [RFC2866] 1059 server, and if RADIUS accounting is enabled, then the RADIUS server 1060 receives accounting Acct-Status-Type records at the start and at the 1061 end of the connection which include all IPv6 (and IPv4) addresses 1062 used by the user. This technique can be used notably for Wi-Fi 1063 networks with Wi-Fi Protected Address (WPA) or any other IEEE 802.1X 1064 [IEEE-802.1X] wired interface on an Ethernet switch. 1066 2.6.1.7. Other Data Sources 1068 There are other data sources that must be kept exactly as in the IPv4 1069 network: 1071 o historical mapping of IPv6 addresses to users of remote access 1072 VPN; 1074 o historical mapping of MAC address to switch interface in a wired 1075 network. 1077 2.6.2. Use of Collected Data 1079 This section leverages the data collected as described before 1080 (Section 2.6.1) in order to achieve several security benefits. 1081 Section 9.1 of [RFC7934] contains more details about host tracking. 1083 2.6.2.1. Forensic and User Accountability 1085 The forensic use case is when the network operator must locate an 1086 IPv6 address that was present in the network at a certain time or is 1087 still currently in the network. 1089 To locate an IPv6 address in a enterprise network where the operator 1090 has control over all ressources, the source of information can be, in 1091 decreasing order, neighbor cache, DHCP lease file. Then, the 1092 procedure is: 1094 1. based on the IPv6 prefix of the IPv6 address find the router(s) 1095 which is(are) used to reach this prefix (assuming that anti- 1096 spoofing mechanisms are used); 1098 2. based on this limited set of routers, on the incident time and on 1099 IPv6 address to retrieve the data-link address from live neighbor 1100 cache, from the historical data of the neighbor cache or from 1101 SAVI events, or retrieve the data-link address from the DHCP 1102 lease file (Section 2.6.1.5); 1104 3. based on the data-link layer address, look-up on which switch 1105 interface was this data-link layer address. In the case of 1106 wireless LAN, the RADIUS log should have the mapping between user 1107 identification and the MAC address. If a Configuration 1108 Management Data Base (CMDB) is used, the mapping between the 1109 data-link layer address and a switch port. 1111 At the end of the process, the interface the host originating 1112 malicious activity or the username which was abused for malicious 1113 activity has been determined. 1115 To identify the subscriber of an IPv6 address is a residential 1116 Internet Service Provider, the main source will be the DHCP-PD leased 1117 prefix which will often be linked to a subscriber via the RADIUS log. 1118 Alternatively, the Forwarding Information Base of the CMTS or BNG 1119 will indicate the CPE of the subscriber and the RADIUS log can be 1120 used to retrieve the actual subscriber. 1122 More generally, a mix of the above techniques can be used in most if 1123 not all networks. 1125 2.6.2.2. Inventory 1127 RFC 7707 [RFC7707] is about the difficulties for an attacker to scan 1128 an IPv6 network due to the vast number of IPv6 addresses per link 1129 (and why in some case it can still be done). While the huge 1130 addressing space can sometime be perceived as a 'protection', it also 1131 make the inventory task difficult in an IPv6 network while it was 1132 trivial to do in an IPv4 network (a simple enumeration of all IPv4 1133 addresses, followed by a ping and a TCP/UDP port scan). Getting an 1134 inventory of all connected devices is of prime importance for a 1135 secure operation of a network. 1137 There are many ways to do an inventory of an IPv6 network. 1139 The first technique is to use the IPfix information and extract the 1140 list of all IPv6 source addresses to find all IPv6 nodes that sent 1141 packets through a router. This is very efficient but alas will not 1142 discover silent node that never transmitted such packets. Also, it 1143 must be noted that link-local addresses will never be discovered by 1144 this means. 1146 The second way is again to use the collected neighbor cache content 1147 to find all IPv6 addresses in the cache. This process will also 1148 discover all link-local addresses. See Section 2.6.1.4. 1150 Another way works only for local network, it consists in sending a 1151 ICMP ECHO_REQUEST to the link-local multicast address ff02::1 which 1152 is all IPv6 nodes on the network. All nodes should reply to this 1153 ECHO_REQUEST per [RFC4443]. 1155 Other techniques involve obtaining data from DNS, parsing log files, 1156 leveraging service discovery such as mDNS [RFC6762] and [RFC6763]. 1158 Enumerating DNS zones, especially looking at reverse DNS records and 1159 CNAMES, is another common method employed by various tools. As 1160 already mentioned in [RFC7707], this allows an attacker to prune the 1161 IPv6 reverse DNS tree, and hence enumerate it in a feasible time. 1163 Furthermore, authoritative servers that allow zone transfers (AXFR) 1164 may be a further information source. 1166 2.6.2.3. Correlation 1168 In an IPv4 network, it is easy to correlate multiple logs, for 1169 example to find events related to a specific IPv4 address. A simple 1170 Unix grep command was enough to scan through multiple text-based 1171 files and extract all lines relevant to a specific IPv4 address. 1173 In an IPv6 network, this is slightly more difficult because different 1174 character strings can express the same IPv6 address. Therefore, the 1175 simple Unix grep command cannot be used. Moreover, an IPv6 node can 1176 have multiple IPv6 addresses. 1178 In order to do correlation in IPv6-related logs, it is advised to 1179 have all logs with canonical IPv6 addresses. Then, the neighbor 1180 cache current (or historical) data set must be searched to find the 1181 data-link layer address of the IPv6 address. Then, the current and 1182 historical neighbor cache data sets must be searched for all IPv6 1183 addresses associated to this data-link layer address: this is the 1184 search set. The last step is to search in all log files (containing 1185 only IPv6 address in canonical format) for any IPv6 addresses in the 1186 search set. 1188 Moreover, [RFC7934] recommends to use multiple IPv6 addresses per 1189 prefix, so, the correlation must also be done among those multiple 1190 IPv6 addresses, for example by discovering in the NDP cache 1191 (Section 2.6.1.4) all IPv6 addresses associated with the same MAC 1192 address and interface. 1194 2.6.2.4. Abnormal Behavior Detection 1196 Abnormal behaviors (such as network scanning, spamming, denial of 1197 service) can be detected in the same way as in an IPv4 network 1199 o sudden increase of traffic detected by interface counter (SNMP) or 1200 by aggregated traffic from IPfix records [RFC7012]; 1202 o change of traffic pattern (number of connection per second, number 1203 of connection per host...) with the use of IPfix [RFC7012] 1205 2.6.3. Summary 1207 While some data sources (IPfix, MIB, switch CAM tables, logs, ...) 1208 used in IPv4 are also used in the secure operation of an IPv6 1209 network, the DHCPv6 lease file is less reliable and the neighbor 1210 cache is of prime importance. 1212 The fact that there are multiple ways to express in a character 1213 string the same IPv6 address renders the use of filters mandatory 1214 when correlation must be done. 1216 2.7. Transition/Coexistence Technologies 1218 As it is expected that some networks will not run in a pure IPv6-only 1219 way, the different transition mechanisms must be deployed and 1220 operated in a secure way. This section proposes operational 1221 guidelines for the most known and deployed transition techniques. 1223 2.7.1. Dual Stack 1225 Dual stack is often the first deployment choice for network 1226 operators. Dual stacking the network offers some advantages over 1227 other transition mechanisms. Firstly, the impact on existing IPv4 1228 operations is reduced. Secondly, in the absence of tunnels or 1229 address translation, the IPv4 and IPv6 traffics are native (easier to 1230 observe and secure) and should have the same network processing 1231 (path, quality of service, ...). Dual stack allows to gradually turn 1232 IPv4 operations off when your IPv6 network is ready for prime time. 1233 On the other hand, the operators have to manage two network stacks 1234 with the added complexities. 1236 From an operational security perspective, this now means that you 1237 have twice the exposure. One needs to think about protecting both 1238 protocols now. At a minimum, the IPv6 portion of a dual stacked 1239 network should maintain parity with IPv4 from a security policy point 1240 of view. Typically, the following methods are employed to protect 1241 IPv4 networks at the edge or security perimeter: 1243 o ACLs to permit or deny traffic; 1245 o Firewalls with stateful packet inspection. 1247 It is recommended that these ACLs and/or firewalls be additionally 1248 configured to protect IPv6 communications. The enforced IPv6 1249 security must be congruent with the IPv4 security policy, else the 1250 attacker will use the protocol version having the more relax security 1251 policy. Maintaining the congruence between security policies can be 1252 challenging (especially over time); it is recommended to use a 1253 firewall or an ACL manager that is dual-stack, i.e., a system that 1254 can apply a single ACL entry to a mixed group of IPv4 and IPv6 1255 addresses. 1257 Also, given the end-to-end connectivity that IPv6 provides, it is 1258 also recommended that hosts be fortified against threats. General 1259 device hardening guidelines are provided in Section 2.8. 1261 For many years, all host operating systems have IPv6 enabled by 1262 default, so, it is possible even in an 'IPv4-only' network to attack 1263 layer-2 adjacent victims over their IPv6 link-local address or over a 1264 global IPv6 address once rogue RAs or rogue DHCPv6 addresses are 1265 provided by an attacker. 1267 2.7.2. Encapsulation Mechanisms 1269 There are many tunnels used for specific use cases. Except when 1270 protected by IPsec [RFC4301], all those tunnels have a couple of 1271 security issues; most of them because being tunnel as described in 1272 RFC 6169 [RFC6169]; 1274 o tunnel injection: a malevolent person knowing a few pieces of 1275 information (for example the tunnel endpoints and the used 1276 protocol) can forge a packet which looks like a legit and valid 1277 encapsulated packet that will gladly be accepted by the 1278 destination tunnel endpoint, this is a specific case of spoofing; 1280 o traffic interception: no confidentiality is provided by the tunnel 1281 protocols (without the use of IPsec or alternative encryption 1282 methods), therefore anybody on the tunnel path can intercept the 1283 traffic and have access to the clear-text IPv6 packet; combined 1284 with the absence of authentication, a man in the middle attack can 1285 also be mounted; 1287 o service theft: as there is no authorization, even a non authorized 1288 user can use a tunnel relay for free (this is a specific case of 1289 tunnel injection); 1291 o reflection attack: another specific use case of tunnel injection 1292 where the attacker injects packets with an IPv4 destination 1293 address not matching the IPv6 address causing the first tunnel 1294 endpoint to re-encapsulate the packet to the destination... Hence, 1295 the final IPv4 destination will not see the original IPv4 address 1296 but only one IPv4 address of the relay router. 1298 o bypassing security policy: if a firewall or an IPS is on the path 1299 of the tunnel, then it will probably neither inspect nor detect an 1300 malevolent IPv6 traffic contained in the tunnel. 1302 To mitigate the bypassing of security policies, it is recommended to 1303 block all default configuration tunnels by denying all IPv4 traffic 1304 matching: 1306 o IP protocol 41: this will block ISATAP (Section 2.7.2.2), 6to4 1307 (Section 2.7.2.7), 6rd (Section 2.7.2.3) as well as 6in4 1308 (Section 2.7.2.1) tunnels; 1310 o IP protocol 47: this will block GRE (Section 2.7.2.1) tunnels; 1312 o UDP protocol 3544: this will block the default encapsulation of 1313 Teredo (Section 2.7.2.8) tunnels. Teredo is now mostly never used 1314 and it is no more automated in most environment, so, it is less of 1315 a threat, however, special consideration must be taken in case of 1316 devices with older or non-updated operating systems may be 1317 present, which by default were running Teredo. 1319 Ingress filtering [RFC2827] should also be applied on all tunnel 1320 endpoints if applicable to prevent IPv6 address spoofing. 1322 As several of the tunnel techniques share the same encapsulation 1323 (i.e. IPv4 protocol 41) and embed the IPv4 address in the IPv6 1324 address, there are a set of well-known looping attacks described in 1325 RFC 6324 [RFC6324], this RFC also proposes mitigation techniques. 1327 2.7.2.1. Site-to-Site Static Tunnels 1329 Site-to-site static tunnels are described in RFC 2529 [RFC2529] and 1330 in GRE [RFC2784]. As the IPv4 endpoints are statically configured 1331 and are not dynamic they are slightly more secure (bi-directional 1332 service theft is mostly impossible) but traffic interception and 1333 tunnel injection are still possible. Therefore, the use of IPsec 1334 [RFC4301] in transport mode and protecting the encapsulated IPv4 1335 packets is recommended for those tunnels. Alternatively, IPsec in 1336 tunnel mode can be used to transport IPv6 traffic over a non-trusted 1337 IPv4 network. 1339 2.7.2.2. ISATAP 1341 ISATAP tunnels [RFC5214] are mainly used within a single 1342 administrative domain and to connect a single IPv6 host to the IPv6 1343 network. This often implies that those systems are usually managed 1344 by a single entity; therefore, audit trail and strict anti-spoofing 1345 are usually possible and this raises the overall security. 1347 Special care must be taken to avoid looping attack by implementing 1348 the measures of RFC 6324 [RFC6324] and of [RFC6964]. 1350 IPsec [RFC4301] in transport or tunnel mode can be used to secure the 1351 IPv4 ISATAP traffic to provide IPv6 traffic confidentiality and 1352 prevent service theft. 1354 2.7.2.3. 6rd 1356 While 6rd tunnels share the same encapsulation as 6to4 tunnels 1357 (Section 2.7.2.7), they are designed to be used within a single SP 1358 domain, in other words they are deployed in a more constrained 1359 environment than 6to4 tunnels and have little security issues except 1360 lack of confidentiality. The security considerations (Section 12) of 1361 [RFC5969] describes how to secure the 6rd tunnels. 1363 IPsec [RFC4301] for the transported IPv6 traffic can be used if 1364 confidentiality is important. 1366 2.7.2.4. 6PE, 6VPE, and LDPv6 1368 Organizations using MPLS in their core can also use 6PE [RFC4798] and 1369 6VPE [RFC4659] to enable IPv6 access over MPLS. As 6PE and 6VPE are 1370 really similar to BGP/MPLS IP VPN described in [RFC4364], the 1371 security of these networks is also similar to the one described in 1372 [RFC4381]. It relies on: 1374 o Address space, routing and traffic separation with the help of 1375 VRFs (only applicable to 6VPE); 1377 o Hiding the IPv4 core, hence removing all attacks against 1378 P-routers; 1380 o Securing the routing protocol between CE and PE; in the case of 1381 6PE and 6VPE, link-local addresses (see [RFC7404]) can be used and 1382 as these addresses cannot be reached from outside of the link, the 1383 security of 6PE and 6VPE is even higher than the IPv4 BGP/MPLS IP 1384 VPN. 1386 LDPv6 itself does not induce new risks, see also [RFC7552]. 1388 2.7.2.5. DS-Lite 1390 DS-lite is more a translation mechanism and is therefore analyzed 1391 further (Section 2.7.3.3) in this document. 1393 2.7.2.6. Mapping of Address and Port 1395 With the encapsulation and translation versions of mapping of Address 1396 and Port (MAP-E [RFC7597] and MAP-T [RFC7599]), the access network is 1397 purely an IPv6 network and MAP protocols are used to give IPv4 hosts 1398 on the subscriber network, access to IPv4 hosts on the Internet. The 1399 subscriber router does stateful operations in order to map all 1400 internal IPv4 addresses and layer-4 ports to the IPv4 address and the 1401 set of layer-4 ports received through MAP configuration process. The 1402 SP equipment always does stateless operations (either decapsulation 1403 or stateless translation). Therefore, as opposed to Section 2.7.3.3 1404 there is no state-exhaustion DoS attack against the SP equipment 1405 because there is no state and there is no operation caused by a new 1406 layer-4 connection (no logging operation). 1408 The SP MAP equipment MUST implement all the security considerations 1409 of [RFC7597]; notably, ensuring that the mapping of the IPv4 address 1410 and port are consistent with the configuration. As MAP has a 1411 predictable IPv4 address and port mapping, the audit logs are easier 1412 to manage. 1414 2.7.2.7. 6to4 1416 6to4 tunnels [RFC3056] require a public routable IPv4 address in 1417 order to work correctly. They can be used to provide either one IPv6 1418 host connectivity to the IPv6 Internet or multiple IPv6 networks 1419 connectivity to the IPv6 Internet. The 6to4 relay is usually the 1420 anycast address defined in [RFC3068] which has been deprecated by 1421 [RFC7526], and is no more used by recent Operating Systems. Some 1422 security considerations are explained in [RFC3964]. 1424 [RFC6343] points out that if an operator provides well-managed 1425 servers and relays for 6to4, non-encapsulated IPv6 packets will pass 1426 through well- defined points (the native IPv6 interfaces of those 1427 servers and relays) at which security mechanisms may be applied. 1428 Client usage of 6to4 by default is now discouraged, and significant 1429 precautions are needed to avoid operational problems. 1431 2.7.2.8. Teredo 1433 Teredo tunnels [RFC4380] are mainly used in a residential environment 1434 because that can easily traverse an IPv4 NAT-PT device thanks to its 1435 UDP encapsulation and they connect a single host to the IPv6 1436 Internet. Teredo shares the same issues as other tunnels: no 1437 authentication, no confidentiality, possible spoofing and reflection 1438 attacks. 1440 IPsec [RFC4301] for the transported IPv6 traffic is recommended. 1442 The biggest threat to Teredo is probably for IPv4-only network as 1443 Teredo has been designed to easily traverse IPV4 NAT-PT devices which 1444 are quite often co-located with a stateful firewall. Therefore, if 1445 the stateful IPv4 firewall allows unrestricted UDP outbound and 1446 accept the return UDP traffic, then Teredo actually punches a hole in 1447 this firewall for all IPv6 traffic to the Internet and from the 1448 Internet. While host policies can be deployed to block Teredo in an 1449 IPv4-only network in order to avoid this firewall bypass, it would be 1450 more efficient to block all UDP outbound traffic at the IPv4 firewall 1451 if deemed possible (of course, at least port 53 should be left open 1452 for DNS traffic). 1454 Teredo is now mostly never used and it is no more automated in most 1455 environment, so, it is less of a threat, however, special 1456 consideration must be taken in case of devices with older or non- 1457 updated operating systems may be present, which by default were 1458 running Teredo. 1460 2.7.3. Translation Mechanisms 1462 Translation mechanisms between IPv4 and IPv6 networks are alternative 1463 coexistence strategies while networks transition to IPv6. While a 1464 framework is described in [RFC6144] the specific security 1465 considerations are documented in each individual mechanism. For the 1466 most part they specifically mention interference with IPsec or DNSSEC 1467 deployments, how to mitigate spoofed traffic and what some effective 1468 filtering strategies may be. 1470 2.7.3.1. Carrier-Grade NAT (CGN) 1472 Carrier-Grade NAT (CGN), also called NAT444 CGN or Large Scale NAT 1473 (LSN) or SP NAT is described in [RFC6264] and is utilized as an 1474 interim measure to prolong the use of IPv4 in a large service 1475 provider network until the provider can deploy and effective IPv6 1476 solution. [RFC6598] requested a specific IANA allocated /10 IPv4 1477 address block to be used as address space shared by all access 1478 networks using CGN. This has been allocated as 100.64.0.0/10. 1480 Section 13 of [RFC6269] lists some specific security-related issues 1481 caused by large scale address sharing. The Security Considerations 1482 section of [RFC6598] also lists some specific mitigation techniques 1483 for potential misuse of shared address space. Some Law Enforcement 1484 Agencies have identified CGN as impeding their cyber-crime 1485 investigations (for example Europol press release on CGN 1486 [europol-cgn]). Many translation techniques (NAT64, DS-lite, ...) 1487 have the same security issues as CGN when one part of the connection 1488 is IPv4-only. 1490 [RFC6302] has recommendations for Internet-facing servers to also log 1491 the source TCP or UDP ports of incoming connections in an attempt to 1492 help identify the users behind such a CGN. 1494 [RFC7422] suggests the use of deterministic address mapping in order 1495 to reduce logging requirements for CGN. The idea is to have an 1496 algorithm mapping back and forth the internal subscriber to public 1497 ports. 1499 2.7.3.2. NAT64/DNS64 and 464XLAT 1501 Stateful NAT64 translation [RFC6146] allows IPv6-only clients to 1502 contact IPv4 servers using unicast UDP, TCP, or ICMP. It can be used 1503 in conjunction with DNS64 [RFC6147], a mechanism which synthesizes 1504 AAAA records from existing A records. There is also a stateless 1505 NAT64 [RFC7915] which is similar for the security aspects with the 1506 added benefit of being stateless, so, less prone to a state 1507 exhaustion attack. 1509 The Security Consideration sections of [RFC6146] and [RFC6147] list 1510 the comprehensive issues. A specific issue with the use of NAT64 is 1511 that it will interfere with most IPsec deployments unless UDP 1512 encapsulation is used. DNS64 has an impact on DNSSEC see section 3.1 1513 of [RFC7050]. 1515 464XLAT [RFC6877] shares the same security considerations as NAT64 1516 and DNS64, however it can be used without DNS64, avoiding the DNSSEC 1517 implications. 1519 2.7.3.3. DS-Lite 1521 Dual-Stack Lite (DS-Lite) [RFC6333] is a transition technique that 1522 enables a service provider to share IPv4 addresses among customers by 1523 combining two well-known technologies: IP in IP (IPv4-in-IPv6) and 1524 Network Address and Port Translation (NAPT). 1526 Security considerations with respect to DS-Lite mainly revolve around 1527 logging data, preventing DoS attacks from rogue devices (as the 1528 Address Family Translation Router, AFTR [RFC6333] function is 1529 stateful) and restricting service offered by the AFTR only to 1530 registered customers. 1532 Section 11 of [RFC6333] describes important security issues 1533 associated with this technology. 1535 2.8. General Device Hardening 1537 There are many environments which rely too much on the network 1538 infrastructure to disallow malicious traffic to get access to 1539 critical hosts. In new IPv6 deployments it has been common to see 1540 IPv6 traffic enabled but none of the typical access control 1541 mechanisms enabled for IPv6 device access. With the possibility of 1542 network device configuration mistakes and the growth of IPv6 in the 1543 overall Internet it is important to ensure that all individual 1544 devices are hardened against miscreant behavior. 1546 The following guidelines should be used to ensure appropriate 1547 hardening of the host, be it an individual computer or router, 1548 firewall, load-balancer,server, etc device. 1550 o Restrict access to the device to authorized individuals 1552 o Monitor and audit access to the device 1554 o Turn off any unused services on the end node 1556 o Understand which IPv6 addresses are being used to source traffic 1557 and change defaults if necessary 1559 o Use cryptographically protected protocols for device management if 1560 possible (SCP, SNMPv3, SSH, TLS, etc) 1562 o Use host firewall capabilities to control traffic that gets 1563 processed by upper layer protocols 1565 o Use virus scanners to detect malicious programs 1567 3. Enterprises Specific Security Considerations 1569 Enterprises generally have robust network security policies in place 1570 to protect existing IPv4 networks. These policies have been 1571 distilled from years of experiential knowledge of securing IPv4 1572 networks. At the very least, it is recommended that enterprise 1573 networks have parity between their security policies for both 1574 protocol versions. This section also applies to the enterprise part 1575 of all ISP, i.e., the part of the network where the ISP employees are 1576 connected. 1578 Security considerations in the enterprise can be broadly categorized 1579 into two sections - External and Internal. 1581 3.1. External Security Considerations: 1583 The external aspect deals with providing security at the edge or 1584 perimeter of the enterprise network where it meets the service 1585 providers network. This is commonly achieved by enforcing a security 1586 policy either by implementing dedicated firewalls with stateful 1587 packet inspection or a router with ACLs. A common default IPv4 1588 policy on firewalls that could easily be ported to IPv6 is to allow 1589 all traffic outbound while only allowing specific traffic, such as 1590 established sessions, inbound (see also [RFC6092]). Here are a few 1591 more things that could enhance the default policy: 1593 o Filter internal-use IPv6 addresses at the perimeter 1594 o Discard packets from and to bogon and reserved space, see also 1595 [CYMRU] and [RFC8190] 1597 o Accept certain ICMPv6 messages to allow proper operation of ND and 1598 PMTUD, see also [RFC4890] or [REY_PF] for hosts 1600 o Filter specific extension headers by accepting only the required 1601 ones (white list approach) such as ESP, AH (not forgetting the 1602 required transport layers: ICMP, TCP, UDP, ...) , where possible 1603 at the edge and possibly inside the perimeter; see also 1604 [I-D.ietf-opsec-ipv6-eh-filtering] 1606 o Filter packets having an illegal IPv6 headers chain at the 1607 perimeter (and possible inside as well), see Section 2.2 1609 o Filter unneeded services at the perimeter 1611 o Implement ingress and egress anti-spoofing in the forwarding and 1612 control planes 1614 o Implement appropriate rate-limiters and control-plane policers 1616 3.2. Internal Security Considerations: 1618 The internal aspect deals with providing security inside the 1619 perimeter of the network, including the end host. The most 1620 significant concerns here are related to Neighbor Discovery. At the 1621 network level, it is recommended that all security considerations 1622 discussed in Section 2.3 be reviewed carefully and the 1623 recommendations be considered in-depth as well. 1625 As mentioned in Section 2.6.2, care must be taken when running 1626 automated IPv6-in-IP4 tunnels. 1628 When site-to-site VPNs are used it should be kept in mind that, given 1629 the global scope of IPv6 global addresses as opposed to the common 1630 use of IPv4 private address space [RFC1918], sites might be able to 1631 communicate with each other over the Internet even when the VPN 1632 mechanism is not available and hence no traffic encryption is 1633 performed and traffic could be injected from the Internet in the 1634 site, see [WEBER_VPN]. It is recommended to filter at the Internet 1635 connection(s) packets having a source or destination address 1636 belonging to the site internal prefix(es); this should be done for 1637 ingress and egress traffic. 1639 Hosts need to be hardened directly through security policy to protect 1640 against security threats. The host firewall default capabilities 1641 have to be clearly understood, especially 3rd party ones which can 1642 have different settings for IPv4 or IPv6 default permit/deny 1643 behavior. In some cases, 3rd party firewalls have no IPv6 support 1644 whereas the native firewall installed by default has it. General 1645 device hardening guidelines are provided in Section 2.8 1647 It should also be noted that many hosts still use IPv4 for transport 1648 for things like RADIUS, TACACS+, SYSLOG, etc. This will require some 1649 extra level of due diligence on the part of the operator. 1651 4. Service Providers Security Considerations 1653 4.1. BGP 1655 The threats and mitigation techniques are identical between IPv4 and 1656 IPv6. Broadly speaking they are: 1658 o Authenticating the TCP session; 1660 o TTL security (which becomes hop-limit security in IPv6) as 1661 [RFC5082]; 1663 o bogon AS filtering; 1665 o Prefix filtering. 1667 These are explained in more detail in Section 2.5. Also, the 1668 recommendations of [RFC7454] should be considered. 1670 4.1.1. Remote Triggered Black Hole Filtering 1672 RTBH [RFC5635] works identically in IPv4 and IPv6. IANA has 1673 allocated 100::/64 as discard prefix [RFC6666]. 1675 4.2. Transition Mechanism 1677 SP will typically use transition mechanisms such as 6rd, 6PE, MAP, 1678 DS-Lite which have been analyzed in the transition Section 2.7.2 1679 section. 1681 4.3. Lawful Intercept 1683 The Lawful Intercept requirements are similar for IPv6 and IPv4 1684 architectures and will be subject to the laws enforced in varying 1685 geographic regions. The local issues with each jurisdiction can make 1686 this challenging and both corporate legal and privacy personnel 1687 should be involved in discussions pertaining to what information gets 1688 logged and what the logging retention policies will be. 1690 The target of interception will usually be a residential subscriber 1691 (e.g. his/her PPP session or physical line or CPE MAC address). With 1692 the absence of NAT on the CPE, IPv6 has the provision to allow for 1693 intercepting the traffic from a single host (a /128 target) rather 1694 than the whole set of hosts of a subscriber (which could be a /48, a 1695 /60 or /64). 1697 In contrast, in mobile environments, since the 3GPP specifications 1698 allocate a /64 per device, it may be sufficient to intercept traffic 1699 from the /64 rather than specific /128's (since each time the device 1700 powers up it gets a new IID). 1702 A sample architecture which was written for informational purposes is 1703 found in [RFC3924]. 1705 5. Residential Users Security Considerations 1707 The IETF Homenet working group is working on how IPv6 residential 1708 network should be done; this obviously includes operational security 1709 considerations; but, this is still work in progress. 1711 Residential users have usually less experience and knowledge about 1712 security or networking. As most of the recent hosts, smartphones, 1713 tablets have all IPv6 enabled by default, IPv6 security is important 1714 for those users. Even with an IPv4-only ISP, those users can get 1715 IPv6 Internet access with the help of Teredo tunnels. Several peer- 1716 to-peer programs (notably Bittorrent) support IPv6 and those programs 1717 can initiate a Teredo tunnel through the IPv4 residential gateway, 1718 with the consequence of making the internal host reachable from any 1719 IPv6 host on the Internet. It is therefore recommended that all host 1720 security products (personal firewall, ...) are configured with a 1721 dual-stack security policy. 1723 If the Residential Gateway has IPv6 connectivity, [RFC7084] defines 1724 the requirements of an IPv6 CPE and does not take position on the 1725 debate of default IPv6 security policy as defined in [RFC6092]: 1727 o outbound only: allowing all internally initiated connections and 1728 block all externally initiated ones, which is a common default 1729 security policy enforced by IPv4 Residential Gateway doing NAT-PT 1730 but it also breaks the end-to-end reachability promise of IPv6. 1731 [RFC6092] lists several recommendations to design such a CPE; 1733 o open/transparent: allowing all internally and externally initiated 1734 connections, therefore restoring the end-to-end nature of the 1735 Internet for the IPv6 traffic but having a different security 1736 policy for IPv6 than for IPv4. 1738 [RFC6092] REC-49 states that a choice must be given to the user to 1739 select one of those two policies. 1741 There is also an alternate solution which has been deployed notably 1742 by Swisscom: open to all outbound and inbound connections at the 1743 exception of a handful of TCP and UDP ports known as vulnerable. 1745 6. Further Reading 1747 There are several documents that describe in more details the 1748 security of an IPv6 network; these documents are not written by the 1749 IETF and some of them are dated but are listed here for your 1750 convenience: 1752 1. Guidelines for the Secure Deployment of IPv6 [NIST] 1754 2. North American IPv6 Task Force Technology Report - IPv6 Security 1755 Technology Paper [NAv6TF_Security] 1757 3. IPv6 Security [IPv6_Security_Book] 1759 7. Acknowledgements 1761 The authors would like to thank the following people for their useful 1762 comments: Mikael Abrahamsson, Fred Baker, Mustafa Suha Botsali, Brian 1763 Carpenter, Tim Chown, Lorenzo Colitti, Markus de Bruen, Tobias 1764 Fiebig, Fernando Gont, Jeffry Handal, Lee Howard, Panos Kampanakis, 1765 Erik Kline, Jouni Korhonen, Mark Lentczner, Jen Linkova (and her 1766 detailed review), Jordi Palet, Bob Sleigh, Donal Smith, Tarko Tikan, 1767 Ole Troan, Bernie Volz (by alphabetical order). 1769 8. IANA Considerations 1771 This memo includes no request to IANA. 1773 9. Security Considerations 1775 This memo attempts to give an overview of security considerations of 1776 operating an IPv6 network both in an IPv6-only network and in 1777 utilizing the most widely deployed IPv4/IPv6 coexistence strategies. 1779 10. References 1781 10.1. Normative References 1783 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1784 Requirement Levels", BCP 14, RFC 2119, 1785 DOI 10.17487/RFC2119, March 1997, 1786 . 1788 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1789 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1790 May 2017, . 1792 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1793 (IPv6) Specification", STD 86, RFC 8200, 1794 DOI 10.17487/RFC8200, July 2017, 1795 . 1797 10.2. Informative References 1799 [CYMRU] "Packet Filter and Route Filter Recommendation for IPv6 at 1800 xSP routers", . 1804 [europol-cgn] 1805 Europol, "ARE YOU SHARING THE SAME IP ADDRESS AS A 1806 CRIMINAL? LAW ENFORCEMENT CALL FOR THE END OF CARRIER 1807 GRADE NAT (CGN) TO INCREASE ACCOUNTABILITY ONLINE", 1808 October 2017, 1809 . 1814 [I-D.chakrabarti-nordmark-6man-efficient-nd] 1815 Chakrabarti, S., Nordmark, E., Thubert, P., and M. 1816 Wasserman, "IPv6 Neighbor Discovery Optimizations for 1817 Wired and Wireless Networks", draft-chakrabarti-nordmark- 1818 6man-efficient-nd-07 (work in progress), February 2015. 1820 [I-D.ietf-opsec-ipv6-eh-filtering] 1821 Gont, F. and W. LIU, "Recommendations on the Filtering of 1822 IPv6 Packets Containing IPv6 Extension Headers", draft- 1823 ietf-opsec-ipv6-eh-filtering-06 (work in progress), July 1824 2018. 1826 [I-D.ietf-v6ops-ula-usage-considerations] 1827 Liu, B. and S. Jiang, "Considerations For Using Unique 1828 Local Addresses", draft-ietf-v6ops-ula-usage- 1829 considerations-02 (work in progress), March 2017. 1831 [I-D.kampanakis-6man-ipv6-eh-parsing] 1832 Kampanakis, P., "Implementation Guidelines for parsing 1833 IPv6 Extension Headers", draft-kampanakis-6man-ipv6-eh- 1834 parsing-01 (work in progress), August 2014. 1836 [I-D.thubert-savi-ra-throttler] 1837 Thubert, P., "Throttling RAs on constrained interfaces", 1838 draft-thubert-savi-ra-throttler-01 (work in progress), 1839 June 2012. 1841 [IEEE-802.1X] 1842 IEEE, "IEEE Standard for Local and metropolitan area 1843 networks - Port-Based Network Access Control", IEEE Std 1844 802.1X-2010, February 2010. 1846 [IPv6_Security_Book] 1847 Hogg, S. and E. Vyncke, "IPv6 Security", 1848 ISBN 1-58705-594-5, Publisher CiscoPress, December 2008. 1850 [NAv6TF_Security] 1851 Kaeo, M., Green, D., Bound, J., and Y. Pouffary, "North 1852 American IPv6 Task Force Technology Report - IPv6 Security 1853 Technology Paper", 2006, 1854 . 1857 [NIST] Frankel, S., Graveman, R., Pearce, J., and M. Rooks, 1858 "Guidelines for the Secure Deployment of IPv6", 2010, 1859 . 1862 [REY_PF] Rey, E., "Local Packet Filtering with IPv6", July 2017, 1863 . 1866 [RFC0826] Plummer, D., "An Ethernet Address Resolution Protocol: Or 1867 Converting Network Protocol Addresses to 48.bit Ethernet 1868 Address for Transmission on Ethernet Hardware", STD 37, 1869 RFC 826, DOI 10.17487/RFC0826, November 1982, 1870 . 1872 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 1873 and E. Lear, "Address Allocation for Private Internets", 1874 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 1875 . 1877 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 1878 RFC 2131, DOI 10.17487/RFC2131, March 1997, 1879 . 1881 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1882 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 1883 December 1998, . 1885 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 1886 Domains without Explicit Tunnels", RFC 2529, 1887 DOI 10.17487/RFC2529, March 1999, 1888 . 1890 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 1891 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 1892 DOI 10.17487/RFC2784, March 2000, 1893 . 1895 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1896 Defeating Denial of Service Attacks which employ IP Source 1897 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 1898 May 2000, . 1900 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, 1901 DOI 10.17487/RFC2866, June 2000, 1902 . 1904 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 1905 via IPv4 Clouds", RFC 3056, DOI 10.17487/RFC3056, February 1906 2001, . 1908 [RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", 1909 RFC 3068, DOI 10.17487/RFC3068, June 2001, 1910 . 1912 [RFC3627] Savola, P., "Use of /127 Prefix Length Between Routers 1913 Considered Harmful", RFC 3627, DOI 10.17487/RFC3627, 1914 September 2003, . 1916 [RFC3756] Nikander, P., Ed., Kempf, J., and E. Nordmark, "IPv6 1917 Neighbor Discovery (ND) Trust Models and Threats", 1918 RFC 3756, DOI 10.17487/RFC3756, May 2004, 1919 . 1921 [RFC3924] Baker, F., Foster, B., and C. Sharp, "Cisco Architecture 1922 for Lawful Intercept in IP Networks", RFC 3924, 1923 DOI 10.17487/RFC3924, October 2004, 1924 . 1926 [RFC3964] Savola, P. and C. Patel, "Security Considerations for 1927 6to4", RFC 3964, DOI 10.17487/RFC3964, December 2004, 1928 . 1930 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 1931 "SEcure Neighbor Discovery (SEND)", RFC 3971, 1932 DOI 10.17487/RFC3971, March 2005, 1933 . 1935 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 1936 RFC 3972, DOI 10.17487/RFC3972, March 2005, 1937 . 1939 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1940 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 1941 . 1943 [RFC4293] Routhier, S., Ed., "Management Information Base for the 1944 Internet Protocol (IP)", RFC 4293, DOI 10.17487/RFC4293, 1945 April 2006, . 1947 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1948 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 1949 December 2005, . 1951 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 1952 DOI 10.17487/RFC4302, December 2005, 1953 . 1955 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1956 RFC 4303, DOI 10.17487/RFC4303, December 2005, 1957 . 1959 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1960 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 1961 2006, . 1963 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 1964 Network Address Translations (NATs)", RFC 4380, 1965 DOI 10.17487/RFC4380, February 2006, 1966 . 1968 [RFC4381] Behringer, M., "Analysis of the Security of BGP/MPLS IP 1969 Virtual Private Networks (VPNs)", RFC 4381, 1970 DOI 10.17487/RFC4381, February 2006, 1971 . 1973 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 1974 Control Message Protocol (ICMPv6) for the Internet 1975 Protocol Version 6 (IPv6) Specification", STD 89, 1976 RFC 4443, DOI 10.17487/RFC4443, March 2006, 1977 . 1979 [RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality 1980 for OSPFv3", RFC 4552, DOI 10.17487/RFC4552, June 2006, 1981 . 1983 [RFC4649] Volz, B., "Dynamic Host Configuration Protocol for IPv6 1984 (DHCPv6) Relay Agent Remote-ID Option", RFC 4649, 1985 DOI 10.17487/RFC4649, August 2006, 1986 . 1988 [RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur, 1989 "BGP-MPLS IP Virtual Private Network (VPN) Extension for 1990 IPv6 VPN", RFC 4659, DOI 10.17487/RFC4659, September 2006, 1991 . 1993 [RFC4798] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur, 1994 "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 1995 Provider Edge Routers (6PE)", RFC 4798, 1996 DOI 10.17487/RFC4798, February 2007, 1997 . 1999 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 2000 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 2001 DOI 10.17487/RFC4861, September 2007, 2002 . 2004 [RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and 2005 E. Klein, "Local Network Protection for IPv6", RFC 4864, 2006 DOI 10.17487/RFC4864, May 2007, 2007 . 2009 [RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering 2010 ICMPv6 Messages in Firewalls", RFC 4890, 2011 DOI 10.17487/RFC4890, May 2007, 2012 . 2014 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 2015 Extensions for Stateless Address Autoconfiguration in 2016 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 2017 . 2019 [RFC4942] Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/ 2020 Co-existence Security Considerations", RFC 4942, 2021 DOI 10.17487/RFC4942, September 2007, 2022 . 2024 [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. 2025 Pignataro, "The Generalized TTL Security Mechanism 2026 (GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007, 2027 . 2029 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 2030 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 2031 DOI 10.17487/RFC5214, March 2008, 2032 . 2034 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 2035 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 2036 . 2038 [RFC5635] Kumari, W. and D. McPherson, "Remote Triggered Black Hole 2039 Filtering with Unicast Reverse Path Forwarding (uRPF)", 2040 RFC 5635, DOI 10.17487/RFC5635, August 2009, 2041 . 2043 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 2044 Address Text Representation", RFC 5952, 2045 DOI 10.17487/RFC5952, August 2010, 2046 . 2048 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 2049 Infrastructures (6rd) -- Protocol Specification", 2050 RFC 5969, DOI 10.17487/RFC5969, August 2010, 2051 . 2053 [RFC6092] Woodyatt, J., Ed., "Recommended Simple Security 2054 Capabilities in Customer Premises Equipment (CPE) for 2055 Providing Residential IPv6 Internet Service", RFC 6092, 2056 DOI 10.17487/RFC6092, January 2011, 2057 . 2059 [RFC6104] Chown, T. and S. Venaas, "Rogue IPv6 Router Advertisement 2060 Problem Statement", RFC 6104, DOI 10.17487/RFC6104, 2061 February 2011, . 2063 [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. 2064 Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, 2065 DOI 10.17487/RFC6105, February 2011, 2066 . 2068 [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 2069 IPv4/IPv6 Translation", RFC 6144, DOI 10.17487/RFC6144, 2070 April 2011, . 2072 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 2073 NAT64: Network Address and Protocol Translation from IPv6 2074 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 2075 April 2011, . 2077 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 2078 Beijnum, "DNS64: DNS Extensions for Network Address 2079 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 2080 DOI 10.17487/RFC6147, April 2011, 2081 . 2083 [RFC6164] Kohno, M., Nitzan, B., Bush, R., Matsuzaki, Y., Colitti, 2084 L., and T. Narten, "Using 127-Bit IPv6 Prefixes on Inter- 2085 Router Links", RFC 6164, DOI 10.17487/RFC6164, April 2011, 2086 . 2088 [RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, "Security 2089 Concerns with IP Tunneling", RFC 6169, 2090 DOI 10.17487/RFC6169, April 2011, 2091 . 2093 [RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the 2094 Router Control Plane", RFC 6192, DOI 10.17487/RFC6192, 2095 March 2011, . 2097 [RFC6221] Miles, D., Ed., Ooghe, S., Dec, W., Krishnan, S., and A. 2098 Kavanagh, "Lightweight DHCPv6 Relay Agent", RFC 6221, 2099 DOI 10.17487/RFC6221, May 2011, 2100 . 2102 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 2103 and A. Bierman, Ed., "Network Configuration Protocol 2104 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 2105 . 2107 [RFC6264] Jiang, S., Guo, D., and B. Carpenter, "An Incremental 2108 Carrier-Grade NAT (CGN) for IPv6 Transition", RFC 6264, 2109 DOI 10.17487/RFC6264, June 2011, 2110 . 2112 [RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and 2113 P. Roberts, "Issues with IP Address Sharing", RFC 6269, 2114 DOI 10.17487/RFC6269, June 2011, 2115 . 2117 [RFC6302] Durand, A., Gashinsky, I., Lee, D., and S. Sheppard, 2118 "Logging Recommendations for Internet-Facing Servers", 2119 BCP 162, RFC 6302, DOI 10.17487/RFC6302, June 2011, 2120 . 2122 [RFC6324] Nakibly, G. and F. Templin, "Routing Loop Attack Using 2123 IPv6 Automatic Tunnels: Problem Statement and Proposed 2124 Mitigations", RFC 6324, DOI 10.17487/RFC6324, August 2011, 2125 . 2127 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 2128 Stack Lite Broadband Deployments Following IPv4 2129 Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011, 2130 . 2132 [RFC6343] Carpenter, B., "Advisory Guidelines for 6to4 Deployment", 2133 RFC 6343, DOI 10.17487/RFC6343, August 2011, 2134 . 2136 [RFC6459] Korhonen, J., Ed., Soininen, J., Patil, B., Savolainen, 2137 T., Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation 2138 Partnership Project (3GPP) Evolved Packet System (EPS)", 2139 RFC 6459, DOI 10.17487/RFC6459, January 2012, 2140 . 2142 [RFC6547] George, W., "RFC 3627 to Historic Status", RFC 6547, 2143 DOI 10.17487/RFC6547, February 2012, 2144 . 2146 [RFC6564] Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and 2147 M. Bhatia, "A Uniform Format for IPv6 Extension Headers", 2148 RFC 6564, DOI 10.17487/RFC6564, April 2012, 2149 . 2151 [RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational 2152 Neighbor Discovery Problems", RFC 6583, 2153 DOI 10.17487/RFC6583, March 2012, 2154 . 2156 [RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and 2157 M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address 2158 Space", BCP 153, RFC 6598, DOI 10.17487/RFC6598, April 2159 2012, . 2161 [RFC6620] Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS 2162 SAVI: First-Come, First-Served Source Address Validation 2163 Improvement for Locally Assigned IPv6 Addresses", 2164 RFC 6620, DOI 10.17487/RFC6620, May 2012, 2165 . 2167 [RFC6666] Hilliard, N. and D. Freedman, "A Discard Prefix for IPv6", 2168 RFC 6666, DOI 10.17487/RFC6666, August 2012, 2169 . 2171 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 2172 DOI 10.17487/RFC6762, February 2013, 2173 . 2175 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 2176 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 2177 . 2179 [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: 2180 Combination of Stateful and Stateless Translation", 2181 RFC 6877, DOI 10.17487/RFC6877, April 2013, 2182 . 2184 [RFC6939] Halwasia, G., Bhandari, S., and W. Dec, "Client Link-Layer 2185 Address Option in DHCPv6", RFC 6939, DOI 10.17487/RFC6939, 2186 May 2013, . 2188 [RFC6964] Templin, F., "Operational Guidance for IPv6 Deployment in 2189 IPv4 Sites Using the Intra-Site Automatic Tunnel 2190 Addressing Protocol (ISATAP)", RFC 6964, 2191 DOI 10.17487/RFC6964, May 2013, 2192 . 2194 [RFC6980] Gont, F., "Security Implications of IPv6 Fragmentation 2195 with IPv6 Neighbor Discovery", RFC 6980, 2196 DOI 10.17487/RFC6980, August 2013, 2197 . 2199 [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, 2200 "Specification of the IP Flow Information Export (IPFIX) 2201 Protocol for the Exchange of Flow Information", STD 77, 2202 RFC 7011, DOI 10.17487/RFC7011, September 2013, 2203 . 2205 [RFC7012] Claise, B., Ed. and B. Trammell, Ed., "Information Model 2206 for IP Flow Information Export (IPFIX)", RFC 7012, 2207 DOI 10.17487/RFC7012, September 2013, 2208 . 2210 [RFC7039] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, Ed., 2211 "Source Address Validation Improvement (SAVI) Framework", 2212 RFC 7039, DOI 10.17487/RFC7039, October 2013, 2213 . 2215 [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing 2216 of IPv6 Extension Headers", RFC 7045, 2217 DOI 10.17487/RFC7045, December 2013, 2218 . 2220 [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of 2221 the IPv6 Prefix Used for IPv6 Address Synthesis", 2222 RFC 7050, DOI 10.17487/RFC7050, November 2013, 2223 . 2225 [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic 2226 Requirements for IPv6 Customer Edge Routers", RFC 7084, 2227 DOI 10.17487/RFC7084, November 2013, 2228 . 2230 [RFC7112] Gont, F., Manral, V., and R. Bonica, "Implications of 2231 Oversized IPv6 Header Chains", RFC 7112, 2232 DOI 10.17487/RFC7112, January 2014, 2233 . 2235 [RFC7113] Gont, F., "Implementation Advice for IPv6 Router 2236 Advertisement Guard (RA-Guard)", RFC 7113, 2237 DOI 10.17487/RFC7113, February 2014, 2238 . 2240 [RFC7166] Bhatia, M., Manral, V., and A. Lindem, "Supporting 2241 Authentication Trailer for OSPFv3", RFC 7166, 2242 DOI 10.17487/RFC7166, March 2014, 2243 . 2245 [RFC7381] Chittimaneni, K., Chown, T., Howard, L., Kuarsingh, V., 2246 Pouffary, Y., and E. Vyncke, "Enterprise IPv6 Deployment 2247 Guidelines", RFC 7381, DOI 10.17487/RFC7381, October 2014, 2248 . 2250 [RFC7404] Behringer, M. and E. Vyncke, "Using Only Link-Local 2251 Addressing inside an IPv6 Network", RFC 7404, 2252 DOI 10.17487/RFC7404, November 2014, 2253 . 2255 [RFC7422] Donley, C., Grundemann, C., Sarawat, V., Sundaresan, K., 2256 and O. Vautrin, "Deterministic Address Mapping to Reduce 2257 Logging in Carrier-Grade NAT Deployments", RFC 7422, 2258 DOI 10.17487/RFC7422, December 2014, 2259 . 2261 [RFC7454] Durand, J., Pepelnjak, I., and G. Doering, "BGP Operations 2262 and Security", BCP 194, RFC 7454, DOI 10.17487/RFC7454, 2263 February 2015, . 2265 [RFC7513] Bi, J., Wu, J., Yao, G., and F. Baker, "Source Address 2266 Validation Improvement (SAVI) Solution for DHCP", 2267 RFC 7513, DOI 10.17487/RFC7513, May 2015, 2268 . 2270 [RFC7526] Troan, O. and B. Carpenter, Ed., "Deprecating the Anycast 2271 Prefix for 6to4 Relay Routers", BCP 196, RFC 7526, 2272 DOI 10.17487/RFC7526, May 2015, 2273 . 2275 [RFC7552] Asati, R., Pignataro, C., Raza, K., Manral, V., and R. 2276 Papneja, "Updates to LDP for IPv6", RFC 7552, 2277 DOI 10.17487/RFC7552, June 2015, 2278 . 2280 [RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S., 2281 Murakami, T., and T. Taylor, Ed., "Mapping of Address and 2282 Port with Encapsulation (MAP-E)", RFC 7597, 2283 DOI 10.17487/RFC7597, July 2015, 2284 . 2286 [RFC7599] Li, X., Bao, C., Dec, W., Ed., Troan, O., Matsushima, S., 2287 and T. Murakami, "Mapping of Address and Port using 2288 Translation (MAP-T)", RFC 7599, DOI 10.17487/RFC7599, July 2289 2015, . 2291 [RFC7610] Gont, F., Liu, W., and G. Van de Velde, "DHCPv6-Shield: 2292 Protecting against Rogue DHCPv6 Servers", BCP 199, 2293 RFC 7610, DOI 10.17487/RFC7610, August 2015, 2294 . 2296 [RFC7707] Gont, F. and T. Chown, "Network Reconnaissance in IPv6 2297 Networks", RFC 7707, DOI 10.17487/RFC7707, March 2016, 2298 . 2300 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 2301 Considerations for IPv6 Address Generation Mechanisms", 2302 RFC 7721, DOI 10.17487/RFC7721, March 2016, 2303 . 2305 [RFC7872] Gont, F., Linkova, J., Chown, T., and W. Liu, 2306 "Observations on the Dropping of Packets with IPv6 2307 Extension Headers in the Real World", RFC 7872, 2308 DOI 10.17487/RFC7872, June 2016, 2309 . 2311 [RFC7915] Bao, C., Li, X., Baker, F., Anderson, T., and F. Gont, 2312 "IP/ICMP Translation Algorithm", RFC 7915, 2313 DOI 10.17487/RFC7915, June 2016, 2314 . 2316 [RFC7934] Colitti, L., Cerf, V., Cheshire, S., and D. Schinazi, 2317 "Host Address Availability Recommendations", BCP 204, 2318 RFC 7934, DOI 10.17487/RFC7934, July 2016, 2319 . 2321 [RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu, 2322 "Recommendation on Stable IPv6 Interface Identifiers", 2323 RFC 8064, DOI 10.17487/RFC8064, February 2017, 2324 . 2326 [RFC8190] Bonica, R., Cotton, M., Haberman, B., and L. Vegoda, 2327 "Updates to the Special-Purpose IP Address Registries", 2328 BCP 153, RFC 8190, DOI 10.17487/RFC8190, June 2017, 2329 . 2331 [RFC8210] Bush, R. and R. Austein, "The Resource Public Key 2332 Infrastructure (RPKI) to Router Protocol, Version 1", 2333 RFC 8210, DOI 10.17487/RFC8210, September 2017, 2334 . 2336 [RFC8273] Brzozowski, J. and G. Van de Velde, "Unique IPv6 Prefix 2337 per Host", RFC 8273, DOI 10.17487/RFC8273, December 2017, 2338 . 2340 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 2341 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 2342 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 2343 RFC 8415, DOI 10.17487/RFC8415, November 2018, 2344 . 2346 [RFC8504] Chown, T., Loughney, J., and T. Winters, "IPv6 Node 2347 Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504, 2348 January 2019, . 2350 [SCANNING] 2351 Barnes, R., Altmann, R., and D. Kerr, "Mapping the Great 2352 Void - Smarter scanning for IPv6", February 2012, 2353 . 2356 [WEBER_VPN] 2357 Weber, J., "Dynamic IPv6 Prefix - Problems and VPNs", 2358 March 2018, . 2362 Authors' Addresses 2364 Eric Vyncke (editor) 2365 Cisco 2366 De Kleetlaan 6a 2367 Diegem 1831 2368 Belgium 2370 Phone: +32 2 778 4677 2371 Email: evyncke@cisco.com 2373 Kiran K. Chittimaneni 2374 WeWork 2376 Email: kk.chittimaneni@gmail.com 2378 Merike Kaeo 2379 Double Shot Security 2380 3518 Fremont Ave N 363 2381 Seattle 98103 2382 USA 2384 Phone: +12066696394 2385 Email: merike@doubleshotsecurity.com 2386 Enno Rey 2387 ERNW 2388 Carl-Bosch-Str. 4 2389 Heidelberg, Baden-Wuertemberg 69115 2390 Germany 2392 Phone: +49 6221 480390 2393 Email: erey@ernw.de