idnits 2.17.1 draft-ietf-opsec-v6-06.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 (March 9, 2015) is 3336 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'IEEE-802.1X' is defined on line 1565, but no explicit reference was found in the text == Outdated reference: A later version (-08) exists of draft-ietf-6man-ipv6-address-generation-privacy-04 == Outdated reference: A later version (-08) exists of draft-ietf-opsec-dhcpv6-shield-06 == Outdated reference: A later version (-13) exists of draft-ietf-softwire-map-12 -- 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 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: 0 errors (**), 0 flaws (~~), 6 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OPSEC K. Chittimaneni 3 Internet-Draft Dropbox Inc. 4 Intended status: Informational M. Kaeo 5 Expires: September 10, 2015 Double Shot Security 6 E. Vyncke 7 Cisco 8 March 9, 2015 10 Operational Security Considerations for IPv6 Networks 11 draft-ietf-opsec-v6-06 13 Abstract 15 Knowledge and experience on how to operate IPv4 securely is 16 available: whether it is the Internet or an enterprise internal 17 network. However, IPv6 presents some new security challenges. RFC 18 4942 describes the security issues in the protocol but network 19 managers also need a more practical, operations-minded document to 20 enumerate advantages and/or disadvantages of certain choices. 22 This document analyzes the operational security issues in all places 23 of a network (service providers, enterprises and residential users) 24 and proposes technical and procedural mitigations techniques. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on September 10, 2015. 43 Copyright Notice 45 Copyright (c) 2015 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 62 2. Generic Security Considerations . . . . . . . . . . . . . . . 3 63 2.1. Addressing Architecture . . . . . . . . . . . . . . . . . 4 64 2.1.1. Statically Configured Addresses . . . . . . . . . . . 4 65 2.1.2. Use of ULAs . . . . . . . . . . . . . . . . . . . . . 4 66 2.1.3. Point-to-Point Links . . . . . . . . . . . . . . . . 5 67 2.1.4. Temporary Addresses - Privacy Extensions for SLAAC . 6 68 2.1.5. Privacy consideration of Addresses . . . . . . . . . 7 69 2.1.6. DHCP/DNS Considerations . . . . . . . . . . . . . . . 7 70 2.2. Link-Layer Security . . . . . . . . . . . . . . . . . . . 7 71 2.2.1. SeND and CGA . . . . . . . . . . . . . . . . . . . . 7 72 2.2.2. Securing DHCP . . . . . . . . . . . . . . . . . . . . 8 73 2.2.3. ND/RA Rate Limiting . . . . . . . . . . . . . . . . . 9 74 2.2.4. ND/RA Filtering . . . . . . . . . . . . . . . . . . . 9 75 2.2.5. 3GPP Link-Layer Security . . . . . . . . . . . . . . 10 76 2.3. Control Plane Security . . . . . . . . . . . . . . . . . 11 77 2.3.1. Control Protocols . . . . . . . . . . . . . . . . . . 12 78 2.3.2. Management Protocols . . . . . . . . . . . . . . . . 13 79 2.3.3. Packet Exceptions . . . . . . . . . . . . . . . . . . 13 80 2.4. Routing Security . . . . . . . . . . . . . . . . . . . . 14 81 2.4.1. Authenticating Neighbors/Peers . . . . . . . . . . . 14 82 2.4.2. Securing Routing Updates Between Peers . . . . . . . 15 83 2.4.3. Route Filtering . . . . . . . . . . . . . . . . . . . 15 84 2.5. Logging/Monitoring . . . . . . . . . . . . . . . . . . . 16 85 2.5.1. Data Sources . . . . . . . . . . . . . . . . . . . . 17 86 2.5.2. Use of Collected Data . . . . . . . . . . . . . . . . 20 87 2.5.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 22 88 2.6. Transition/Coexistence Technologies . . . . . . . . . . . 23 89 2.6.1. Dual Stack . . . . . . . . . . . . . . . . . . . . . 23 90 2.6.2. Transition Mechanisms . . . . . . . . . . . . . . . . 23 91 2.6.3. Translation Mechanisms . . . . . . . . . . . . . . . 27 92 2.7. General Device Hardening . . . . . . . . . . . . . . . . 28 93 3. Enterprises Specific Security Considerations . . . . . . . . 29 94 3.1. External Security Considerations: . . . . . . . . . . . . 29 95 3.2. Internal Security Considerations: . . . . . . . . . . . . 30 97 4. Service Providers Security Considerations . . . . . . . . . . 30 98 4.1. BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 99 4.1.1. Remote Triggered Black Hole Filtering . . . . . . . . 30 100 4.2. Transition Mechanism . . . . . . . . . . . . . . . . . . 31 101 4.3. Lawful Intercept . . . . . . . . . . . . . . . . . . . . 31 102 5. Residential Users Security Considerations . . . . . . . . . . 31 103 6. Further Reading . . . . . . . . . . . . . . . . . . . . . . . 32 104 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 105 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 106 9. Security Considerations . . . . . . . . . . . . . . . . . . . 33 107 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 108 10.1. Normative References . . . . . . . . . . . . . . . . . . 33 109 10.2. Informative References . . . . . . . . . . . . . . . . . 33 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 112 1. Introduction 114 Running an IPv6 network is new for most operators not only because 115 they are not yet used to large scale IPv6 networks but also because 116 there are subtle differences between IPv4 and IPv6 especially with 117 respect to security. For example, all layer-2 interactions are now 118 done by Neighbor Discovery Protocol [RFC4861] rather than by Address 119 Resolution Protocol [RFC0826]. Also, there are subtle differences 120 between NAT44 and NPTv6 [RFC6296] which are explicitly pointed out in 121 the latter's security considerations section. 123 IPv6 networks are deployed using a variety of techniques, each of 124 which have their own specific security concerns. 126 This document complements [RFC4942] by listing all security issues 127 when operating a network utilizing varying transition technologies 128 and updating with ones that have been standardized since 2007. It 129 also provides more recent operational deployment experiences where 130 warranted. 132 1.1. Requirements Language 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 136 document are to be interpreted as described in [RFC2119] when they 137 appear in ALL CAPS. These words may also appear in this document in 138 lower case as plain English words, absent their normative meanings. 140 2. Generic Security Considerations 141 2.1. Addressing Architecture 143 IPv6 address allocations and overall architecture are an important 144 part of securing IPv6. Typically what you initially design for will 145 be what you use for a very long time. Although initially IPv6 was 146 thought to make renumbering easy, in practice, it would be extremely 147 difficult to renumber. 149 Once an address allocation has been assigned, there should be some 150 thought given to an overall address allocation plan. With the 151 abundance of address space available, an address allocation may be 152 structured around services along with geographic locations, which 153 then can be a basis for more structured security policies to permit 154 or deny services between geographic regions. 156 A common question is whether companies should use PI vs PA space 157 [RFC7381] but from a security perspective there is little difference. 158 However, one aspect to keep in mind is who has ownership of the 159 address space and who is responsible if/when Law Enforcement may need 160 to enforce restrictions on routability of the space due to malicious 161 criminal activity. 163 2.1.1. Statically Configured Addresses 165 When considering how to assign statically configured addresses it is 166 necessary to take into consideration the effectiveness of perimeter 167 security in a given environment. There is a trade-off between ease 168 of operational deployment where some portions of the IPv6 address 169 could be easily recognizable for operational debugging and 170 troubleshooting versus the risk of scanning; [SCANNING] shows that 171 there are scientifically based mechanisms that make scanning for IPv6 172 reachable nodes more realizable than expected. The use of common 173 multicast groups which are defined for important networked devices 174 and the use of commonly repeated addresses could make it easy to 175 figure out which devices are name servers, routers or other critical 176 devices. 178 While in some environments the perimeter security is so poor that 179 obfuscating addresses is considered a benefit; it is a better 180 practice to ensure that perimeter rules are actively checked and 181 enforced and that statically configured addresses follow some logical 182 allocation scheme for ease of operation. 184 2.1.2. Use of ULAs 186 ULAs are intended for scenarios where IP addresses will not have 187 global scope. The implicit expectation from the RFC is that all ULAs 188 will be randomly created as /48s. Any use of ULAs that are not 189 created as a /48 violates [RFC4193]. 191 ULAs could be useful for infrastructure hiding as described in 192 [RFC4864]; Alternatively Link-Local addresses [RFC7404] could also be 193 used. Although ULAs are supposed to be used in conjunction with 194 global addresses for hosts that desire external connectivity, a few 195 operators chose to use ULAs in conjunction with some sort of address 196 translation at the border in order to maintain a perception of parity 197 between their IPv4 and IPv6 setup. Some operators believe that 198 stateful IPv6 Network Address and Port Translation (NAPT) provides 199 some security not provided by NPTv6 (the authors of this document do 200 not share this point of view). The latter would be problematic in 201 trying to track specific machines that may source malware although 202 this is less of an issue if appropriate logging is done which 203 includes utilizing accurate timestamps and logging a node's source 204 ports [RFC6302]. 206 The use of ULA does not isolate 'by magic' the part of the network 207 using ULA from other parts of the network (including the Internet). 208 Although section 4.1 of [RFC4193] explicitly states "If BGP is being 209 used at the site border with an ISP, the default BGP configuration 210 must filter out any Local IPv6 address prefixes, both incoming and 211 outgoing.", the operational reality is that this guideline is not 212 always followed. As written, RFC4193 makes no changes to default 213 routing behavior of exterior protocols. Therefore, routers will 214 happily forward packets whose source or destination address is ULA as 215 long as they have a route to the destination and there is no ACL 216 blocking those packets. This means that using ULA does not prevent 217 route and packet filters to be implemented and monitored. This also 218 means that all Internet transit networks should consider ULA as 219 source or destination as bogons packets and drop them. 221 It is important to carefully weigh the benefits of using ULAs versus 222 utilizing a section of the global allocation and creating a more 223 effective filtering strategy. A typical argument is that there are 224 too many mistakes made with filters and ULAs make things easier to 225 hide machines. 227 2.1.3. Point-to-Point Links 229 [RFC6164] recommends the use of /127 for inter-router point-to-point 230 links. A /127 prevents the ping-pong attack between routers. 231 However, it should be noted that at the time of this writing, there 232 are still many networks out there that follow the advice provided by 233 [RFC3627] (obsoleted and marked Historic by [RFC6547]) and therefore 234 continue to use /64's and/or /112's. We recommend that the guidance 235 provided by RFC6164 be followed. 237 Some environments are also using link-local addressing for point-to- 238 point links. While this practice could further reduce the attack 239 surface against infrastructure devices, the operational disadvantages 240 need also to be carefully considered [RFC7404]. 242 2.1.4. Temporary Addresses - Privacy Extensions for SLAAC 244 Normal stateless address autoconfiguration (SLAAC) relies on the 245 automatically generated EUI-64 address, which together with the /64 246 prefix makes up the global unique IPv6 address. The EUI-64 address 247 is generated from the MAC address. Randomly generating an interface 248 ID, as described in [RFC4941], is part of SLAAC with so-called 249 privacy extension addresses and used to address some privacy 250 concerns. Privacy extension addresses a.k.a. temporary addresses may 251 help to mitigate the correlation of activities of a node within the 252 same network, and may also reduce the attack exposure window. 254 As privacy extension addresses could also be used to obfuscate some 255 malevolent activities (whether on purpose or not), it is advised in 256 scenarios where user attribution is important to disable SLAAC and 257 rely only on DHCPv6. However, in scenarios where anonymity is a 258 strong desire since protecting user privacy is more important than 259 user attribution, privacy extension addresses should be used 261 Using privacy extension addresses prevents the operator from building 262 a priori host specific access control lists (ACLs). It must be noted 263 that recent versions of Windows do not use the MAC address anymore to 264 build the stable address but use a mechanism similar to the one 265 described in [RFC7217], this also means that such an ACL cannot be 266 configured based solely on the MAC address of the nodes, diminishing 267 the value of such ACL. On the other hand, different VLANs are often 268 used to segregate users, then ACL can rely on a /64 prefix per VLAN 269 rather than a per host ACL entry. 271 The decision to utilize privacy extension addresses can come down to 272 whether the network is managed versus unmanaged. In some 273 environments full visibility into the network is required at all 274 times which requires that all traffic be attributable to where it is 275 sourced or where it is destined to within a specific network. This 276 situation is dependent on what level of logging is performed. If 277 logging considerations include utilizing accurate timestamps and 278 logging a node's source ports [RFC6302] then there should always 279 exist appropriate user attribution needed to get to the source of any 280 malware originator or source of criminal activity. 282 Disabling SLAAC and privacy extensions addresses can be done by 283 sending Router Advertisement with a hint to use DHCPv6 by setting the 284 M-bit but also disabling SLAAC by resetting all A-bits in all 285 prefixes sent in the Router Advertisement message. 287 2.1.5. Privacy consideration of Addresses 289 However, there are several privacy issues still present with 290 [RFC4941] such as host tracking, and address scanning attacks are 291 still possible. More details are provided in Appendix A. of 292 [RFC7217] and in [I-D.ietf-6man-ipv6-address-generation-privacy]. 294 2.1.6. DHCP/DNS Considerations 296 Many environments use DHCPv6 to allocate addresses to ensure 297 audibility and traceability (but see Section 2.5.1.5). A main 298 security concern is the ability to detect and mitigate against rogue 299 DHCP servers (Section 2.2.2). 301 DNS is often used for malware activities and while there are no 302 fundamental differences with IPv4 and IPv6 security concerns, there 303 are specific consideration in DNS64 [RFC6147] environments that need 304 to be understood. Specifically the interactions and potential to 305 interference with DNSsec implementation need to be understood - these 306 are pointed out in detail in Section 2.6.3.2. 308 2.2. Link-Layer Security 310 IPv6 relies heavily on the Neighbor Discovery protocol (NDP) 311 [RFC4861] to perform a variety of link operations such as discovering 312 other nodes on the link, resolving their link-layer addresses, and 313 finding routers on the link. If not secured, NDP is vulnerable to 314 various attacks such as router/neighbor message spoofing, redirect 315 attacks, Duplicate Address Detection (DAD) DoS attacks, etc. many of 316 these security threats to NDP have been documented in IPv6 ND Trust 317 Models and Threats [RFC3756] and in [RFC6583]. 319 2.2.1. SeND and CGA 321 SEcure Neighbor Discovery (SeND), as described in [RFC3971], is a 322 mechanism that was designed to secure ND messages. This approach 323 involves the use of new NDP options to carry public key based 324 signatures. Cryptographically Generated Addresses (CGA), as 325 described in [RFC3972], are used to ensure that the sender of a 326 Neighbor Discovery message is the actual "owner" of the claimed IPv6 327 address. A new NDP option, the CGA option, was introduced and is 328 used to carry the public key and associated parameters. Another NDP 329 option, the RSA Signature option, is used to protect all messages 330 relating to neighbor and Router discovery. 332 SeND protects against: 334 o Neighbor Solicitation/Advertisement Spoofing 336 o Neighbor Unreachability Detection Failure 338 o Duplicate Address Detection DoS Attack 340 o Router Solicitation and Advertisement Attacks 342 o Replay Attacks 344 o Neighbor Discovery DoS Attacks 346 SeND does NOT: 348 o Protect statically configured addresses 350 o Protect addresses configured using fixed identifiers (i.e. EUI- 351 64) 353 o Provide confidentiality for NDP communications 355 o Compensate for an unsecured link - SEND does not require that the 356 addresses on the link and Neighbor Advertisements correspond 358 However, at this time, CGA and SeND do not have wide support from 359 generic operating systems; hence, their usefulness is limited. 361 2.2.2. Securing DHCP 363 Dynamic Host Configuration Protocol for IPv6 (DHCPv6), as detailed in 364 [RFC3315], enables DHCP servers to pass configuration parameters such 365 as IPv6 network addresses and other configuration information to IPv6 366 nodes. DHCP plays an important role in any large network by 367 providing robust stateful autoconfiguration and autoregistration of 368 DNS Host Names. 370 The two most common threats to DHCP clients come from malicious 371 (a.k.a. rogue) or unintentionally misconfigured DHCP servers. A 372 malicious DHCP server is established with the intent of providing 373 incorrect configuration information to the client to cause a denial 374 of service attack or mount a man in the middle attack. While 375 unintentionall, a misconfigured DHCP server can have the same impact. 376 Additional threats against DHCP are discussed in the security 377 considerations section of [RFC3315] 379 [I-D.ietf-opsec-dhcpv6-shield] specifies a mechanism for protecting 380 hosts connected against rogue DHCPv6 servers. This mechanism is 381 based on DHCPv6 packet-filtering at the layer-2 device; the 382 administrator specifies the interfaces connected to DHCPv6 servers. 384 It is recommended to use DHCP-shield. 386 2.2.3. ND/RA Rate Limiting 388 Neighbor Discovery (ND) can be vulnerable to denial of service (DoS) 389 attacks in which a router is forced to perform address resolution for 390 a large number of unassigned addresses. Possible side effects of 391 this attack preclude new devices from joining the network or even 392 worse rendering the last hop router ineffective due to high CPU 393 usage. Easy mitigative steps include rate limiting Neighbor 394 Solicitations, restricting the amount of state reserved for 395 unresolved solicitations, and clever cache/timer management. 397 [RFC6583] discusses the potential for DOS in detail and suggests 398 implementation improvements and operational mitigation techniques 399 that may be used to mitigate or alleviate the impact of such attacks. 400 Here are some feasible mitigation options that can be employed by 401 network operators today: 403 o Ingress filtering of unused addresses by ACL, route filtering, 404 longer than /64 prefix; These require static configuration of the 405 addresses. 407 o Tuning of NDP process (where supported). 409 Additionally, IPv6 ND uses multicast extensively for signaling 410 messages on the local link to avoid broadcast messages for on-the- 411 wire efficiency. However, this has some side effects on wifi 412 networks, especially a negative impact on battery life of smartphones 413 and other battery operated devices that are connected to such 414 networks. The following drafts are actively discussing methods to 415 rate limit RAs and other ND messages on wifi networks in order to 416 address this issue: 418 o [I-D.thubert-savi-ra-throttler] 420 o [I-D.chakrabarti-nordmark-6man-efficient-nd] 422 2.2.4. ND/RA Filtering 424 Router Advertisement spoofing is a well-known attack vector and has 425 been extensively documented. The presence of rogue RAs, either 426 intentional or malicious, can cause partial or complete failure of 427 operation of hosts on an IPv6 link. For example, a host can select 428 an incorrect router address which can be used as a man-in-the-middle 429 (MITM) attack or can assume wrong prefixes to be used for stateless 430 address configuration (SLAAC). [RFC6104] summarizes the scenarios in 431 which rogue RAs may be observed and presents a list of possible 432 solutions to the problem. [RFC6105] (RA-Guard) describes a solution 433 framework for the rogue RA problem where network segments are 434 designed around switching devices that are capable of identifying 435 invalid RAs and blocking them before the attack packets actually 436 reach the target nodes. 438 However, several evasion techniques that circumvent the protection 439 provided by RA-Guard have surfaced. A key challenge to this 440 mitigation technique is introduced by IPv6 fragmentation. An 441 attacker can conceal the attack by fragmenting his packets into 442 multiple fragments such that the switching device that is responsible 443 for blocking invalid RAs cannot find all the necessary information to 444 perform packet filtering in the same packet. [RFC7113] describes 445 such evasion techniques, and provides advice to RA-Guard implementers 446 such that the aforementioned evasion vectors can be eliminated. 448 Given that the IPv6 Fragmentation Header can be leveraged to 449 circumvent current implementations of RA-Guard, [RFC6980] aims to 450 update [RFC4861] such that use of the IPv6 Fragmentation Header is 451 forbidden in all Neighbor Discovery messages except "Certification 452 Path Advertisement", thus allowing for simple and effective measures 453 to counter Neighbor Discovery attacks. 455 The Source Address Validation Improvements (SAVI) working group has 456 worked on other ways to mitigate the effects of such attacks. 457 [I-D.ietf-savi-dhcp] would help in creating bindings between a DHCPv4 458 [RFC2131] /DHCPv6 [RFC3315] assigned source IP address and a binding 459 anchor [RFC7039] on a SAVI device. Also, [RFC6620] describes how to 460 glean similar bindings when DHCP is not used. The bindings can be 461 used to filter packets generated on the local link with forged source 462 IP address. 464 It is still recommended that RA-Guard be be employed as a first line 465 of defense against common attack vectors including misconfigured 466 hosts. 468 2.2.5. 3GPP Link-Layer Security 470 The 3GPP link is a point-to-point like link that has no link-layer 471 address. This implies there can only be an end host (the mobile 472 hand-set) and the first-hop router (i.e., a GPRS Gatewat Support Node 473 (GGSN) or a Packet Gateway (PGW)) on that link. The GGSN/PGW never 474 configures a non link-local address on the link using the advertised 475 /64 prefix on it. The advertised prefix must not be used for on-link 476 determination. There is no need for an address resolution on the 477 3GPP link, since there are no link-layer addresses. Furthermore, the 478 GGSN/PGW assigns a prefix that is unique within each 3GPP link that 479 uses IPv6 stateless address autoconfiguration. This avoids the 480 necessity to perform DAD at the network level for every address built 481 by the mobile host. The GGSN/PGW always provides an IID to the 482 cellular host for the purpose of configuring the link-local address 483 and ensures the uniqueness of the IID on the link (i.e., no 484 collisions between its own link-local address and the mobile host's 485 one). 487 The 3GPP link model itself mitigates most of the known NDP-related 488 Denial-of-Service attacks. In practice, the GGSN/PGW only needs to 489 route all traffic to the mobile host that falls under the prefix 490 assigned to it. As there is also a single host on the 3GPP link, 491 there is no need to defend that IPv6 address. 493 See Section 5 of [RFC6459] for a more detailed discussion on the 3GPP 494 link model, NDP on it and the address configuration detail. 496 2.3. Control Plane Security 498 [RFC6192] defines the router control plane and this definition is 499 repeated here for the reader's convenience. 501 Modern router architecture design maintains a strict separation of 502 forwarding and router control plane hardware and software. The 503 router control plane supports routing and management functions. It 504 is generally described as the router architecture hardware and 505 software components for handling packets destined to the device 506 itself as well as building and sending packets originated locally on 507 the device. The forwarding plane is typically described as the 508 router architecture hardware and software components responsible for 509 receiving a packet on an incoming interface, performing a lookup to 510 identify the packet's IP next hop and determine the best outgoing 511 interface towards the destination, and forwarding the packet out 512 through the appropriate outgoing interface. 514 While the forwarding plane is usually implemented in high-speed 515 hardware, the control plane is implemented by a generic processor 516 (named router processor RP) and cannot process packets at a high 517 rate. Hence, this processor can be attacked by flooding its input 518 queue with more packets than it can process. The control plane 519 processor is then unable to process valid control packets and the 520 router can lose OSPF or BGP adjacencies which can cause a severe 521 network disruption. 523 The mitigation technique is: 525 o To drop non-legit control packet before they are queued to the RP 526 (this can be done by a forwarding plane ACL) and 528 o To rate limit the remaining packets to a rate that the RP can 529 sustain. Protocol specific protection should also be done (for 530 example, a spoofed OSPFv3 packet could trigger the execution of 531 the Dijkstra algorithm, therefore the number of Dijsktra execution 532 should be also rate limited). 534 This section will consider several classes of control packets: 536 o Control protocols: routing protocols: such as OSPFv3, BGP and by 537 extension Neighbor Discovery and ICMP 539 o Management protocols: SSH, SNMP, IPfix, etc 541 o Packet exceptions: which are normal data packets which requires a 542 specific processing such as generating a packet-too-big ICMP 543 message or having the hop-by-hop extension header. 545 2.3.1. Control Protocols 547 This class includes OSPFv3, BGP, NDP, ICMP. 549 An ingress ACL to be applied on all the router interfaces SHOULD be 550 configured such as: 552 o drop OSPFv3 (identified by Next-Header being 89) and RIPng 553 (identified by UDP port 521) packets from a non link-local address 555 o allow BGP (identified by TCP port 179) packets from all BGP 556 neighbors and drop the others 558 o allow all ICMP packets (transit and to the router interfaces) 560 Note: dropping OSPFv3 packets which are authenticated by IPsec could 561 be impossible on some routers whose ACL are unable to parse the IPsec 562 ESP or AH extension headers. 564 Rate limiting of the valid packets SHOULD be done. The exact 565 configuration obviously depends on the power of the Route Processor. 567 2.3.2. Management Protocols 569 This class includes: SSH, SNMP, syslog, NTP, etc 571 An ingress ACL to be applied on all the router interfaces SHOULD be 572 configured such as: 574 o Drop packets destined to the routers except those belonging to 575 protocols which are used (for example, permit TCP 22 and drop all 576 when only SSH is used); 578 o Drop packets where the source does not match the security policy, 579 for example if SSH connections should only be originated from the 580 NOC, then the ACL should permit TCP port 22 packets only from the 581 NOC prefix. 583 Rate limiting of the valid packets SHOULD be done. The exact 584 configuration obviously depends on the power of the Route Processor. 586 2.3.3. Packet Exceptions 588 This class covers multiple cases where a data plane packet is punted 589 to the route processor because it requires specific processing: 591 o generation of an ICMP packet-too-big message when a data plane 592 packet cannot be forwarded because it is too large; 594 o generation of an ICMP hop-limit-expired message when a data plane 595 packet cannot be forwarded because its hop-limit field has reached 596 0; 598 o generation of an ICMP destination-unreachable message when a data 599 plane packet cannot be forwarded for any reason; 601 o processing of the hop-by-hop extension header; 603 o or more specific to some router implementation: an oversized 604 extension header chain which cannot be processed by the hardware 605 and force the packet to be punted to the generic router CPU. 607 On some routers, not everything can be done by the specialized data 608 plane hardware which requires some packets to be 'punted' to the 609 generic RP. This could include for example the processing of a long 610 extension header chain in order to apply an ACL based on layer 4 611 information. [RFC6980] and more generally [RFC7112] highlight the 612 security implications of oversized header chains on routers and aims 613 to update RFC2460 such that the first fragment of a packet is 614 required to contain the entire IPv6 header chain. 616 An ingress ACL cannot help to mitigate a control plane attack using 617 those packet exceptions. The only protection for the RP is to limit 618 the rate of those packet exceptions forwarded to the RP, this means 619 that some data plane packets will be dropped without any ICMP 620 messages back to the source which will cause Path MTU holes. But, 621 there is no other solution. 623 In addition to limiting the rate of data plane packets queued to the 624 RP, it is also important to limit the generation rate of ICMP 625 messages both the save the RP but also to prevent an amplification 626 attack using the router as a reflector. 628 2.4. Routing Security 630 Routing security in general can be broadly divided into three 631 sections: 633 1. Authenticating neighbors/peers 635 2. Securing routing updates between peers 637 3. Route filtering 639 [RFC7454] covers these sections specifically for BGP in detail. 641 2.4.1. Authenticating Neighbors/Peers 643 A basic element of routing is the process of forming adjacencies, 644 neighbor, or peering relationships with other routers. From a 645 security perspective, it is very important to establish such 646 relationships only with routers and/or administrative domains that 647 one trusts. A traditional approach has been to use MD5 HMAC, which 648 allows routers to authenticate each other prior to establishing a 649 routing relationship. 651 OSPFv3 can rely on IPsec to fulfill the authentication function. 652 However, it should be noted that IPsec support is not standard on all 653 routing platforms. In some cases, this requires specialized hardware 654 that offloads crypto over to dedicated ASICs or enhanced software 655 images (both of which often come with added financial cost) to 656 provide such functionality. An added detail is to determine whether 657 OSPFv3 IPsec implementations use AH or ESP-Null for integrity 658 protection. In early implementations all OSPFv3 IPsec configurations 659 relied on AH since the details weren't specified in [RFC5340] or 660 [RFC2740] that was obsoleted by the former. However, the document 661 which specifically describes how IPsec should be implemented for 662 OSPFv3 [RFC4552] specifically states that ESP-Null MUST and AH MAY be 663 implemented since it follows the overall IPsec standards wordings. 665 OSPFv3 can also use normal ESP to encrypt the OSPFv3 payload to hide 666 the routing information. 668 [RFC7166] (which obsoletes [RFC6506] changes OSPFv3's reliance on 669 IPsec by appending an authentication trailer to the end of the OSPFv3 670 packets. This document does not specifically provide for a mechanism 671 that will authenticate the specific originator of a packet. Rather, 672 it will allow a router to confirm that the packet has indeed been 673 issued by a router that had access to the shared authentication key. 675 With all authentication mechanisms, operators should confirm that 676 implementations can support re-keying mechanisms that do not cause 677 outages. There have been instances where any re-keying cause outages 678 and therefore the tradeoff between utilizing this functionality needs 679 to be weighed against the protection it provides. 681 2.4.2. Securing Routing Updates Between Peers 683 IPv6 initially mandated the provisioning of IPsec capability in all 684 nodes. However, in the updated IPv6 Nodes Requirement standard 685 [RFC6434] is now a SHOULD and not MUST implement. Theoretically it 686 is possible, and recommended, that communication between two IPv6 687 nodes, including routers exchanging routing information be encrypted 688 using IPsec. In practice however, deploying IPsec is not always 689 feasible given hardware and software limitations of various platforms 690 deployed, as described in the earlier section. Additionally, in a 691 protocol such as OSPFv3 where adjacencies are formed on a one-to-many 692 basis, IPsec key management becomes difficult to maintain and is not 693 often utilized. 695 2.4.3. Route Filtering 697 Route filtering policies will be different depending on whether they 698 pertain to edge route filtering vs internal route filtering. At a 699 minimum, IPv6 routing policy as it pertains to routing between 700 different administrative domains should aim to maintain parity with 701 IPv4 from a policy perspective e.g., 703 o Filter internal-use, non-globally routable IPv6 addresses at the 704 perimeter 706 o Discard packets from and to bogon and reserved space 708 o Configure ingress route filters that validate route origin, prefix 709 ownership, etc. through the use of various routing databases, 710 e.g., RADB. There is additional work being done in this area to 711 formally validate the origin ASs of BGP announcements in [RFC6810] 713 Some good recommendations for filtering can be found from Team CYMRU 714 at [CYMRU]. 716 2.5. Logging/Monitoring 718 In order to perform forensic research in case of any security 719 incident or to detect abnormal behaviors, network operator should log 720 multiple pieces of information. 722 This includes: 724 o logs of all applications when available (for example web servers); 726 o use of IP Flow Information Export [RFC7011] also known as IPfix; 728 o use of SNMP MIB [RFC4293]; 730 o use of the Neighbor cache; 732 o use of stateful DHCPv6 [RFC3315] lease cache, especially when a 733 relay agent [RFC6221] in layer-2 switches is used; 735 o use of RADIUS [RFC2866] for accounting records. 737 Please note that there are privacy issues related to how those logs 738 are collected, kept and safely discarded. Operators are urged to 739 check their country legislation. 741 All those pieces of information will be used for: 743 o forensic (Section 2.5.2.1) research to answer questions such as 744 who did what and when? 746 o correlation (Section 2.5.2.3): which IP addresses were used by a 747 specific node (assuming the use of privacy extensions addresses 748 [RFC4941]) 750 o inventory (Section 2.5.2.2): which IPv6 nodes are on my network? 752 o abnormal behavior detection (Section 2.5.2.4): unusual traffic 753 patterns are often the symptoms of a abnormal behavior which is in 754 turn a potential attack (denial of services, network scan, a node 755 being part of a botnet, ...) 757 2.5.1. Data Sources 759 This section lists the most important sources of data that are useful 760 for operational security. 762 2.5.1.1. Logs of Applications 764 Those logs are usually text files where the remote IPv6 address is 765 stored in all characters (not binary). This can complicate the 766 processing since one IPv6 address, 2001:db8::1 can be written in 767 multiple ways such as: 769 o 2001:DB8::1 (in uppercase) 771 o 2001:0db8::0001 (with leading 0) 773 o and many other ways. 775 RFC 5952 [RFC5952] explains this problem in detail and recommends the 776 use of a single canonical format (in short use lower case and 777 suppress leading 0). This memo recommends the use of canonical 778 format [RFC5952] for IPv6 addresses in all possible cases. If the 779 existing application cannot log under the canonical format, then this 780 memo recommends the use an external program in order to canonicalize 781 all IPv6 addresses. 783 For example, this perl script can be used: 785 #!/usr/bin/perl ?w 786 use strict ; 787 use warnings ; 788 use Socket ; 789 use Socket6 ; 791 my (@words, $word, $binary_address) ; 793 ## go through the file one line at a time 794 while (my $line = ) { 795 chomp $line; 796 foreach my $word (split /[ \n]/, $line) { 797 $binary_address = inet_pton AF_INET6, $word ; 798 if ($binary_address) { 799 print inet_ntop AF_INET6, $binary_address ; 800 } else { 801 print $word ; 802 } 803 print " " ; 804 } 805 print "\n" ; 806 } 808 2.5.1.2. IP Flow Information Export by IPv6 Routers 810 IPfix [RFC7012] defines some data elements that are useful for 811 security: 813 o in section 5.4 (IP Header fields): nextHeaderIPv6 and 814 sourceIPv6Address; 816 o in section 5.6 (Sub-IP fields) sourceMacAddress. 818 Moreover, IPfix is very efficient in terms of data handling and 819 transport. It can also aggregate flows by a key such as 820 sourceMacAddress in order to have aggregated data associated with a 821 specific sourceMacAddress. This memo recommends the use of IPfix and 822 aggregation on nextHeaderIPv6, sourceIPv6Address and 823 sourceMacAddress. 825 2.5.1.3. SNMP MIB by IPv6 Routers 827 RFC 4293 [RFC4293] defines a Management Information Base (MIB) for 828 the two address families of IP. This memo recommends the use of: 830 o ipIfStatsTable table which collects traffic counters per 831 interface; 833 o ipNetToPhysicalTable table which is the content of the Neighbor 834 cache, i.e. the mapping between IPv6 and data-link layer 835 addresses. 837 2.5.1.4. Neighbor Cache of IPv6 Routers 839 The neighbor cache of routers contains all mappings between IPv6 840 addresses and data-link layer addresses. It is usually available by 841 two means: 843 o the SNMP MIB (Section 2.5.1.3) as explained above; 845 o also by connecting over a secure management channel (such as SSH 846 or HTTPS) and explicitely requesting a neighbor cache dump. 848 The neighbor cache is highly dynamic as mappings are added when a new 849 IPv6 address appears on the network (could be quite often with 850 privacy extension addresses [RFC4941] or when they are removed when 851 the state goes from UNREACH to removed (the default time for a 852 removal per Neighbor Unreachability Detection [RFC4861] algorithm is 853 38 seconds for a typical host such as Windows 7). This means that 854 the content of the neighbor cache must periodically be fetched every 855 30 seconds (to be on the safe side) and stored for later use. 857 This is an important source of information because it is trivial (on 858 a switch not using the SAVI [RFC7039] algorithm) to defeat the 859 mapping between data-link layer address and IPv6 address. Let us 860 rephrase the previous statement: having access to the current and 861 past content of the neighbor cache has a paramount value for forensic 862 and audit trail. 864 2.5.1.5. Stateful DHCPv6 Lease 866 In some networks, IPv6 addresses are managed by stateful DHCPv6 867 server [RFC3315] that leases IPv6 addresses to clients. It is indeed 868 quite similar to DHCP for IPv4 so it can be tempting to use this DHCP 869 lease file to discover the mapping between IPv6 addresses and data- 870 link layer addresses as it was usually done in the IPv4 era. 872 It is not so easy in the IPv6 era because not all nodes will use 873 DHCPv6 (there are nodes which can only do stateless 874 autoconfiguration) but also because DHCPv6 clients are identified not 875 by their hardware-client address as in IPv4 but by a DHCP Unique ID 876 (DUID) which can have several formats: some being the data-link layer 877 address, some being data-link layer address prepended with time 878 information or even an opaque number which is useless for operation 879 security. Moreover, when the DUID is based on the data-link address, 880 this address can be of any interface of the client (such as the 881 wireless interface while the client actually uses its wired interface 882 to connect to the network). 884 If a lightweight DHCP relay agent [RFC6221] is used in the layer-2 885 switches, then the DHCP server also receives the Interface-ID 886 information which could be save in order to identifity the interface 887 of the switches which received a specific leased IPv6 address. 889 In short, the DHCPv6 lease file is less interesting than in the IPv4 890 era. DHCPv6 servers that keeps the relayed data-link layer address 891 in addition to the DUID in the lease file do not suffer from this 892 limitation. On a managed network where all hosts support DHCPv6, 893 special care must be taken to prevent stateless autoconfiguration 894 anyway (and if applicable) by sending RA with all announced prefixes 895 without the A-bit set. 897 The mapping between data-link layer address and the IPv6 address can 898 be secured by using switches implementing the SAVI 899 [I-D.ietf-savi-dhcp] algorithms. 901 2.5.1.6. RADIUS Accounting Log 903 For interfaces where the user is authenticated via a RADIUS [RFC2866] 904 server, and if RADIUS accounting is enabled, then the RADIUS server 905 receives accounting Acct-Status-Type records at the start and at the 906 end of the connection which include all IPv6 (and IPv4) addresses 907 used by the user. This technique can be used notably for Wi-Fi 908 networks with Wi-Fi Protected Address (WPA) or any other IEEE 802.1X 909 [IEEE-802.1X]wired interface on an Ethernet switch. 911 2.5.1.7. Other Data Sources 913 There are other data sources that must be kept exactly as in the IPv4 914 network: 916 o historical mapping of IPv6 addresses to users of remote access 917 VPN; 919 o historical mapping of MAC address to switch interface in a wired 920 network. 922 2.5.2. Use of Collected Data 924 This section leverages the data collected as described before 925 (Section 2.5.1) in order to achieve several security benefits. 927 2.5.2.1. Forensic 929 The forensic use case is when the network operator must locate an 930 IPv6 address that was present in the network at a certain time or is 931 still currently in the network. 933 The source of information can be, in decreasing order, neighbor 934 cache, DHCP lease file. Then, the procedure is: 936 1. based on the IPv6 prefix of the IPv6 address find the router(s) 937 which are used to reach this prefix; 939 2. based on this limited set of routers, on the incident time and on 940 IPv6 address to retrieve the data-link address from live neighbor 941 cache, from the historical data of the neighbor cache, or from 942 the DHCP lease file; 944 3. based on the data-link layer address, look-up on which switch 945 interface was this data-link layer address. In the case of 946 wireless LAN, the RADIUS log should have the mapping between user 947 identification and the MAC address. 949 At the end of the process, the interface where the malicious user was 950 connected or the username that was used by the malicious user is 951 found. 953 2.5.2.2. Inventory 955 RFC 5157 [RFC5157] is about the difficulties to scan an IPv6 network 956 due to the vast number of IPv6 addresses per link. This has the side 957 effect of making the inventory task difficult in an IPv6 network 958 while it was trivial to do in an IPv4 network (a simple enumeration 959 of all IPv4 addresses, followed by a ping and a TCP/UDP port scan). 960 Getting an inventory of all connected devices is of prime importance 961 for a secure operation of a network. 963 There are two ways to do an inventory of an IPv6 network. 965 The first technique is to use the IPfix information and extract the 966 list of all IPv6 source addresses to find all IPv6 nodes that sent 967 packets through a router. This is very efficient but alas will not 968 discover silent node that never transmitted such packets... Also, it 969 must be noted that link-local addresses will never be discovered by 970 this means. 972 The second way is again to use the collected neighbor cache content 973 to find all IPv6 addresses in the cache. This process will also 974 discover all link-local addresses. See Section 2.5.1.4. 976 Another way works only for local network, it consists in sending a 977 ICMP ECHO_REQUEST to the link-local multicast address ff02::1 which 978 is all IPv6 nodes on the network. All nodes should reply to this 979 ECHO_REQUEST per [RFC4443]. 981 2.5.2.3. Correlation 983 In an IPv4 network, it is easy to correlate multiple logs, for 984 example to find events related to a specific IPv4 address. A simple 985 Unix grep command was enough to scan through multiple text-based 986 files and extract all lines relevant to a specific IPv4 address. 988 In an IPv6 network, this is slightly more difficult because different 989 character strings can express the same IPv6 address. Therefore, the 990 simple Unix grep command cannot be used. Moreover, an IPv6 node can 991 have multiple IPv6 addresses... 993 In order to do correlation in IPv6-related logs, it is advised to 994 have all logs with canonical IPv6 addresses. Then, the neighbor 995 cache current (or historical) data set must be searched to find the 996 data-link layer address of the IPv6 address. Then, the current and 997 historical neighbor cache data sets must be searched for all IPv6 998 addresses associated to this data-link layer address: this is the 999 search set. The last step is to search in all log files (containing 1000 only IPv6 address in canonical format) for any IPv6 addresses in the 1001 search set. 1003 2.5.2.4. Abnormal Behavior Detection 1005 Abnormal behaviors (such as network scanning, spamming, denial of 1006 service) can be detected in the same way as in an IPv4 network 1008 o sudden increase of traffic detected by interface counter (SNMP) or 1009 by aggregated traffic from IPfix records [RFC7012]; 1011 o change of traffic pattern (number of connection per second, number 1012 of connection per host...) with the use of IPfix [RFC7012] 1014 2.5.3. Summary 1016 While some data sources (IPfix, MIB, switch CAM tables, logs, ...) 1017 used in IPv4 are also used in the secure operation of an IPv6 1018 network, the DHCPv6 lease file is less reliable and the neighbor 1019 cache is of prime importance. 1021 The fact that there are multiple ways to express in a character 1022 string the same IPv6 address renders the use of filters mandatory 1023 when correlation must be done. 1025 2.6. Transition/Coexistence Technologies 1027 Some text 1029 2.6.1. Dual Stack 1031 Dual stack has established itself as the preferred deployment choice 1032 for most network operators without a MPLS core where 6PE [RFC4798] is 1033 quite common. Dual stacking the network offers many advantages over 1034 other transition mechanisms. Firstly, it is easy to turn on without 1035 impacting normal IPv4 operations. Secondly, perhaps more 1036 importantly, it is easier to troubleshoot when things break. Dual 1037 stack allows you to gradually turn IPv4 operations down when your 1038 IPv6 network is ready for prime time. 1040 From an operational security perspective, this now means that you 1041 have twice the exposure. One needs to think about protecting both 1042 protocols now. At a minimum, the IPv6 portion of a dual stacked 1043 network should maintain parity with IPv4 from a security policy point 1044 of view. Typically, the following methods are employed to protect 1045 IPv4 networks at the edge: 1047 o ACLs to permit or deny traffic 1049 o Firewalls with stateful packet inspection 1051 It is recommended that these ACLs and/or firewalls be additionally 1052 configured to protect IPv6 communications. Also, given the end-to- 1053 end connectivity that IPv6 provides, it is also recommended that 1054 hosts be fortified against threats. General device hardening 1055 guidelines are provided in Section 2.7 1057 2.6.2. Transition Mechanisms 1059 There are many tunnels used for specific use cases. Except when 1060 protected by IPsec [RFC4301], all those tunnels have a couple of 1061 security issues (most of them being described in RFC 6169 [RFC6169]); 1063 o tunnel injection: a malevolent person knowing a few pieces of 1064 information (for example the tunnel endpoints and the used 1065 protocol) can forge a packet which looks like a legit and valid 1066 encapsulated packet that will gladly be accepted by the 1067 destination tunnel endpoint, this is a specific case of spoofing; 1069 o traffic interception: no confidentiality is provided by the tunnel 1070 protocols (without the use of IPsec), therefore anybody on the 1071 tunnel path can intercept the traffic and have access to the 1072 clear-text IPv6 packet; 1074 o service theft: as there is no authorization, even a non authorized 1075 user can use a tunnel relay for free (this is a specific case of 1076 tunnel injection); 1078 o reflection attack: another specific use case of tunnel injection 1079 where the attacker injects packets with an IPv4 destination 1080 address not matching the IPv6 address causing the first tunnel 1081 endpoint to re-encapsulate the packet to the destination... Hence, 1082 the final IPv4 destination will not see the original IPv4 address 1083 but only one IPv4 address of the relay router. 1085 o bypassing security policy: if a firewall or an IPS is on the path 1086 of the tunnel, then it will probably neither inspect not detect an 1087 malevolent IPv6 traffic contained in the tunnel. 1089 To mitigate the bypassing of security policies, it could be helpful 1090 to block all default configuration tunnels by denying all IPv4 1091 traffic matching: 1093 o IP protocol 41: this will block ISATAP (Section 2.6.2.2), 6to4 1094 (Section 2.6.2.4), 6rd (Section 2.6.2.5) as well as 6in4 1095 (Section 2.6.2.1) tunnels; 1097 o IP protocol 47: this will block GRE (Section 2.6.2.1) tunnels; 1099 o UDP protocol 3544: this will block the default encapsulation of 1100 Teredo (Section 2.6.2.3) tunnels. 1102 Ingress filtering [RFC2827] should also be applied on all tunnel 1103 endpoints if applicable to prevent IPv6 address spoofing. 1105 As several of the tunnel techniques share the same encapsulation 1106 (i.e. IPv4 protocol 41) and embeb the IPv4 address in the IPv6 1107 address, there are a set of well-known looping attacks described in 1108 RFC 6324 [RFC6324], this RFC also proposes mitigation techniques. 1110 2.6.2.1. Site-to-Site Static Tunnels 1112 Site-to-site static tunnels are described in RFC 2529 [RFC2529] and 1113 in GRE [RFC2784]. As the IPv4 endpoints are statically configured 1114 and are not dynamic they are slightly more secure (bi-directional 1115 service theft is mostly impossible) but traffic interception ad 1116 tunnel injection are still possible. Therefore, the use of IPsec 1117 [RFC4301] in transport mode and protecting the encapsulated IPv4 1118 packets is recommended for those tunnels. Alternatively, IPsec in 1119 tunnel mode can be used to transport IPv6 traffic over a non-trusted 1120 IPv4 network. 1122 2.6.2.2. ISATAP 1124 ISATAP tunnels [RFC5214] are mainly used within a single 1125 administrative domain and to connect a single IPv6 host to the IPv6 1126 network. This means that endpoints and and the tunnel endpoint are 1127 usually managed by a single entity; therefore, audit trail and strict 1128 anti-spoofing are usually possible and this raises the overall 1129 security. 1131 Special care must be taken to avoid looping attack by implementing 1132 the measures of RFC 6324 [RFC6324] and of [RFC6964]. 1134 IPsec [RFC4301] in transport or tunnel mode can be used to secure the 1135 IPv4 ISATAP traffic to provide IPv6 traffic confidentiality and 1136 prevent service theft. 1138 2.6.2.3. Teredo 1140 Teredo tunnels [RFC4380] are mainly used in a residential environment 1141 because that can easily traverse an IPv4 NAT-PT device thanks to its 1142 UDP encapsulation and they connect a single host to the IPv6 1143 Internet. Teredo shares the same issues as other tunnels: no 1144 authentication, no confidentiality, possible spoofing and reflection 1145 attacks. 1147 IPsec [RFC4301] for the transported IPv6 traffic is recommended. 1149 The biggest threat to Teredo is probably for IPv4-only network as 1150 Teredo has been designed to easily traverse IPV4 NAT-PT devices which 1151 are quite often co-located with a stateful firewall. Therefore, if 1152 the stateful IPv4 firewall allows unrestricted UDP outbound and 1153 accept the return UDP traffic, then Teredo actually punches a hole in 1154 this firewall for all IPv6 traffic to the Internet and from the 1155 Internet. While host policies can be deployed to block Teredo in an 1156 IPv4-only network in order to avoid this firewall bypass, it would be 1157 more efficient to block all UDP outbound traffic at the IPv4 firewall 1158 if deemed possible (of course, at least port 53 should be left open 1159 for DNS traffic). 1161 2.6.2.4. 6to4 1163 6to4 tunnels [RFC3056] require a public routable IPv4 address in 1164 order to work correctly. They can be used to provide either one IPv6 1165 host connectivity to the IPv6 Internet or multiple IPv6 networks 1166 connectivity to the IPV6 Internet. The 6to4 relay is usually the 1167 anycast address defined in [RFC3068]. Some security considerations 1168 are explained in [RFC3964]. 1170 [RFC6343] points out that if an operator provides well-managed 1171 servers and relays for 6to4, non-encapsulated IPv6 packets will pass 1172 through well- defined points (the native IPv6 interfaces of those 1173 servers and relays) at which security mechanisms may be applied. 1174 Client usage of 6to4 by default is now discouraged, and significant 1175 precautions are needed to avoid operational problems 1177 2.6.2.5. 6rd 1179 While 6rd tunnels share the same encapsulation as 6to4 tunnels 1180 (Section 2.6.2.4), they are designed to be used within a single SP 1181 domain, in other words they are deployed in a more constrained 1182 environment than 6to4 tunnels and have little security issues except 1183 lack of confidentiality. The security considerations (Section 12) of 1184 [RFC5969] describes how to secure the 6rd tunnels. 1186 IPsec [RFC4301] for the transported IPv6 traffic can be used if 1187 confidentiality is important. 1189 2.6.2.6. 6PE and 6VPE 1191 Organizations using MPLS in their core can also use 6PE [RFC4798] and 1192 6VPE [RFC4659] to enable IPv6 access over MPLS. As 6PE and 6VPE are 1193 really similar to BGP/MPLS IP VPN described in [RFC4364], the 1194 security of these networks is also similar to the one described in 1195 [RFC4381]. It relies on: 1197 o Address space, routing and traffic seperation with the help of VRF 1198 (only applicable to 6VPE); 1200 o Hiding the IPv4 core, hence removing all attacks against 1201 P-routers; 1203 o Securing the routing protocol between CE and PE, in the case of 1204 6PE and 6VPE, link-local addresses (see [RFC7404]) can be used and 1205 as these addresses cannot be reached from outside of the link, the 1206 security of 6PE and 6VPE is even higher than the IPv4 BGP/MPLS IP 1207 VPN. 1209 2.6.2.7. DS-Lite 1211 DS-lite is more a translation mechanism and is therefore analyzed 1212 further (Section 2.6.3.3) in this document. 1214 2.6.2.8. Mapping of Address and Port 1216 With the tunnel and encapsulation versions of Mapping of Address and 1217 Port (MAP [I-D.ietf-softwire-map]), the access network is purely an 1218 IPv6 network and MAP protocols are used to give IPv4 hosts on the 1219 subscriber network, access to IPv4 hosts on the Internet. The 1220 subscriber router does stateful operations in order to map all 1221 internal IPv4 addresses and layer-4 ports to the IPv4 address and the 1222 set of layer-4 ports received through MAP configuration process. The 1223 SP equipment always does stateless operations (either decapsulation 1224 or stateless translation). Therefore, as opposed to Section 2.6.3.3 1225 there is no state-exhaustion DoS attack against the SP equipment 1226 because there is no state and there is no operation caused by a new 1227 layer-4 connection (no logging operation). 1229 The SP MAP equipment MUST implement all the security considerations 1230 of [I-D.ietf-softwire-map]; notably, ensuring that the mapping of the 1231 IPv4 address and port are consistent with the configuration. As MAP 1232 has a predictable IPv4 address and port mapping, the audit log are 1233 easier to manager. 1235 2.6.3. Translation Mechanisms 1237 Translation mechanisms between IPv4 and IPv6 networks are alternative 1238 coexistence strategies while networks transition to IPv6. While a 1239 framework is described in [RFC6144] the specific security 1240 considerations are documented in each individual mechanism. For the 1241 most part they specifically mention interference with IPsec or DNSSEC 1242 deployments, how to mitigate spoofed traffic and what some effective 1243 filtering strategies may be. 1245 2.6.3.1. Carrier-Grade Nat (CGN) 1247 Carrier-Grade NAT (CGN), also called NAT444 CGN or Large Scale NAT 1248 (LSN) or SP NAT is described in [RFC6264] and is utilized as an 1249 interim measure to prolong the use of IPv4 in a large service 1250 provider network until the provider can deploy and effective IPv6 1251 solution. [RFC6598] requested a specific IANA allocated /10 IPv4 1252 address block to be used as address space shared by all access 1253 networks using CGN. This has been allocated as 100.64.0.0/10. 1255 Section 13 of [RFC6269] lists some specific security-related issues 1256 caused by large scale address sharing. The Security Considerations 1257 section of [RFC6598] also lists some specific mitigation techniques 1258 for potential misuse of shared address space. 1260 [From Panos K: could mention the log size concern and draft-donley- 1261 behave-deterministic-cgn that alleviates it] 1263 2.6.3.2. NAT64/DNS64 1265 Stateful NAT64 translation [RFC6146] allows IPv6-only clients to 1266 contact IPv4 servers using unicast UDP, TCP, or ICMP. It can be used 1267 in conjunction with DNS64 [RFC6147], a mechanism which synthesizes 1268 AAAA records from existing A records. 1270 The Security Consideration sections of [RFC6146] and [RFC6147] list 1271 the comprehensive issues. A specific issue with the use of NAT64 is 1272 that it will interfere with most IPsec deployments unless UDP 1273 encapsulation is used. DNS64 has an incidence on DNSSEC see section 1274 3.1 of [RFC7050]. 1276 2.6.3.3. DS-lite 1278 Dual-Stack Lite (DS-Lite) [RFC6333] is a transition technique that 1279 enables a service provider to share IPv4 addresses among customers by 1280 combining two well-known technologies: IP in IP (IPv4-in-IPv6) and 1281 Network Address and Port Translation (NAPT) 1283 Security considerations with respect to DS-Lite mainly revolve around 1284 logging data, preventing DoS attacks from rogue devices and 1285 restricting service offered by the AFTR only to registered customers. 1287 Section 11 of [RFC6333] describes important security issues 1288 associated with this technology. 1290 2.7. General Device Hardening 1292 There are many environments which rely too much on the network 1293 infrastructure to disallow malicious traffic to get access to 1294 critical hosts. In new IPv6 deployments it has been common to see 1295 IPv6 traffic enabled but none of the typical access control 1296 mechanisms enabled for IPv6 device access. With the possibility of 1297 network device configuration mistakes and the growth of IPv6 in the 1298 overall Internet it is important to ensure that all individual 1299 devices are hardened agains miscreant behavior. 1301 The following guidelines should be used to ensure appropriate 1302 hardening of the host, be it an individual computer or router, 1303 firewall, load-balancer,server, etc device. 1305 o Restrict access to the device to authenticated and authorized 1306 individuals 1308 o Monitor and audit access to the device 1310 o Turn off any unused services on the end node 1311 o Understand which IPv6 addresses are being used to source traffic 1312 and change defaults if necessary 1314 o Use cryptographically protected protocols for device management if 1315 possible (SCP, SNMPv3, SSH, TLS, etc) 1317 o Use host firewall capabilities to control traffic that gets 1318 processed by upper layer protocols 1320 o Use virus scanners to detect malicious programs 1322 3. Enterprises Specific Security Considerations 1324 Enterprises generally have robust network security policies in place 1325 to protect existing IPv4 networks. These policies have been 1326 distilled from years of experiential knowledge of securing IPv4 1327 networks. At the very least, it is recommended that enterprise 1328 networks have parity between their security policies for both 1329 protocol versions. 1331 Security considerations in the enterprise can be broadly categorized 1332 into two sections - External and Internal. 1334 3.1. External Security Considerations: 1336 The external aspect deals with providing security at the edge or 1337 perimeter of the enterprise network where it meets the service 1338 providers network. This is commonly achieved by enforcing a security 1339 policy either by implementing dedicated firewalls with stateful 1340 packet inspection or a router with ACLs. A common default IPv4 1341 policy on firewalls that could easily be ported to IPv6 is to allow 1342 all traffic outbound while only allowing specific traffic, such as 1343 established sessions, inbound. Here are a few more things that could 1344 enhance the default policy: 1346 o Filter internal-use IPv6 addresses at the perimeter 1348 o Discard packets from and to bogon and reserved space 1350 o Accept certain ICMPv6 messages to allow proper operation of ND and 1351 PMTUD, see also [RFC4890] 1353 o Filter specific extension headers, where possible 1355 o Filter unneeded services at the perimeter 1357 o Implement anti-spoofing 1358 o Implement appropriate rate-limiters and control-plane policers 1360 3.2. Internal Security Considerations: 1362 The internal aspect deals with providing security inside the 1363 perimeter of the network, including the end host. The most 1364 significant concerns here are related to Neighbor Discovery. At the 1365 network level, it is recommended that all security considerations 1366 discussed in Section 2.2 be reviewed carefully and the 1367 recommendations be considered in-depth as well. 1369 As mentioned in Section 2.6.2, care must be taken when running 1370 automated IPv6-in-IP4 tunnels. 1372 Hosts need to be hardened directly through security policy to protect 1373 against security threats. The host firewall default capabilities 1374 have to be clearly understood, especially 3rd party ones which can 1375 have different settings for IPv4 or IPv6 default permit/deny 1376 behavior. In some cases, 3rd party firewalls have no IPv6 support 1377 whereas the native firewall installed by default has it. General 1378 device hardening guidelines are provided in Section 2.7 1380 It should also be noted that many hosts still use IPv4 for transport 1381 for things like RADIUS, TACACS+, SYSLOG, etc. This will require some 1382 extra level of due diligence on the part of the operator. 1384 4. Service Providers Security Considerations 1386 4.1. BGP 1388 The threats and mitigation techniques are identical between IPv4 and 1389 IPv6. Broadly speaking they are: 1391 o Authenticating the TCP session; 1393 o TTL security (which becomes hop-limit security in IPv6); 1395 o Prefix Filtering. 1397 These are explained in more detail in section Section 2.4. 1399 4.1.1. Remote Triggered Black Hole Filtering 1401 RTBH [RFC5635] works identically in IPv4 and IPv6. IANA has 1402 allocated 100::/64 as discard prefix [RFC6666]. 1404 4.2. Transition Mechanism 1406 SP will typically use transition mechanisms such as 6rd, 6PE, MAP, 1407 DS-LITE which have been analyzed in the transition Section 2.6.2 1408 section. 1410 4.3. Lawful Intercept 1412 The Lawful Intercept requirements are similar for IPv6 and IPv4 1413 architectures and will be subject to the laws enforced in varying 1414 geographic regions. The local issues with each jurisdiction can make 1415 this challenging and both corporate legal and privacy personnel 1416 should be involved in discussions pertaining to what information gets 1417 logged and what the logging retention policies will be. 1419 The target of interception will usually be a residential subscriber 1420 (e.g. his/her PPP session or physical line or CPE MAC address). With 1421 the absence of NAT on the CPE, IPv6 has the provision to allow for 1422 intercepting the traffic from a single host (a /128 target) rather 1423 than the whole set of hosts of a subscriber (which could be a /48, a 1424 /60 or /64). 1426 In contrast, in mobile environments, since the 3GPP specifications 1427 allocate a /64 per device, it may be sufficient to intercept traffic 1428 from the /64 rather than specific /128's (since each time the device 1429 powers up it gets a new IID). 1431 A sample architecture which was written for informational purposes is 1432 found in [RFC3924]. 1434 5. Residential Users Security Considerations 1436 The IETF Homenet working group is working on how IPv6 residential 1437 network should be done; this obviously includes operational security 1438 considerations; but, this is still work in progress. 1440 Residential users have usually less experience and knowledge about 1441 security or networking. As most of the recent hosts, smartphones, 1442 tablets have all IPv6 enabled by default, IPv6 security is important 1443 for those users. Even with an IPv4-only ISP, those users can get 1444 IPv6 Internet access with the help of Teredo tunnels. Several peer- 1445 to-peer programs (notably Bittorrent) support IPv6 and those programs 1446 can initiate a Teredo tunnel through the IPv4 residential gateway, 1447 with the consequence of making the internal host reachable from any 1448 IPv6 host on the Internet. It is therefore recommended that all host 1449 security products (personal firewall, ...) are configured with a 1450 dual-stack security policy. 1452 If the Residential Gateway has IPv6 connectivity, [RFC7084] (which 1453 obsoletes [RFC6204] defines the requirements of an IPv6 CPE and does 1454 not take position on the debate of default IPv6 security policy: 1456 o outbound only: allowing all internally initiated connections and 1457 block all externally initiated ones, which is a common default 1458 security policy enforced by IPv4 Residential Gateway doing NAT-PT 1459 but it also breaks the end-to-end reachability promise of IPv6. 1460 [RFC6092] lists several recommendations to design such a CPE; 1462 o open: allowing all internally and externally initiated 1463 connections, therefore restoring the end-to-end nature of the 1464 Internet for the IPv6 traffic but having a different security 1465 policy for IPv6 than for IPv4. 1467 [RFC7084] states that a clear choice must be given to the user to 1468 select one of those two policies. 1470 There is also an alternate solution which has been deployed notably 1471 by Swisscom ([I-D.ietf-v6ops-balanced-ipv6-security]: open to all 1472 outbound and inbound connections at the exception of an handful of 1473 TCP and UDP ports known as vulnerable. 1475 6. Further Reading 1477 There are several documents that describe in more details the 1478 security of an IPv6 network; these documents are not written by the 1479 IETF but are listed here for your convenience: 1481 1. Guidelines for the Secure Deployment of IPv6 [NIST] 1483 2. North American IPv6 Task Force Technology Report - IPv6 Security 1484 Technology Paper [NAv6TF_Security] 1486 3. IPv6 Security [IPv6_Security_Book] 1488 7. Acknowledgements 1490 The authors would like to thank the following people for their useful 1491 comments: Mikael Abrahamsson, Brian Carpenter, Tim Chown, Fernando 1492 Gont, Jeffry Handal, Panos Kampanakis, Jouni Korhonen, Mark 1493 Lentczner, Tarko Tikan (by alphabetical order). 1495 8. IANA Considerations 1497 This memo includes no request to IANA. 1499 9. Security Considerations 1501 This memo attempts to give an overview of security considerations of 1502 operating an IPv6 network both in an IPv6-only network and in 1503 utilizing the most widely deployed IPv4/IPv6 coexistence strategies. 1505 10. References 1507 10.1. Normative References 1509 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1510 Requirement Levels", BCP 14, RFC 2119, March 1997. 1512 [RFC6104] Chown, T. and S. Venaas, "Rogue IPv6 Router Advertisement 1513 Problem Statement", RFC 6104, February 2011. 1515 [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. 1516 Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, 1517 February 2011. 1519 10.2. Informative References 1521 [CYMRU] "Packet Filter and Route Filter Recommendation for IPv6 at 1522 xSP routers", . 1526 [I-D.chakrabarti-nordmark-6man-efficient-nd] 1527 Chakrabarti, S., Nordmark, E., Thubert, P., and M. 1528 Wasserman, "IPv6 Neighbor Discovery Optimizations for 1529 Wired and Wireless Networks", draft-chakrabarti-nordmark- 1530 6man-efficient-nd-07 (work in progress), February 2015. 1532 [I-D.ietf-6man-ipv6-address-generation-privacy] 1533 Cooper, A., Gont, F., and D. Thaler, "Privacy 1534 Considerations for IPv6 Address Generation Mechanisms", 1535 draft-ietf-6man-ipv6-address-generation-privacy-04 (work 1536 in progress), February 2015. 1538 [I-D.ietf-opsec-dhcpv6-shield] 1539 Gont, F., Will, W., and G. Velde, "DHCPv6-Shield: 1540 Protecting Against Rogue DHCPv6 Servers", draft-ietf- 1541 opsec-dhcpv6-shield-06 (work in progress), February 2015. 1543 [I-D.ietf-savi-dhcp] 1544 Bi, J., Wu, J., Yao, G., and F. Baker, "SAVI Solution for 1545 DHCP", draft-ietf-savi-dhcp-34 (work in progress), 1546 February 2015. 1548 [I-D.ietf-softwire-map] 1549 Troan, O., Dec, W., Li, X., Bao, C., Matsushima, S., 1550 Murakami, T., and T. Taylor, "Mapping of Address and Port 1551 with Encapsulation (MAP)", draft-ietf-softwire-map-12 1552 (work in progress), November 2014. 1554 [I-D.ietf-v6ops-balanced-ipv6-security] 1555 Gysi, M., Leclanche, G., Vyncke, E., and R. Anfinsen, 1556 "Balanced Security for IPv6 Residential CPE", draft-ietf- 1557 v6ops-balanced-ipv6-security-01 (work in progress), 1558 December 2013. 1560 [I-D.thubert-savi-ra-throttler] 1561 Thubert, P., "Throttling RAs on constrained interfaces", 1562 draft-thubert-savi-ra-throttler-01 (work in progress), 1563 June 2012. 1565 [IEEE-802.1X] 1566 IEEE, , "IEEE Standard for Local and metropolitan area 1567 networks - Port-Based Network Access Control", IEEE Std 1568 802.1X-2010, February 2010. 1570 [IPv6_Security_Book] 1571 Hogg, and Vyncke, "IPv6 Security", ISBN 1-58705-594-5, 1572 Publisher CiscoPress, December 2008. 1574 [NAv6TF_Security] 1575 Kaeo, , Green, , Bound, , and Pouffary, "North American 1576 IPv6 Task Force Technology Report - IPv6 Security 1577 Technology Paper", 2006, 1578 . 1581 [NIST] Frankel, , Graveman, , Pearce, , and Rooks, "Guidelines 1582 for the Secure Deployment of IPv6", 2010, 1583 . 1586 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 1587 converting network protocol addresses to 48.bit Ethernet 1588 address for transmission on Ethernet hardware", STD 37, 1589 RFC 826, November 1982. 1591 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 1592 2131, March 1997. 1594 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 1595 Domains without Explicit Tunnels", RFC 2529, March 1999. 1597 [RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", RFC 1598 2740, December 1999. 1600 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 1601 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 1602 March 2000. 1604 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1605 Defeating Denial of Service Attacks which employ IP Source 1606 Address Spoofing", BCP 38, RFC 2827, May 2000. 1608 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 1610 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 1611 via IPv4 Clouds", RFC 3056, February 2001. 1613 [RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", 1614 RFC 3068, June 2001. 1616 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1617 and M. Carney, "Dynamic Host Configuration Protocol for 1618 IPv6 (DHCPv6)", RFC 3315, July 2003. 1620 [RFC3627] Savola, P., "Use of /127 Prefix Length Between Routers 1621 Considered Harmful", RFC 3627, September 2003. 1623 [RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor 1624 Discovery (ND) Trust Models and Threats", RFC 3756, May 1625 2004. 1627 [RFC3924] Baker, F., Foster, B., and C. Sharp, "Cisco Architecture 1628 for Lawful Intercept in IP Networks", RFC 3924, October 1629 2004. 1631 [RFC3964] Savola, P. and C. Patel, "Security Considerations for 1632 6to4", RFC 3964, December 2004. 1634 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 1635 Neighbor Discovery (SEND)", RFC 3971, March 2005. 1637 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 1638 RFC 3972, March 2005. 1640 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1641 Addresses", RFC 4193, October 2005. 1643 [RFC4293] Routhier, S., "Management Information Base for the 1644 Internet Protocol (IP)", RFC 4293, April 2006. 1646 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1647 Internet Protocol", RFC 4301, December 2005. 1649 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1650 Networks (VPNs)", RFC 4364, February 2006. 1652 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 1653 Network Address Translations (NATs)", RFC 4380, February 1654 2006. 1656 [RFC4381] Behringer, M., "Analysis of the Security of BGP/MPLS IP 1657 Virtual Private Networks (VPNs)", RFC 4381, February 2006. 1659 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 1660 Message Protocol (ICMPv6) for the Internet Protocol 1661 Version 6 (IPv6) Specification", RFC 4443, March 2006. 1663 [RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality 1664 for OSPFv3", RFC 4552, June 2006. 1666 [RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur, 1667 "BGP-MPLS IP Virtual Private Network (VPN) Extension for 1668 IPv6 VPN", RFC 4659, September 2006. 1670 [RFC4798] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur, 1671 "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 1672 Provider Edge Routers (6PE)", RFC 4798, February 2007. 1674 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1675 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1676 September 2007. 1678 [RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and 1679 E. Klein, "Local Network Protection for IPv6", RFC 4864, 1680 May 2007. 1682 [RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering 1683 ICMPv6 Messages in Firewalls", RFC 4890, May 2007. 1685 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 1686 Extensions for Stateless Address Autoconfiguration in 1687 IPv6", RFC 4941, September 2007. 1689 [RFC4942] Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/ 1690 Co-existence Security Considerations", RFC 4942, September 1691 2007. 1693 [RFC5157] Chown, T., "IPv6 Implications for Network Scanning", RFC 1694 5157, March 2008. 1696 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 1697 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 1698 March 2008. 1700 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 1701 for IPv6", RFC 5340, July 2008. 1703 [RFC5635] Kumari, W. and D. McPherson, "Remote Triggered Black Hole 1704 Filtering with Unicast Reverse Path Forwarding (uRPF)", 1705 RFC 5635, August 2009. 1707 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 1708 Address Text Representation", RFC 5952, August 2010. 1710 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 1711 Infrastructures (6rd) -- Protocol Specification", RFC 1712 5969, August 2010. 1714 [RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in 1715 Customer Premises Equipment (CPE) for Providing 1716 Residential IPv6 Internet Service", RFC 6092, January 1717 2011. 1719 [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 1720 IPv4/IPv6 Translation", RFC 6144, April 2011. 1722 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 1723 NAT64: Network Address and Protocol Translation from IPv6 1724 Clients to IPv4 Servers", RFC 6146, April 2011. 1726 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 1727 Beijnum, "DNS64: DNS Extensions for Network Address 1728 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 1729 April 2011. 1731 [RFC6164] Kohno, M., Nitzan, B., Bush, R., Matsuzaki, Y., Colitti, 1732 L., and T. Narten, "Using 127-Bit IPv6 Prefixes on Inter- 1733 Router Links", RFC 6164, April 2011. 1735 [RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, "Security 1736 Concerns with IP Tunneling", RFC 6169, April 2011. 1738 [RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the 1739 Router Control Plane", RFC 6192, March 2011. 1741 [RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O. 1742 Troan, "Basic Requirements for IPv6 Customer Edge 1743 Routers", RFC 6204, April 2011. 1745 [RFC6221] Miles, D., Ooghe, S., Dec, W., Krishnan, S., and A. 1746 Kavanagh, "Lightweight DHCPv6 Relay Agent", RFC 6221, May 1747 2011. 1749 [RFC6264] Jiang, S., Guo, D., and B. Carpenter, "An Incremental 1750 Carrier-Grade NAT (CGN) for IPv6 Transition", RFC 6264, 1751 June 2011. 1753 [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 1754 Roberts, "Issues with IP Address Sharing", RFC 6269, June 1755 2011. 1757 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 1758 Translation", RFC 6296, June 2011. 1760 [RFC6302] Durand, A., Gashinsky, I., Lee, D., and S. Sheppard, 1761 "Logging Recommendations for Internet-Facing Servers", BCP 1762 162, RFC 6302, June 2011. 1764 [RFC6324] Nakibly, G. and F. Templin, "Routing Loop Attack Using 1765 IPv6 Automatic Tunnels: Problem Statement and Proposed 1766 Mitigations", RFC 6324, August 2011. 1768 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 1769 Stack Lite Broadband Deployments Following IPv4 1770 Exhaustion", RFC 6333, August 2011. 1772 [RFC6343] Carpenter, B., "Advisory Guidelines for 6to4 Deployment", 1773 RFC 6343, August 2011. 1775 [RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node 1776 Requirements", RFC 6434, December 2011. 1778 [RFC6459] Korhonen, J., Soininen, J., Patil, B., Savolainen, T., 1779 Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation 1780 Partnership Project (3GPP) Evolved Packet System (EPS)", 1781 RFC 6459, January 2012. 1783 [RFC6506] Bhatia, M., Manral, V., and A. Lindem, "Supporting 1784 Authentication Trailer for OSPFv3", RFC 6506, February 1785 2012. 1787 [RFC6547] George, W., "RFC 3627 to Historic Status", RFC 6547, 1788 February 2012. 1790 [RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational 1791 Neighbor Discovery Problems", RFC 6583, March 2012. 1793 [RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and 1794 M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address 1795 Space", BCP 153, RFC 6598, April 2012. 1797 [RFC6620] Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS 1798 SAVI: First-Come, First-Served Source Address Validation 1799 Improvement for Locally Assigned IPv6 Addresses", RFC 1800 6620, May 2012. 1802 [RFC6666] Hilliard, N. and D. Freedman, "A Discard Prefix for IPv6", 1803 RFC 6666, August 2012. 1805 [RFC6810] Bush, R. and R. Austein, "The Resource Public Key 1806 Infrastructure (RPKI) to Router Protocol", RFC 6810, 1807 January 2013. 1809 [RFC6964] Templin, F., "Operational Guidance for IPv6 Deployment in 1810 IPv4 Sites Using the Intra-Site Automatic Tunnel 1811 Addressing Protocol (ISATAP)", RFC 6964, May 2013. 1813 [RFC6980] Gont, F., "Security Implications of IPv6 Fragmentation 1814 with IPv6 Neighbor Discovery", RFC 6980, August 2013. 1816 [RFC7011] Claise, B., Trammell, B., and P. Aitken, "Specification of 1817 the IP Flow Information Export (IPFIX) Protocol for the 1818 Exchange of Flow Information", STD 77, RFC 7011, September 1819 2013. 1821 [RFC7012] Claise, B. and B. Trammell, "Information Model for IP Flow 1822 Information Export (IPFIX)", RFC 7012, September 2013. 1824 [RFC7039] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, 1825 "Source Address Validation Improvement (SAVI) Framework", 1826 RFC 7039, October 2013. 1828 [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of 1829 the IPv6 Prefix Used for IPv6 Address Synthesis", RFC 1830 7050, November 2013. 1832 [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic 1833 Requirements for IPv6 Customer Edge Routers", RFC 7084, 1834 November 2013. 1836 [RFC7112] Gont, F., Manral, V., and R. Bonica, "Implications of 1837 Oversized IPv6 Header Chains", RFC 7112, January 2014. 1839 [RFC7113] Gont, F., "Implementation Advice for IPv6 Router 1840 Advertisement Guard (RA-Guard)", RFC 7113, February 2014. 1842 [RFC7166] Bhatia, M., Manral, V., and A. Lindem, "Supporting 1843 Authentication Trailer for OSPFv3", RFC 7166, March 2014. 1845 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 1846 Interface Identifiers with IPv6 Stateless Address 1847 Autoconfiguration (SLAAC)", RFC 7217, April 2014. 1849 [RFC7381] Chittimaneni, K., Chown, T., Howard, L., Kuarsingh, V., 1850 Pouffary, Y., and E. Vyncke, "Enterprise IPv6 Deployment 1851 Guidelines", RFC 7381, October 2014. 1853 [RFC7404] Behringer, M. and E. Vyncke, "Using Only Link-Local 1854 Addressing inside an IPv6 Network", RFC 7404, November 1855 2014. 1857 [RFC7454] Durand, J., Pepelnjak, I., and G. Doering, "BGP Operations 1858 and Security", BCP 194, RFC 7454, February 2015. 1860 [SCANNING] 1861 "Mapping the Great Void - Smarter scanning for IPv6", 1862 . 1865 Authors' Addresses 1867 Kiran K. Chittimaneni 1868 Dropbox Inc. 1869 185 Berry Street, Suite 400 1870 San Francisco, CA 94107 1871 USA 1873 Email: kk@dropbox.com 1875 Merike Kaeo 1876 Double Shot Security 1877 3518 Fremont Ave N 363 1878 Seattle 98103 1879 USA 1881 Phone: +12066696394 1882 Email: merike@doubleshotsecurity.com 1883 Eric Vyncke 1884 Cisco 1885 De Kleetlaan 6a 1886 Diegem 1831 1887 Belgium 1889 Phone: +32 2 778 4677 1890 Email: evyncke@cisco.com