idnits 2.17.1 draft-ietf-opsec-v6-13.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 28, 2018) is 2250 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-10) exists of draft-ietf-opsec-ipv6-eh-filtering-04 -- Obsolete informational reference (is this intentional?): RFC 2740 (Obsoleted by RFC 5340) -- Obsolete informational reference (is this intentional?): RFC 3068 (Obsoleted by RFC 7526) -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3627 (Obsoleted by RFC 6547) -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) -- Obsolete informational reference (is this intentional?): RFC 5157 (Obsoleted by RFC 7707) -- Obsolete informational reference (is this intentional?): RFC 6145 (Obsoleted by RFC 7915) -- Obsolete informational reference (is this intentional?): RFC 6204 (Obsoleted by RFC 7084) -- Obsolete informational reference (is this intentional?): RFC 6434 (Obsoleted by RFC 8504) -- Obsolete informational reference (is this intentional?): RFC 6506 (Obsoleted by RFC 7166) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OPSEC E. Vyncke, Ed. 3 Internet-Draft Cisco 4 Intended status: Informational K. Chittimaneni 5 Expires: September 1, 2018 Dropbox Inc. 6 M. Kaeo 7 Double Shot Security 8 E. Rey 9 ERNW 10 February 28, 2018 12 Operational Security Considerations for IPv6 Networks 13 draft-ietf-opsec-v6-13 15 Abstract 17 Knowledge and experience on how to operate IPv4 securely is 18 available: whether it is the Internet or an enterprise internal 19 network. However, IPv6 presents some new security challenges. RFC 20 4942 describes the security issues in the protocol but network 21 managers also need a more practical, operations-minded document to 22 enumerate advantages and/or disadvantages of certain choices. 24 This document analyzes the operational security issues in several 25 places of a network (enterprises, service providers and residential 26 users) and proposes technical and procedural mitigations techniques. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on September 1, 2018. 45 Copyright Notice 47 Copyright (c) 2018 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 64 2. Generic Security Considerations . . . . . . . . . . . . . . . 4 65 2.1. Addressing Architecture . . . . . . . . . . . . . . . . . 4 66 2.1.1. Statically Configured Addresses . . . . . . . . . . . 4 67 2.1.2. Use of ULAs . . . . . . . . . . . . . . . . . . . . . 5 68 2.1.3. Point-to-Point Links . . . . . . . . . . . . . . . . 6 69 2.1.4. Temporary Addresses - Privacy Extensions for SLAAC . 6 70 2.1.5. Privacy consideration of Addresses . . . . . . . . . 7 71 2.1.6. DHCP/DNS Considerations . . . . . . . . . . . . . . . 7 72 2.1.7. Using a /64 per host . . . . . . . . . . . . . . . . 7 73 2.2. Extension Headers . . . . . . . . . . . . . . . . . . . . 8 74 2.2.1. Order and Repetition of Extension Headers . . . . . . 8 75 2.2.2. Hop-by-Hop Options Header . . . . . . . . . . . . . . 9 76 2.2.3. Fragment Header . . . . . . . . . . . . . . . . . . . 9 77 2.2.4. IP Security Extension Header . . . . . . . . . . . . 9 78 2.3. Link-Layer Security . . . . . . . . . . . . . . . . . . . 9 79 2.3.1. Securing DHCP . . . . . . . . . . . . . . . . . . . . 10 80 2.3.2. ND/RA Rate Limiting . . . . . . . . . . . . . . . . . 10 81 2.3.3. ND/RA Filtering . . . . . . . . . . . . . . . . . . . 11 82 2.3.4. 3GPP Link-Layer Security . . . . . . . . . . . . . . 12 83 2.3.5. SeND and CGA . . . . . . . . . . . . . . . . . . . . 13 84 2.4. Control Plane Security . . . . . . . . . . . . . . . . . 13 85 2.4.1. Control Protocols . . . . . . . . . . . . . . . . . . 15 86 2.4.2. Management Protocols . . . . . . . . . . . . . . . . 15 87 2.4.3. Packet Exceptions . . . . . . . . . . . . . . . . . . 15 88 2.5. Routing Security . . . . . . . . . . . . . . . . . . . . 16 89 2.5.1. Authenticating Neighbors/Peers . . . . . . . . . . . 17 90 2.5.2. Securing Routing Updates Between Peers . . . . . . . 17 91 2.5.3. Route Filtering . . . . . . . . . . . . . . . . . . . 18 92 2.6. Logging/Monitoring . . . . . . . . . . . . . . . . . . . 18 93 2.6.1. Data Sources . . . . . . . . . . . . . . . . . . . . 19 94 2.6.2. Use of Collected Data . . . . . . . . . . . . . . . . 23 95 2.6.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 25 96 2.7. Transition/Coexistence Technologies . . . . . . . . . . . 25 97 2.7.1. Dual Stack . . . . . . . . . . . . . . . . . . . . . 25 98 2.7.2. Transition Mechanisms . . . . . . . . . . . . . . . . 26 99 2.7.3. Translation Mechanisms . . . . . . . . . . . . . . . 30 100 2.8. General Device Hardening . . . . . . . . . . . . . . . . 31 101 3. Enterprises Specific Security Considerations . . . . . . . . 32 102 3.1. External Security Considerations: . . . . . . . . . . . . 32 103 3.2. Internal Security Considerations: . . . . . . . . . . . . 33 104 4. Service Providers Security Considerations . . . . . . . . . . 34 105 4.1. BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 106 4.1.1. Remote Triggered Black Hole Filtering . . . . . . . . 34 107 4.2. Transition Mechanism . . . . . . . . . . . . . . . . . . 34 108 4.3. Lawful Intercept . . . . . . . . . . . . . . . . . . . . 34 109 5. Residential Users Security Considerations . . . . . . . . . . 35 110 6. Further Reading . . . . . . . . . . . . . . . . . . . . . . . 36 111 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36 112 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 113 9. Security Considerations . . . . . . . . . . . . . . . . . . . 36 114 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 115 10.1. Normative References . . . . . . . . . . . . . . . . . . 36 116 10.2. Informative References . . . . . . . . . . . . . . . . . 37 117 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48 119 1. Introduction 121 Running an IPv6 network is new for most operators not only because 122 they are not yet used to large scale IPv6 networks but also because 123 there are subtle differences between IPv4 and IPv6 especially with 124 respect to security. For example, all layer-2 interactions are now 125 done using Neighbor Discovery Protocol [RFC4861] rather than using 126 Address Resolution Protocol [RFC0826]. Also, there are subtle 127 differences between NAT44 [RFC2993] and NPTv6 [RFC6296] which are 128 explicitly pointed out in the latter's security considerations 129 section. 131 IPv6 networks are deployed using a variety of techniques, each of 132 which have their own specific security concerns. 134 This document complements [RFC4942] by listing all security issues 135 when operating a network utilizing varying transition technologies 136 and updating with ones that have been standardized since 2007. It 137 also provides more recent operational deployment experiences where 138 warranted. 140 1.1. Requirements Language 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 144 document are to be interpreted as described in [RFC2119] when they 145 appear in ALL CAPS. These words may also appear in this document in 146 lower case as plain English words, absent their normative meanings. 148 2. Generic Security Considerations 150 2.1. Addressing Architecture 152 IPv6 address allocations and overall architecture are an important 153 part of securing IPv6. Initial designs, even if intended to be 154 temporary, tend to last much longer than expected. Although 155 initially IPv6 was thought to make renumbering easy, in practice, it 156 may be extremely difficult to renumber without a good IP Addresses 157 Management (IPAM) system. 159 Once an address allocation has been assigned, there should be some 160 thought given to an overall address allocation plan. With the 161 abundance of address space available, an address allocation may be 162 structured around services along with geographic locations, which 163 then can be a basis for more structured security policies to permit 164 or deny services between geographic regions. 166 A common question is whether companies should use PI vs PA space 167 [RFC7381], but from a security perspective there is little 168 difference. However, one aspect to keep in mind is who has 169 administrative ownership of the address space and who is technically 170 responsible if/when there is a need to enforce restrictions on 171 routability of the space due to malicious criminal activity. Using 172 PA space exposes the organization to a renumbering of the complete 173 network including security policies (based on ACL), audit system, ... 174 in short a complex task which could lead to some temporary security 175 risk if done for a large network and without automation; hence, for 176 large network, PI space should be preferred even if it comes with 177 additional complexities (for example BGP routing) and duties (adding 178 a route6 object in the Regional Internet Registry database). 180 2.1.1. Statically Configured Addresses 182 When considering how to assign statically configured addresses it is 183 necessary to take into consideration the effectiveness of perimeter 184 security in a given environment. There is a trade-off between ease 185 of operation (where some portions of the IPv6 address could be easily 186 recognizable for operational debugging and troubleshooting) versus 187 the risk of trivial scanning used for reconnaissance. [SCANNING] 188 shows that there are scientifically based mechanisms that make 189 scanning for IPv6 reachable nodes more realizable than expected; see 190 also [RFC7707]. The use of common multicast groups which are defined 191 for important networked devices and the use of commonly repeated 192 addresses could make it easy to figure out which devices are name 193 servers, routers or other critical devices; even a simple traceroute 194 will expose most of the routers on a path. There are many scanning 195 techniques and more to come possible, hence, operators should never 196 relly on the 'impossible to find because my address is random' 197 paradigm. 199 While in some unmanaged environments obfuscating addresses could be 200 considered a benefit; it is a better practice to ensure that 201 perimeter rules are actively checked and enforced and that statically 202 configured addresses follow some logical allocation scheme for ease 203 of operation (as simplicity always helps security). 205 2.1.2. Use of ULAs 207 Unique Local Addresses (ULAs) RFC4193 [RFC4193] are intended for 208 scenarios where IP addresses are not globally reachable, despite 209 formally having global scope. They must not appear in the routing 210 system outside the administrative domain where they are considered 211 valid. Therefore, packets with ULA source and/or destination 212 addresses MUST be filtered at the domain boundary. 214 ULAs are assigned within pseudo-random /48 prefixes created as 215 specified in RFC4193 [RFC4193]. They could be useful for 216 infrastructure hiding as described in RFC4864 [RFC4864]. 218 ULAs may be used for internal communication, in conjunction with 219 globally reachable unicast addresses (GUAs) for hosts that also 220 require external connectivity through a firewall. For this reason, 221 no form of address translation is required in conjunction with ULAs. 223 Using ULAs as described here might simplify the filtering rules 224 needed at the domain boundary, by allowing a regime in which only 225 hosts that require external connectivity possess a globally reachable 226 address. However, this does not remove the need for careful design 227 of the filtering rules. Routers with ULA on their interfaces may 228 also leak their address to the Internet when generating ICMP messages 229 or ICMP error messages can also include ULA address as they contain a 230 copy of the offending packet. 232 2.1.3. Point-to-Point Links 234 RFC6164 [RFC6164] in section 5.1 documents the reasons why to use a 235 /127 for inter-router point-to-point links; notably, a /127 prevents 236 the ping-pong attack between routers not implementing correctly 237 RFC4443 [RFC4443]. The previous recommendation of RFC3627 [RFC3627] 238 has been obsoleted and marked Historic by RFC6547 [RFC6547]). 240 Some environments are also using link-local addressing for point-to- 241 point links. While this practice could further reduce the attack 242 surface against infrastructure devices, the operational disadvantages 243 need also to be carefully considered; see also RFC7404 [RFC7404]. 245 2.1.4. Temporary Addresses - Privacy Extensions for SLAAC 247 Normal stateless address autoconfiguration (SLAAC) relies on the 248 automatically generated EUI-64 address, which together with the /64 249 prefix makes up the global unique IPv6 address. The EUI-64 address 250 is generated from the MAC address. Randomly generating an interface 251 ID, as described in [RFC4941], is part of SLAAC with so-called 252 privacy extension addresses and used to address some privacy 253 concerns. Privacy extension addresses a.k.a. temporary addresses may 254 help to mitigate the correlation of activities of a node within the 255 same network, and may also reduce the attack exposure window. 257 As privacy extension addresses could also be used to obfuscate some 258 malevolent activities (whether on purpose or not), it is advised in 259 scenarios where user attribution is important to rely on a layer-2 260 authentication mechanism such as IEEE 802.1X [IEEE-802.1X] with the 261 appropriate RADIUS accounting (Section 2.6.1.6) or to disable SLAAC 262 and rely only on DHCPv6. However, in scenarios where anonymity is a 263 strong desire (protecting user privacy is more important than user 264 attribution), privacy extension addresses should be used. When 265 [RFC8064] is available, the stable temporary address are probably a 266 good balance between privacy (among multiple networks) and security/ 267 user attribution (within a network). 269 Using privacy extension addresses prevents the operator from building 270 a priori host specific access control lists (ACLs). It must be noted 271 that recent versions of Windows do not use the MAC address anymore to 272 build the stable address but use a mechanism similar to the one 273 described in [RFC7217], this also means that such an ACL cannot be 274 configured based solely on the MAC address of the nodes, diminishing 275 the value of such ACL. On the other hand, different VLANs are often 276 used to segregate users, in this case ACL can rely on a /64 prefix 277 per VLAN rather than a per host ACL entry. 279 The decision to utilize privacy extension addresses can come down to 280 whether the network is managed versus unmanaged. In some 281 environments full visibility into the network is required at all 282 times which requires that all traffic be attributable to where it is 283 sourced or where it is destined to within a specific network. This 284 situation is dependent on what level of logging is performed. If 285 logging considerations include utilizing accurate timestamps and 286 logging a node's source ports [RFC6302] then there should always 287 exist appropriate user attribution needed to get to the source of any 288 malware originator or source of criminal activity. 290 Disabling SLAAC and privacy extensions addresses can be done for most 291 OS and for non-hacker users by sending RA messages with a hint to get 292 addresses via DHCPv6 by setting the M-bit but also disabling SLAAC by 293 resetting all A-bits in all prefix information options. Hackers will 294 find a way to bypass this mechanism if not enforced at the switch/ 295 router level. 297 2.1.5. Privacy consideration of Addresses 299 The reader can learn more about privacy considerations for IPv6 300 addresses in RFC7721 [RFC7721]. 302 2.1.6. DHCP/DNS Considerations 304 Many environments use DHCPv6 to allocate addresses to ensure audit- 305 ability and traceability (but see Section 2.6.1.5). A main security 306 concern is the ability to detect and counteract against rogue DHCP 307 servers (Section 2.3.1). 309 While there are no fundamental differences with IPv4 and IPv6 310 security concerns about DNS, there are specific consideration in 311 DNS64 RFC6147 [RFC6147] environments that need to be understood. 312 Specifically the interactions and potential to interference with 313 DNSSEC implementation need to be understood - these are pointed out 314 in detail in Section 2.7.3.2. 316 2.1.7. Using a /64 per host 318 An interesting approach is using a /64 per host as proposed in 319 RFC8273 [RFC8273]. This allows an easier user attribution (typically 320 based on the host MAC address) as its /64 prefix is stable even if 321 applications, containers within the host can change of IPv6 address 322 within this /64. 324 2.2. Extension Headers 326 The extension headers are an important difference between IPv4 and 327 IPv6. The packet structure does make a big difference. For 328 instance, it's trivial to find (in IPv4-based packets) the upper 329 layer protocol type and protocol header, while in IPv6 it actually 330 isn't as the extension header chain must be parsed completely. The 331 IANA has closed the existing empty "Next Header Types" registry to 332 new entries and is redirecting its users to a new "IPv6 Extension 333 Header Types" registry per RFC7045 [RFC7045]. 335 They have also become a very controversial topic since forwarding 336 nodes that discard packets containing extension headers are known to 337 cause connectivity failures and deployment problems RFC7872 338 [RFC7872]. Understanding the role of varying extension headers is 339 important and this section enumerates the ones that need careful 340 consideration. 342 A clarification on how intermediate nodes should handle existing 343 packets with extension headers and any extension headers that are 344 defined in the future is found in RFC7045 [RFC7045]. The uniform TLV 345 format to be used for defining future extension headers is described 346 in RFC6564 [RFC6564]. 348 It must also be noted that there is no indication in the packet 349 whether the Next Protocol field points to an extension header or to a 350 transport header. This may confuse some filtering rules. 352 There is work in progress at the IETF about filtering rules for those 353 extension headers: [I-D.ietf-opsec-ipv6-eh-filtering] for transit 354 routers. 356 2.2.1. Order and Repetition of Extension Headers 358 While RFC8200 [RFC8200] recommends the order and the maximum 359 repetition of extension headers, there are still IPv6 implementations 360 at the time of writing this document which support a non-recommended 361 order of headers (such as ESP before routing) or an illegal 362 repetition of headers (such as multiple routing headers). The same 363 applies for options contained in the extension headers (see 364 [I-D.kampanakis-6man-ipv6-eh-parsing]). In some cases, it has lead 365 to nodes crashing when receiving or forwarding wrongly formated 366 packets. 368 A firewall or any edge device able to enforce the recommended order 369 and number of occurences of extension headers is recommended. 371 2.2.2. Hop-by-Hop Options Header 373 The hop-by-hop options header, when present in an IPv6 packet, forces 374 all nodes in the path to inspect this header in the original IPv6 375 specification RFC2460 [RFC2460]. This was of course a large avenue 376 for a denial of service as most if not all routers cannot process 377 this kind of packets in hardware but have to 'punt' this packet for 378 software processing. Section 4.3 of the current Internet Standard 379 for IPv6, RFC8200 [RFC8200], is more sensible to this respect as the 380 processing of hop-by-hop options header is optional. 382 2.2.3. Fragment Header 384 The fragment header is used by the source when it has to fragment 385 packets. RFC7112 [RFC7112] and section 4.5 of RFC8200 [RFC8200] 386 explain why it is important to: 388 firewall and security devices should drop first fragment not 389 containing an upper-layer header; 391 destination nodes should discard first fragments not containing an 392 upper-layer header. 394 Else, stateless filtering could be bypassed by an hostile party. 395 RFC6980 [RFC6980] applies the same rule to NDP and the RA-guard 396 function described in RFC6105 [RFC6105]. 398 2.2.4. IP Security Extension Header 400 The IPsec [RFC4301] [RFC4301] extension headers (AH [RFC4302] and ESP 401 [RFC4303]) are required if IPsec is to be utilized for network level 402 security functionality. 404 2.3. Link-Layer Security 406 IPv6 relies heavily on the Neighbor Discovery protocol (NDP) RFC4861 407 [RFC4861] to perform a variety of link operations such as discovering 408 other nodes on the link, resolving their link-layer addresses, and 409 finding routers on the link. If not secured, NDP is vulnerable to 410 various attacks such as router/neighbor message spoofing, redirect 411 attacks, Duplicate Address Detection (DAD) DoS attacks, etc. many of 412 these security threats to NDP have been documented in IPv6 ND Trust 413 Models and Threats RFC3756 [RFC3756] and in RFC6583 [RFC6583]. 415 2.3.1. Securing DHCP 417 Dynamic Host Configuration Protocol for IPv6 (DHCPv6), as detailed in 418 RFC3315 [RFC3315], enables DHCP servers to pass configuration 419 parameters such as IPv6 network addresses and other configuration 420 information to IPv6 nodes. DHCP plays an important role in any large 421 network by providing robust stateful configuration and 422 autoregistration of DNS Host Names. 424 The two most common threats to DHCP clients come from malicious 425 (a.k.a. rogue) or unintentionally misconfigured DHCP servers. A 426 malicious DHCP server is established with the intent of providing 427 incorrect configuration information to the client to cause a denial 428 of service attack or mount a man in the middle attack. While 429 unintentionall, a misconfigured DHCP server can have the same impact. 430 Additional threats against DHCP are discussed in the security 431 considerations section of RFC3315 [RFC3315]DHCP-shield. 433 RFC7610 [RFC7610], DHCPv6-Shield, specifies a mechanism for 434 protecting connected DHCPv6 clients against rogue DHCPv6 servers. 435 This mechanism is based on DHCPv6 packet-filtering at the layer-2 436 device; the administrator specifies the interfaces connected to 437 DHCPv6 servers. Of course, extension headers could be leveraged to 438 bypass DHCPv6-Shield unless RFC7112 [RFC7112] is enforced. Another 439 way to secure DHCPv6 would be to use the secure DHCPv6 protocol which 440 is currently work in progress per [I-D.ietf-dhc-sedhcpv6] , but, with 441 no real deployment known by the authors of this document. 443 It is recommended to use DHCP-shield and to analyze the log generated 444 by this security feature. 446 2.3.2. ND/RA Rate Limiting 448 Neighbor Discovery (ND) can be vulnerable to denial of service (DoS) 449 attacks in which a router is forced to perform address resolution for 450 a large number of unassigned addresses. Possible side effects of 451 this attack preclude new devices from joining the network or even 452 worse rendering the last hop router ineffective due to high CPU 453 usage. Easy mitigative steps include rate limiting Neighbor 454 Solicitations, restricting the amount of state reserved for 455 unresolved solicitations, and clever cache/timer management. 457 RFC6583 [RFC6583] discusses the potential for DoS in detail and 458 suggests implementation improvements and operational mitigation 459 techniques that may be used to mitigate or alleviate the impact of 460 such attacks. Here are some feasible mitigation options that can be 461 employed by network operators today: 463 o Ingress filtering of unused addresses by ACL, route filtering, 464 longer than /64 prefix; These require static configuration of the 465 addresses. 467 o Tuning of NDP process (where supported). 469 o Using /127 on point-to-point link per RFC6164 [RFC6164]. 471 Additionally, IPv6 ND uses multicast extensively for signaling 472 messages on the local link to avoid broadcast messages for on-the- 473 wire efficiency. However, this has some side effects on wifi 474 networks, especially a negative impact on battery life of smartphones 475 and other battery operated devices that are connected to such 476 networks. The following drafts are actively discussing methods to 477 rate limit RAs and other ND messages on wifi networks in order to 478 address this issue: 480 o [I-D.thubert-savi-ra-throttler] 482 o [I-D.chakrabarti-nordmark-6man-efficient-nd] 484 2.3.3. ND/RA Filtering 486 Router Advertisement spoofing is a well-known attack vector and has 487 been extensively documented. The presence of rogue RAs, either 488 intentional or malicious, can cause partial or complete failure of 489 operation of hosts on an IPv6 link. For example, a host can select 490 an incorrect router address which can be used as a man-in-the-middle 491 (MITM) attack or can assume wrong prefixes to be used for stateless 492 address configuration (SLAAC). RFC6104 [RFC6104] summarizes the 493 scenarios in which rogue RAs may be observed and presents a list of 494 possible solutions to the problem. RFC6105 [RFC6105] (RA-Guard) 495 describes a solution framework for the rogue RA problem where network 496 segments are designed around switching devices that are capable of 497 identifying invalid RAs and blocking them before the attack packets 498 actually reach the target nodes. 500 However, several evasion techniques that circumvent the protection 501 provided by RA-Guard have surfaced. A key challenge to this 502 mitigation technique is introduced by IPv6 fragmentation. An 503 attacker can conceal the attack by fragmenting his packets into 504 multiple fragments such that the switching device that is responsible 505 for blocking invalid RAs cannot find all the necessary information to 506 perform packet filtering in the same packet. RFC7113 [RFC7113] 507 describes such evasion techniques, and provides advice to RA-Guard 508 implementers such that the aforementioned evasion vectors can be 509 eliminated. 511 Given that the IPv6 Fragmentation Header can be leveraged to 512 circumvent current implementations of RA-Guard, RFC6980 [RFC6980] 513 updates RFC4861 [RFC4861] such that use of the IPv6 Fragmentation 514 Header is forbidden in all Neighbor Discovery messages except 515 "Certification Path Advertisement", thus allowing for simple and 516 effective measures to counter Neighbor Discovery attacks. 518 The Source Address Validation Improvements (SAVI) working group has 519 worked on other ways to mitigate the effects of such attacks. 520 RFC7513 [RFC7513] would help in creating bindings between a DHCPv4 521 RFC2131 [RFC2131] /DHCPv6 RFC3315 [RFC3315] assigned source IP 522 address and a binding anchor RFC7039 [RFC7039] on a SAVI device. 523 Also, RFC6620 [RFC6620] describes how to glean similar bindings when 524 DHCP is not used. The bindings can be used to filter packets 525 generated on the local link with forged source IP address. 527 It is still recommended that RA-Guard be be employed as a first line 528 of defense against common attack vectors including misconfigured 529 hosts. The generated log should also be analyzed to act on 530 violations. 532 2.3.4. 3GPP Link-Layer Security 534 The 3GPP link is a point-to-point like link that has no link-layer 535 address. This implies there can only be an end host (the mobile 536 hand-set) and the first-hop router (i.e., a GPRS Gateway Support Node 537 (GGSN) or a Packet Gateway (PGW)) on that link. The GGSN/PGW never 538 configures a non link-local address on the link using the advertised 539 /64 prefix on it. The advertised prefix must not be used for on-link 540 determination. There is no need for an address resolution on the 541 3GPP link, since there are no link-layer addresses. Furthermore, the 542 GGSN/PGW assigns a prefix that is unique within each 3GPP link that 543 uses IPv6 stateless address autoconfiguration. This avoids the 544 necessity to perform DAD at the network level for every address built 545 by the mobile host. The GGSN/PGW always provides an IID to the 546 cellular host for the purpose of configuring the link-local address 547 and ensures the uniqueness of the IID on the link (i.e., no 548 collisions between its own link-local address and the mobile host's 549 one). 551 The 3GPP link model itself mitigates most of the known NDP-related 552 Denial-of-Service attacks. In practice, the GGSN/PGW only needs to 553 route all traffic to the mobile host that falls under the prefix 554 assigned to it. As there is also a single host on the 3GPP link, 555 there is no need to defend that IPv6 address. 557 See Section 5 of RFC6459 [RFC6459] for a more detailed discussion on 558 the 3GPP link model, NDP on it and the address configuration detail. 560 2.3.5. SeND and CGA 562 SEcure Neighbor Discovery (SeND), as described in RFC3971 [RFC3971], 563 is a mechanism that was designed to secure ND messages. This 564 approach involves the use of new NDP options to carry public key 565 based signatures. Cryptographically Generated Addresses (CGA), as 566 described in RFC3972 [RFC3972], are used to ensure that the sender of 567 a Neighbor Discovery message is the actual "owner" of the claimed 568 IPv6 address. A new NDP option, the CGA option, was introduced and 569 is used to carry the public key and associated parameters. Another 570 NDP option, the RSA Signature option, is used to protect all messages 571 relating to neighbor and Router discovery. 573 SeND protects against: 575 o Neighbor Solicitation/Advertisement Spoofing 577 o Neighbor Unreachability Detection Failure 579 o Duplicate Address Detection DoS Attack 581 o Router Solicitation and Advertisement Attacks 583 o Replay Attacks 585 o Neighbor Discovery DoS Attacks 587 SeND does NOT: 589 o Protect statically configured addresses 591 o Protect addresses configured using fixed identifiers (i.e. EUI- 592 64) 594 o Provide confidentiality for NDP communications 596 o Compensate for an unsecured link - SEND does not require that the 597 addresses on the link and Neighbor Advertisements correspond 599 However, at this time and after many years after their 600 specifications, CGA and SeND do not have wide support from generic 601 operating systems; hence, their usefulness is limited. 603 2.4. Control Plane Security 605 RFC6192 [RFC6192] defines the router control plane. This definition 606 is repeated here for the reader's convenience. 608 Modern router architecture design maintains a strict separation of 609 forwarding and router control plane hardware and software. The 610 router control plane supports routing and management functions. It 611 is generally described as the router architecture hardware and 612 software components for handling packets destined to the device 613 itself as well as building and sending packets originated locally on 614 the device. The forwarding plane is typically described as the 615 router architecture hardware and software components responsible for 616 receiving a packet on an incoming interface, performing a lookup to 617 identify the packet's IP next hop and determine the best outgoing 618 interface towards the destination, and forwarding the packet out 619 through the appropriate outgoing interface. 621 While the forwarding plane is usually implemented in high-speed 622 hardware, the control plane is implemented by a generic processor 623 (named router processor RP) and cannot process packets at a high 624 rate. Hence, this processor can be attacked by flooding its input 625 queue with more packets than it can process. The control plane 626 processor is then unable to process valid control packets and the 627 router can lose OSPF or BGP adjacencies which can cause a severe 628 network disruption. 630 The mitigation technique is: 632 o To drop non-legit control packet before they are queued to the RP 633 (this can be done by a forwarding plane ACL) and 635 o To rate limit the remaining packets to a rate that the RP can 636 sustain. Protocol specific protection should also be done (for 637 example, a spoofed OSPFv3 packet could trigger the execution of 638 the Dijkstra algorithm, therefore the number of Dijsktra execution 639 should be also rate limited). 641 This section will consider several classes of control packets: 643 o Control protocols: routing protocols: such as OSPFv3, BGP and by 644 extension Neighbor Discovery and ICMP 646 o Management protocols: SSH, SNMP, IPfix, etc 648 o Packet exceptions: which are normal data packets which requires a 649 specific processing such as generating a packet-too-big ICMP 650 message or having the hop-by-hop options header. 652 2.4.1. Control Protocols 654 This class includes OSPFv3, BGP, NDP, ICMP. 656 An ingress ACL to be applied on all the router interfaces SHOULD be 657 configured such as: 659 o drop OSPFv3 (identified by Next-Header being 89) and RIPng 660 (identified by UDP port 521) packets from a non link-local address 662 o allow BGP (identified by TCP port 179) packets from all BGP 663 neighbors and drop the others 665 o allow all ICMP packets (transit and to the router interfaces) 667 Note: dropping OSPFv3 packets which are authenticated by IPsec could 668 be impossible on some routers whose ACL are unable to parse the IPsec 669 ESP or AH extension headers. 671 Rate limiting of the valid packets SHOULD be done. The exact 672 configuration obviously depends on the power of the Route Processor. 674 2.4.2. Management Protocols 676 This class includes: SSH, SNMP, syslog, NTP, etc 678 An ingress ACL to be applied on all the router interfaces SHOULD be 679 configured such as: 681 o Drop packets destined to the routers except those belonging to 682 protocols which are used (for example, permit TCP 22 and drop all 683 when only SSH is used); 685 o Drop packets where the source does not match the security policy, 686 for example if SSH connections should only be originated from the 687 NOC, then the ACL should permit TCP port 22 packets only from the 688 NOC prefix. 690 Rate limiting of the valid packets SHOULD be done. The exact 691 configuration obviously depends on the power of the Route Processor. 693 2.4.3. Packet Exceptions 695 This class covers multiple cases where a data plane packet is punted 696 to the route processor because it requires specific processing: 698 o generation of an ICMP packet-too-big message when a data plane 699 packet cannot be forwarded because it is too large; 701 o generation of an ICMP hop-limit-expired message when a data plane 702 packet cannot be forwarded because its hop-limit field has reached 703 0; 705 o generation of an ICMP destination-unreachable message when a data 706 plane packet cannot be forwarded for any reason; 708 o processing of the hop-by-hop options header, new implementations 709 follow section 4.3 of RFC8200 [RFC8200] where this processing is 710 optional; 712 o or more specific to some router implementation: an oversized 713 extension header chain which cannot be processed by the hardware 714 and force the packet to be punted to the generic router CPU. 716 On some routers, not everything can be done by the specialized data 717 plane hardware which requires some packets to be 'punted' to the 718 generic RP. This could include for example the processing of a long 719 extension header chain in order to apply an ACL based on layer 4 720 information. RFC6980 [RFC6980] and more generally RFC7112 [RFC7112] 721 highlights the security implications of oversized extension header 722 chains on routers and updates RFC2460 [RFC2460] such that the first 723 fragment of a packet is required to contain the entire IPv6 header 724 chain. 726 An ingress ACL cannot help to mitigate a control plane attack using 727 those packet exceptions. The only protection for the RP is to limit 728 the rate of those packet exceptions forwarded to the RP, this means 729 that some data plane packets will be dropped without any ICMP 730 messages back to the source which may cause Path MTU holes. 732 In addition to limiting the rate of data plane packets queued to the 733 RP, it is also important to limit the generation rate of ICMP 734 messages both the save the RP but also to prevent an amplification 735 attack using the router as a reflector. 737 2.5. Routing Security 739 Routing security in general can be broadly divided into three 740 sections: 742 1. Authenticating neighbors/peers 744 2. Securing routing updates between peers 746 3. Route filtering 748 [RFC7454] covers these sections specifically for BGP in detail. 750 2.5.1. Authenticating Neighbors/Peers 752 A basic element of routing is the process of forming adjacencies, 753 neighbor, or peering relationships with other routers. From a 754 security perspective, it is very important to establish such 755 relationships only with routers and/or administrative domains that 756 one trusts. A traditional approach has been to use MD5 HMAC, which 757 allows routers to authenticate each other prior to establishing a 758 routing relationship. 760 OSPFv3 can rely on IPsec to fulfill the authentication function. 761 However, it should be noted that IPsec support is not standard on all 762 routing platforms. In some cases, this requires specialized hardware 763 that offloads crypto over to dedicated ASICs or enhanced software 764 images (both of which often come with added financial cost) to 765 provide such functionality. An added detail is to determine whether 766 OSPFv3 IPsec implementations use AH or ESP-Null for integrity 767 protection. In early implementations all OSPFv3 IPsec configurations 768 relied on AH since the details weren't specified in RFC5340 [RFC5340] 769 or RFC2740 [RFC2740] that was obsoleted by the former. However, the 770 document which specifically describes how IPsec should be implemented 771 for OSPFv3 RFC4552 [RFC4552] specifically states that ESP-Null MUST 772 and AH MAY be implemented since it follows the overall IPsec 773 standards wordings. OSPFv3 can also use normal ESP to encrypt the 774 OSPFv3 payload to hide the routing information. 776 RFC7166 [RFC7166] (which obsoletes RFC6506 [RFC6506] changes OSPFv3's 777 reliance on IPsec by appending an authentication trailer to the end 778 of the OSPFv3 packets; it does not specifically authenticate the 779 specific originator of an OSPFv3 packet; rather, it allows a router 780 to confirm that the packet has indeed been issued by a router that 781 had access to the shared authentication key. 783 With all authentication mechanisms, operators should confirm that 784 implementations can support re-keying mechanisms that do not cause 785 outages. There have been instances where any re-keying cause outages 786 and therefore the tradeoff between utilizing this functionality needs 787 to be weighed against the protection it provides. 789 2.5.2. Securing Routing Updates Between Peers 791 IPv6 initially mandated the provisioning of IPsec capability in all 792 nodes. However, in the updated IPv6 Nodes Requirement standard 793 RFC6434 [RFC6434] is now a 'SHOULD' and no more a 'MUST' implement. 794 Theoretically it is possible, and recommended, that communication 795 between two IPv6 nodes, including routers exchanging routing 796 information be encrypted using IPsec. In practice however, deploying 797 IPsec is not always feasible given hardware and software limitations 798 of various platforms deployed, as described in the earlier section. 800 2.5.3. Route Filtering 802 Route filtering policies will be different depending on whether they 803 pertain to edge route filtering vs internal route filtering. At a 804 minimum, IPv6 routing policy as it pertains to routing between 805 different administrative domains should aim to maintain parity with 806 IPv4 from a policy perspective e.g., 808 o Filter internal-use, non-globally routable IPv6 addresses at the 809 perimeter 811 o Discard packets from and to bogon and reserved space (see RFC8190 812 [RFC8190]) 814 o Configure ingress route filters that validate route origin, prefix 815 ownership, etc. through the use of various routing databases, 816 e.g., RADB. There is additional work being done in this area to 817 formally validate the origin ASs of BGP announcements in RFC6810 818 [RFC6810] 820 Some good recommendations for filtering can be found from Team CYMRU 821 at [CYMRU]. 823 2.6. Logging/Monitoring 825 In order to perform forensic research in case of any security 826 incident or to detect abnormal behaviors, network operators should 827 log multiple pieces of information. 829 This includes: 831 o logs of all applications when available (for example web servers); 833 o use of IP Flow Information Export [RFC7011] also known as IPfix; 835 o use of SNMP MIB [RFC4293]; 837 o use of the Neighbor cache; 839 o use of stateful DHCPv6 [RFC3315] lease cache, especially when a 840 relay agent [RFC6221] in layer-2 switches is used; 842 o use of RADIUS [RFC2866] for accounting records. 844 Please note that there are privacy issues related to how those logs 845 are collected, kept and safely discarded. Operators are urged to 846 check their country legislation. 848 All those pieces of information will be used for: 850 o forensic (Section 2.6.2.1) investigations such as who did what and 851 when? 853 o correlation (Section 2.6.2.3): which IP addresses were used by a 854 specific node (assuming the use of privacy extensions addresses 855 [RFC4941]) 857 o inventory (Section 2.6.2.2): which IPv6 nodes are on my network? 859 o abnormal behavior detection (Section 2.6.2.4): unusual traffic 860 patterns are often the symptoms of a abnormal behavior which is in 861 turn a potential attack (denial of services, network scan, a node 862 being part of a botnet, ...) 864 2.6.1. Data Sources 866 This section lists the most important sources of data that are useful 867 for operational security. 869 2.6.1.1. Logs of Applications 871 Those logs are usually text files where the remote IPv6 address is 872 stored in all characters (not binary). This can complicate the 873 processing since one IPv6 address, 2001:db8::1 can be written in 874 multiple ways such as: 876 o 2001:DB8::1 (in uppercase) 878 o 2001:0db8::0001 (with leading 0) 880 o and many other ways including the reverse DNS mapping into a FQDN 881 (which should not be trusted). 883 RFC 5952 [RFC5952] explains this problem in detail and recommends the 884 use of a single canonical format (in short use lower case and 885 suppress leading 0). This memo recommends the use of canonical 886 format [RFC5952] for IPv6 addresses in all possible cases. If the 887 existing application cannot log under the canonical format, then this 888 memo recommends the use an external program in order to canonicalize 889 all IPv6 addresses. 891 For example, this perl script can be used: 893 #!/usr/bin/perl -w 894 use strict ; 895 use warnings ; 896 use Socket ; 897 use Socket6 ; 899 my (@words, $word, $binary_address) ; 901 ## go through the file one line at a time 902 while (my $line = ) { 903 chomp $line; 904 foreach my $word (split /[\s+]/, $line) { 905 $binary_address = inet_pton AF_INET6, $word ; 906 if ($binary_address) { 907 print inet_ntop AF_INET6, $binary_address ; 908 } else { 909 print $word ; 910 } 911 print " " ; 912 } 913 print "\n" ; 914 } 916 2.6.1.2. IP Flow Information Export by IPv6 Routers 918 IPfix [RFC7012] defines some data elements that are useful for 919 security: 921 o in section 5.4 (IP Header fields): nextHeaderIPv6 and 922 sourceIPv6Address; 924 o in section 5.6 (Sub-IP fields) sourceMacAddress. 926 Moreover, IPfix is very efficient in terms of data handling and 927 transport. It can also aggregate flows by a key such as 928 sourceMacAddress in order to have aggregated data associated with a 929 specific sourceMacAddress. This memo recommends the use of IPfix and 930 aggregation on nextHeaderIPv6, sourceIPv6Address and 931 sourceMacAddress. 933 2.6.1.3. SNMP MIB by IPv6 Routers 935 RFC 4293 [RFC4293] defines a Management Information Base (MIB) for 936 the two address families of IP. This memo recommends the use of: 938 o ipIfStatsTable table which collects traffic counters per 939 interface; 941 o ipNetToPhysicalTable table which is the content of the Neighbor 942 cache, i.e. the mapping between IPv6 and data-link layer 943 addresses. 945 2.6.1.4. Neighbor Cache of IPv6 Routers 947 The neighbor cache of routers contains all mappings between IPv6 948 addresses and data-link layer addresses. It is usually available by 949 two means: 951 o the SNMP MIB (Section 2.6.1.3) as explained above; 953 o using NETCONF RFC6241 [RFC6241] to collect the state of the 954 neighbor cache; 956 o also by connecting over a secure management channel (such as SSH) 957 and explicitely requesting a neighbor cache dump via the Command 958 Line Interface or any other monitoring mechanism. 960 The neighbor cache is highly dynamic as mappings are added when a new 961 IPv6 address appears on the network (could be quite often with 962 privacy extension addresses [RFC4941] or when they are removed when 963 the state goes from UNREACH to removed (the default time for a 964 removal per Neighbor Unreachability Detection [RFC4861] algorithm is 965 38 seconds for a typical host such as Windows 7). This means that 966 the content of the neighbor cache must periodically be fetched every 967 30 seconds (to be on the safe side) and stored for later use. 969 This is an important source of information because it is trivial (on 970 a switch not using the SAVI [RFC7039] algorithm) to defeat the 971 mapping between data-link layer address and IPv6 address. Let us 972 rephrase the previous statement: having access to the current and 973 past content of the neighbor cache has a paramount value for forensic 974 and audit trail. 976 Using the approach of one /64 per host (Section 2.1.7) replaces the 977 neighbor cache dumps by a mere caching of the allocated /64 prefix 978 when combined with strict enforcement rule on the router and switches 979 to prevent IPv6 spoofing. 981 2.6.1.5. Stateful DHCPv6 Lease 983 In some networks, IPv6 addresses are managed by stateful DHCPv6 984 server [RFC3315] that leases IPv6 addresses to clients. It is indeed 985 quite similar to DHCP for IPv4 so it can be tempting to use this DHCP 986 lease file to discover the mapping between IPv6 addresses and data- 987 link layer addresses as it was usually done in the IPv4 era. 989 It is not so easy in the IPv6 era because not all nodes will use 990 DHCPv6 (there are nodes which can only do stateless 991 autoconfiguration) but also because DHCPv6 clients are identified not 992 by their hardware-client address as in IPv4 but by a DHCP Unique ID 993 (DUID) which can have several formats: some being the data-link layer 994 address, some being data-link layer address prepended with time 995 information or even an opaque number which is useless for operation 996 security. Moreover, when the DUID is based on the data-link address, 997 this address can be of any interface of the client (such as the 998 wireless interface while the client actually uses its wired interface 999 to connect to the network). 1001 If a lightweight DHCP relay agent [RFC6221] is used in the layer-2 1002 switches, then the DHCP server also receives the Interface-ID 1003 information which could be save in order to identifity the interface 1004 of the switches which received a specific leased IPv6 address. Also, 1005 if a 'normal' (not lightweight) relay agent adds the data-link layer 1006 address in the option for Relay Agent Remote-ID [RFC4649] or RFC6939 1007 [RFC6939], then the DHCPv6 server can keep track of the data-link and 1008 leased IPv6 addresses. 1010 In short, the DHCPv6 lease file is less interesting than in the IPv4 1011 era. DHCPv6 servers that keep the relayed data-link layer address in 1012 addition to the DUID in the lease file do not suffer from this 1013 limitation. 1015 The mapping between data-link layer address and the IPv6 address can 1016 be secured by using switches implementing the SAVI [RFC7513] 1017 algorithms. Of course, this also requires that data-link layer 1018 address is protected by using layer-2 mechanism such as 1019 [IEEE-802.1X]. 1021 2.6.1.6. RADIUS Accounting Log 1023 For interfaces where the user is authenticated via a RADIUS [RFC2866] 1024 server, and if RADIUS accounting is enabled, then the RADIUS server 1025 receives accounting Acct-Status-Type records at the start and at the 1026 end of the connection which include all IPv6 (and IPv4) addresses 1027 used by the user. This technique can be used notably for Wi-Fi 1028 networks with Wi-Fi Protected Address (WPA) or any other IEEE 802.1X 1029 [IEEE-802.1X]wired interface on an Ethernet switch. 1031 2.6.1.7. Other Data Sources 1033 There are other data sources that must be kept exactly as in the IPv4 1034 network: 1036 o historical mapping of IPv6 addresses to users of remote access 1037 VPN; 1039 o historical mapping of MAC address to switch interface in a wired 1040 network. 1042 2.6.2. Use of Collected Data 1044 This section leverages the data collected as described before 1045 (Section 2.6.1) in order to achieve several security benefits. 1047 2.6.2.1. Forensic 1049 The forensic use case is when the network operator must locate an 1050 IPv6 address that was present in the network at a certain time or is 1051 still currently in the network. 1053 The source of information can be, in decreasing order, neighbor 1054 cache, DHCP lease file. Then, the procedure is: 1056 1. based on the IPv6 prefix of the IPv6 address find the router(s) 1057 which are used to reach this prefix (assuming that anti-spoofing 1058 mechanisms are used); 1060 2. based on this limited set of routers, on the incident time and on 1061 IPv6 address to retrieve the data-link address from live neighbor 1062 cache, from the historical data of the neighbor cache, 1064 3. based on the incident time and on the IPv6 address, retrieve the 1065 data-link address from the DHCP lease file (Section 2.6.1.5); 1067 4. based on the data-link layer address, look-up on which switch 1068 interface was this data-link layer address. In the case of 1069 wireless LAN, the RADIUS log should have the mapping between user 1070 identification and the MAC address. If a Configuration 1071 Management Data Base (CMDB) is used, the mapping between the 1072 data-link layer address and a switch port. 1074 At the end of the process, the interface the host originating 1075 malicious activity or the username which was abused for malicious 1076 activity has been determined. 1078 2.6.2.2. Inventory 1080 RFC 7707 [RFC7707] (which obsoletes RFC 5157 [RFC5157]) is about the 1081 difficulties for an attacker to scan an IPv6 network due to the vast 1082 number of IPv6 addresses per link (and why in some case it can stil 1083 be done). While the huge addressing space can sometime be perceived 1084 as a 'protection', it also make the inventory task difficult in an 1085 IPv6 network while it was trivial to do in an IPv4 network (a simple 1086 enumeration of all IPv4 addresses, followed by a ping and a TCP/UDP 1087 port scan). Getting an inventory of all connected devices is of 1088 prime importance for a secure operation of a network. 1090 There are many ways to do an inventory of an IPv6 network. 1092 The first technique is to use the IPfix information and extract the 1093 list of all IPv6 source addresses to find all IPv6 nodes that sent 1094 packets through a router. This is very efficient but alas will not 1095 discover silent node that never transmitted such packets... Also, it 1096 must be noted that link-local addresses will never be discovered by 1097 this means. 1099 The second way is again to use the collected neighbor cache content 1100 to find all IPv6 addresses in the cache. This process will also 1101 discover all link-local addresses. See Section 2.6.1.4. 1103 Another way works only for local network, it consists in sending a 1104 ICMP ECHO_REQUEST to the link-local multicast address ff02::1 which 1105 is all IPv6 nodes on the network. All nodes should reply to this 1106 ECHO_REQUEST per [RFC4443]. 1108 Other techniques involve obtaining data from DNS, parsing log files, 1109 leveraging service discovery such as mDNS RFC6761 [RFC6762] and 1110 RFC6763 [RFC6763]. 1112 Enumerating DNS zones, especially looking at reverse DNS records and 1113 CNAMES, is another common method employed by various tools. As 1114 already metioned in RFC7707 [RFC7707], this allows an attacker to 1115 prune the IPv6 reverse DNS tree, and hence enumerate it in a feasible 1116 time. Furthermore, authoritative servers that allow zone transfers 1117 (AXFR) may be a further information source. 1119 2.6.2.3. Correlation 1121 In an IPv4 network, it is easy to correlate multiple logs, for 1122 example to find events related to a specific IPv4 address. A simple 1123 Unix grep command was enough to scan through multiple text-based 1124 files and extract all lines relevant to a specific IPv4 address. 1126 In an IPv6 network, this is slightly more difficult because different 1127 character strings can express the same IPv6 address. Therefore, the 1128 simple Unix grep command cannot be used. Moreover, an IPv6 node can 1129 have multiple IPv6 addresses. 1131 In order to do correlation in IPv6-related logs, it is advised to 1132 have all logs with canonical IPv6 addresses. Then, the neighbor 1133 cache current (or historical) data set must be searched to find the 1134 data-link layer address of the IPv6 address. Then, the current and 1135 historical neighbor cache data sets must be searched for all IPv6 1136 addresses associated to this data-link layer address: this is the 1137 search set. The last step is to search in all log files (containing 1138 only IPv6 address in canonical format) for any IPv6 addresses in the 1139 search set. 1141 2.6.2.4. Abnormal Behavior Detection 1143 Abnormal behaviors (such as network scanning, spamming, denial of 1144 service) can be detected in the same way as in an IPv4 network 1146 o sudden increase of traffic detected by interface counter (SNMP) or 1147 by aggregated traffic from IPfix records [RFC7012]; 1149 o change of traffic pattern (number of connection per second, number 1150 of connection per host...) with the use of IPfix [RFC7012] 1152 2.6.3. Summary 1154 While some data sources (IPfix, MIB, switch CAM tables, logs, ...) 1155 used in IPv4 are also used in the secure operation of an IPv6 1156 network, the DHCPv6 lease file is less reliable and the neighbor 1157 cache is of prime importance. 1159 The fact that there are multiple ways to express in a character 1160 string the same IPv6 address renders the use of filters mandatory 1161 when correlation must be done. 1163 2.7. Transition/Coexistence Technologies 1165 As it is expected that network will not run in a pure IPv6-only way, 1166 the different transition mechanisms must be deployed and operated in 1167 a secure way. This section proposes operational guidelines for the 1168 most known and deployed transition techniques. 1170 2.7.1. Dual Stack 1172 Dual stack is often the first deployment choice for most existing 1173 network operators without an MPLS core where 6PE RFC4798 [RFC4798] is 1174 quite common. Dual stacking the network offers some advantages over 1175 other transition mechanisms. Firstly, the impact on existing IPv4 1176 operations is reduced. Secondly, in the absence of tunnels or 1177 address translation, the IPv4 and IPv6 traffics are native (easier to 1178 observe) and should have the same network processing (path, quality 1179 of service, ...). Dual stack allows you to gradually turn IPv4 1180 operations down when your IPv6 network is ready for prime time. On 1181 the other hand, the operators have to manage two networks with the 1182 added complexities. 1184 From an operational security perspective, this now means that you 1185 have twice the exposure. One needs to think about protecting both 1186 protocols now. At a minimum, the IPv6 portion of a dual stacked 1187 network should maintain parity with IPv4 from a security policy point 1188 of view. Typically, the following methods are employed to protect 1189 IPv4 networks at the edge: 1191 o ACLs to permit or deny traffic 1193 o Firewalls with stateful packet inspection 1195 It is recommended that these ACLs and/or firewalls be additionally 1196 configured to protect IPv6 communications. Also, given the end-to- 1197 end connectivity that IPv6 provides, it is also recommended that 1198 hosts be fortified against threats. General device hardening 1199 guidelines are provided in Section 2.8 1201 For many years, all host operating systems have IPv6 enabled by 1202 default, so, it is possible even in an 'IPv4-only' network to attack 1203 layer-2 adjacent victims over IPv6 link-local address or over a 1204 global IPv6 address is rogue RA or rogue DHCPv6 addresses are 1205 provided by an attacker. 1207 2.7.2. Transition Mechanisms 1209 There are many tunnels used for specific use cases. Except when 1210 protected by IPsec [RFC4301], all those tunnels have a couple of 1211 security issues (most of them being described in RFC 6169 [RFC6169]); 1213 o tunnel injection: a malevolent person knowing a few pieces of 1214 information (for example the tunnel endpoints and the used 1215 protocol) can forge a packet which looks like a legit and valid 1216 encapsulated packet that will gladly be accepted by the 1217 destination tunnel endpoint, this is a specific case of spoofing; 1219 o traffic interception: no confidentiality is provided by the tunnel 1220 protocols (without the use of IPsec), therefore anybody on the 1221 tunnel path can intercept the traffic and have access to the 1222 clear-text IPv6 packet; combined with the absence of 1223 authentication, a man in the middle attack can also be mounted; 1225 o service theft: as there is no authorization, even a non authorized 1226 user can use a tunnel relay for free (this is a specific case of 1227 tunnel injection); 1229 o reflection attack: another specific use case of tunnel injection 1230 where the attacker injects packets with an IPv4 destination 1231 address not matching the IPv6 address causing the first tunnel 1232 endpoint to re-encapsulate the packet to the destination... Hence, 1233 the final IPv4 destination will not see the original IPv4 address 1234 but only one IPv4 address of the relay router. 1236 o bypassing security policy: if a firewall or an IPS is on the path 1237 of the tunnel, then it will probably neither inspect not detect an 1238 malevolent IPv6 traffic contained in the tunnel. 1240 To mitigate the bypassing of security policies, it is recomended to 1241 block all default configuration tunnels by denying all IPv4 traffic 1242 matching: 1244 o IP protocol 41: this will block ISATAP (Section 2.7.2.2), 6to4 1245 (Section 2.7.2.7), 6rd (Section 2.7.2.3) as well as 6in4 1246 (Section 2.7.2.1) tunnels; 1248 o IP protocol 47: this will block GRE (Section 2.7.2.1) tunnels; 1250 o UDP protocol 3544: this will block the default encapsulation of 1251 Teredo (Section 2.7.2.6) tunnels. 1253 Ingress filtering [RFC2827] should also be applied on all tunnel 1254 endpoints if applicable to prevent IPv6 address spoofing. 1256 As several of the tunnel techniques share the same encapsulation 1257 (i.e. IPv4 protocol 41) and embed the IPv4 address in the IPv6 1258 address, there are a set of well-known looping attacks described in 1259 RFC 6324 [RFC6324], this RFC also proposes mitigation techniques. 1261 2.7.2.1. Site-to-Site Static Tunnels 1263 Site-to-site static tunnels are described in RFC 2529 [RFC2529] and 1264 in GRE [RFC2784]. As the IPv4 endpoints are statically configured 1265 and are not dynamic they are slightly more secure (bi-directional 1266 service theft is mostly impossible) but traffic interception and 1267 tunnel injection are still possible. Therefore, the use of IPsec 1268 [RFC4301] in transport mode and protecting the encapsulated IPv4 1269 packets is recommended for those tunnels. Alternatively, IPsec in 1270 tunnel mode can be used to transport IPv6 traffic over a non-trusted 1271 IPv4 network. 1273 2.7.2.2. ISATAP 1275 ISATAP tunnels [RFC5214] are mainly used within a single 1276 administrative domain and to connect a single IPv6 host to the IPv6 1277 network. This means that endpoints and and the tunnel endpoint are 1278 usually managed by a single entity; therefore, audit trail and strict 1279 anti-spoofing are usually possible and this raises the overall 1280 security. 1282 Special care must be taken to avoid looping attack by implementing 1283 the measures of RFC 6324 [RFC6324] and of RFC6964 [RFC6964]. 1285 IPsec [RFC4301] in transport or tunnel mode can be used to secure the 1286 IPv4 ISATAP traffic to provide IPv6 traffic confidentiality and 1287 prevent service theft. 1289 2.7.2.3. 6rd 1291 While 6rd tunnels share the same encapsulation as 6to4 tunnels 1292 (Section 2.7.2.7), they are designed to be used within a single SP 1293 domain, in other words they are deployed in a more constrained 1294 environment than 6to4 tunnels and have little security issues except 1295 lack of confidentiality. The security considerations (Section 12) of 1296 RFC5969 [RFC5969] describes how to secure the 6rd tunnels. 1298 IPsec [RFC4301] for the transported IPv6 traffic can be used if 1299 confidentiality is important. 1301 2.7.2.4. 6PE and 6VPE 1303 Organizations using MPLS in their core can also use 6PE [RFC4798] and 1304 6VPE RFC4659 [RFC4659] to enable IPv6 access over MPLS. As 6PE and 1305 6VPE are really similar to BGP/MPLS IP VPN described in RFC4364 1306 [RFC4364], the security of these networks is also similar to the one 1307 described in RFC4381 [RFC4381]. It relies on: 1309 o Address space, routing and traffic seperation with the help of VRF 1310 (only applicable to 6VPE); 1312 o Hiding the IPv4 core, hence removing all attacks against 1313 P-routers; 1315 o Securing the routing protocol between CE and PE, in the case of 1316 6PE and 6VPE, link-local addresses (see [RFC7404]) can be used and 1317 as these addresses cannot be reached from outside of the link, the 1318 security of 6PE and 6VPE is even higher than the IPv4 BGP/MPLS IP 1319 VPN. 1321 2.7.2.5. DS-Lite 1323 DS-lite is more a translation mechanism and is therefore analyzed 1324 further (Section 2.7.3.3) in this document. 1326 2.7.2.6. Teredo 1328 Teredo tunnels [RFC4380] are mainly used in a residential environment 1329 because that can easily traverse an IPv4 NAT-PT device thanks to its 1330 UDP encapsulation and they connect a single host to the IPv6 1331 Internet. Teredo shares the same issues as other tunnels: no 1332 authentication, no confidentiality, possible spoofing and reflection 1333 attacks. 1335 IPsec [RFC4301] for the transported IPv6 traffic is recommended. 1337 The biggest threat to Teredo is probably for IPv4-only network as 1338 Teredo has been designed to easily traverse IPV4 NAT-PT devices which 1339 are quite often co-located with a stateful firewall. Therefore, if 1340 the stateful IPv4 firewall allows unrestricted UDP outbound and 1341 accept the return UDP traffic, then Teredo actually punches a hole in 1342 this firewall for all IPv6 traffic to the Internet and from the 1343 Internet. While host policies can be deployed to block Teredo in an 1344 IPv4-only network in order to avoid this firewall bypass, it would be 1345 more efficient to block all UDP outbound traffic at the IPv4 firewall 1346 if deemed possible (of course, at least port 53 should be left open 1347 for DNS traffic). 1349 Teredo is now mostly never used and it is no more automated in most 1350 environment, so, it is less of a threat. 1352 2.7.2.7. 6to4 1354 6to4 tunnels [RFC3056] require a public routable IPv4 address in 1355 order to work correctly. They can be used to provide either one IPv6 1356 host connectivity to the IPv6 Internet or multiple IPv6 networks 1357 connectivity to the IPv6 Internet. The 6to4 relay is usually the 1358 anycast address defined in RFC3068 [RFC3068] which has been 1359 deprecated by RFC7526 [RFC7526], and is no more used by recent 1360 Operating Systems. Some security considerations are explained in 1361 RFC3694 [RFC3964]. 1363 RFC6343 [RFC6343] points out that if an operator provides well- 1364 managed servers and relays for 6to4, non-encapsulated IPv6 packets 1365 will pass through well- defined points (the native IPv6 interfaces of 1366 those servers and relays) at which security mechanisms may be 1367 applied. Client usage of 6to4 by default is now discouraged, and 1368 significant precautions are needed to avoid operational problems. 1370 2.7.2.8. Mapping of Address and Port 1372 With the encapsulation and translation versions of mapping of Address 1373 and Port (MAP-E [RFC7597] and MAP-T [RFC7599]), the access network is 1374 purely an IPv6 network and MAP protocols are used to give IPv4 hosts 1375 on the subscriber network, access to IPv4 hosts on the Internet. The 1376 subscriber router does stateful operations in order to map all 1377 internal IPv4 addresses and layer-4 ports to the IPv4 address and the 1378 set of layer-4 ports received through MAP configuration process. The 1379 SP equipment always does stateless operations (either decapsulation 1380 or stateless translation). Therefore, as opposed to Section 2.7.3.3 1381 there is no state-exhaustion DoS attack against the SP equipment 1382 because there is no state and there is no operation caused by a new 1383 layer-4 connection (no logging operation). 1385 The SP MAP equipment MUST implement all the security considerations 1386 of [RFC7597]; notably, ensuring that the mapping of the IPv4 address 1387 and port are consistent with the configuration. As MAP has a 1388 predictable IPv4 address and port mapping, the audit logs are easier 1389 to manager. 1391 2.7.3. Translation Mechanisms 1393 Translation mechanisms between IPv4 and IPv6 networks are alternative 1394 coexistence strategies while networks transition to IPv6. While a 1395 framework is described in [RFC6144] the specific security 1396 considerations are documented in each individual mechanism. For the 1397 most part they specifically mention interference with IPsec or DNSSEC 1398 deployments, how to mitigate spoofed traffic and what some effective 1399 filtering strategies may be. 1401 2.7.3.1. Carrier-Grade Nat (CGN) 1403 Carrier-Grade NAT (CGN), also called NAT444 CGN or Large Scale NAT 1404 (LSN) or SP NAT is described in [RFC6264] and is utilized as an 1405 interim measure to prolong the use of IPv4 in a large service 1406 provider network until the provider can deploy and effective IPv6 1407 solution. [RFC6598] requested a specific IANA allocated /10 IPv4 1408 address block to be used as address space shared by all access 1409 networks using CGN. This has been allocated as 100.64.0.0/10. 1411 Section 13 of [RFC6269] lists some specific security-related issues 1412 caused by large scale address sharing. The Security Considerations 1413 section of [RFC6598] also lists some specific mitigation techniques 1414 for potential misuse of shared address space. Some Law Enforcement 1415 Agencies have identified CGN as impeding their cyber-crime 1416 investigations (for example Europol press release on CGN 1417 [europol-cgn]). 1419 RFC7422 [RFC7422] suggests the use of deterministic address mapping 1420 in order to reduce logging requirements for CGN. The idea is to have 1421 an algorithm mapping back and forth the internal subscriber to public 1422 ports. 1424 2.7.3.2. NAT64/DNS64 1426 Stateful NAT64 translation [RFC6146] allows IPv6-only clients to 1427 contact IPv4 servers using unicast UDP, TCP, or ICMP. It can be used 1428 in conjunction with DNS64 [RFC6147], a mechanism which synthesizes 1429 AAAA records from existing A records. There is also a stateless 1430 NAT64 [RFC6145] which is similar for the security aspects with the 1431 added benefit of being stateless, so, less prone to a state 1432 exhaustion attack. 1434 The Security Consideration sections of [RFC6146] and [RFC6147] list 1435 the comprehensive issues. A specific issue with the use of NAT64 is 1436 that it will interfere with most IPsec deployments unless UDP 1437 encapsulation is used. DNS64 has an incidence on DNSSEC see section 1438 3.1 of [RFC7050]. 1440 2.7.3.3. DS-Lite 1442 Dual-Stack Lite (DS-Lite) [RFC6333] is a transition technique that 1443 enables a service provider to share IPv4 addresses among customers by 1444 combining two well-known technologies: IP in IP (IPv4-in-IPv6) and 1445 Network Address and Port Translation (NAPT). 1447 Security considerations with respect to DS-Lite mainly revolve around 1448 logging data, preventing DoS attacks from rogue devices (as the AFTR 1449 function is stateful) and restricting service offered by the AFTR 1450 only to registered customers. 1452 Section 11 of [RFC6333] describes important security issues 1453 associated with this technology. 1455 2.8. General Device Hardening 1457 There are many environments which rely too much on the network 1458 infrastructure to disallow malicious traffic to get access to 1459 critical hosts. In new IPv6 deployments it has been common to see 1460 IPv6 traffic enabled but none of the typical access control 1461 mechanisms enabled for IPv6 device access. With the possibility of 1462 network device configuration mistakes and the growth of IPv6 in the 1463 overall Internet it is important to ensure that all individual 1464 devices are hardened agains miscreant behavior. 1466 The following guidelines should be used to ensure appropriate 1467 hardening of the host, be it an individual computer or router, 1468 firewall, load-balancer,server, etc device. 1470 o Restrict access to the device to authorized individuals 1472 o Monitor and audit access to the device 1474 o Turn off any unused services on the end node 1476 o Understand which IPv6 addresses are being used to source traffic 1477 and change defaults if necessary 1479 o Use cryptographically protected protocols for device management if 1480 possible (SCP, SNMPv3, SSH, TLS, etc) 1482 o Use host firewall capabilities to control traffic that gets 1483 processed by upper layer protocols 1485 o Use virus scanners to detect malicious programs 1487 3. Enterprises Specific Security Considerations 1489 Enterprises generally have robust network security policies in place 1490 to protect existing IPv4 networks. These policies have been 1491 distilled from years of experiential knowledge of securing IPv4 1492 networks. At the very least, it is recommended that enterprise 1493 networks have parity between their security policies for both 1494 protocol versions. 1496 Security considerations in the enterprise can be broadly categorized 1497 into two sections - External and Internal. 1499 3.1. External Security Considerations: 1501 The external aspect deals with providing security at the edge or 1502 perimeter of the enterprise network where it meets the service 1503 providers network. This is commonly achieved by enforcing a security 1504 policy either by implementing dedicated firewalls with stateful 1505 packet inspection or a router with ACLs. A common default IPv4 1506 policy on firewalls that could easily be ported to IPv6 is to allow 1507 all traffic outbound while only allowing specific traffic, such as 1508 established sessions, inbound (see also [RFC6092]). Here are a few 1509 more things that could enhance the default policy: 1511 o Filter internal-use IPv6 addresses at the perimeter 1512 o Discard packets from and to bogon and reserved space, see also 1513 [CYMRU] 1515 o Accept certain ICMPv6 messages to allow proper operation of ND and 1516 PMTUD, see also [RFC4890] 1518 o Filter specific extension headers by accepting only the required 1519 ones (white list approach) such as ESP, AH (not forgetting the 1520 required transport layers: ICMP, TCP, UDP, ...) , where possible 1521 at the edge and possibly inside the perimeter; see also 1522 [I-D.gont-opsec-ipv6-eh-filtering] 1524 o Filter packets having an illegal IPv6 headers chain at the 1525 perimeter (and possible inside as well), see Section 2.2 1527 o Filter unneeded services at the perimeter 1529 o Implement anti-spoofing 1531 o Implement appropriate rate-limiters and control-plane policers 1533 3.2. Internal Security Considerations: 1535 The internal aspect deals with providing security inside the 1536 perimeter of the network, including the end host. The most 1537 significant concerns here are related to Neighbor Discovery. At the 1538 network level, it is recommended that all security considerations 1539 discussed in Section 2.3 be reviewed carefully and the 1540 recommendations be considered in-depth as well. 1542 As mentioned in Section 2.6.2, care must be taken when running 1543 automated IPv6-in-IP4 tunnels. 1545 Hosts need to be hardened directly through security policy to protect 1546 against security threats. The host firewall default capabilities 1547 have to be clearly understood, especially 3rd party ones which can 1548 have different settings for IPv4 or IPv6 default permit/deny 1549 behavior. In some cases, 3rd party firewalls have no IPv6 support 1550 whereas the native firewall installed by default has it. General 1551 device hardening guidelines are provided in Section 2.8 1553 It should also be noted that many hosts still use IPv4 for transport 1554 for things like RADIUS, TACACS+, SYSLOG, etc. This will require some 1555 extra level of due diligence on the part of the operator. 1557 4. Service Providers Security Considerations 1559 4.1. BGP 1561 The threats and mitigation techniques are identical between IPv4 and 1562 IPv6. Broadly speaking they are: 1564 o Authenticating the TCP session; 1566 o TTL security (which becomes hop-limit security in IPv6); 1568 o Prefix Filtering. 1570 These are explained in more detail in section Section 2.5. 1572 4.1.1. Remote Triggered Black Hole Filtering 1574 RTBH [RFC5635] works identically in IPv4 and IPv6. IANA has 1575 allocated 100::/64 as discard prefix RFC6666 [RFC6666]. 1577 4.2. Transition Mechanism 1579 SP will typically use transition mechanisms such as 6rd, 6PE, MAP, 1580 DS-Lite which have been analyzed in the transition Section 2.7.2 1581 section. 1583 4.3. Lawful Intercept 1585 The Lawful Intercept requirements are similar for IPv6 and IPv4 1586 architectures and will be subject to the laws enforced in varying 1587 geographic regions. The local issues with each jurisdiction can make 1588 this challenging and both corporate legal and privacy personnel 1589 should be involved in discussions pertaining to what information gets 1590 logged and what the logging retention policies will be. 1592 The target of interception will usually be a residential subscriber 1593 (e.g. his/her PPP session or physical line or CPE MAC address). With 1594 the absence of NAT on the CPE, IPv6 has the provision to allow for 1595 intercepting the traffic from a single host (a /128 target) rather 1596 than the whole set of hosts of a subscriber (which could be a /48, a 1597 /60 or /64). 1599 In contrast, in mobile environments, since the 3GPP specifications 1600 allocate a /64 per device, it may be sufficient to intercept traffic 1601 from the /64 rather than specific /128's (since each time the device 1602 powers up it gets a new IID). 1604 A sample architecture which was written for informational purposes is 1605 found in [RFC3924]. 1607 5. Residential Users Security Considerations 1609 The IETF Homenet working group is working on how IPv6 residential 1610 network should be done; this obviously includes operational security 1611 considerations; but, this is still work in progress. 1613 Residential users have usually less experience and knowledge about 1614 security or networking. As most of the recent hosts, smartphones, 1615 tablets have all IPv6 enabled by default, IPv6 security is important 1616 for those users. Even with an IPv4-only ISP, those users can get 1617 IPv6 Internet access with the help of Teredo tunnels. Several peer- 1618 to-peer programs (notably Bittorrent) support IPv6 and those programs 1619 can initiate a Teredo tunnel through the IPv4 residential gateway, 1620 with the consequence of making the internal host reachable from any 1621 IPv6 host on the Internet. It is therefore recommended that all host 1622 security products (personal firewall, ...) are configured with a 1623 dual-stack security policy. 1625 If the Residential Gateway has IPv6 connectivity, [RFC7084] (which 1626 obsoletes [RFC6204]) defines the requirements of an IPv6 CPE and does 1627 not take position on the debate of default IPv6 security policy as 1628 defined in [RFC6092]: 1630 o outbound only: allowing all internally initiated connections and 1631 block all externally initiated ones, which is a common default 1632 security policy enforced by IPv4 Residential Gateway doing NAT-PT 1633 but it also breaks the end-to-end reachability promise of IPv6. 1634 [RFC6092] lists several recommendations to design such a CPE; 1636 o open/transparent: allowing all internally and externally initiated 1637 connections, therefore restoring the end-to-end nature of the 1638 Internet for the IPv6 traffic but having a different security 1639 policy for IPv6 than for IPv4. 1641 [RFC6092] REC-49 states that a choice must be given to the user to 1642 select one of those two policies. 1644 There is also an alternate solution which has been deployed notably 1645 by Swisscom: open to all outbound and inbound connections at the 1646 exception of an handful of TCP and UDP ports known as vulnerable. 1648 6. Further Reading 1650 There are several documents that describe in more details the 1651 security of an IPv6 network; these documents are not written by the 1652 IETF but are listed here for your convenience: 1654 1. Guidelines for the Secure Deployment of IPv6 [NIST] 1656 2. North American IPv6 Task Force Technology Report - IPv6 Security 1657 Technology Paper [NAv6TF_Security] 1659 3. IPv6 Security [IPv6_Security_Book] 1661 7. Acknowledgements 1663 The authors would like to thank the following people for their useful 1664 comments: Mikael Abrahamsson, Fred Baker, Brian Carpenter, Tim Chown, 1665 Markus deBruen, Tobias Fiebig, Fernando Gont, Jeffry Handal, Panos 1666 Kampanakis, Erik Kline, Jouni Korhonen, Mark Lentczner, Bob 1667 Sleigh,Tarko Tikan, Ole Troan, Bernie Volz (by alphabetical order). 1669 8. IANA Considerations 1671 This memo includes no request to IANA. 1673 9. Security Considerations 1675 This memo attempts to give an overview of security considerations of 1676 operating an IPv6 network both in an IPv6-only network and in 1677 utilizing the most widely deployed IPv4/IPv6 coexistence strategies. 1679 10. References 1681 10.1. Normative References 1683 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1684 Requirement Levels", BCP 14, RFC 2119, 1685 DOI 10.17487/RFC2119, March 1997, 1686 . 1688 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1689 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 1690 December 1998, . 1692 [RFC6104] Chown, T. and S. Venaas, "Rogue IPv6 Router Advertisement 1693 Problem Statement", RFC 6104, DOI 10.17487/RFC6104, 1694 February 2011, . 1696 [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. 1697 Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, 1698 DOI 10.17487/RFC6105, February 2011, 1699 . 1701 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1702 (IPv6) Specification", STD 86, RFC 8200, 1703 DOI 10.17487/RFC8200, July 2017, 1704 . 1706 10.2. Informative References 1708 [CYMRU] "Packet Filter and Route Filter Recommendation for IPv6 at 1709 xSP routers", . 1713 [europol-cgn] 1714 "ARE YOU SHARING THE SAME IP ADDRESS AS A CRIMINAL? LAW 1715 ENFORCEMENT CALL FOR THE END OF CARRIER GRADE NAT (CGN) TO 1716 INCREASE ACCOUNTABILITY ONLINE", October 2017, 1717 . 1722 [I-D.chakrabarti-nordmark-6man-efficient-nd] 1723 Chakrabarti, S., Nordmark, E., Thubert, P., and M. 1724 Wasserman, "IPv6 Neighbor Discovery Optimizations for 1725 Wired and Wireless Networks", draft-chakrabarti-nordmark- 1726 6man-efficient-nd-07 (work in progress), February 2015. 1728 [I-D.gont-opsec-ipv6-eh-filtering] 1729 Gont, F., Will, W., and R. Bonica, "Recommendations on 1730 Filtering of IPv6 Packets Containing IPv6 Extension 1731 Headers", draft-gont-opsec-ipv6-eh-filtering-02 (work in 1732 progress), August 2014. 1734 [I-D.ietf-dhc-sedhcpv6] 1735 Li, L., Jiang, S., Cui, Y., Jinmei, T., Lemon, T., and D. 1736 Zhang, "Secure DHCPv6", draft-ietf-dhc-sedhcpv6-21 (work 1737 in progress), February 2017. 1739 [I-D.ietf-opsec-ipv6-eh-filtering] 1740 Gont, F., LIU, W., and R. Bonica, "Recommendations on the 1741 Filtering of IPv6 Packets Containing IPv6 Extension 1742 Headers", draft-ietf-opsec-ipv6-eh-filtering-04 (work in 1743 progress), October 2017. 1745 [I-D.kampanakis-6man-ipv6-eh-parsing] 1746 Kampanakis, P., "Implementation Guidelines for parsing 1747 IPv6 Extension Headers", draft-kampanakis-6man-ipv6-eh- 1748 parsing-01 (work in progress), August 2014. 1750 [I-D.thubert-savi-ra-throttler] 1751 Thubert, P., "Throttling RAs on constrained interfaces", 1752 draft-thubert-savi-ra-throttler-01 (work in progress), 1753 June 2012. 1755 [IEEE-802.1X] 1756 IEEE, "IEEE Standard for Local and metropolitan area 1757 networks - Port-Based Network Access Control", IEEE Std 1758 802.1X-2010, February 2010. 1760 [IPv6_Security_Book] 1761 Hogg and Vyncke, "IPv6 Security", ISBN 1-58705-594-5, 1762 Publisher CiscoPress, December 2008. 1764 [NAv6TF_Security] 1765 Kaeo, Green, Bound, and Pouffary, "North American IPv6 1766 Task Force Technology Report - IPv6 Security Technology 1767 Paper", 2006, . 1770 [NIST] Frankel, Graveman, Pearce, and Rooks, "Guidelines for the 1771 Secure Deployment of IPv6", 2010, 1772 . 1775 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 1776 Converting Network Protocol Addresses to 48.bit Ethernet 1777 Address for Transmission on Ethernet Hardware", STD 37, 1778 RFC 826, DOI 10.17487/RFC0826, November 1982, 1779 . 1781 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 1782 RFC 2131, DOI 10.17487/RFC2131, March 1997, 1783 . 1785 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 1786 Domains without Explicit Tunnels", RFC 2529, 1787 DOI 10.17487/RFC2529, March 1999, 1788 . 1790 [RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", 1791 RFC 2740, DOI 10.17487/RFC2740, December 1999, 1792 . 1794 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 1795 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 1796 DOI 10.17487/RFC2784, March 2000, 1797 . 1799 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1800 Defeating Denial of Service Attacks which employ IP Source 1801 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 1802 May 2000, . 1804 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, 1805 DOI 10.17487/RFC2866, June 2000, 1806 . 1808 [RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, 1809 DOI 10.17487/RFC2993, November 2000, 1810 . 1812 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 1813 via IPv4 Clouds", RFC 3056, DOI 10.17487/RFC3056, February 1814 2001, . 1816 [RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", 1817 RFC 3068, DOI 10.17487/RFC3068, June 2001, 1818 . 1820 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 1821 C., and M. Carney, "Dynamic Host Configuration Protocol 1822 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 1823 2003, . 1825 [RFC3627] Savola, P., "Use of /127 Prefix Length Between Routers 1826 Considered Harmful", RFC 3627, DOI 10.17487/RFC3627, 1827 September 2003, . 1829 [RFC3756] Nikander, P., Ed., Kempf, J., and E. Nordmark, "IPv6 1830 Neighbor Discovery (ND) Trust Models and Threats", 1831 RFC 3756, DOI 10.17487/RFC3756, May 2004, 1832 . 1834 [RFC3924] Baker, F., Foster, B., and C. Sharp, "Cisco Architecture 1835 for Lawful Intercept in IP Networks", RFC 3924, 1836 DOI 10.17487/RFC3924, October 2004, 1837 . 1839 [RFC3964] Savola, P. and C. Patel, "Security Considerations for 1840 6to4", RFC 3964, DOI 10.17487/RFC3964, December 2004, 1841 . 1843 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 1844 "SEcure Neighbor Discovery (SEND)", RFC 3971, 1845 DOI 10.17487/RFC3971, March 2005, 1846 . 1848 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 1849 RFC 3972, DOI 10.17487/RFC3972, March 2005, 1850 . 1852 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1853 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 1854 . 1856 [RFC4293] Routhier, S., Ed., "Management Information Base for the 1857 Internet Protocol (IP)", RFC 4293, DOI 10.17487/RFC4293, 1858 April 2006, . 1860 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1861 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 1862 December 2005, . 1864 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 1865 DOI 10.17487/RFC4302, December 2005, 1866 . 1868 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1869 RFC 4303, DOI 10.17487/RFC4303, December 2005, 1870 . 1872 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1873 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 1874 2006, . 1876 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 1877 Network Address Translations (NATs)", RFC 4380, 1878 DOI 10.17487/RFC4380, February 2006, 1879 . 1881 [RFC4381] Behringer, M., "Analysis of the Security of BGP/MPLS IP 1882 Virtual Private Networks (VPNs)", RFC 4381, 1883 DOI 10.17487/RFC4381, February 2006, 1884 . 1886 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 1887 Control Message Protocol (ICMPv6) for the Internet 1888 Protocol Version 6 (IPv6) Specification", STD 89, 1889 RFC 4443, DOI 10.17487/RFC4443, March 2006, 1890 . 1892 [RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality 1893 for OSPFv3", RFC 4552, DOI 10.17487/RFC4552, June 2006, 1894 . 1896 [RFC4649] Volz, B., "Dynamic Host Configuration Protocol for IPv6 1897 (DHCPv6) Relay Agent Remote-ID Option", RFC 4649, 1898 DOI 10.17487/RFC4649, August 2006, 1899 . 1901 [RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur, 1902 "BGP-MPLS IP Virtual Private Network (VPN) Extension for 1903 IPv6 VPN", RFC 4659, DOI 10.17487/RFC4659, September 2006, 1904 . 1906 [RFC4798] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur, 1907 "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 1908 Provider Edge Routers (6PE)", RFC 4798, 1909 DOI 10.17487/RFC4798, February 2007, 1910 . 1912 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1913 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1914 DOI 10.17487/RFC4861, September 2007, 1915 . 1917 [RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and 1918 E. Klein, "Local Network Protection for IPv6", RFC 4864, 1919 DOI 10.17487/RFC4864, May 2007, 1920 . 1922 [RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering 1923 ICMPv6 Messages in Firewalls", RFC 4890, 1924 DOI 10.17487/RFC4890, May 2007, 1925 . 1927 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 1928 Extensions for Stateless Address Autoconfiguration in 1929 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 1930 . 1932 [RFC4942] Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/ 1933 Co-existence Security Considerations", RFC 4942, 1934 DOI 10.17487/RFC4942, September 2007, 1935 . 1937 [RFC5157] Chown, T., "IPv6 Implications for Network Scanning", 1938 RFC 5157, DOI 10.17487/RFC5157, March 2008, 1939 . 1941 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 1942 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 1943 DOI 10.17487/RFC5214, March 2008, 1944 . 1946 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 1947 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 1948 . 1950 [RFC5635] Kumari, W. and D. McPherson, "Remote Triggered Black Hole 1951 Filtering with Unicast Reverse Path Forwarding (uRPF)", 1952 RFC 5635, DOI 10.17487/RFC5635, August 2009, 1953 . 1955 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 1956 Address Text Representation", RFC 5952, 1957 DOI 10.17487/RFC5952, August 2010, 1958 . 1960 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 1961 Infrastructures (6rd) -- Protocol Specification", 1962 RFC 5969, DOI 10.17487/RFC5969, August 2010, 1963 . 1965 [RFC6092] Woodyatt, J., Ed., "Recommended Simple Security 1966 Capabilities in Customer Premises Equipment (CPE) for 1967 Providing Residential IPv6 Internet Service", RFC 6092, 1968 DOI 10.17487/RFC6092, January 2011, 1969 . 1971 [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 1972 IPv4/IPv6 Translation", RFC 6144, DOI 10.17487/RFC6144, 1973 April 2011, . 1975 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 1976 Algorithm", RFC 6145, DOI 10.17487/RFC6145, April 2011, 1977 . 1979 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 1980 NAT64: Network Address and Protocol Translation from IPv6 1981 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 1982 April 2011, . 1984 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 1985 Beijnum, "DNS64: DNS Extensions for Network Address 1986 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 1987 DOI 10.17487/RFC6147, April 2011, 1988 . 1990 [RFC6164] Kohno, M., Nitzan, B., Bush, R., Matsuzaki, Y., Colitti, 1991 L., and T. Narten, "Using 127-Bit IPv6 Prefixes on Inter- 1992 Router Links", RFC 6164, DOI 10.17487/RFC6164, April 2011, 1993 . 1995 [RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, "Security 1996 Concerns with IP Tunneling", RFC 6169, 1997 DOI 10.17487/RFC6169, April 2011, 1998 . 2000 [RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the 2001 Router Control Plane", RFC 6192, DOI 10.17487/RFC6192, 2002 March 2011, . 2004 [RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O. 2005 Troan, Ed., "Basic Requirements for IPv6 Customer Edge 2006 Routers", RFC 6204, DOI 10.17487/RFC6204, April 2011, 2007 . 2009 [RFC6221] Miles, D., Ed., Ooghe, S., Dec, W., Krishnan, S., and A. 2010 Kavanagh, "Lightweight DHCPv6 Relay Agent", RFC 6221, 2011 DOI 10.17487/RFC6221, May 2011, 2012 . 2014 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 2015 and A. Bierman, Ed., "Network Configuration Protocol 2016 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 2017 . 2019 [RFC6264] Jiang, S., Guo, D., and B. Carpenter, "An Incremental 2020 Carrier-Grade NAT (CGN) for IPv6 Transition", RFC 6264, 2021 DOI 10.17487/RFC6264, June 2011, 2022 . 2024 [RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and 2025 P. Roberts, "Issues with IP Address Sharing", RFC 6269, 2026 DOI 10.17487/RFC6269, June 2011, 2027 . 2029 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 2030 Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011, 2031 . 2033 [RFC6302] Durand, A., Gashinsky, I., Lee, D., and S. Sheppard, 2034 "Logging Recommendations for Internet-Facing Servers", 2035 BCP 162, RFC 6302, DOI 10.17487/RFC6302, June 2011, 2036 . 2038 [RFC6324] Nakibly, G. and F. Templin, "Routing Loop Attack Using 2039 IPv6 Automatic Tunnels: Problem Statement and Proposed 2040 Mitigations", RFC 6324, DOI 10.17487/RFC6324, August 2011, 2041 . 2043 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 2044 Stack Lite Broadband Deployments Following IPv4 2045 Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011, 2046 . 2048 [RFC6343] Carpenter, B., "Advisory Guidelines for 6to4 Deployment", 2049 RFC 6343, DOI 10.17487/RFC6343, August 2011, 2050 . 2052 [RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node 2053 Requirements", RFC 6434, DOI 10.17487/RFC6434, December 2054 2011, . 2056 [RFC6459] Korhonen, J., Ed., Soininen, J., Patil, B., Savolainen, 2057 T., Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation 2058 Partnership Project (3GPP) Evolved Packet System (EPS)", 2059 RFC 6459, DOI 10.17487/RFC6459, January 2012, 2060 . 2062 [RFC6506] Bhatia, M., Manral, V., and A. Lindem, "Supporting 2063 Authentication Trailer for OSPFv3", RFC 6506, 2064 DOI 10.17487/RFC6506, February 2012, 2065 . 2067 [RFC6547] George, W., "RFC 3627 to Historic Status", RFC 6547, 2068 DOI 10.17487/RFC6547, February 2012, 2069 . 2071 [RFC6564] Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and 2072 M. Bhatia, "A Uniform Format for IPv6 Extension Headers", 2073 RFC 6564, DOI 10.17487/RFC6564, April 2012, 2074 . 2076 [RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational 2077 Neighbor Discovery Problems", RFC 6583, 2078 DOI 10.17487/RFC6583, March 2012, 2079 . 2081 [RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and 2082 M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address 2083 Space", BCP 153, RFC 6598, DOI 10.17487/RFC6598, April 2084 2012, . 2086 [RFC6620] Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS 2087 SAVI: First-Come, First-Served Source Address Validation 2088 Improvement for Locally Assigned IPv6 Addresses", 2089 RFC 6620, DOI 10.17487/RFC6620, May 2012, 2090 . 2092 [RFC6666] Hilliard, N. and D. Freedman, "A Discard Prefix for IPv6", 2093 RFC 6666, DOI 10.17487/RFC6666, August 2012, 2094 . 2096 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 2097 DOI 10.17487/RFC6762, February 2013, 2098 . 2100 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 2101 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 2102 . 2104 [RFC6810] Bush, R. and R. Austein, "The Resource Public Key 2105 Infrastructure (RPKI) to Router Protocol", RFC 6810, 2106 DOI 10.17487/RFC6810, January 2013, 2107 . 2109 [RFC6939] Halwasia, G., Bhandari, S., and W. Dec, "Client Link-Layer 2110 Address Option in DHCPv6", RFC 6939, DOI 10.17487/RFC6939, 2111 May 2013, . 2113 [RFC6964] Templin, F., "Operational Guidance for IPv6 Deployment in 2114 IPv4 Sites Using the Intra-Site Automatic Tunnel 2115 Addressing Protocol (ISATAP)", RFC 6964, 2116 DOI 10.17487/RFC6964, May 2013, 2117 . 2119 [RFC6980] Gont, F., "Security Implications of IPv6 Fragmentation 2120 with IPv6 Neighbor Discovery", RFC 6980, 2121 DOI 10.17487/RFC6980, August 2013, 2122 . 2124 [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, 2125 "Specification of the IP Flow Information Export (IPFIX) 2126 Protocol for the Exchange of Flow Information", STD 77, 2127 RFC 7011, DOI 10.17487/RFC7011, September 2013, 2128 . 2130 [RFC7012] Claise, B., Ed. and B. Trammell, Ed., "Information Model 2131 for IP Flow Information Export (IPFIX)", RFC 7012, 2132 DOI 10.17487/RFC7012, September 2013, 2133 . 2135 [RFC7039] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, Ed., 2136 "Source Address Validation Improvement (SAVI) Framework", 2137 RFC 7039, DOI 10.17487/RFC7039, October 2013, 2138 . 2140 [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing 2141 of IPv6 Extension Headers", RFC 7045, 2142 DOI 10.17487/RFC7045, December 2013, 2143 . 2145 [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of 2146 the IPv6 Prefix Used for IPv6 Address Synthesis", 2147 RFC 7050, DOI 10.17487/RFC7050, November 2013, 2148 . 2150 [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic 2151 Requirements for IPv6 Customer Edge Routers", RFC 7084, 2152 DOI 10.17487/RFC7084, November 2013, 2153 . 2155 [RFC7112] Gont, F., Manral, V., and R. Bonica, "Implications of 2156 Oversized IPv6 Header Chains", RFC 7112, 2157 DOI 10.17487/RFC7112, January 2014, 2158 . 2160 [RFC7113] Gont, F., "Implementation Advice for IPv6 Router 2161 Advertisement Guard (RA-Guard)", RFC 7113, 2162 DOI 10.17487/RFC7113, February 2014, 2163 . 2165 [RFC7166] Bhatia, M., Manral, V., and A. Lindem, "Supporting 2166 Authentication Trailer for OSPFv3", RFC 7166, 2167 DOI 10.17487/RFC7166, March 2014, 2168 . 2170 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 2171 Interface Identifiers with IPv6 Stateless Address 2172 Autoconfiguration (SLAAC)", RFC 7217, 2173 DOI 10.17487/RFC7217, April 2014, 2174 . 2176 [RFC7381] Chittimaneni, K., Chown, T., Howard, L., Kuarsingh, V., 2177 Pouffary, Y., and E. Vyncke, "Enterprise IPv6 Deployment 2178 Guidelines", RFC 7381, DOI 10.17487/RFC7381, October 2014, 2179 . 2181 [RFC7404] Behringer, M. and E. Vyncke, "Using Only Link-Local 2182 Addressing inside an IPv6 Network", RFC 7404, 2183 DOI 10.17487/RFC7404, November 2014, 2184 . 2186 [RFC7422] Donley, C., Grundemann, C., Sarawat, V., Sundaresan, K., 2187 and O. Vautrin, "Deterministic Address Mapping to Reduce 2188 Logging in Carrier-Grade NAT Deployments", RFC 7422, 2189 DOI 10.17487/RFC7422, December 2014, 2190 . 2192 [RFC7454] Durand, J., Pepelnjak, I., and G. Doering, "BGP Operations 2193 and Security", BCP 194, RFC 7454, DOI 10.17487/RFC7454, 2194 February 2015, . 2196 [RFC7513] Bi, J., Wu, J., Yao, G., and F. Baker, "Source Address 2197 Validation Improvement (SAVI) Solution for DHCP", 2198 RFC 7513, DOI 10.17487/RFC7513, May 2015, 2199 . 2201 [RFC7526] Troan, O. and B. Carpenter, Ed., "Deprecating the Anycast 2202 Prefix for 6to4 Relay Routers", BCP 196, RFC 7526, 2203 DOI 10.17487/RFC7526, May 2015, 2204 . 2206 [RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S., 2207 Murakami, T., and T. Taylor, Ed., "Mapping of Address and 2208 Port with Encapsulation (MAP-E)", RFC 7597, 2209 DOI 10.17487/RFC7597, July 2015, 2210 . 2212 [RFC7599] Li, X., Bao, C., Dec, W., Ed., Troan, O., Matsushima, S., 2213 and T. Murakami, "Mapping of Address and Port using 2214 Translation (MAP-T)", RFC 7599, DOI 10.17487/RFC7599, July 2215 2015, . 2217 [RFC7610] Gont, F., Liu, W., and G. Van de Velde, "DHCPv6-Shield: 2218 Protecting against Rogue DHCPv6 Servers", BCP 199, 2219 RFC 7610, DOI 10.17487/RFC7610, August 2015, 2220 . 2222 [RFC7707] Gont, F. and T. Chown, "Network Reconnaissance in IPv6 2223 Networks", RFC 7707, DOI 10.17487/RFC7707, March 2016, 2224 . 2226 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 2227 Considerations for IPv6 Address Generation Mechanisms", 2228 RFC 7721, DOI 10.17487/RFC7721, March 2016, 2229 . 2231 [RFC7872] Gont, F., Linkova, J., Chown, T., and W. Liu, 2232 "Observations on the Dropping of Packets with IPv6 2233 Extension Headers in the Real World", RFC 7872, 2234 DOI 10.17487/RFC7872, June 2016, 2235 . 2237 [RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu, 2238 "Recommendation on Stable IPv6 Interface Identifiers", 2239 RFC 8064, DOI 10.17487/RFC8064, February 2017, 2240 . 2242 [RFC8190] Bonica, R., Cotton, M., Haberman, B., and L. Vegoda, 2243 "Updates to the Special-Purpose IP Address Registries", 2244 BCP 153, RFC 8190, DOI 10.17487/RFC8190, June 2017, 2245 . 2247 [RFC8273] Brzozowski, J. and G. Van de Velde, "Unique IPv6 Prefix 2248 per Host", RFC 8273, DOI 10.17487/RFC8273, December 2017, 2249 . 2251 [SCANNING] 2252 "Mapping the Great Void - Smarter scanning for IPv6", 2253 . 2256 Authors' Addresses 2258 Eric Vyncke (editor) 2259 Cisco 2260 De Kleetlaan 6a 2261 Diegem 1831 2262 Belgium 2264 Phone: +32 2 778 4677 2265 Email: evyncke@cisco.com 2266 Kiran K. Chittimaneni 2267 Dropbox Inc. 2268 185 Berry Street, Suite 400 2269 San Francisco, CA 94107 2270 USA 2272 Email: kk@dropbox.com 2274 Merike Kaeo 2275 Double Shot Security 2276 3518 Fremont Ave N 363 2277 Seattle 98103 2278 USA 2280 Phone: +12066696394 2281 Email: merike@doubleshotsecurity.com 2283 Enno Rey 2284 ERNW 2285 Carl-Bosch-Str. 4 2286 Heidelberg, Baden-Wuertemberg 69115 2287 Germany 2289 Phone: +49 6221 480390 2290 Email: erey@ernw.de