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