idnits 2.17.1 draft-ietf-opsec-v6-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 9, 2015) is 3124 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 1556, but no explicit reference was found in the text == Outdated reference: A later version (-08) exists of draft-ietf-6man-ipv6-address-generation-privacy-07 -- 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 (~~), 4 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: March 12, 2016 Double Shot Security 6 E. Vyncke 7 Cisco 8 September 9, 2015 10 Operational Security Considerations for IPv6 Networks 11 draft-ietf-opsec-v6-07 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 (enterprises, service providers 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 March 12, 2016. 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 . . . . . . . . . . . . . . . 4 63 2.1. Addressing Architecture . . . . . . . . . . . . . . . . . 4 64 2.1.1. Statically Configured Addresses . . . . . . . . . . . 4 65 2.1.2. Use of ULAs . . . . . . . . . . . . . . . . . . . . . 5 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. Extension Headers . . . . . . . . . . . . . . . . . . . . 7 71 2.3. Link-Layer Security . . . . . . . . . . . . . . . . . . . 7 72 2.3.1. SeND and CGA . . . . . . . . . . . . . . . . . . . . 8 73 2.3.2. Securing DHCP . . . . . . . . . . . . . . . . . . . . 8 74 2.3.3. ND/RA Rate Limiting . . . . . . . . . . . . . . . . . 9 75 2.3.4. ND/RA Filtering . . . . . . . . . . . . . . . . . . . 10 76 2.3.5. 3GPP Link-Layer Security . . . . . . . . . . . . . . 11 77 2.4. Control Plane Security . . . . . . . . . . . . . . . . . 11 78 2.4.1. Control Protocols . . . . . . . . . . . . . . . . . . 12 79 2.4.2. Management Protocols . . . . . . . . . . . . . . . . 13 80 2.4.3. Packet Exceptions . . . . . . . . . . . . . . . . . . 13 81 2.5. Routing Security . . . . . . . . . . . . . . . . . . . . 14 82 2.5.1. Authenticating Neighbors/Peers . . . . . . . . . . . 14 83 2.5.2. Securing Routing Updates Between Peers . . . . . . . 15 84 2.5.3. Route Filtering . . . . . . . . . . . . . . . . . . . 15 85 2.6. Logging/Monitoring . . . . . . . . . . . . . . . . . . . 16 86 2.6.1. Data Sources . . . . . . . . . . . . . . . . . . . . 17 87 2.6.2. Use of Collected Data . . . . . . . . . . . . . . . . 20 88 2.6.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 22 89 2.7. Transition/Coexistence Technologies . . . . . . . . . . . 23 90 2.7.1. Dual Stack . . . . . . . . . . . . . . . . . . . . . 23 91 2.7.2. Transition Mechanisms . . . . . . . . . . . . . . . . 23 92 2.7.3. Translation Mechanisms . . . . . . . . . . . . . . . 27 93 2.8. General Device Hardening . . . . . . . . . . . . . . . . 28 94 3. Enterprises Specific Security Considerations . . . . . . . . 29 95 3.1. External Security Considerations: . . . . . . . . . . . . 29 96 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 . . . . . . . . . . . . . . . . . . . . . . . 43 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 142 2.1. Addressing Architecture 144 IPv6 address allocations and overall architecture are an important 145 part of securing IPv6. Typically what you initially design for will 146 be what you use for a very long time. Although initially IPv6 was 147 thought to make renumbering easy, in practice, it would be extremely 148 difficult to renumber. 150 Once an address allocation has been assigned, there should be some 151 thought given to an overall address allocation plan. With the 152 abundance of address space available, an address allocation may be 153 structured around services along with geographic locations, which 154 then can be a basis for more structured security policies to permit 155 or deny services between geographic regions. 157 A common question is whether companies should use PI vs PA space 158 [RFC7381] but from a security perspective there is little difference. 159 However, one aspect to keep in mind is who has ownership of the 160 address space and who is responsible if/when Law Enforcement may need 161 to enforce restrictions on routability of the space due to malicious 162 criminal activity. 164 2.1.1. Statically Configured Addresses 166 When considering how to assign statically configured addresses it is 167 necessary to take into consideration the effectiveness of perimeter 168 security in a given environment. There is a trade-off between ease 169 of operational deployment where some portions of the IPv6 address 170 could be easily recognizable for operational debugging and 171 troubleshooting versus the risk of scanning; [SCANNING] shows that 172 there are scientifically based mechanisms that make scanning for IPv6 173 reachable nodes more realizable than expected. The use of common 174 multicast groups which are defined for important networked devices 175 and the use of commonly repeated addresses could make it easy to 176 figure out which devices are name servers, routers or other critical 177 devices. 179 While in some environments the perimeter security is so poor that 180 obfuscating addresses is considered a benefit; it is a better 181 practice to ensure that perimeter rules are actively checked and 182 enforced and that statically configured addresses follow some logical 183 allocation scheme for ease of operation. 185 2.1.2. Use of ULAs 187 ULAs are intended for scenarios where IP addresses will not have 188 global scope. The implicit expectation from the RFC is that all ULAs 189 will be randomly created as /48s. Any use of ULAs that are not 190 created as a /48 violates [RFC4193]. 192 ULAs could be useful for infrastructure hiding as described in 193 [RFC4864]; Alternatively Link-Local addresses [RFC7404] could also be 194 used. Although ULAs are supposed to be used in conjunction with 195 global addresses for hosts that desire external connectivity, a few 196 operators chose to use ULAs in conjunction with some sort of address 197 translation at the border in order to maintain a perception of parity 198 between their IPv4 and IPv6 setup. Some operators believe that 199 stateful IPv6 Network Address and Port Translation (NAPT) provides 200 some security not provided by NPTv6 (the authors of this document do 201 not share this point of view). The latter would be problematic in 202 trying to track specific machines that may source malware although 203 this is less of an issue if appropriate logging is done which 204 includes utilizing accurate timestamps and logging a node's source 205 ports [RFC6302]. 207 The use of ULA does not isolate 'by magic' the part of the network 208 using ULA from other parts of the network (including the Internet). 209 Although section 4.1 of [RFC4193] explicitly states "If BGP is being 210 used at the site border with an ISP, the default BGP configuration 211 must filter out any Local IPv6 address prefixes, both incoming and 212 outgoing.", the operational reality is that this guideline is not 213 always followed. As written, RFC4193 makes no changes to default 214 routing behavior of exterior protocols. Therefore, routers will 215 happily forward packets whose source or destination address is ULA as 216 long as they have a route to the destination and there is no ACL 217 blocking those packets. This means that using ULA does not prevent 218 route and packet filters to be implemented and monitored. This also 219 means that all Internet transit networks should consider ULA as 220 source or destination as bogons packets and drop them. 222 It is important to carefully weigh the benefits of using ULAs versus 223 utilizing a section of the global allocation and creating a more 224 effective filtering strategy. A typical argument is that there are 225 too many mistakes made with filters and ULAs make things easier to 226 hide machines. 228 2.1.3. Point-to-Point Links 230 [RFC6164] recommends the use of /127 for inter-router point-to-point 231 links. A /127 prevents the ping-pong attack between routers. 232 However, it should be noted that at the time of this writing, there 233 are still many networks out there that follow the advice provided by 234 [RFC3627] (obsoleted and marked Historic by [RFC6547]) and therefore 235 continue to use /64's and/or /112's. We recommend that the guidance 236 provided by RFC6164 be followed. 238 Some environments are also using link-local addressing for point-to- 239 point links. While this practice could further reduce the attack 240 surface against infrastructure devices, the operational disadvantages 241 need also to be carefully considered [RFC7404]. 243 2.1.4. Temporary Addresses - Privacy Extensions for SLAAC 245 Normal stateless address autoconfiguration (SLAAC) relies on the 246 automatically generated EUI-64 address, which together with the /64 247 prefix makes up the global unique IPv6 address. The EUI-64 address 248 is generated from the MAC address. Randomly generating an interface 249 ID, as described in [RFC4941], is part of SLAAC with so-called 250 privacy extension addresses and used to address some privacy 251 concerns. Privacy extension addresses a.k.a. temporary addresses may 252 help to mitigate the correlation of activities of a node within the 253 same network, and may also reduce the attack exposure window. 255 As privacy extension addresses could also be used to obfuscate some 256 malevolent activities (whether on purpose or not), it is advised in 257 scenarios where user attribution is important to disable SLAAC and 258 rely only on DHCPv6. However, in scenarios where anonymity is a 259 strong desire since protecting user privacy is more important than 260 user attribution, privacy extension addresses should be used 262 Using privacy extension addresses prevents the operator from building 263 a priori host specific access control lists (ACLs). It must be noted 264 that recent versions of Windows do not use the MAC address anymore to 265 build the stable address but use a mechanism similar to the one 266 described in [RFC7217], this also means that such an ACL cannot be 267 configured based solely on the MAC address of the nodes, diminishing 268 the value of such ACL. On the other hand, different VLANs are often 269 used to segregate users, then ACL can rely on a /64 prefix per VLAN 270 rather than a per host ACL entry. 272 The decision to utilize privacy extension addresses can come down to 273 whether the network is managed versus unmanaged. In some 274 environments full visibility into the network is required at all 275 times which requires that all traffic be attributable to where it is 276 sourced or where it is destined to within a specific network. This 277 situation is dependent on what level of logging is performed. If 278 logging considerations include utilizing accurate timestamps and 279 logging a node's source ports [RFC6302] then there should always 280 exist appropriate user attribution needed to get to the source of any 281 malware originator or source of criminal activity. 283 Disabling SLAAC and privacy extensions addresses can be done by 284 sending Router Advertisement with a hint to use DHCPv6 by setting the 285 M-bit but also disabling SLAAC by resetting all A-bits in all prefixe 286 information options sent in the Router Advertisement message. 288 2.1.5. Privacy consideration of Addresses 290 However, there are several privacy issues still present with 291 [RFC4941] such as host tracking, and address scanning attacks are 292 still possible. More details are provided in Appendix A. of 293 [RFC7217] and in [I-D.ietf-6man-ipv6-address-generation-privacy]. 295 2.1.6. DHCP/DNS Considerations 297 Many environments use DHCPv6 to allocate addresses to ensure 298 audibility and traceability (but see Section 2.6.1.5). A main 299 security concern is the ability to detect and mitigate against rogue 300 DHCP servers (Section 2.3.2). 302 DNS is often used for malware activities and while there are no 303 fundamental differences with IPv4 and IPv6 security concerns, there 304 are specific consideration in DNS64 [RFC6147] environments that need 305 to be understood. Specifically the interactions and potential to 306 interference with DNSsec implementation need to be understood - these 307 are pointed out in detail in Section 2.7.3.2. 309 2.2. Extension Headers 311 TBD, a short section referring to all Fernando's I-D & RFC. 313 2.3. Link-Layer Security 315 IPv6 relies heavily on the Neighbor Discovery protocol (NDP) 316 [RFC4861] to perform a variety of link operations such as discovering 317 other nodes on the link, resolving their link-layer addresses, and 318 finding routers on the link. If not secured, NDP is vulnerable to 319 various attacks such as router/neighbor message spoofing, redirect 320 attacks, Duplicate Address Detection (DAD) DoS attacks, etc. many of 321 these security threats to NDP have been documented in IPv6 ND Trust 322 Models and Threats [RFC3756] and in [RFC6583]. 324 2.3.1. SeND and CGA 326 SEcure Neighbor Discovery (SeND), as described in [RFC3971], is a 327 mechanism that was designed to secure ND messages. This approach 328 involves the use of new NDP options to carry public key based 329 signatures. Cryptographically Generated Addresses (CGA), as 330 described in [RFC3972], are used to ensure that the sender of a 331 Neighbor Discovery message is the actual "owner" of the claimed IPv6 332 address. A new NDP option, the CGA option, was introduced and is 333 used to carry the public key and associated parameters. Another NDP 334 option, the RSA Signature option, is used to protect all messages 335 relating to neighbor and Router discovery. 337 SeND protects against: 339 o Neighbor Solicitation/Advertisement Spoofing 341 o Neighbor Unreachability Detection Failure 343 o Duplicate Address Detection DoS Attack 345 o Router Solicitation and Advertisement Attacks 347 o Replay Attacks 349 o Neighbor Discovery DoS Attacks 351 SeND does NOT: 353 o Protect statically configured addresses 355 o Protect addresses configured using fixed identifiers (i.e. EUI- 356 64) 358 o Provide confidentiality for NDP communications 360 o Compensate for an unsecured link - SEND does not require that the 361 addresses on the link and Neighbor Advertisements correspond 363 However, at this time and after many years after their 364 specifications, CGA and SeND do not have wide support from generic 365 operating systems; hence, their usefulness is limited. 367 2.3.2. Securing DHCP 369 Dynamic Host Configuration Protocol for IPv6 (DHCPv6), as detailed in 370 [RFC3315], enables DHCP servers to pass configuration parameters such 371 as IPv6 network addresses and other configuration information to IPv6 372 nodes. DHCP plays an important role in any large network by 373 providing robust stateful autoconfiguration and autoregistration of 374 DNS Host Names. 376 The two most common threats to DHCP clients come from malicious 377 (a.k.a. rogue) or unintentionally misconfigured DHCP servers. A 378 malicious DHCP server is established with the intent of providing 379 incorrect configuration information to the client to cause a denial 380 of service attack or mount a man in the middle attack. While 381 unintentionall, a misconfigured DHCP server can have the same impact. 382 Additional threats against DHCP are discussed in the security 383 considerations section of [RFC3315]DHCP-shield 385 [RFC7610] specifies a mechanism for protecting hosts connected 386 against rogue DHCPv6 servers. This mechanism is based on DHCPv6 387 packet-filtering at the layer-2 device; the administrator specifies 388 the interfaces connected to DHCPv6 servers. 390 It is recommended to use DHCP-shield. 392 2.3.3. ND/RA Rate Limiting 394 Neighbor Discovery (ND) can be vulnerable to denial of service (DoS) 395 attacks in which a router is forced to perform address resolution for 396 a large number of unassigned addresses. Possible side effects of 397 this attack preclude new devices from joining the network or even 398 worse rendering the last hop router ineffective due to high CPU 399 usage. Easy mitigative steps include rate limiting Neighbor 400 Solicitations, restricting the amount of state reserved for 401 unresolved solicitations, and clever cache/timer management. 403 [RFC6583] discusses the potential for DOS in detail and suggests 404 implementation improvements and operational mitigation techniques 405 that may be used to mitigate or alleviate the impact of such attacks. 406 Here are some feasible mitigation options that can be employed by 407 network operators today: 409 o Ingress filtering of unused addresses by ACL, route filtering, 410 longer than /64 prefix; These require static configuration of the 411 addresses. 413 o Tuning of NDP process (where supported). 415 Additionally, IPv6 ND uses multicast extensively for signaling 416 messages on the local link to avoid broadcast messages for on-the- 417 wire efficiency. However, this has some side effects on wifi 418 networks, especially a negative impact on battery life of smartphones 419 and other battery operated devices that are connected to such 420 networks. The following drafts are actively discussing methods to 421 rate limit RAs and other ND messages on wifi networks in order to 422 address this issue: 424 o [I-D.thubert-savi-ra-throttler] 426 o [I-D.chakrabarti-nordmark-6man-efficient-nd] 428 2.3.4. ND/RA Filtering 430 Router Advertisement spoofing is a well-known attack vector and has 431 been extensively documented. The presence of rogue RAs, either 432 intentional or malicious, can cause partial or complete failure of 433 operation of hosts on an IPv6 link. For example, a host can select 434 an incorrect router address which can be used as a man-in-the-middle 435 (MITM) attack or can assume wrong prefixes to be used for stateless 436 address configuration (SLAAC). [RFC6104] summarizes the scenarios in 437 which rogue RAs may be observed and presents a list of possible 438 solutions to the problem. [RFC6105] (RA-Guard) describes a solution 439 framework for the rogue RA problem where network segments are 440 designed around switching devices that are capable of identifying 441 invalid RAs and blocking them before the attack packets actually 442 reach the target nodes. 444 However, several evasion techniques that circumvent the protection 445 provided by RA-Guard have surfaced. A key challenge to this 446 mitigation technique is introduced by IPv6 fragmentation. An 447 attacker can conceal the attack by fragmenting his packets into 448 multiple fragments such that the switching device that is responsible 449 for blocking invalid RAs cannot find all the necessary information to 450 perform packet filtering in the same packet. [RFC7113] describes 451 such evasion techniques, and provides advice to RA-Guard implementers 452 such that the aforementioned evasion vectors can be eliminated. 454 Given that the IPv6 Fragmentation Header can be leveraged to 455 circumvent current implementations of RA-Guard, [RFC6980] aims to 456 update [RFC4861] such that use of the IPv6 Fragmentation Header is 457 forbidden in all Neighbor Discovery messages except "Certification 458 Path Advertisement", thus allowing for simple and effective measures 459 to counter Neighbor Discovery attacks. 461 The Source Address Validation Improvements (SAVI) working group has 462 worked on other ways to mitigate the effects of such attacks. 463 [RFC7513] would help in creating bindings between a DHCPv4 [RFC2131] 464 /DHCPv6 [RFC3315] assigned source IP address and a binding anchor 465 [RFC7039] on a SAVI device. Also, [RFC6620] describes how to glean 466 similar bindings when DHCP is not used. The bindings can be used to 467 filter packets generated on the local link with forged source IP 468 address. 470 It is still recommended that RA-Guard be be employed as a first line 471 of defense against common attack vectors including misconfigured 472 hosts. 474 2.3.5. 3GPP Link-Layer Security 476 The 3GPP link is a point-to-point like link that has no link-layer 477 address. This implies there can only be an end host (the mobile 478 hand-set) and the first-hop router (i.e., a GPRS Gatewat Support Node 479 (GGSN) or a Packet Gateway (PGW)) on that link. The GGSN/PGW never 480 configures a non link-local address on the link using the advertised 481 /64 prefix on it. The advertised prefix must not be used for on-link 482 determination. There is no need for an address resolution on the 483 3GPP link, since there are no link-layer addresses. Furthermore, the 484 GGSN/PGW assigns a prefix that is unique within each 3GPP link that 485 uses IPv6 stateless address autoconfiguration. This avoids the 486 necessity to perform DAD at the network level for every address built 487 by the mobile host. The GGSN/PGW always provides an IID to the 488 cellular host for the purpose of configuring the link-local address 489 and ensures the uniqueness of the IID on the link (i.e., no 490 collisions between its own link-local address and the mobile host's 491 one). 493 The 3GPP link model itself mitigates most of the known NDP-related 494 Denial-of-Service attacks. In practice, the GGSN/PGW only needs to 495 route all traffic to the mobile host that falls under the prefix 496 assigned to it. As there is also a single host on the 3GPP link, 497 there is no need to defend that IPv6 address. 499 See Section 5 of [RFC6459] for a more detailed discussion on the 3GPP 500 link model, NDP on it and the address configuration detail. 502 2.4. Control Plane Security 504 [RFC6192] defines the router control plane and this definition is 505 repeated here for the reader's convenience. 507 Modern router architecture design maintains a strict separation of 508 forwarding and router control plane hardware and software. The 509 router control plane supports routing and management functions. It 510 is generally described as the router architecture hardware and 511 software components for handling packets destined to the device 512 itself as well as building and sending packets originated locally on 513 the device. The forwarding plane is typically described as the 514 router architecture hardware and software components responsible for 515 receiving a packet on an incoming interface, performing a lookup to 516 identify the packet's IP next hop and determine the best outgoing 517 interface towards the destination, and forwarding the packet out 518 through the appropriate outgoing interface. 520 While the forwarding plane is usually implemented in high-speed 521 hardware, the control plane is implemented by a generic processor 522 (named router processor RP) and cannot process packets at a high 523 rate. Hence, this processor can be attacked by flooding its input 524 queue with more packets than it can process. The control plane 525 processor is then unable to process valid control packets and the 526 router can lose OSPF or BGP adjacencies which can cause a severe 527 network disruption. 529 The mitigation technique is: 531 o To drop non-legit control packet before they are queued to the RP 532 (this can be done by a forwarding plane ACL) and 534 o To rate limit the remaining packets to a rate that the RP can 535 sustain. Protocol specific protection should also be done (for 536 example, a spoofed OSPFv3 packet could trigger the execution of 537 the Dijkstra algorithm, therefore the number of Dijsktra execution 538 should be also rate limited). 540 This section will consider several classes of control packets: 542 o Control protocols: routing protocols: such as OSPFv3, BGP and by 543 extension Neighbor Discovery and ICMP 545 o Management protocols: SSH, SNMP, IPfix, etc 547 o Packet exceptions: which are normal data packets which requires a 548 specific processing such as generating a packet-too-big ICMP 549 message or having the hop-by-hop extension header. 551 2.4.1. Control Protocols 553 This class includes OSPFv3, BGP, NDP, ICMP. 555 An ingress ACL to be applied on all the router interfaces SHOULD be 556 configured such as: 558 o drop OSPFv3 (identified by Next-Header being 89) and RIPng 559 (identified by UDP port 521) packets from a non link-local address 561 o allow BGP (identified by TCP port 179) packets from all BGP 562 neighbors and drop the others 564 o allow all ICMP packets (transit and to the router interfaces) 566 Note: dropping OSPFv3 packets which are authenticated by IPsec could 567 be impossible on some routers whose ACL are unable to parse the IPsec 568 ESP or AH extension headers. 570 Rate limiting of the valid packets SHOULD be done. The exact 571 configuration obviously depends on the power of the Route Processor. 573 2.4.2. Management Protocols 575 This class includes: SSH, SNMP, syslog, NTP, etc 577 An ingress ACL to be applied on all the router interfaces SHOULD be 578 configured such as: 580 o Drop packets destined to the routers except those belonging to 581 protocols which are used (for example, permit TCP 22 and drop all 582 when only SSH is used); 584 o Drop packets where the source does not match the security policy, 585 for example if SSH connections should only be originated from the 586 NOC, then the ACL should permit TCP port 22 packets only from the 587 NOC prefix. 589 Rate limiting of the valid packets SHOULD be done. The exact 590 configuration obviously depends on the power of the Route Processor. 592 2.4.3. Packet Exceptions 594 This class covers multiple cases where a data plane packet is punted 595 to the route processor because it requires specific processing: 597 o generation of an ICMP packet-too-big message when a data plane 598 packet cannot be forwarded because it is too large; 600 o generation of an ICMP hop-limit-expired message when a data plane 601 packet cannot be forwarded because its hop-limit field has reached 602 0; 604 o generation of an ICMP destination-unreachable message when a data 605 plane packet cannot be forwarded for any reason; 607 o processing of the hop-by-hop extension header; 609 o or more specific to some router implementation: an oversized 610 extension header chain which cannot be processed by the hardware 611 and force the packet to be punted to the generic router CPU. 613 On some routers, not everything can be done by the specialized data 614 plane hardware which requires some packets to be 'punted' to the 615 generic RP. This could include for example the processing of a long 616 extension header chain in order to apply an ACL based on layer 4 617 information. [RFC6980] and more generally [RFC7112] highlight the 618 security implications of oversized header chains on routers and aims 619 to update RFC2460 such that the first fragment of a packet is 620 required to contain the entire IPv6 header chain. 622 An ingress ACL cannot help to mitigate a control plane attack using 623 those packet exceptions. The only protection for the RP is to limit 624 the rate of those packet exceptions forwarded to the RP, this means 625 that some data plane packets will be dropped without any ICMP 626 messages back to the source which will cause Path MTU holes. But, 627 there is no other solution. 629 In addition to limiting the rate of data plane packets queued to the 630 RP, it is also important to limit the generation rate of ICMP 631 messages both the save the RP but also to prevent an amplification 632 attack using the router as a reflector. 634 2.5. Routing Security 636 Routing security in general can be broadly divided into three 637 sections: 639 1. Authenticating neighbors/peers 641 2. Securing routing updates between peers 643 3. Route filtering 645 [RFC7454] covers these sections specifically for BGP in detail. 647 2.5.1. Authenticating Neighbors/Peers 649 A basic element of routing is the process of forming adjacencies, 650 neighbor, or peering relationships with other routers. From a 651 security perspective, it is very important to establish such 652 relationships only with routers and/or administrative domains that 653 one trusts. A traditional approach has been to use MD5 HMAC, which 654 allows routers to authenticate each other prior to establishing a 655 routing relationship. 657 OSPFv3 can rely on IPsec to fulfill the authentication function. 658 However, it should be noted that IPsec support is not standard on all 659 routing platforms. In some cases, this requires specialized hardware 660 that offloads crypto over to dedicated ASICs or enhanced software 661 images (both of which often come with added financial cost) to 662 provide such functionality. An added detail is to determine whether 663 OSPFv3 IPsec implementations use AH or ESP-Null for integrity 664 protection. In early implementations all OSPFv3 IPsec configurations 665 relied on AH since the details weren't specified in [RFC5340] or 666 [RFC2740] that was obsoleted by the former. However, the document 667 which specifically describes how IPsec should be implemented for 668 OSPFv3 [RFC4552] specifically states that ESP-Null MUST and AH MAY be 669 implemented since it follows the overall IPsec standards wordings. 670 OSPFv3 can also use normal ESP to encrypt the OSPFv3 payload to hide 671 the routing information. 673 [RFC7166] (which obsoletes [RFC6506] changes OSPFv3's reliance on 674 IPsec by appending an authentication trailer to the end of the OSPFv3 675 packets. This document does not specifically provide for a mechanism 676 that will authenticate the specific originator of a packet. Rather, 677 it will allow a router to confirm that the packet has indeed been 678 issued by a router that had access to the shared authentication key. 680 With all authentication mechanisms, operators should confirm that 681 implementations can support re-keying mechanisms that do not cause 682 outages. There have been instances where any re-keying cause outages 683 and therefore the tradeoff between utilizing this functionality needs 684 to be weighed against the protection it provides. 686 2.5.2. Securing Routing Updates Between Peers 688 IPv6 initially mandated the provisioning of IPsec capability in all 689 nodes. However, in the updated IPv6 Nodes Requirement standard 690 [RFC6434] is now a SHOULD and not MUST implement. Theoretically it 691 is possible, and recommended, that communication between two IPv6 692 nodes, including routers exchanging routing information be encrypted 693 using IPsec. In practice however, deploying IPsec is not always 694 feasible given hardware and software limitations of various platforms 695 deployed, as described in the earlier section. Additionally, in a 696 protocol such as OSPFv3 where adjacencies are formed on a one-to-many 697 basis, IPsec key management becomes difficult to maintain and is not 698 often utilized. 700 2.5.3. Route Filtering 702 Route filtering policies will be different depending on whether they 703 pertain to edge route filtering vs internal route filtering. At a 704 minimum, IPv6 routing policy as it pertains to routing between 705 different administrative domains should aim to maintain parity with 706 IPv4 from a policy perspective e.g., 707 o Filter internal-use, non-globally routable IPv6 addresses at the 708 perimeter 710 o Discard packets from and to bogon and reserved space 712 o Configure ingress route filters that validate route origin, prefix 713 ownership, etc. through the use of various routing databases, 714 e.g., RADB. There is additional work being done in this area to 715 formally validate the origin ASs of BGP announcements in [RFC6810] 717 Some good recommendations for filtering can be found from Team CYMRU 718 at [CYMRU]. 720 2.6. Logging/Monitoring 722 In order to perform forensic research in case of any security 723 incident or to detect abnormal behaviors, network operator should log 724 multiple pieces of information. 726 This includes: 728 o logs of all applications when available (for example web servers); 730 o use of IP Flow Information Export [RFC7011] also known as IPfix; 732 o use of SNMP MIB [RFC4293]; 734 o use of the Neighbor cache; 736 o use of stateful DHCPv6 [RFC3315] lease cache, especially when a 737 relay agent [RFC6221] in layer-2 switches is used; 739 o use of RADIUS [RFC2866] for accounting records. 741 Please note that there are privacy issues related to how those logs 742 are collected, kept and safely discarded. Operators are urged to 743 check their country legislation. 745 All those pieces of information will be used for: 747 o forensic (Section 2.6.2.1) research to answer questions such as 748 who did what and when? 750 o correlation (Section 2.6.2.3): which IP addresses were used by a 751 specific node (assuming the use of privacy extensions addresses 752 [RFC4941]) 754 o inventory (Section 2.6.2.2): which IPv6 nodes are on my network? 755 o abnormal behavior detection (Section 2.6.2.4): unusual traffic 756 patterns are often the symptoms of a abnormal behavior which is in 757 turn a potential attack (denial of services, network scan, a node 758 being part of a botnet, ...) 760 2.6.1. Data Sources 762 This section lists the most important sources of data that are useful 763 for operational security. 765 2.6.1.1. Logs of Applications 767 Those logs are usually text files where the remote IPv6 address is 768 stored in all characters (not binary). This can complicate the 769 processing since one IPv6 address, 2001:db8::1 can be written in 770 multiple ways such as: 772 o 2001:DB8::1 (in uppercase) 774 o 2001:0db8::0001 (with leading 0) 776 o and many other ways. 778 RFC 5952 [RFC5952] explains this problem in detail and recommends the 779 use of a single canonical format (in short use lower case and 780 suppress leading 0). This memo recommends the use of canonical 781 format [RFC5952] for IPv6 addresses in all possible cases. If the 782 existing application cannot log under the canonical format, then this 783 memo recommends the use an external program in order to canonicalize 784 all IPv6 addresses. 786 For example, this perl script can be used: 788 #!/usr/bin/perl ?w 789 use strict ; 790 use warnings ; 791 use Socket ; 792 use Socket6 ; 794 my (@words, $word, $binary_address) ; 796 ## go through the file one line at a time 797 while (my $line = ) { 798 chomp $line; 799 foreach my $word (split /[ \n]/, $line) { 800 $binary_address = inet_pton AF_INET6, $word ; 801 if ($binary_address) { 802 print inet_ntop AF_INET6, $binary_address ; 803 } else { 804 print $word ; 805 } 806 print " " ; 807 } 808 print "\n" ; 809 } 811 2.6.1.2. IP Flow Information Export by IPv6 Routers 813 IPfix [RFC7012] defines some data elements that are useful for 814 security: 816 o in section 5.4 (IP Header fields): nextHeaderIPv6 and 817 sourceIPv6Address; 819 o in section 5.6 (Sub-IP fields) sourceMacAddress. 821 Moreover, IPfix is very efficient in terms of data handling and 822 transport. It can also aggregate flows by a key such as 823 sourceMacAddress in order to have aggregated data associated with a 824 specific sourceMacAddress. This memo recommends the use of IPfix and 825 aggregation on nextHeaderIPv6, sourceIPv6Address and 826 sourceMacAddress. 828 2.6.1.3. SNMP MIB by IPv6 Routers 830 RFC 4293 [RFC4293] defines a Management Information Base (MIB) for 831 the two address families of IP. This memo recommends the use of: 833 o ipIfStatsTable table which collects traffic counters per 834 interface; 836 o ipNetToPhysicalTable table which is the content of the Neighbor 837 cache, i.e. the mapping between IPv6 and data-link layer 838 addresses. 840 2.6.1.4. Neighbor Cache of IPv6 Routers 842 The neighbor cache of routers contains all mappings between IPv6 843 addresses and data-link layer addresses. It is usually available by 844 two means: 846 o the SNMP MIB (Section 2.6.1.3) as explained above; 848 o also by connecting over a secure management channel (such as SSH 849 or HTTPS) and explicitely requesting a neighbor cache dump. 851 The neighbor cache is highly dynamic as mappings are added when a new 852 IPv6 address appears on the network (could be quite often with 853 privacy extension addresses [RFC4941] or when they are removed when 854 the state goes from UNREACH to removed (the default time for a 855 removal per Neighbor Unreachability Detection [RFC4861] algorithm is 856 38 seconds for a typical host such as Windows 7). This means that 857 the content of the neighbor cache must periodically be fetched every 858 30 seconds (to be on the safe side) and stored for later use. 860 This is an important source of information because it is trivial (on 861 a switch not using the SAVI [RFC7039] algorithm) to defeat the 862 mapping between data-link layer address and IPv6 address. Let us 863 rephrase the previous statement: having access to the current and 864 past content of the neighbor cache has a paramount value for forensic 865 and audit trail. 867 2.6.1.5. Stateful DHCPv6 Lease 869 In some networks, IPv6 addresses are managed by stateful DHCPv6 870 server [RFC3315] that leases IPv6 addresses to clients. It is indeed 871 quite similar to DHCP for IPv4 so it can be tempting to use this DHCP 872 lease file to discover the mapping between IPv6 addresses and data- 873 link layer addresses as it was usually done in the IPv4 era. 875 It is not so easy in the IPv6 era because not all nodes will use 876 DHCPv6 (there are nodes which can only do stateless 877 autoconfiguration) but also because DHCPv6 clients are identified not 878 by their hardware-client address as in IPv4 but by a DHCP Unique ID 879 (DUID) which can have several formats: some being the data-link layer 880 address, some being data-link layer address prepended with time 881 information or even an opaque number which is useless for operation 882 security. Moreover, when the DUID is based on the data-link address, 883 this address can be of any interface of the client (such as the 884 wireless interface while the client actually uses its wired interface 885 to connect to the network). 887 If a lightweight DHCP relay agent [RFC6221] is used in the layer-2 888 switches, then the DHCP server also receives the Interface-ID 889 information which could be save in order to identifity the interface 890 of the switches which received a specific leased IPv6 address. 892 In short, the DHCPv6 lease file is less interesting than in the IPv4 893 era. DHCPv6 servers that keeps the relayed data-link layer address 894 in addition to the DUID in the lease file do not suffer from this 895 limitation. On a managed network where all hosts support DHCPv6, 896 special care must be taken to prevent stateless autoconfiguration 897 anyway (and if applicable) by sending RA with all announced prefixes 898 without the A-bit set. 900 The mapping between data-link layer address and the IPv6 address can 901 be secured by using switches implementing the SAVI [RFC7513] 902 algorithms. 904 2.6.1.6. RADIUS Accounting Log 906 For interfaces where the user is authenticated via a RADIUS [RFC2866] 907 server, and if RADIUS accounting is enabled, then the RADIUS server 908 receives accounting Acct-Status-Type records at the start and at the 909 end of the connection which include all IPv6 (and IPv4) addresses 910 used by the user. This technique can be used notably for Wi-Fi 911 networks with Wi-Fi Protected Address (WPA) or any other IEEE 802.1X 912 [IEEE-802.1X]wired interface on an Ethernet switch. 914 2.6.1.7. Other Data Sources 916 There are other data sources that must be kept exactly as in the IPv4 917 network: 919 o historical mapping of IPv6 addresses to users of remote access 920 VPN; 922 o historical mapping of MAC address to switch interface in a wired 923 network. 925 2.6.2. Use of Collected Data 927 This section leverages the data collected as described before 928 (Section 2.6.1) in order to achieve several security benefits. 930 2.6.2.1. Forensic 932 The forensic use case is when the network operator must locate an 933 IPv6 address that was present in the network at a certain time or is 934 still currently in the network. 936 The source of information can be, in decreasing order, neighbor 937 cache, DHCP lease file. Then, the procedure is: 939 1. based on the IPv6 prefix of the IPv6 address find the router(s) 940 which are used to reach this prefix; 942 2. based on this limited set of routers, on the incident time and on 943 IPv6 address to retrieve the data-link address from live neighbor 944 cache, from the historical data of the neighbor cache, or from 945 the DHCP lease file; 947 3. based on the data-link layer address, look-up on which switch 948 interface was this data-link layer address. In the case of 949 wireless LAN, the RADIUS log should have the mapping between user 950 identification and the MAC address. 952 At the end of the process, the interface where the malicious user was 953 connected or the username that was used by the malicious user is 954 found. 956 2.6.2.2. Inventory 958 RFC 5157 [RFC5157] is about the difficulties to scan an IPv6 network 959 due to the vast number of IPv6 addresses per link. This has the side 960 effect of making the inventory task difficult in an IPv6 network 961 while it was trivial to do in an IPv4 network (a simple enumeration 962 of all IPv4 addresses, followed by a ping and a TCP/UDP port scan). 963 Getting an inventory of all connected devices is of prime importance 964 for a secure operation of a network. 966 There are two ways to do an inventory of an IPv6 network. 968 The first technique is to use the IPfix information and extract the 969 list of all IPv6 source addresses to find all IPv6 nodes that sent 970 packets through a router. This is very efficient but alas will not 971 discover silent node that never transmitted such packets... Also, it 972 must be noted that link-local addresses will never be discovered by 973 this means. 975 The second way is again to use the collected neighbor cache content 976 to find all IPv6 addresses in the cache. This process will also 977 discover all link-local addresses. See Section 2.6.1.4. 979 Another way works only for local network, it consists in sending a 980 ICMP ECHO_REQUEST to the link-local multicast address ff02::1 which 981 is all IPv6 nodes on the network. All nodes should reply to this 982 ECHO_REQUEST per [RFC4443]. 984 2.6.2.3. Correlation 986 In an IPv4 network, it is easy to correlate multiple logs, for 987 example to find events related to a specific IPv4 address. A simple 988 Unix grep command was enough to scan through multiple text-based 989 files and extract all lines relevant to a specific IPv4 address. 991 In an IPv6 network, this is slightly more difficult because different 992 character strings can express the same IPv6 address. Therefore, the 993 simple Unix grep command cannot be used. Moreover, an IPv6 node can 994 have multiple IPv6 addresses... 996 In order to do correlation in IPv6-related logs, it is advised to 997 have all logs with canonical IPv6 addresses. Then, the neighbor 998 cache current (or historical) data set must be searched to find the 999 data-link layer address of the IPv6 address. Then, the current and 1000 historical neighbor cache data sets must be searched for all IPv6 1001 addresses associated to this data-link layer address: this is the 1002 search set. The last step is to search in all log files (containing 1003 only IPv6 address in canonical format) for any IPv6 addresses in the 1004 search set. 1006 2.6.2.4. Abnormal Behavior Detection 1008 Abnormal behaviors (such as network scanning, spamming, denial of 1009 service) can be detected in the same way as in an IPv4 network 1011 o sudden increase of traffic detected by interface counter (SNMP) or 1012 by aggregated traffic from IPfix records [RFC7012]; 1014 o change of traffic pattern (number of connection per second, number 1015 of connection per host...) with the use of IPfix [RFC7012] 1017 2.6.3. Summary 1019 While some data sources (IPfix, MIB, switch CAM tables, logs, ...) 1020 used in IPv4 are also used in the secure operation of an IPv6 1021 network, the DHCPv6 lease file is less reliable and the neighbor 1022 cache is of prime importance. 1024 The fact that there are multiple ways to express in a character 1025 string the same IPv6 address renders the use of filters mandatory 1026 when correlation must be done. 1028 2.7. Transition/Coexistence Technologies 1030 Some text 1032 2.7.1. Dual Stack 1034 Dual stack has established itself as the preferred deployment choice 1035 for most network operators without a MPLS core where 6PE [RFC4798] is 1036 quite common. Dual stacking the network offers many advantages over 1037 other transition mechanisms. Firstly, it is easy to turn on without 1038 impacting normal IPv4 operations. Secondly, perhaps more 1039 importantly, it is easier to troubleshoot when things break. Dual 1040 stack allows you to gradually turn IPv4 operations down when your 1041 IPv6 network is ready for prime time. 1043 From an operational security perspective, this now means that you 1044 have twice the exposure. One needs to think about protecting both 1045 protocols now. At a minimum, the IPv6 portion of a dual stacked 1046 network should maintain parity with IPv4 from a security policy point 1047 of view. Typically, the following methods are employed to protect 1048 IPv4 networks at the edge: 1050 o ACLs to permit or deny traffic 1052 o Firewalls with stateful packet inspection 1054 It is recommended that these ACLs and/or firewalls be additionally 1055 configured to protect IPv6 communications. Also, given the end-to- 1056 end connectivity that IPv6 provides, it is also recommended that 1057 hosts be fortified against threats. General device hardening 1058 guidelines are provided in Section 2.8 1060 2.7.2. Transition Mechanisms 1062 There are many tunnels used for specific use cases. Except when 1063 protected by IPsec [RFC4301], all those tunnels have a couple of 1064 security issues (most of them being described in RFC 6169 [RFC6169]); 1066 o tunnel injection: a malevolent person knowing a few pieces of 1067 information (for example the tunnel endpoints and the used 1068 protocol) can forge a packet which looks like a legit and valid 1069 encapsulated packet that will gladly be accepted by the 1070 destination tunnel endpoint, this is a specific case of spoofing; 1072 o traffic interception: no confidentiality is provided by the tunnel 1073 protocols (without the use of IPsec), therefore anybody on the 1074 tunnel path can intercept the traffic and have access to the 1075 clear-text IPv6 packet; 1077 o service theft: as there is no authorization, even a non authorized 1078 user can use a tunnel relay for free (this is a specific case of 1079 tunnel injection); 1081 o reflection attack: another specific use case of tunnel injection 1082 where the attacker injects packets with an IPv4 destination 1083 address not matching the IPv6 address causing the first tunnel 1084 endpoint to re-encapsulate the packet to the destination... Hence, 1085 the final IPv4 destination will not see the original IPv4 address 1086 but only one IPv4 address of the relay router. 1088 o bypassing security policy: if a firewall or an IPS is on the path 1089 of the tunnel, then it will probably neither inspect not detect an 1090 malevolent IPv6 traffic contained in the tunnel. 1092 To mitigate the bypassing of security policies, it could be helpful 1093 to block all default configuration tunnels by denying all IPv4 1094 traffic matching: 1096 o IP protocol 41: this will block ISATAP (Section 2.7.2.2), 6to4 1097 (Section 2.7.2.4), 6rd (Section 2.7.2.5) as well as 6in4 1098 (Section 2.7.2.1) tunnels; 1100 o IP protocol 47: this will block GRE (Section 2.7.2.1) tunnels; 1102 o UDP protocol 3544: this will block the default encapsulation of 1103 Teredo (Section 2.7.2.3) tunnels. 1105 Ingress filtering [RFC2827] should also be applied on all tunnel 1106 endpoints if applicable to prevent IPv6 address spoofing. 1108 As several of the tunnel techniques share the same encapsulation 1109 (i.e. IPv4 protocol 41) and embeb the IPv4 address in the IPv6 1110 address, there are a set of well-known looping attacks described in 1111 RFC 6324 [RFC6324], this RFC also proposes mitigation techniques. 1113 2.7.2.1. Site-to-Site Static Tunnels 1115 Site-to-site static tunnels are described in RFC 2529 [RFC2529] and 1116 in GRE [RFC2784]. As the IPv4 endpoints are statically configured 1117 and are not dynamic they are slightly more secure (bi-directional 1118 service theft is mostly impossible) but traffic interception ad 1119 tunnel injection are still possible. Therefore, the use of IPsec 1120 [RFC4301] in transport mode and protecting the encapsulated IPv4 1121 packets is recommended for those tunnels. Alternatively, IPsec in 1122 tunnel mode can be used to transport IPv6 traffic over a non-trusted 1123 IPv4 network. 1125 2.7.2.2. ISATAP 1127 ISATAP tunnels [RFC5214] are mainly used within a single 1128 administrative domain and to connect a single IPv6 host to the IPv6 1129 network. This means that endpoints and and the tunnel endpoint are 1130 usually managed by a single entity; therefore, audit trail and strict 1131 anti-spoofing are usually possible and this raises the overall 1132 security. 1134 Special care must be taken to avoid looping attack by implementing 1135 the measures of RFC 6324 [RFC6324] and of [RFC6964]. 1137 IPsec [RFC4301] in transport or tunnel mode can be used to secure the 1138 IPv4 ISATAP traffic to provide IPv6 traffic confidentiality and 1139 prevent service theft. 1141 2.7.2.3. Teredo 1143 Teredo tunnels [RFC4380] are mainly used in a residential environment 1144 because that can easily traverse an IPv4 NAT-PT device thanks to its 1145 UDP encapsulation and they connect a single host to the IPv6 1146 Internet. Teredo shares the same issues as other tunnels: no 1147 authentication, no confidentiality, possible spoofing and reflection 1148 attacks. 1150 IPsec [RFC4301] for the transported IPv6 traffic is recommended. 1152 The biggest threat to Teredo is probably for IPv4-only network as 1153 Teredo has been designed to easily traverse IPV4 NAT-PT devices which 1154 are quite often co-located with a stateful firewall. Therefore, if 1155 the stateful IPv4 firewall allows unrestricted UDP outbound and 1156 accept the return UDP traffic, then Teredo actually punches a hole in 1157 this firewall for all IPv6 traffic to the Internet and from the 1158 Internet. While host policies can be deployed to block Teredo in an 1159 IPv4-only network in order to avoid this firewall bypass, it would be 1160 more efficient to block all UDP outbound traffic at the IPv4 firewall 1161 if deemed possible (of course, at least port 53 should be left open 1162 for DNS traffic). 1164 2.7.2.4. 6to4 1166 6to4 tunnels [RFC3056] require a public routable IPv4 address in 1167 order to work correctly. They can be used to provide either one IPv6 1168 host connectivity to the IPv6 Internet or multiple IPv6 networks 1169 connectivity to the IPV6 Internet. The 6to4 relay is usually the 1170 anycast address defined in [RFC3068]. Some security considerations 1171 are explained in [RFC3964]. 1173 [RFC6343] points out that if an operator provides well-managed 1174 servers and relays for 6to4, non-encapsulated IPv6 packets will pass 1175 through well- defined points (the native IPv6 interfaces of those 1176 servers and relays) at which security mechanisms may be applied. 1177 Client usage of 6to4 by default is now discouraged, and significant 1178 precautions are needed to avoid operational problems 1180 2.7.2.5. 6rd 1182 While 6rd tunnels share the same encapsulation as 6to4 tunnels 1183 (Section 2.7.2.4), they are designed to be used within a single SP 1184 domain, in other words they are deployed in a more constrained 1185 environment than 6to4 tunnels and have little security issues except 1186 lack of confidentiality. The security considerations (Section 12) of 1187 [RFC5969] describes how to secure the 6rd tunnels. 1189 IPsec [RFC4301] for the transported IPv6 traffic can be used if 1190 confidentiality is important. 1192 2.7.2.6. 6PE and 6VPE 1194 Organizations using MPLS in their core can also use 6PE [RFC4798] and 1195 6VPE [RFC4659] to enable IPv6 access over MPLS. As 6PE and 6VPE are 1196 really similar to BGP/MPLS IP VPN described in [RFC4364], the 1197 security of these networks is also similar to the one described in 1198 [RFC4381]. It relies on: 1200 o Address space, routing and traffic seperation with the help of VRF 1201 (only applicable to 6VPE); 1203 o Hiding the IPv4 core, hence removing all attacks against 1204 P-routers; 1206 o Securing the routing protocol between CE and PE, in the case of 1207 6PE and 6VPE, link-local addresses (see [RFC7404]) can be used and 1208 as these addresses cannot be reached from outside of the link, the 1209 security of 6PE and 6VPE is even higher than the IPv4 BGP/MPLS IP 1210 VPN. 1212 2.7.2.7. DS-Lite 1214 DS-lite is more a translation mechanism and is therefore analyzed 1215 further (Section 2.7.3.3) in this document. 1217 2.7.2.8. Mapping of Address and Port 1219 With the tunnel and encapsulation versions of Mapping of Address and 1220 Port (MAP [RFC7597]), the access network is purely an IPv6 network 1221 and MAP protocols are used to give IPv4 hosts on the subscriber 1222 network, access to IPv4 hosts on the Internet. The subscriber router 1223 does stateful operations in order to map all internal IPv4 addresses 1224 and layer-4 ports to the IPv4 address and the set of layer-4 ports 1225 received through MAP configuration process. The SP equipment always 1226 does stateless operations (either decapsulation or stateless 1227 translation). Therefore, as opposed to Section 2.7.3.3 there is no 1228 state-exhaustion DoS attack against the SP equipment because there is 1229 no state and there is no operation caused by a new layer-4 connection 1230 (no logging operation). 1232 The SP MAP equipment MUST implement all the security considerations 1233 of [RFC7597]; notably, ensuring that the mapping of the IPv4 address 1234 and port are consistent with the configuration. As MAP has a 1235 predictable IPv4 address and port mapping, the audit log are easier 1236 to manager. 1238 2.7.3. Translation Mechanisms 1240 Translation mechanisms between IPv4 and IPv6 networks are alternative 1241 coexistence strategies while networks transition to IPv6. While a 1242 framework is described in [RFC6144] the specific security 1243 considerations are documented in each individual mechanism. For the 1244 most part they specifically mention interference with IPsec or DNSSEC 1245 deployments, how to mitigate spoofed traffic and what some effective 1246 filtering strategies may be. 1248 2.7.3.1. Carrier-Grade Nat (CGN) 1250 Carrier-Grade NAT (CGN), also called NAT444 CGN or Large Scale NAT 1251 (LSN) or SP NAT is described in [RFC6264] and is utilized as an 1252 interim measure to prolong the use of IPv4 in a large service 1253 provider network until the provider can deploy and effective IPv6 1254 solution. [RFC6598] requested a specific IANA allocated /10 IPv4 1255 address block to be used as address space shared by all access 1256 networks using CGN. This has been allocated as 100.64.0.0/10. 1258 Section 13 of [RFC6269] lists some specific security-related issues 1259 caused by large scale address sharing. The Security Considerations 1260 section of [RFC6598] also lists some specific mitigation techniques 1261 for potential misuse of shared address space. 1263 [From Panos K: could mention the log size concern and draft-donley- 1264 behave-deterministic-cgn that alleviates it] 1266 2.7.3.2. NAT64/DNS64 1268 Stateful NAT64 translation [RFC6146] allows IPv6-only clients to 1269 contact IPv4 servers using unicast UDP, TCP, or ICMP. It can be used 1270 in conjunction with DNS64 [RFC6147], a mechanism which synthesizes 1271 AAAA records from existing A records. 1273 The Security Consideration sections of [RFC6146] and [RFC6147] list 1274 the comprehensive issues. A specific issue with the use of NAT64 is 1275 that it will interfere with most IPsec deployments unless UDP 1276 encapsulation is used. DNS64 has an incidence on DNSSEC see section 1277 3.1 of [RFC7050]. 1279 2.7.3.3. DS-lite 1281 Dual-Stack Lite (DS-Lite) [RFC6333] is a transition technique that 1282 enables a service provider to share IPv4 addresses among customers by 1283 combining two well-known technologies: IP in IP (IPv4-in-IPv6) and 1284 Network Address and Port Translation (NAPT) 1286 Security considerations with respect to DS-Lite mainly revolve around 1287 logging data, preventing DoS attacks from rogue devices and 1288 restricting service offered by the AFTR only to registered customers. 1290 Section 11 of [RFC6333] describes important security issues 1291 associated with this technology. 1293 2.8. General Device Hardening 1295 There are many environments which rely too much on the network 1296 infrastructure to disallow malicious traffic to get access to 1297 critical hosts. In new IPv6 deployments it has been common to see 1298 IPv6 traffic enabled but none of the typical access control 1299 mechanisms enabled for IPv6 device access. With the possibility of 1300 network device configuration mistakes and the growth of IPv6 in the 1301 overall Internet it is important to ensure that all individual 1302 devices are hardened agains miscreant behavior. 1304 The following guidelines should be used to ensure appropriate 1305 hardening of the host, be it an individual computer or router, 1306 firewall, load-balancer,server, etc device. 1308 o Restrict access to the device to authenticated and authorized 1309 individuals 1311 o Monitor and audit access to the device 1313 o Turn off any unused services on the end node 1314 o Understand which IPv6 addresses are being used to source traffic 1315 and change defaults if necessary 1317 o Use cryptographically protected protocols for device management if 1318 possible (SCP, SNMPv3, SSH, TLS, etc) 1320 o Use host firewall capabilities to control traffic that gets 1321 processed by upper layer protocols 1323 o Use virus scanners to detect malicious programs 1325 3. Enterprises Specific Security Considerations 1327 Enterprises generally have robust network security policies in place 1328 to protect existing IPv4 networks. These policies have been 1329 distilled from years of experiential knowledge of securing IPv4 1330 networks. At the very least, it is recommended that enterprise 1331 networks have parity between their security policies for both 1332 protocol versions. 1334 Security considerations in the enterprise can be broadly categorized 1335 into two sections - External and Internal. 1337 3.1. External Security Considerations: 1339 The external aspect deals with providing security at the edge or 1340 perimeter of the enterprise network where it meets the service 1341 providers network. This is commonly achieved by enforcing a security 1342 policy either by implementing dedicated firewalls with stateful 1343 packet inspection or a router with ACLs. A common default IPv4 1344 policy on firewalls that could easily be ported to IPv6 is to allow 1345 all traffic outbound while only allowing specific traffic, such as 1346 established sessions, inbound. Here are a few more things that could 1347 enhance the default policy: 1349 o Filter internal-use IPv6 addresses at the perimeter 1351 o Discard packets from and to bogon and reserved space 1353 o Accept certain ICMPv6 messages to allow proper operation of ND and 1354 PMTUD, see also [RFC4890] 1356 o Filter specific extension headers, where possible 1358 o Filter unneeded services at the perimeter 1360 o Implement anti-spoofing 1361 o Implement appropriate rate-limiters and control-plane policers 1363 3.2. Internal Security Considerations: 1365 The internal aspect deals with providing security inside the 1366 perimeter of the network, including the end host. The most 1367 significant concerns here are related to Neighbor Discovery. At the 1368 network level, it is recommended that all security considerations 1369 discussed in Section 2.3 be reviewed carefully and the 1370 recommendations be considered in-depth as well. 1372 As mentioned in Section 2.6.2, care must be taken when running 1373 automated IPv6-in-IP4 tunnels. 1375 Hosts need to be hardened directly through security policy to protect 1376 against security threats. The host firewall default capabilities 1377 have to be clearly understood, especially 3rd party ones which can 1378 have different settings for IPv4 or IPv6 default permit/deny 1379 behavior. In some cases, 3rd party firewalls have no IPv6 support 1380 whereas the native firewall installed by default has it. General 1381 device hardening guidelines are provided in Section 2.8 1383 It should also be noted that many hosts still use IPv4 for transport 1384 for things like RADIUS, TACACS+, SYSLOG, etc. This will require some 1385 extra level of due diligence on the part of the operator. 1387 4. Service Providers Security Considerations 1389 4.1. BGP 1391 The threats and mitigation techniques are identical between IPv4 and 1392 IPv6. Broadly speaking they are: 1394 o Authenticating the TCP session; 1396 o TTL security (which becomes hop-limit security in IPv6); 1398 o Prefix Filtering. 1400 These are explained in more detail in section Section 2.5. 1402 4.1.1. Remote Triggered Black Hole Filtering 1404 RTBH [RFC5635] works identically in IPv4 and IPv6. IANA has 1405 allocated 100::/64 as discard prefix [RFC6666]. 1407 4.2. Transition Mechanism 1409 SP will typically use transition mechanisms such as 6rd, 6PE, MAP, 1410 DS-LITE which have been analyzed in the transition Section 2.7.2 1411 section. 1413 4.3. Lawful Intercept 1415 The Lawful Intercept requirements are similar for IPv6 and IPv4 1416 architectures and will be subject to the laws enforced in varying 1417 geographic regions. The local issues with each jurisdiction can make 1418 this challenging and both corporate legal and privacy personnel 1419 should be involved in discussions pertaining to what information gets 1420 logged and what the logging retention policies will be. 1422 The target of interception will usually be a residential subscriber 1423 (e.g. his/her PPP session or physical line or CPE MAC address). With 1424 the absence of NAT on the CPE, IPv6 has the provision to allow for 1425 intercepting the traffic from a single host (a /128 target) rather 1426 than the whole set of hosts of a subscriber (which could be a /48, a 1427 /60 or /64). 1429 In contrast, in mobile environments, since the 3GPP specifications 1430 allocate a /64 per device, it may be sufficient to intercept traffic 1431 from the /64 rather than specific /128's (since each time the device 1432 powers up it gets a new IID). 1434 A sample architecture which was written for informational purposes is 1435 found in [RFC3924]. 1437 5. Residential Users Security Considerations 1439 The IETF Homenet working group is working on how IPv6 residential 1440 network should be done; this obviously includes operational security 1441 considerations; but, this is still work in progress. 1443 Residential users have usually less experience and knowledge about 1444 security or networking. As most of the recent hosts, smartphones, 1445 tablets have all IPv6 enabled by default, IPv6 security is important 1446 for those users. Even with an IPv4-only ISP, those users can get 1447 IPv6 Internet access with the help of Teredo tunnels. Several peer- 1448 to-peer programs (notably Bittorrent) support IPv6 and those programs 1449 can initiate a Teredo tunnel through the IPv4 residential gateway, 1450 with the consequence of making the internal host reachable from any 1451 IPv6 host on the Internet. It is therefore recommended that all host 1452 security products (personal firewall, ...) are configured with a 1453 dual-stack security policy. 1455 If the Residential Gateway has IPv6 connectivity, [RFC7084] (which 1456 obsoletes [RFC6204] defines the requirements of an IPv6 CPE and does 1457 not take position on the debate of default IPv6 security policy: 1459 o outbound only: allowing all internally initiated connections and 1460 block all externally initiated ones, which is a common default 1461 security policy enforced by IPv4 Residential Gateway doing NAT-PT 1462 but it also breaks the end-to-end reachability promise of IPv6. 1463 [RFC6092] lists several recommendations to design such a CPE; 1465 o open: allowing all internally and externally initiated 1466 connections, therefore restoring the end-to-end nature of the 1467 Internet for the IPv6 traffic but having a different security 1468 policy for IPv6 than for IPv4. 1470 [RFC7084] states that a clear choice must be given to the user to 1471 select one of those two policies. 1473 There is also an alternate solution which has been deployed notably 1474 by Swisscom ([I-D.ietf-v6ops-balanced-ipv6-security]: open to all 1475 outbound and inbound connections at the exception of an handful of 1476 TCP and UDP ports known as vulnerable. 1478 6. Further Reading 1480 There are several documents that describe in more details the 1481 security of an IPv6 network; these documents are not written by the 1482 IETF but are listed here for your convenience: 1484 1. Guidelines for the Secure Deployment of IPv6 [NIST] 1486 2. North American IPv6 Task Force Technology Report - IPv6 Security 1487 Technology Paper [NAv6TF_Security] 1489 3. IPv6 Security [IPv6_Security_Book] 1491 7. Acknowledgements 1493 The authors would like to thank the following people for their useful 1494 comments: Mikael Abrahamsson, Brian Carpenter, Tim Chown, Fernando 1495 Gont, Jeffry Handal, Panos Kampanakis, Jouni Korhonen, Mark 1496 Lentczner, Tarko Tikan (by alphabetical order). 1498 8. IANA Considerations 1500 This memo includes no request to IANA. 1502 9. Security Considerations 1504 This memo attempts to give an overview of security considerations of 1505 operating an IPv6 network both in an IPv6-only network and in 1506 utilizing the most widely deployed IPv4/IPv6 coexistence strategies. 1508 10. References 1510 10.1. Normative References 1512 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1513 Requirement Levels", BCP 14, RFC 2119, 1514 DOI 10.17487/RFC2119, March 1997, 1515 . 1517 [RFC6104] Chown, T. and S. Venaas, "Rogue IPv6 Router Advertisement 1518 Problem Statement", RFC 6104, DOI 10.17487/RFC6104, 1519 February 2011, . 1521 [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. 1522 Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, 1523 DOI 10.17487/RFC6105, February 2011, 1524 . 1526 10.2. Informative References 1528 [CYMRU] "Packet Filter and Route Filter Recommendation for IPv6 at 1529 xSP routers", . 1533 [I-D.chakrabarti-nordmark-6man-efficient-nd] 1534 Chakrabarti, S., Nordmark, E., Thubert, P., and M. 1535 Wasserman, "IPv6 Neighbor Discovery Optimizations for 1536 Wired and Wireless Networks", draft-chakrabarti-nordmark- 1537 6man-efficient-nd-07 (work in progress), February 2015. 1539 [I-D.ietf-6man-ipv6-address-generation-privacy] 1540 Cooper, A., Gont, F., and D. Thaler, "Privacy 1541 Considerations for IPv6 Address Generation Mechanisms", 1542 draft-ietf-6man-ipv6-address-generation-privacy-07 (work 1543 in progress), June 2015. 1545 [I-D.ietf-v6ops-balanced-ipv6-security] 1546 Gysi, M., Leclanche, G., Vyncke, E., and R. Anfinsen, 1547 "Balanced Security for IPv6 Residential CPE", draft-ietf- 1548 v6ops-balanced-ipv6-security-01 (work in progress), 1549 December 2013. 1551 [I-D.thubert-savi-ra-throttler] 1552 Thubert, P., "Throttling RAs on constrained interfaces", 1553 draft-thubert-savi-ra-throttler-01 (work in progress), 1554 June 2012. 1556 [IEEE-802.1X] 1557 IEEE, , "IEEE Standard for Local and metropolitan area 1558 networks - Port-Based Network Access Control", IEEE Std 1559 802.1X-2010, February 2010. 1561 [IPv6_Security_Book] 1562 Hogg, and Vyncke, "IPv6 Security", ISBN 1-58705-594-5, 1563 Publisher CiscoPress, December 2008. 1565 [NAv6TF_Security] 1566 Kaeo, , Green, , Bound, , and Pouffary, "North American 1567 IPv6 Task Force Technology Report - IPv6 Security 1568 Technology Paper", 2006, 1569 . 1572 [NIST] Frankel, , Graveman, , Pearce, , and Rooks, "Guidelines 1573 for the Secure Deployment of IPv6", 2010, 1574 . 1577 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 1578 Converting Network Protocol Addresses to 48.bit Ethernet 1579 Address for Transmission on Ethernet Hardware", STD 37, 1580 RFC 826, DOI 10.17487/RFC0826, November 1982, 1581 . 1583 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 1584 RFC 2131, DOI 10.17487/RFC2131, March 1997, 1585 . 1587 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 1588 Domains without Explicit Tunnels", RFC 2529, 1589 DOI 10.17487/RFC2529, March 1999, 1590 . 1592 [RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", 1593 RFC 2740, DOI 10.17487/RFC2740, December 1999, 1594 . 1596 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 1597 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 1598 DOI 10.17487/RFC2784, March 2000, 1599 . 1601 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1602 Defeating Denial of Service Attacks which employ IP Source 1603 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 1604 May 2000, . 1606 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, 1607 DOI 10.17487/RFC2866, June 2000, 1608 . 1610 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 1611 via IPv4 Clouds", RFC 3056, DOI 10.17487/RFC3056, February 1612 2001, . 1614 [RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", 1615 RFC 3068, DOI 10.17487/RFC3068, June 2001, 1616 . 1618 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 1619 C., and M. Carney, "Dynamic Host Configuration Protocol 1620 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 1621 2003, . 1623 [RFC3627] Savola, P., "Use of /127 Prefix Length Between Routers 1624 Considered Harmful", RFC 3627, DOI 10.17487/RFC3627, 1625 September 2003, . 1627 [RFC3756] Nikander, P., Ed., Kempf, J., and E. Nordmark, "IPv6 1628 Neighbor Discovery (ND) Trust Models and Threats", 1629 RFC 3756, DOI 10.17487/RFC3756, May 2004, 1630 . 1632 [RFC3924] Baker, F., Foster, B., and C. Sharp, "Cisco Architecture 1633 for Lawful Intercept in IP Networks", RFC 3924, 1634 DOI 10.17487/RFC3924, October 2004, 1635 . 1637 [RFC3964] Savola, P. and C. Patel, "Security Considerations for 1638 6to4", RFC 3964, DOI 10.17487/RFC3964, December 2004, 1639 . 1641 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 1642 "SEcure Neighbor Discovery (SEND)", RFC 3971, 1643 DOI 10.17487/RFC3971, March 2005, 1644 . 1646 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 1647 RFC 3972, DOI 10.17487/RFC3972, March 2005, 1648 . 1650 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1651 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 1652 . 1654 [RFC4293] Routhier, S., Ed., "Management Information Base for the 1655 Internet Protocol (IP)", RFC 4293, DOI 10.17487/RFC4293, 1656 April 2006, . 1658 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1659 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 1660 December 2005, . 1662 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1663 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 1664 2006, . 1666 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 1667 Network Address Translations (NATs)", RFC 4380, 1668 DOI 10.17487/RFC4380, February 2006, 1669 . 1671 [RFC4381] Behringer, M., "Analysis of the Security of BGP/MPLS IP 1672 Virtual Private Networks (VPNs)", RFC 4381, 1673 DOI 10.17487/RFC4381, February 2006, 1674 . 1676 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 1677 Control Message Protocol (ICMPv6) for the Internet 1678 Protocol Version 6 (IPv6) Specification", RFC 4443, 1679 DOI 10.17487/RFC4443, March 2006, 1680 . 1682 [RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality 1683 for OSPFv3", RFC 4552, DOI 10.17487/RFC4552, June 2006, 1684 . 1686 [RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur, 1687 "BGP-MPLS IP Virtual Private Network (VPN) Extension for 1688 IPv6 VPN", RFC 4659, DOI 10.17487/RFC4659, September 2006, 1689 . 1691 [RFC4798] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur, 1692 "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 1693 Provider Edge Routers (6PE)", RFC 4798, 1694 DOI 10.17487/RFC4798, February 2007, 1695 . 1697 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1698 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1699 DOI 10.17487/RFC4861, September 2007, 1700 . 1702 [RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and 1703 E. Klein, "Local Network Protection for IPv6", RFC 4864, 1704 DOI 10.17487/RFC4864, May 2007, 1705 . 1707 [RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering 1708 ICMPv6 Messages in Firewalls", RFC 4890, 1709 DOI 10.17487/RFC4890, May 2007, 1710 . 1712 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 1713 Extensions for Stateless Address Autoconfiguration in 1714 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 1715 . 1717 [RFC4942] Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/ 1718 Co-existence Security Considerations", RFC 4942, 1719 DOI 10.17487/RFC4942, September 2007, 1720 . 1722 [RFC5157] Chown, T., "IPv6 Implications for Network Scanning", 1723 RFC 5157, DOI 10.17487/RFC5157, March 2008, 1724 . 1726 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 1727 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 1728 DOI 10.17487/RFC5214, March 2008, 1729 . 1731 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 1732 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 1733 . 1735 [RFC5635] Kumari, W. and D. McPherson, "Remote Triggered Black Hole 1736 Filtering with Unicast Reverse Path Forwarding (uRPF)", 1737 RFC 5635, DOI 10.17487/RFC5635, August 2009, 1738 . 1740 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 1741 Address Text Representation", RFC 5952, 1742 DOI 10.17487/RFC5952, August 2010, 1743 . 1745 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 1746 Infrastructures (6rd) -- Protocol Specification", 1747 RFC 5969, DOI 10.17487/RFC5969, August 2010, 1748 . 1750 [RFC6092] Woodyatt, J., Ed., "Recommended Simple Security 1751 Capabilities in Customer Premises Equipment (CPE) for 1752 Providing Residential IPv6 Internet Service", RFC 6092, 1753 DOI 10.17487/RFC6092, January 2011, 1754 . 1756 [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 1757 IPv4/IPv6 Translation", RFC 6144, DOI 10.17487/RFC6144, 1758 April 2011, . 1760 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 1761 NAT64: Network Address and Protocol Translation from IPv6 1762 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 1763 April 2011, . 1765 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 1766 Beijnum, "DNS64: DNS Extensions for Network Address 1767 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 1768 DOI 10.17487/RFC6147, April 2011, 1769 . 1771 [RFC6164] Kohno, M., Nitzan, B., Bush, R., Matsuzaki, Y., Colitti, 1772 L., and T. Narten, "Using 127-Bit IPv6 Prefixes on Inter- 1773 Router Links", RFC 6164, DOI 10.17487/RFC6164, April 2011, 1774 . 1776 [RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, "Security 1777 Concerns with IP Tunneling", RFC 6169, 1778 DOI 10.17487/RFC6169, April 2011, 1779 . 1781 [RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the 1782 Router Control Plane", RFC 6192, DOI 10.17487/RFC6192, 1783 March 2011, . 1785 [RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O. 1786 Troan, Ed., "Basic Requirements for IPv6 Customer Edge 1787 Routers", RFC 6204, DOI 10.17487/RFC6204, April 2011, 1788 . 1790 [RFC6221] Miles, D., Ed., Ooghe, S., Dec, W., Krishnan, S., and A. 1791 Kavanagh, "Lightweight DHCPv6 Relay Agent", RFC 6221, 1792 DOI 10.17487/RFC6221, May 2011, 1793 . 1795 [RFC6264] Jiang, S., Guo, D., and B. Carpenter, "An Incremental 1796 Carrier-Grade NAT (CGN) for IPv6 Transition", RFC 6264, 1797 DOI 10.17487/RFC6264, June 2011, 1798 . 1800 [RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and 1801 P. Roberts, "Issues with IP Address Sharing", RFC 6269, 1802 DOI 10.17487/RFC6269, June 2011, 1803 . 1805 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 1806 Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011, 1807 . 1809 [RFC6302] Durand, A., Gashinsky, I., Lee, D., and S. Sheppard, 1810 "Logging Recommendations for Internet-Facing Servers", 1811 BCP 162, RFC 6302, DOI 10.17487/RFC6302, June 2011, 1812 . 1814 [RFC6324] Nakibly, G. and F. Templin, "Routing Loop Attack Using 1815 IPv6 Automatic Tunnels: Problem Statement and Proposed 1816 Mitigations", RFC 6324, DOI 10.17487/RFC6324, August 2011, 1817 . 1819 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 1820 Stack Lite Broadband Deployments Following IPv4 1821 Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011, 1822 . 1824 [RFC6343] Carpenter, B., "Advisory Guidelines for 6to4 Deployment", 1825 RFC 6343, DOI 10.17487/RFC6343, August 2011, 1826 . 1828 [RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node 1829 Requirements", RFC 6434, DOI 10.17487/RFC6434, December 1830 2011, . 1832 [RFC6459] Korhonen, J., Ed., Soininen, J., Patil, B., Savolainen, 1833 T., Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation 1834 Partnership Project (3GPP) Evolved Packet System (EPS)", 1835 RFC 6459, DOI 10.17487/RFC6459, January 2012, 1836 . 1838 [RFC6506] Bhatia, M., Manral, V., and A. Lindem, "Supporting 1839 Authentication Trailer for OSPFv3", RFC 6506, 1840 DOI 10.17487/RFC6506, February 2012, 1841 . 1843 [RFC6547] George, W., "RFC 3627 to Historic Status", RFC 6547, 1844 DOI 10.17487/RFC6547, February 2012, 1845 . 1847 [RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational 1848 Neighbor Discovery Problems", RFC 6583, 1849 DOI 10.17487/RFC6583, March 2012, 1850 . 1852 [RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and 1853 M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address 1854 Space", BCP 153, RFC 6598, DOI 10.17487/RFC6598, April 1855 2012, . 1857 [RFC6620] Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS 1858 SAVI: First-Come, First-Served Source Address Validation 1859 Improvement for Locally Assigned IPv6 Addresses", 1860 RFC 6620, DOI 10.17487/RFC6620, May 2012, 1861 . 1863 [RFC6666] Hilliard, N. and D. Freedman, "A Discard Prefix for IPv6", 1864 RFC 6666, DOI 10.17487/RFC6666, August 2012, 1865 . 1867 [RFC6810] Bush, R. and R. Austein, "The Resource Public Key 1868 Infrastructure (RPKI) to Router Protocol", RFC 6810, 1869 DOI 10.17487/RFC6810, January 2013, 1870 . 1872 [RFC6964] Templin, F., "Operational Guidance for IPv6 Deployment in 1873 IPv4 Sites Using the Intra-Site Automatic Tunnel 1874 Addressing Protocol (ISATAP)", RFC 6964, 1875 DOI 10.17487/RFC6964, May 2013, 1876 . 1878 [RFC6980] Gont, F., "Security Implications of IPv6 Fragmentation 1879 with IPv6 Neighbor Discovery", RFC 6980, 1880 DOI 10.17487/RFC6980, August 2013, 1881 . 1883 [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, 1884 "Specification of the IP Flow Information Export (IPFIX) 1885 Protocol for the Exchange of Flow Information", STD 77, 1886 RFC 7011, DOI 10.17487/RFC7011, September 2013, 1887 . 1889 [RFC7012] Claise, B., Ed. and B. Trammell, Ed., "Information Model 1890 for IP Flow Information Export (IPFIX)", RFC 7012, 1891 DOI 10.17487/RFC7012, September 2013, 1892 . 1894 [RFC7039] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, Ed., 1895 "Source Address Validation Improvement (SAVI) Framework", 1896 RFC 7039, DOI 10.17487/RFC7039, October 2013, 1897 . 1899 [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of 1900 the IPv6 Prefix Used for IPv6 Address Synthesis", 1901 RFC 7050, DOI 10.17487/RFC7050, November 2013, 1902 . 1904 [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic 1905 Requirements for IPv6 Customer Edge Routers", RFC 7084, 1906 DOI 10.17487/RFC7084, November 2013, 1907 . 1909 [RFC7112] Gont, F., Manral, V., and R. Bonica, "Implications of 1910 Oversized IPv6 Header Chains", RFC 7112, 1911 DOI 10.17487/RFC7112, January 2014, 1912 . 1914 [RFC7113] Gont, F., "Implementation Advice for IPv6 Router 1915 Advertisement Guard (RA-Guard)", RFC 7113, 1916 DOI 10.17487/RFC7113, February 2014, 1917 . 1919 [RFC7166] Bhatia, M., Manral, V., and A. Lindem, "Supporting 1920 Authentication Trailer for OSPFv3", RFC 7166, 1921 DOI 10.17487/RFC7166, March 2014, 1922 . 1924 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 1925 Interface Identifiers with IPv6 Stateless Address 1926 Autoconfiguration (SLAAC)", RFC 7217, 1927 DOI 10.17487/RFC7217, April 2014, 1928 . 1930 [RFC7381] Chittimaneni, K., Chown, T., Howard, L., Kuarsingh, V., 1931 Pouffary, Y., and E. Vyncke, "Enterprise IPv6 Deployment 1932 Guidelines", RFC 7381, DOI 10.17487/RFC7381, October 2014, 1933 . 1935 [RFC7404] Behringer, M. and E. Vyncke, "Using Only Link-Local 1936 Addressing inside an IPv6 Network", RFC 7404, 1937 DOI 10.17487/RFC7404, November 2014, 1938 . 1940 [RFC7454] Durand, J., Pepelnjak, I., and G. Doering, "BGP Operations 1941 and Security", BCP 194, RFC 7454, DOI 10.17487/RFC7454, 1942 February 2015, . 1944 [RFC7513] Bi, J., Wu, J., Yao, G., and F. Baker, "Source Address 1945 Validation Improvement (SAVI) Solution for DHCP", 1946 RFC 7513, DOI 10.17487/RFC7513, May 2015, 1947 . 1949 [RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S., 1950 Murakami, T., and T. Taylor, Ed., "Mapping of Address and 1951 Port with Encapsulation (MAP-E)", RFC 7597, 1952 DOI 10.17487/RFC7597, July 2015, 1953 . 1955 [RFC7610] Gont, F., Liu, W., and G. Van de Velde, "DHCPv6-Shield: 1956 Protecting against Rogue DHCPv6 Servers", BCP 199, 1957 RFC 7610, DOI 10.17487/RFC7610, August 2015, 1958 . 1960 [SCANNING] 1961 "Mapping the Great Void - Smarter scanning for IPv6", 1962 . 1965 Authors' Addresses 1967 Kiran K. Chittimaneni 1968 Dropbox Inc. 1969 185 Berry Street, Suite 400 1970 San Francisco, CA 94107 1971 USA 1973 Email: kk@dropbox.com 1975 Merike Kaeo 1976 Double Shot Security 1977 3518 Fremont Ave N 363 1978 Seattle 98103 1979 USA 1981 Phone: +12066696394 1982 Email: merike@doubleshotsecurity.com 1984 Eric Vyncke 1985 Cisco 1986 De Kleetlaan 6a 1987 Diegem 1831 1988 Belgium 1990 Phone: +32 2 778 4677 1991 Email: evyncke@cisco.com