idnits 2.17.1 draft-ietf-v6ops-enterprise-incremental-ipv6-04.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 16, 2013) is 3838 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 2011 (Obsoleted by RFC 4293) -- Obsolete informational reference (is this intentional?): RFC 2096 (Obsoleted by RFC 4292) -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) -- Obsolete informational reference (is this intentional?): RFC 5102 (Obsoleted by RFC 7012) -- Obsolete informational reference (is this intentional?): RFC 5157 (Obsoleted by RFC 7707) -- Obsolete informational reference (is this intentional?): RFC 6106 (Obsoleted by RFC 8106) -- Obsolete informational reference (is this intentional?): RFC 6145 (Obsoleted by RFC 7915) -- Obsolete informational reference (is this intentional?): RFC 6434 (Obsoleted by RFC 8504) -- Obsolete informational reference (is this intentional?): RFC 6555 (Obsoleted by RFC 8305) == Outdated reference: A later version (-08) exists of draft-xli-behave-divi-05 == Outdated reference: A later version (-05) exists of draft-wierenga-ietf-eduroam-01 == Outdated reference: A later version (-01) exists of draft-ietf-v6ops-dc-ipv6-00 == Outdated reference: A later version (-05) exists of draft-ietf-6man-ext-transmit-04 == Outdated reference: A later version (-12) exists of draft-ietf-v6ops-design-choices-00 == Outdated reference: A later version (-27) exists of draft-ietf-opsec-v6-03 == Outdated reference: A later version (-08) exists of draft-ietf-opsec-ipv6-host-scanning-02 == Outdated reference: A later version (-07) exists of draft-ietf-opsec-ipv6-implications-on-ipv4-nets-05 -- No information found for draft-liu-bonica-dhcpv6 - is the name correct? == Outdated reference: A later version (-05) exists of draft-ietf-v6ops-ula-usage-recommendations-00 Summary: 0 errors (**), 0 flaws (~~), 10 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Chittimaneni 3 Internet-Draft Google Inc. 4 Intended status: Informational T. Chown 5 Expires: April 19, 2014 University of Southampton 6 L. Howard 7 Time Warner Cable 8 V. Kuarsingh 9 Dyn Inc 10 Y. Pouffary 11 Hewlett Packard 12 E. Vyncke 13 Cisco Systems 14 October 16, 2013 16 Enterprise IPv6 Deployment Guidelines 17 draft-ietf-v6ops-enterprise-incremental-ipv6-04 19 Abstract 21 Enterprise network administrators worldwide are in various stages of 22 preparing for or deploying IPv6 into their networks. The 23 administrators face different challenges than operators of Internet 24 access providers, and have reasons for different priorities. The 25 overall problem for many administrators will be to offer Internet- 26 facing services over IPv6, while continuing to support IPv4, and 27 while introducing IPv6 access within the enterprise IT network. The 28 overall transition will take most networks from an IPv4-only 29 environment to a dual stack network environment and eventually an 30 IPv6-only operating mode. This document helps provide a framework 31 for enterprise network architects or administrators who may be faced 32 with many of these challenges as they consider their IPv6 support 33 strategies. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on April 19, 2014. 51 Copyright Notice 53 Copyright (c) 2013 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 69 1.1. Enterprise Assumptions . . . . . . . . . . . . . . . . . 4 70 1.2. IPv4-only Considerations . . . . . . . . . . . . . . . . 4 71 1.3. Reasons for a Phased Approach . . . . . . . . . . . . . . 4 72 2. Preparation and Assessment Phase . . . . . . . . . . . . . . 6 73 2.1. Program Planning . . . . . . . . . . . . . . . . . . . . 6 74 2.2. Inventory Phase . . . . . . . . . . . . . . . . . . . . . 8 75 2.2.1. Network infrastructure readiness assessment . . . . . 8 76 2.2.2. Applications readiness assessment . . . . . . . . . . 8 77 2.2.3. Importance of readiness validation and testing . . . 9 78 2.3. Training . . . . . . . . . . . . . . . . . . . . . . . . 9 79 2.4. Security Policy . . . . . . . . . . . . . . . . . . . . . 9 80 2.4.1. IPv6 is no more secure than IPv4 . . . . . . . . . . 10 81 2.4.2. Similarities between IPv6 and IPv4 security . . . . . 11 82 2.4.3. Specific Security Issues for IPv6 . . . . . . . . . . 11 83 2.5. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 13 84 2.6. Address Plan . . . . . . . . . . . . . . . . . . . . . . 13 85 2.7. Tools Assessment . . . . . . . . . . . . . . . . . . . . 16 86 3. External Phase . . . . . . . . . . . . . . . . . . . . . . . 17 87 3.1. Connectivity . . . . . . . . . . . . . . . . . . . . . . 17 88 3.2. Security . . . . . . . . . . . . . . . . . . . . . . . . 19 89 3.3. Monitoring . . . . . . . . . . . . . . . . . . . . . . . 20 90 3.4. Servers and Applications . . . . . . . . . . . . . . . . 20 91 3.5. Network Prefix Translation for IPv6 . . . . . . . . . . . 20 92 4. Internal Phase . . . . . . . . . . . . . . . . . . . . . . . 21 93 4.1. Security . . . . . . . . . . . . . . . . . . . . . . . . 21 94 4.2. Network Infrastructure . . . . . . . . . . . . . . . . . 22 95 4.3. End user devices . . . . . . . . . . . . . . . . . . . . 23 96 4.4. Corporate Systems . . . . . . . . . . . . . . . . . . . . 24 98 5. IPv6-only . . . . . . . . . . . . . . . . . . . . . . . . . . 24 99 6. Considerations For Specific Enterprises . . . . . . . . . . . 26 100 6.1. Content Delivery Networks . . . . . . . . . . . . . . . . 26 101 6.2. Data Center Virtualization . . . . . . . . . . . . . . . 26 102 6.3. University Campus Networks . . . . . . . . . . . . . . . 26 103 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28 104 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 105 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 106 10. Informative References . . . . . . . . . . . . . . . . . . . 28 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 109 1. Introduction 111 An Enterprise Network is defined in [RFC4057] as a network that has 112 multiple internal links, one or more router connections to one or 113 more Providers, and is actively managed by a network operations 114 entity (the "administrator", whether a single person or department of 115 administrators). Administrators generally support an internal 116 network, consisting of users' workstations, personal computers, other 117 computing devices and related peripherals, a server network, 118 consisting of accounting and business application servers, and an 119 external network, consisting of Internet-accessible services such as 120 web servers, email servers, VPN systems, and customer applications. 121 This document is intended as guidance for network architects and 122 administrators in planning their IPv6 deployments. 124 The business reasons for spending time, effort, and money on IPv6 125 will be unique to each enterprise. The most common drivers are due 126 to the fact that when Internet service providers, including mobile 127 wireless carriers, run out of IPv4 addresses, they will provide 128 native IPv6 and non-native IPv4. The non-native IPv4 service may be 129 NAT64, NAT444, Dual-stack Lite, or other transition technologies. 130 Compared to tunneled or translated, native traffic typically performs 131 better and more reliably than non-native. For example, for client 132 networks trying to reach enterprise networks, the IPv6 experience 133 will be better than the transitional IPv4 if the enterprise deploys 134 IPv6 in its public-facing services. The native IPv6 network path 135 should also be simpler to manage and, if necessary, troubleshoot. 136 Further, enterprises doing business in growing parts of the world may 137 find IPv6 growing faster there, where again potential new customers, 138 employees and partners are using IPv6. It is thus in the 139 enterprise's interests to deploy native IPv6, at the very least in 140 its public-facing services, but ultimately across the majority or all 141 of its scope. 143 The text in this document provides specific guidance for enterprise 144 networks, and complements other related work in the IETF, including 145 [I-D.ietf-v6ops-design-choices] and [RFC5375]. 147 1.1. Enterprise Assumptions 149 For the purpose of this document, we assume: 151 o The administrator is considering deploying IPv6 (but see 152 Section 1.2 below). 154 o The administrator has existing IPv4 networks and devices which 155 will continue to operate and be supported. 157 o The administrator will want to minimize the level of disruption to 158 the users and services by minimizing number of technologies and 159 functions that are needed to mediate any given application. In 160 other words, provide native IP wherever possible. 162 Based on these assumptions, an administrator will want to use 163 technologies which minimize the number of flows being tunnelled, 164 translated or intercepted at any given time. The administrator will 165 choose transition technologies or strategies which allow most traffic 166 to be native, and will manage non-native traffic. This will allow 167 the administrator to minimize the cost of IPv6 transition 168 technologies, by containing the number and scale of transition 169 systems. 171 Tunnels used for IPv6/IPv4 transition are expected as near/mid- term 172 mechanisms, while IPv6 tunneling will be used for many long-term 173 operational purposes such as security, routing control, mobility, 174 multi-homing, traffic engineering, etc. We refer to the former class 175 of tunnels as "transition tunnels" 177 1.2. IPv4-only Considerations 179 As described in [RFC6302] administrators should take certain steps 180 even if they are not considering IPv6. Specifically, Internet-facing 181 servers should log the source port number, timestamp (from a reliable 182 source), and the transport protocol. This will allow investigation 183 of malefactors behind address-sharing technologies such as NAT444 or 184 Dual-stack Lite. 186 Other IPv6 considerations may impact ostensibly IPv4-only networks, 187 e.g. [RFC6104] describes the rogue IPv6 RA problem, which may cause 188 problems in IPv4-only networks where IPv6 is enabled in end systems 189 on that network. Further discussion of the security implications of 190 IPv6 in IPv4-only networks can be found in 191 [I-D.ietf-opsec-ipv6-implications-on-ipv4-nets]). 193 1.3. Reasons for a Phased Approach 194 Given the challenges of transitioning user workstations, corporate 195 systems, and Internet-facing servers, a phased approach allows 196 incremental deployment of IPv6, based on the administrator's own 197 determination of priorities. The Preparation Phase is highly 198 recommended to all administrators, as it will save errors and 199 complexity in later phases. Each administrator must decide whether 200 to begin with the External Phase (as recommended in [RFC5211]) or the 201 Internal Phase. There is no "correct" answer here; the decision is 202 one for each enterprise to make. 204 Each scenario is likely to be different to some extent, but we can 205 highlight some considerations: 207 o In many cases, customers outside the network will have IPv6 before 208 the internal enterprise network. For these customers, IPv6 may 209 well perform better, especially for certain applications, than 210 translated or tunneled IPv4, so the administrator may want to 211 prioritize the External Phase such that those customers have the 212 simplest and most robust connectivity to the enterprise, or at 213 least its external-facing elements. 215 o Employees who access internal systems by VPN may find that their 216 ISPs provide translated IPv4, which does not support the required 217 VPN protocols. In these cases, the administrator may want to 218 prioritize the External Phase, and any other remotely-accessible 219 internal systems. It is worth noting that a number of emerging 220 VPN solutions provide dual-stack connectivity; thus a VPN service 221 may be useful for employees in IPv4-only access networks to access 222 IPv6 resources in the enterprise network (much like many public 223 tunnel broker services, but specifically for the enterprise). 225 o Internet-facing servers cannot be managed over IPv6 unless the 226 management systems are IPv6-capable. These might be Network 227 Management Systems (NMS), monitoring systems, or just remote 228 management desktops. Thus in some cases, the Internet-facing 229 systems are dependent on IPv6-capable internal networks. However, 230 dual-stack Internet-facing systems can still be managed over IPv4. 232 o Virtual machines may enable a faster rollout once initial system 233 deployment is complete. Management of VMs over IPv6 is still 234 dependent on the management software supporting IPv6. 236 o IPv6 is enabled by default on all modern operating systems, so it 237 may be more urgent to manage and have visibility on the internal 238 traffic. It is important to manage IPv6 for security purposes, 239 even in an ostensibly IPv4-only network, as described in 240 [I-D.ietf-opsec-ipv6-implications-on-ipv4-nets]. 242 o In many cases, the corporate accounting, payroll, human resource, 243 and other internal systems may only need to be reachable from the 244 internal network, so they may be a lower priority. As enterprises 245 require their vendors to support IPv6, more internal applications 246 will support IPv6 by default and it can be expected that 247 eventually new applications will only support IPv6. The 248 inventory, as described in Section 2.2, will help determine the 249 systems' readiness, as well as the readiness of the supporting 250 network elements and security, which will be a consideration in 251 prioritization of these corporate systems. 253 o Some large organizations (even when using private IPv4 254 addresses[RFC1918]) are facing IPv4 address exhaustion because of 255 the internal network growth (for example the vast number of 256 virtual machines) or because of the acquisition of other companies 257 that often raise private IPv4 address overlapping issues. 259 o IPv6 restores end to end transparency even for internal 260 applications (of course security policies must still be enforced). 261 When two organizations or networks merge [RFC6879], the unique 262 addressing of IPv6 can make the merger much easier and faster. A 263 merger may, therefore, prioritize IPv6 for the affected systems. 265 These considerations are in conflict; each administrator must 266 prioritize according to their company's conditions. It is worth 267 noting that the reasons given in one "Large Corporate User's View of 268 IPng", described in [RFC1687], for reluctance to deploy have largely 269 been satisfied or overcome in the intervening 18 years. 271 2. Preparation and Assessment Phase 273 2.1. Program Planning 275 As with any project, an IPv6 deployment project will have its own 276 phases. Generally, one person is identified as the project sponsor 277 or champion, who will make sure time, people and other resources are 278 committed appropriately for the project. Because enabling IPv6 can 279 be a project with many interrelated tasks, identifying a project 280 manager is also recommended. The project manager and sponsor can 281 initiate the project, determining the scope of work, the 282 corresponding milestones and deliverables, and identifying whose 283 input is required, and who will be affected by work. The scope will 284 generally include the Preparation Phase, and may include the Internal 285 Phase, the External Phase, or both, and may include any or all of the 286 Other Phases identified. It may be necessary to complete the 287 Preparation Phase before determining which of the other phases will 288 be prioritized, since needs and readiness assessments are part of 289 that phase. 291 The project manager will need to spend some time on planning. It is 292 often useful for the sponsor to communicate with stakeholders at this 293 time, to explain why IPv6 is important to the enterprise. Then, as 294 the project manager is assessing what systems and elements will be 295 affected, the stakeholders will understand why it is important for 296 them to support the effort. Well-informed project participants can 297 help significantly by explaining the relationships between 298 components. For a large enterprise, it may take several iterations 299 to really understand the level of effort required; some systems will 300 require additional development, some might require software updates, 301 and others might need new versions or alternative products from other 302 vendors. Once the projects are understood, the project manager can 303 develop a schedule and a budget, and work with the project sponsor to 304 determine what constraints can be adjusted, if necessary. 306 It is tempting to roll IPv6 projects into other architectural 307 upgrades - this can be an excellent way to improve the network and 308 reduce costs. Project participants are advised that by increasing 309 the scope of projects, the schedule is often affected. For instance, 310 a major systems upgrade may take a year to complete, where just 311 patching existing systems may take only a few months. Understanding 312 and evaluating these trade-offs are why a project manager is 313 important. 315 The deployment of IPv6 will not generally stop all other technology 316 work. Once IPv6 has been identified as an important initiative, all 317 projects will need to evaluate their ability to support IPv6. If 318 expansions or new deployments fail to include IPv6, then additional 319 work will be required after all initial IPv6 has been completed. It 320 may not be possible to delay regular projects for IPv6, if their IPv6 321 support is dependent on network elements that have not yet been 322 upgraded, but the projects need to include a return to IPv6 support 323 in their eventual timeline. 325 It is very common for assessments to continue in some areas even as 326 execution of the project begins in other areas. This is fine, as 327 long as recommendations in other parts of this document are 328 considered, especially regarding security (for instance, one should 329 not deploy IPv6 on a system before security has been evaluated). The 330 project manager will need to continue monitoring the progress of 331 discrete projects and tasks, to be aware of changes in schedule, 332 budget, or scope. "Feature creep" is common, where engineers or 333 management wish to add other features while IPv6 development or 334 deployment is ongoing; each feature will need to be individually 335 evaluated for its effect on the schedule and budget, and whether 336 expanding the scope increases risk to any other part of the project. 338 As projects are completed, the project manager will confirm that work 339 has been completed, often by means of seeing a completed test plan, 340 and will report back to the project sponsor on completed parts of the 341 project. A good project manager will remember to thank the people 342 who executed the project. 344 2.2. Inventory Phase 346 To comprehend the scope of the inventory phase we recommend dividing 347 the problem space in two: network infrastructure readiness and 348 applications readiness. 350 2.2.1. Network infrastructure readiness assessment 352 The goal of this assessment is to identify the level of IPv6 353 readiness of network equipment. This is an important step as it will 354 help identify the effort required to move to an infrastructure that 355 supports IPv6 with the same functional service capabilities as the 356 existing IPv4 network. This may also require a feature comparison 357 and gap analysis between IPv4 and IPv6 functionality on the network 358 equipment and software. 360 Be able to understand which network devices are already capable, 361 which devices can be made IPv6 ready with a code/firmware upgrade, 362 and which devices will need to be replaced. The data collection 363 consists of a network discovery to gain an understanding of the 364 topology and inventory network infrastructure equipment and code 365 versions with information gathered from static files and IP address 366 management, DNS and DHCP tools. 368 Since IPv6 might already be present in the environment, through 369 default configurations or VPNs, an infrastructure assessment (at 370 minimum) is essential to evaluate potential security risks. 372 2.2.2. Applications readiness assessment 374 Just like network equipment, application software needs to support 375 IPv6. This includes OS, firmware, middleware and applications 376 (including internally developed applications). Vendors will 377 typically handle IPv6 enablement of off-the-shelf products, but often 378 enterprises need to request this support from vendors. For 379 internally developed applications it is the responsibility of the 380 enterprise to enable them for IPv6. Analyzing how a given 381 application communicates over the network will dictate the steps 382 required to support IPv6. Applications should be made to use APIs 383 which hide the specifics of a given IP address family. Any 384 applications that use APIs, such as the C language, which exposes the 385 IP version specificity, need to be modified to also work with IPv6. 387 There are two ways to IPv6-enable applications. The first approach 388 is to have separate logic for IPv4 and IPv6, thus leaving the IPv4 389 code path mainly untouched. This approach causes the least 390 disruption to the existing IPv4 logic flow, but introduces more 391 complexity, since the application now has to deal with two logic 392 loops with complex race conditions and error recovery mechanisms 393 between these two logic loops. The second approach is to create a 394 combined IPv4/IPv6 logic, which ensures operation regardless of the 395 IP version used on the network. Knowing whether a given 396 implementation will use IPv4 or IPv6 in a given deployment is a 397 matter of some art; see Source Address Selection [RFC6724] and Happy 398 Eyeballs [RFC6555]. It is generally recommend that the application 399 developer use industry IPv6-porting tools to locate the code that 400 needs to be updated. Some discussion of IPv6 application porting 401 issues can be found in [RFC4038]. 403 2.2.3. Importance of readiness validation and testing 405 Lastly IPv6 introduces a completely new way of addressing endpoints, 406 which can have ramifications at the network layer all the way up to 407 the applications. So to minimize disruption during the transition 408 phase we recommend complete functionality, scalability and security 409 testing to understand how IPv6 impacts the services and networking 410 infrastructure. 412 2.3. Training 414 IPv6 planning and deployment in the enterprise does not only affect 415 the network. IPv6 adoption will be a multifaceted undertaking that 416 will touch everyone in the organization unlike almost any other 417 project. While technology and process transformations are taking 418 place, it is critical that personnel training takes place as well. 419 Training will ensure that people and skill gaps are assessed 420 proactively and managed accordingly. We recommend that training 421 needs be analyzed and defined in order to successfully inform, train, 422 and prepare staff for the impacts of the system or process changes. 423 Better knowledge of the requirements to deploy IPv6 may also help 424 inform procurement processes. 426 2.4. Security Policy 427 It is obvious that IPv6 networks should be deployed in a secure way. 428 The industry has learnt a lot about network security with IPv4, so, 429 network operators should leverage this knowledge and expertise when 430 deploying IPv6. IPv6 is not so different than IPv4: it is a 431 connectionless network protocol using the same lower layer service 432 and delivering the same service to the upper layer. Therefore, the 433 security issues and mitigation techniques are mostly identical with 434 same exceptions that are described further. 436 2.4.1. IPv6 is no more secure than IPv4 438 Some people believe that IPv6 is inherently more secure than IPv4 439 because it is new. Nothing can be more wrong. Indeed, being a new 440 protocol means that bugs in the implementations have yet to be 441 discovered and fixed and that few people have the operational 442 security expertise needed to operate securely an IPv6 network. This 443 lack of operational expertise is the biggest threat when deploying 444 IPv6: the importance of training is to be stressed again. 446 One security myth is that thanks to its huge address space, a network 447 cannot be scanned by enumerating all IPv6 address in a /64 LAN hence 448 a malevolent person cannot find a victim. [RFC5157] describes some 449 alternate techniques to find potential targets on a network, for 450 example enumerating all DNS names in a zone. Additional advice in 451 this area is also given in [I-D.ietf-opsec-ipv6-host-scanning]. 453 Another security myth is that IPv6 is more secure because it mandates 454 the use of IPsec everywhere. While the original IPv6 specifications 455 may have implied this, [RFC6434] clearly states that IPsec support is 456 not mandatory. Moreover, if all the intra-enterprise traffic is 457 encrypted, then this renders a lot of the network security tools 458 (IPS, firewall, ACL, IPFIX, etc) blind and pretty much useless. 459 Therefore, IPsec should be used in IPv6 pretty much like in IPv4 (for 460 example to establish a VPN overlay over a non-trusted network or 461 reserved for some specific applications). 463 The last security myth is that amplification attacks (such as 464 [SMURF]) do not exist in IPv6 because there is no more broadcast. 465 Alas, this is not true as ICMP error (in some cases) or information 466 messages can be generated by routers and hosts when forwarding or 467 receiving a multicast message (see Section 2.4 of [RFC4443]). 468 Therefore, the generation and the forwarding rate of ICMPv6 messages 469 must be limited as in IPv4. 471 It should be noted that in a dual-stack network the security 472 implementation for both IPv4 and IPv6 needs to be considered, in 473 addition to security considerations related to the interaction of 474 (and transition between) the two, while they coexist. 476 2.4.2. Similarities between IPv6 and IPv4 security 478 As mentioned earlier, IPv6 is quite similar to IPv4, therefore 479 several attacks apply for both protocol families: 481 o Application layer attacks: such as cross-site scripting or SQL 482 injection 484 o Rogue device: such as a rogue Wi-Fi Access Point 486 o Flooding and all traffic-based denial of services (including the 487 use of control plane policing for IPv6 traffic see [RFC6192]) 489 o Etc. 491 A specific case of congruence is IPv6 Unique Local Addresses (ULAs) 492 [RFC4193] and IPv4 private addressing [RFC1918], which do not provide 493 any security by 'magic'. In both cases, the edge router must apply 494 strict filters to block those private addresses from entering and, 495 just as importantly, leaving the network. This filtering can be done 496 by the enterprise or by the ISP, but the cautious administrator will 497 prefer to do it in the enterprise. 499 IPv6 addresses can be spoofed as easily as IPv4 addresses and there 500 are packets with bogon IPv6 addresses (see [CYMRU]). Anti-bogon 501 filtering must be done in the data and routing planes. It can be 502 done by the enterprise or by the ISP, or both, but again the cautious 503 administrator will prefer to do it in the enterprise. 505 2.4.3. Specific Security Issues for IPv6 507 Even if IPv6 is similar to IPv4, there are some differences that 508 create some IPv6-only vulnerabilities or issues. We give examples of 509 such differences in this section. 511 Privacy extension addresses [RFC4941] are usually used to protect 512 individual privacy by periodically changing the interface identifier 513 part of the IPv6 address to avoid tracking a host by its otherwise 514 always identical and unique MAC-based EUI-64. While this presents a 515 real advantage on the Internet, moderated by the fact that the prefix 516 part remains the same, it complicates the task of following an audit 517 trail when a security officer or network operator wants to trace back 518 a log entry to a host in their network, because when the tracing is 519 done the searched IPv6 address could have disappeared from the 520 network. Therefore, the use of privacy extension addresses usually 521 requires additional monitoring and logging of the binding of the IPv6 522 address to a data-link layer address (see also the monitoring section 523 of [I-D.ietf-opsec-v6]). Some early enterprise deployments have 524 taken the approach to use tools that harvest IP/MAC address mappings 525 from switch and router devices to provide address accountability; 526 this approach has been shown to work, though it can involve gathering 527 significantly more address data than in equivalent IPv4 networks. An 528 alternative is to try to prevent the use of privacy extension 529 addresses by enforcing the use of DHCPv6, such that hosts only get 530 addresses assigned by a DHCPv6 server. This can be done by 531 configuring routers to set the M-bit in Router Advertisements, 532 combined with all advertised prefixes being included without the 533 A-bit set (to prevent the use of stateless auto-configuration). This 534 technique of course requires that all hosts support stateful DHCPv6. 535 It is important to note that not all operating systems exhibit the 536 same behavior when processing RAs with the M-Bit set. The varying OS 537 behavior is related to the lack of prescriptive definition around the 538 A, M and O-bits within the ND protocol. 539 [I-D.liu-bonica-dhcpv6-slaac-problem] provides a much more detailed 540 analysis on the interaction of the M-Bit and DHCPv6. 542 Extension headers complicate the task of stateless packet filters 543 such as ACLs. If ACLs are used to enforce a security policy, then 544 the enterprise must verify whether its ACL (but also stateful 545 firewalls) are able to process extension headers (this means 546 understand them enough to parse them to find the upper layers 547 payloads) and to block unwanted extension headers (e.g., to implement 548 [RFC5095]). This topic is discussed further in 549 [I-D.ietf-6man-ext-transmit]. 551 Fragmentation is different in IPv6 because it is done only by source 552 host and never during a forwarding operation. This means that ICMPv6 553 packet-too-big messages must be allowed to pass through the network 554 and not be filtered [RFC4890]. Fragments can also be used to evade 555 some security mechanisms such as RA-guard [RFC6105]. See also 556 [RFC5722], and [I-D.ietf-v6ops-ra-guard-implementation]. 558 One of the biggest differences between IPv4 and IPv6 is the 559 introduction of the Neighbor Discovery Protocol [RFC4861], which 560 includes a variety of important IPv6 protocol functions, including 561 those provided in IPv4 by ARP [RFC0826]. NDP runs over ICMPv6 (which 562 as stated above means that security policies must allow some ICMPv6 563 messages to pass, as described in RFC 4890), but has the same lack of 564 security as, for example, ARP, in that there is no inherent message 565 authentication. While Secure Neighbour Discovery (SeND) [RFC3971] 566 and CGA [RFC3972] have been defined, they are not widely 567 implemented). The threat model for Router Advertisements within the 568 NDP suite is similar to that of DHCPv4 (and DHCPv6), in that a rogue 569 host could be either a rogue router or a rogue DHCP server. An IPv4 570 network can be made more secure with the help of DHCPv4 snooping in 571 edge switches, and likewise RA snooping can improve IPv6 network 572 security (in IPv4-only networks as well). Thus enterprises using 573 such techniques for IPv4 should use the equivalent techniques for 574 IPv6, including RA-guard (RFC 6105) and all work in progress from the 575 SAVI WG, e.g. [RFC6959], which is similar to the protection given by 576 dynamic ARP monitoring in IPv4. Other DoS vulnerabilities are 577 related to NDP cache exhaustion, and mitigation techniques can be 578 found in ([RFC6583]). 580 As stated previously, running a dual-stack network doubles the attack 581 exposure as a malevolent person has now two attack vectors: IPv4 and 582 IPv6. This simply means that all routers and hosts operating in a 583 dual-stack environment with both protocol families enabled (even if 584 by default) must have a congruent security policy for both protocol 585 versions. For example, permit TCP ports 80 and 443 to all web 586 servers and deny all other ports to the same servers must be 587 implemented both for IPv4 and IPv6. It is thus important that the 588 tools available to administrators readily support such behaviour. 590 2.5. Routing 592 An important design choice to be made is what IGP to use inside the 593 network. A variety of IGPs (IS-IS, OSPFv3 and RIPng) support IPv6 594 today and picking one over the other is a design choice that will be 595 dictated mostly by existing operational policies in an enterprise 596 network. As mentioned earlier, it would be beneficial to maintain 597 operational parity between IPv4 and IPv6 and therefore it might make 598 sense to continue using the same protocol family that is being used 599 for IPv4. For example, in a network using OSPFv2 for IPv4, it might 600 make sense to use OSPFv3 for IPv6. It is important to note that 601 although OSPFv3 is similar to OSPFv2, they are not the same. On the 602 other hand, some organizations may chose to run different routing 603 protocols for different IP versions. For example, one may chose to 604 run OSPFv2 for IPv4 and IS-IS for IPv6. An important design question 605 to consider here is whether to support one IGP or two different IGPs 606 in the longer term. [I-D.ietf-v6ops-design-choices] presents advice 607 on the design choices that arise when considering IGPs and discusses 608 the advantages and disadvantages to different approaches in detail. 610 2.6. Address Plan 612 The most common problem encountered in IPv6 networking is in applying 613 the same principles of conservation that are so important in IPv4. 614 IPv6 addresses do not need to be assigned conservatively. In fact, a 615 single larger allocation is considered more conservative than 616 multiple non-contiguous small blocks, because a single block occupies 617 only a single entry in a routing table. The advice in [RFC5375] is 618 still sound, and is recommended to the reader. If considering ULAs, 619 give careful thought to how well it is supported, especially in 620 multiple address and multicast scenarios, and assess the strength of 621 the requirement for ULA. [I-D.ietf-v6ops-ula-usage-recommendations] 622 provides much more detailed analysis and recommendations on the usage 623 of ULAs. 625 The enterprise administrator will want to evaluate whether the 626 enterprise will request address space from a LIR (Local Internet 627 Registry, such as an ISP), a RIR (Regional Internet Registry, such as 628 AfriNIC, APNIC, ARIN, LACNIC, or RIPE-NCC) or a NIR (National 629 Internet Registry, operated in some countries). The normal 630 allocation is Provider Aggregatable (PA) address space from the 631 enterprise's ISP, but use of PA space implies renumbering when 632 changing provider. Instead, an enterprise may request Provider 633 Independent (PI) space; this may involve an additional fee, but the 634 enterprise may then be better able to be multihomed using that 635 prefix, and will avoid a renumbering process when changing ISPs 636 (though it should be noted that renumbering caused by outgrowing the 637 space, merger, or other internal reason would still not be avoided 638 with PI space). 640 The type of address selected (PI vs. PA) should be congruent with the 641 routing needs of the enterprise. The selection of address type will 642 determine if an operator will need to apply new routing techniques 643 and may limit future flexibility. There is no right answer, but the 644 needs of the external phase may affect what address type is selected. 646 Each network location or site will need a prefix assignment. 647 Depending on the type of site/location, various prefix sizes may be 648 used. In general, historical guidance suggests that each site should 649 get at least a /48, as documented in RFC 5375 and [RFC6177]. In 650 addition to allowing for simple planning, this can allow a site to 651 use its prefix for local connectivity, should the need arise, and if 652 the local ISP supports it. 654 When assigning addresses to end systems, the enterprise may use 655 manually-configured addresses (common on servers) or SLAAC or DHCPv6 656 for client systems. Early IPv6 enterprise deployments have used 657 SLAAC, both for its simplicity but also due to the time DHCPv6 has 658 taken to mature. However, DHCPv6 is now very mature, and thus 659 workstations managed by an enterprise may use stateful DHCPv6 for 660 addressing on corporate LAN segments. DHCPv6 allows for the 661 additional configuration options often employed by enterprise 662 administrators, and by using stateful DHCPv6, administrators 663 correlating system logs know which system had which address at any 664 given time. Such an accountability model is familiar from IPv4 665 management, though for DHCPv6 hosts are identified by DUID rather 666 than MAC address. For equivalent accountability with SLAAC (and 667 potentially privacy addresses), a monitoring system that harvests IP/ 668 MAC mappings from switch and router equipment could be used. 670 A common deployment consideration for any enterprise network is how 671 to get host DNS records updated. In a traditional IPv4 network, the 672 two commonly used methods are to either have the host send DNS 673 updates itself or have the DHCPv4 server update DNS records. The 674 former implies that there is sufficient trust between the hosts and 675 the DNS server while the latter implies a slightly more controlled 676 environment where only DHCP servers are trusted to make these 677 updates. If the enterprise uses the first model, then SLAAC is a 678 perfectly valid option to assign addresses to end systems. However, 679 an enterprise network with a more controlled environment will need to 680 disable SLAAC and force end hosts to use DHCPv6 only. 682 In the data center or server room, assume a /64 per VLAN. This 683 applies even if each individual system is on a separate VLAN. In a / 684 48 assignment, typical for a site, there are then still 65,535 /64 685 blocks. Addresses are either configured manually on the server, or 686 reserved on a DHCPv6 server, which may also synchronize forward and 687 reverse DNS. Because of the need to synchronize RA timers and DNS 688 TTLs, SLAAC is rarely, if ever, used for servers, and would require 689 tightly coupled dynamic DNS updates. [RFC6866] 691 All user access networks should be a /64. Point-to-point links where 692 Neighbor Discovery Protocol is not used may also utilize a /127 (see 693 [RFC6164]). 695 Plan to aggregate at every layer of network hierarchy. There is no 696 need for VLSM [RFC1817] in IPv6, and addressing plans based on 697 conservation of addresses are short-sighted. Use of prefixes longer 698 then /64 on network segments will break common IPv6 functions such as 699 SLAAC[RFC4862]. Where multiple VLANs or other layer two domains 700 converge, allow some room for expansion. Renumbering due to 701 outgrowing the network plan is a nuisance, so allow room within it. 703 Generally, plan to grow to about twice the current size that can be 704 accommodated; where rapid growth is planned, allow for twice that 705 growth. Also, if DNS (or reverse DNS) authority may be delegated to 706 others in the enterprise, assignments need to be on nibble boundaries 707 (that is, on a multiple of 4 bits, such as /64, /60, /56, ..., /48, / 708 44), to ensure that delegated zones align with assigned prefixes. 710 When using ULAs, it is important to note that AAAA and PTR records 711 for ULA are not recommended to be installed in the global DNS. 712 Similarly, reverse (address-to-name) queries for ULA must not be sent 713 to name servers outside of the organization, due to the load that 714 such queries would create for the authoritative name servers for the 715 ip6.arpa zone. For more details please refer to section 4.4 of 716 [RFC4193]. 718 Enterprise networks more and more include virtual networks where a 719 single physical node may host many virtualized addressable devices. 720 It is imperative that the addressing plans assigned to these virtual 721 networks and devices be consistent and non-overlapping with the 722 addresses assigned to real networks and nodes. For example, a 723 virtual network established within an isolated lab environment may at 724 a later time become attached to the production enterprise network. 726 2.7. Tools Assessment 728 Enterprises will often have a number of operational tools and support 729 systems which are used to provision, monitor, manage and diagnose the 730 network and systems within their environment. These tools and 731 systems will need to be assessed for compatibility with IPv6. The 732 compatibility may be related to the addressing and connectivity of 733 various devices as well as IPv6 awareness of the tools and processing 734 logic. 736 The tools within the organization fall into two general categories, 737 those which focus on managing the network, and those which are 738 focused on managing systems and applications on the network. In 739 either instance, the tools will run on platforms which may or may not 740 be capable of operating in an IPv6 network. This lack in 741 functionality may be related to Operating System version, or based on 742 some hardware constraint. Those systems which are found to be 743 incapable of utilizing an IPv6 connection, or which are dependent on 744 an IPv4 stack, may need to be replaced or upgraded. 746 In addition to devices working on an IPv6 network natively, or via a 747 transition tunnel, many tools and support systems may require 748 additional software updates to be IPv6 aware, or even a hardware 749 upgrade (usually for additional memory: IPv6 addresses are larger and 750 for a while, IPv4 and IPv6 addresses will coexist in the tool). This 751 awareness may include the ability to manage IPv6 elements and/or 752 applications in addition to the ability to store and utilize IPv6 753 addresses. 755 Considerations when assessing the tools and support systems may 756 include the fact that IPv6 addresses are significantly larger than 757 IPv4, requiring data stores to support the increased size. Such 758 issues are among those discussed in [RFC5952]. Many organizations 759 may also run dual-stack networks, therefore the tools need to not 760 only support IPv6 operation, but may also need to support the 761 monitoring, management and intersection with both IPv6 and IPv4 762 simultaneously. It is important to note that managing IPv6 is not 763 just constrained to using large IPv6 addresses, but also that IPv6 764 interfaces and nodes are likely to use two or more addresses as part 765 of normal operation. Updating management systems to deal with these 766 additional nuances will likely consume time and considerable effort. 768 For networking systems, like node management systems, it is not 769 always necessary to support local IPv6 addressing and connectivity. 770 Operations such as SNMP MIB polling can occur over IPv4 transport 771 while seeking responses related to IPv6 information. Where this may 772 seem advantageous to some, it should be noted that without local IPv6 773 connectivity, the management system may not be able to perform all 774 expected functions - such as reachability and service checks. 776 Organizations should be aware that changes to older IPv4-only SNMP 777 MIB specifications have been made by the IETF related to legacy 778 operation in [RFC2096] and [RFC2011]. Updated specifications are now 779 available in [RFC4296] and [RFC4293] which modified the older MIB 780 framework to be IP protocol agnostic, supporting both IPv4 and IPv6. 781 Polling systems will need to be upgraded to support these updates as 782 well as the end stations which are polled. 784 3. External Phase 786 The external phase for enterprise IPv6 adoption covers topics which 787 deal with how an organization connects its infrastructure to the 788 external world. These external connections may be toward the 789 Internet at large, or to other networks. The external phase covers 790 connectivity, security and monitoring of various elements and outward 791 facing or accessible services. 793 How an organization connects to the outside worlds is very important 794 as it is often a critical part of how a business functions, therefore 795 it must be dealt accordingly. 797 3.1. Connectivity 798 The enterprise will need to work with one or more Service Providers 799 to gain connectivity to the Internet or transport service 800 infrastructure such as a BGP/MPLS IP VPN as described in [RFC4364] 801 and [RFC4659]. One significant factor that will guide how an 802 organization may need to communicate with the outside world will 803 involve the use of PI (Provider Independent) and/or PA (Provider 804 Aggregatable) IPv6 space. 806 Enterprises should be aware that depending on which address type they 807 selected (PI vs. PA) in their planning section, they may need to 808 implement new routing functions and/or behaviours to support their 809 connectivity to the ISP. In the case of PI, the upstream ISP may 810 offer options to route the prefix (typically a /48) on the 811 enterprise's behalf and update the relevant routing databases. In 812 other cases, the enterprise may need to perform this task on their 813 own and use BGP to inject the prefix into the global BGP system. The 814 latter case however is not deployed by many enterprises today, which 815 is an important consideration. 817 Note that the rules set by the RIRs for an enterprise acquiring PI 818 address space have changed over time. For example, in the European 819 region the RIPE-NCC no longer requires an enterprise to be multihomed 820 to be eligible for an IPv6 PI allocation. Requests can be made 821 directly or via a LIR. It is possible that the rules may change 822 again, and may vary between RIRs. 824 When seeking IPv6 connectivity to a Service Provider, the Enterprise 825 will prefer to use native IPv6 connectivity. Native IPv6 826 connectivity is preferred since it provides the most robust and 827 efficient form of connectivity. If native IPv6 connectivity is not 828 possible due to technical or business limitations, the enterprise may 829 utilize readily available transition tunnel IPv6 connectivity. There 830 are IPv6 transit providers which provide robust tunnelled IPv6 831 connectivity which can operate over IPv4 networks. It is important 832 to understand the transition tunnel mechanism used, and to consider 833 that it will have higher latency than native IPv4 or IPv6, and may 834 have other problems, e.g. related to MTUs. 836 It is important to evaluate MTU considerations when adding in IPv6 to 837 an existing IPv4 network. It is generally desirable to have the IPv6 838 and IPv4 MTU congruent to simplify operations. If the enterprise 839 uses transition tunnels inside or externally for IPv6 connectivity, 840 then modification of the MTU on hosts/routers may be needed as mid- 841 stream fragmentation is no longer supported in IPv6. It is preferred 842 that pMTUD is used to optimize the MTU, so erroneous filtering of the 843 related ICMPv6 message types should be monitored. Adjusting the MTU 844 may be the only option if undesirable upstream ICMPv6 filtering 845 cannot be removed. 847 3.2. Security 849 The most important part of security for external IPv6 deployment is 850 filtering and monitoring. Filtering can be done by stateless ACLs or 851 a stateful firewall. The security policies must be consistent for 852 IPv4 and IPv6 (else the attacker will use the less protected protocol 853 stack), except that certain ICMPv6 messages must be allowed through 854 and to the filtering device (see [RFC4890]): 856 o Unreachable packet-too-big: it is very important to allow Path MTU 857 discovery to work 859 o Unreachable parameter-problem 861 o Neighbor solicitation 863 o Neighbor advertisement 865 It could also be safer to block all fragments where the transport 866 layer header is not in the first fragment to avoid attacks as 867 described in [RFC5722]. Some filtering devices allow this filtering. 868 To be fully compliant with [RFC5095], all packets containing the 869 routing extension header type 0 must be dropped. 871 If an Intrusion Prevention System (IPS) is used for IPv4 traffic, 872 then an IPS should also be used for IPv6 traffic. In general, make 873 sure IPv6 security is at least as good as IPv4. This also includes 874 all email content protection (anti-spam, content filtering, data 875 leakage prevention, etc.). 877 The edge router must also implement anti-spoofing techniques based on 878 [RFC2827] (also known as BCP 38). 880 In order to protect the networking devices, it is advised to 881 implement control plane policing as per [RFC6192]. 883 The potential NDP cache exhaustion attack (see [RFC6583]) can be 884 mitigated by two techniques: 886 o Good NDP implementation with memory utilization limits as well as 887 rate-limiters and prioritization of requests. 889 o Or, as the external deployment usually involves just a couple of 890 exposed statically configured IPv6 addresses (virtual addresses of 891 web, email, and DNS servers), then it is straightforward to build 892 an ingress ACL allowing traffic for those addresses and denying 893 traffic to any other addresses. This actually prevents the attack 894 as a packet for a random destination will be dropped and will 895 never trigger a neighbor resolution. 897 3.3. Monitoring 899 Monitoring the use of the Internet connectivity should be done for 900 IPv6 as it is done for IPv4. This includes the use of IP Flow 901 Information eXport (IPFIX) [RFC5102] to report abnormal traffic 902 patterns (such as port scanning, SYN-flooding, related IP source 903 addresses) from monitoring tools and evaluating data read from SNMP 904 MIBs [RFC4293] (some of which also enable the detection of abnormal 905 bandwidth utilization). Where Netflow is used, version 9 is required 906 for IPv6 support. 908 3.4. Servers and Applications 910 The path to the servers accessed from the Internet usually involves 911 security devices (firewall, IPS), server load balancing (SLB) and 912 real physical servers. The latter stage is also multi-tiered for 913 scalability and security between presentation and data storage. The 914 ideal transition is to enable dual-stack on all devices but this may 915 seem too time-consuming and too risky. 917 Operators have used the following approaches with success: 919 o Use a network device to apply NAT64 and basically translate an 920 inbound TCP connection (or any other transport protocol) over IPv6 921 into a TCP connection over IPv4. This is the easiest to deploy as 922 the path is mostly unchanged but it hides all IPv6 remote users 923 behind a single IPv4 address which leads to several audit trail 924 and security issues (see [RFC6302]). 926 o Use the server load balancer which acts as an application proxy to 927 do this translation. Compared to the NAT64, it has the potential 928 benefit of going through the security devices as native IPv6 (so 929 more audit and trace abilities) and is also able to insert a HTTP 930 X-Forward-For header which contains the remote IPv6 address. The 931 latter feature allows for logging, and rate-limiting on the real 932 servers based on the IPV6 address even if those servers run only 933 IPv4. 935 3.5. Network Prefix Translation for IPv6 936 Network Prefix Translation for IPv6, or NPTv6 as described in 937 [RFC6296] provides a framework to utilize prefix ranges within the 938 internal network which are separate (address-independent) from the 939 assigned prefix from the upstream provider or registry. As mentioned 940 above, while NPTv6 has potential use-cases in IPv6 networks, the 941 implications of its deployment need to be fully understood, 942 particularly where any applications might embed IPv6 addresses in 943 their payloads. 945 Use of NTPv6 can be chosen independently from how addresses are 946 assigned and routed within the internal network and how prefixes are 947 routed towards the Internet (included both PA and PI address 948 assignment options). 950 4. Internal Phase 952 This phase deals with the delivery of IPv6 to the internal user- 953 facing side of the IT infrastructure, which comprises various 954 components such as network devices (routers, switches, etc.), end 955 user devices and peripherals (workstations, printers, etc.), and 956 internal corporate systems. 958 An important design paradigm to consider during this phase is "dual- 959 stack when you can, tunnel when you must". Dual-stacking allows a 960 more robust, production-quality IPv6 network than is typically 961 facilitated by internal use of transition tunnels that are harder to 962 troubleshoot and support, and that may introduce scalability and 963 performance issues. Tunnels may of course still be used in 964 production networks, but their use needs to be carefully considered, 965 e.g. where the transition tunnel may be run through a security or 966 filtering device. Tunnels do also provide a means to experiment with 967 IPv6 and gain some operational experience with the protocol. 968 [RFC4213] describes various transition mechanisms in more detail. 969 [RFC6964] suggests operational guidance when using ISATAP tunnels 970 [RFC5214], though we would recommend use of dual-stack wherever 971 possible. 973 4.1. Security 975 IPv6 must be deployed in a secure way. This means that all existing 976 IPv4 security policies must be extended to support IPv6; IPv6 977 security policies will be the IPv6 equivalent of the existing IPv4 978 ones (taking into account the difference for ICMPv6 [RFC4890]). As 979 in IPv4, security policies for IPv6 will be enforced by firewalls, 980 ACL, IPS, VPN, and so on. 982 Privacy extension addresses [RFC4941] raise a challenge for an audit 983 trail as explained in section Section 2.4.3. The enterprise may 984 choose to attempt to enforce use of DHCPv6, or deploy monitoring 985 tools that harvest accountability data from switches and routers 986 (thus making the assumption that devices may use any addresses inside 987 the network). 989 But the major issue is probably linked to all threats against 990 Neighbor Discovery. This means, for example, that the internal 991 network at the access layer (where hosts connect to the network over 992 wired or wireless) should implement RA-guard [RFC6105] and the 993 techniques being specified by SAVI WG [RFC6959]; see also 994 Section 2.4.3 for more information. 996 4.2. Network Infrastructure 998 The typical enterprise network infrastructure comprises a combination 999 of the following network elements - wired access switches, wireless 1000 access points, and routers (although it is fairly common to find 1001 hardware that collapses switching and routing functionality into a 1002 single device). Basic wired access switches and access points 1003 operate only at the physical and link layers, and don't really have 1004 any special IPv6 considerations other than being able to support IPv6 1005 addresses themselves for management purposes. In many instances, 1006 these devices possess a lot more intelligence than simply switching 1007 packets. For example, some of these devices help assist with link 1008 layer security by incorporating features such as ARP inspection and 1009 DHCP Snooping, or they may help limit where multicast floods by using 1010 IGMP (or, in the case of IPv6, MLD) snooping. 1012 Another important consideration in enterprise networks is first hop 1013 router redundancy. This directly ties into network reachability from 1014 an end host's point of view. IPv6 Neighbor Discovery (ND), 1015 [RFC4861], provides a node with the capability to maintain a list of 1016 available routers on the link, in order to be able to switch to a 1017 backup path should the primary be unreachable. By default, ND will 1018 detect a router failure in 38 seconds and cycle onto the next default 1019 router listed in its cache. While this feature provides a basic 1020 level of first hop router redundancy, most enterprise IPv4 networks 1021 are designed to fail over much faster. Although this delay can be 1022 improved by adjusting the default timers, care must be taken to 1023 protect against transient failures and to account for increased 1024 traffic on the link. Another option to provide robust first hop 1025 redundancy is to use the Virtual Router Redundancy Protocol for IPv6 1026 (VRRPv3), [RFC5798]. This protocol provides a much faster switchover 1027 to an alternate default router than default ND parameters. Using 1028 VRRPv3, a backup router can take over for a failed default router in 1029 around three seconds (using VRRPv3 default parameters). This is done 1030 without any interaction with the hosts and a minimum amount of VRRP 1031 traffic. 1033 Last but not the least, one of the most important design choices to 1034 make while deploying IPv6 on the internal network is whether to use 1035 Stateless Automatic Address Configuration (SLAAC), [RFC4862], or 1036 Dynamic Host Configuration Protocol for IPv6 (DHCPv6), [RFC3315], or 1037 a combination thereof. Each option has advantages and disadvantages, 1038 and the choice will ultimately depend on the operational policies 1039 that guide each enterprise's network design. For example, if an 1040 enterprise is looking for ease of use, rapid deployment, and less 1041 administrative overhead, then SLAAC makes more sense for 1042 workstations. Manual or DHCPv6 assignments are still needed for 1043 servers, as described in the External Phase and Address Plan sections 1044 of this document. However, if the operational policies call for 1045 precise control over IP address assignment for auditing then DHCPv6 1046 may be preferred. DHCPv6 also allows you to tie into DNS systems for 1047 host entry updates and gives you the ability to send other options 1048 and information to clients. It is worth noting that in general 1049 operation RAs are still needed in DHCPv6 networks, as there is no 1050 DHCPv6 Default Gateway option. Similarly, DHCPv6 is needed in RA 1051 networks for other configuration information, e.g. NTP servers or, in 1052 the absence of support for DNS resolvers in RAs [RFC6106], DNS 1053 resolver information. 1055 4.3. End user devices 1057 Most operating systems (OSes) that are loaded on workstations and 1058 laptops in a typical enterprise support IPv6 today. However, there 1059 are various out-of-the-box nuances that one should be mindful about. 1060 For example, the default behavior of OSes vary; some may have IPv6 1061 turned off by default, some may only have certain features such as 1062 privacy extensions to IPv6 addresses (RFC 4941) turned off while 1063 others have IPv6 fully enabled. Further, even when IPv6 is enabled, 1064 the choice of which address is used may be subject to Source Address 1065 Selection (RFC 6724) and Happy Eyeballs (RFC 6555). Therefore, it is 1066 advised that enterprises investigate the default behavior of their 1067 installed OS base and account for it during the Inventory phases of 1068 their IPv6 preparations. Furthermore, some OSes may have some 1069 transition tunneling mechanisms turned on by default and in such 1070 cases it is recommended to administratively shut down such interfaces 1071 unless required. 1073 It is important to note that it is recommended that IPv6 be deployed 1074 at the network and system infrastructure level before it is rolled 1075 out to end user devices; ensure IPv6 is running and routed on the 1076 wire, and secure and correctly monitored, before exposing IPv6 to end 1077 users. 1079 Smartphones and tablets are poised to become one of the major 1080 consumers of IP addresses and enterprises, and should be ready to 1081 support IPv6 on various networks that serve such devices. In 1082 general, support for IPv6 in these devices, albeit in its infancy, 1083 has been steadily rising. Most of the leading smartphone OSes have 1084 some level of support for IPv6. However, the level of configurable 1085 options are mostly at a minimum and are not consistent across all 1086 platforms. Also, it is fairly common to find IPv6 support on the Wi- 1087 Fi connection alone and not on the radio interface in these devices. 1088 This is sometimes due to the radio network not being IPv6 ready, or 1089 it may be device-related. An IPv6-enabled enterprise Wi-Fi network 1090 will allow the majority of these devices to connect via IPv6. Much 1091 work is still being done to bring the full IPv6 feature set across 1092 all interfaces (802.11, 3G, LTE, etc.) and platforms. For example, 1093 mobility management functions will be needed to accommodate handovers 1094 between diverse access technologies. 1096 IPv6 support in peripheral equipment such as printers, IP cameras, 1097 etc., has been steadily rising as well, although at a much slower 1098 pace than traditional OSes and smartphones. Most newer devices are 1099 coming out with IPv6 support but there is still a large installed 1100 base of legacy peripheral devices that might need IPv4 for some time 1101 to come. The audit phase mentioned earlier will make it easier for 1102 enterprises to plan for equipment upgrades, in line with their 1103 corporate equipment refresh cycle. 1105 4.4. Corporate Systems 1107 No IPv6 deployment will be successful without ensuring that all the 1108 corporate systems that an enterprise uses as part of its IT 1109 infrastructure support IPv6. Examples of such systems include, but 1110 are not limited to, email, video conferencing, telephony (VoIP), DNS, 1111 RADIUS, etc. All these systems must have their own detailed IPv6 1112 rollout plan in conjunction with the network IPv6 rollout. It is 1113 important to note that DNS is one of the main anchors in an 1114 enterprise deployment, since most end hosts decide whether or not to 1115 use IPv6 depending on the presence of IPv6 AAAA records in a reply to 1116 a DNS query. It is recommended that system administrators 1117 selectively turn on AAAA records for various systems as and when they 1118 are IPv6 enabled; care must be taken though to ensure all services 1119 running on that host name are IPv6-enabled before adding the AAAA 1120 record. Additionally, all monitoring and reporting tools across the 1121 enterprise would need to be modified to support IPv6. 1123 5. IPv6-only 1125 Early IPv6 enterprise deployments have generally taken a dual-stack 1126 approach to enabling IPv6, i.e. the existing IPv4 services have not 1127 been turned off. Although IPv4 and IPv6 networks will coexist for a 1128 long time, the long term enterprise network roadmap should include 1129 steps on gradually deprecating IPv4 from the dual-stack network. In 1130 some extreme cases, deploying dual-stack networks may not even be a 1131 viable option for very large enterprises due to the RFC 1918 address 1132 space not being large enough to support the network's growth. In 1133 such cases, deploying IPv6-only networks might be the only choice 1134 available to sustain network growth. In other cases, there may be 1135 elements of an otherwise dual-stack network that may be run 1136 IPv6-only. 1138 If nodes in the network don't need to talk to an IPv4-only node, then 1139 deploying IPv6-only networks should be fairly trivial. However, in 1140 the current environment, given that IPv4 is the dominant protocol on 1141 the Internet, an IPv6-only node most likely needs to talk to an 1142 IPv4-only node on the Internet. It is therefore important to provide 1143 such nodes with a translation mechanism to ensure communication 1144 between nodes configured with different address families. As 1145 [RFC6144] points out, it is important to look at address translation 1146 as a transition strategy towards running an IPv6-only network. 1148 There are various stateless and stateful IPv4/IPv6 translation 1149 methods available today that help IPv6 to IPv4 communication. RFC 1150 6144 provides a framework for IPv4/IPv6 translation and describes in 1151 detail various scenarios in which such translation mechanisms could 1152 be used. [RFC6145] describes stateless address translation. In this 1153 mode, a specific IPv6 address range will represent IPv4 systems 1154 (IPv4-converted addresses), and the IPv6 systems have addresses 1155 (IPv4-translatable addresses) that can be algorithmically mapped to a 1156 subset of the service provider's IPv4 addresses. [RFC6146], NAT64, 1157 describes stateful address translation. As the name suggests, the 1158 translation state is maintained between IPv4 address/port pairs and 1159 IPv6 address/port pairs, enabling IPv6 systems to open sessions with 1160 IPv4 systems. [RFC6147], DNS64, describes a mechanism for 1161 synthesizing AAAA resource records (RRs) from A RRs. Together, RFCs 1162 6146 and RFC 6147 provide a viable method for an IPv6-only client to 1163 initiate communications to an IPv4-only server. At the enterprise 1164 level, operating NAT64 and DNS64 services for heavy usage may have 1165 significant practical implications. 1167 The address translation mechanisms for the stateless and stateful 1168 translations are defined in [RFC6052]. It is important to note that 1169 both of these mechanisms have limitations as to which protocols they 1170 support. For example, RFC 6146 only defines how stateful NAT64 1171 translates unicast packets carrying TCP, UDP, and ICMP traffic only. 1172 The classic problems of IPv4 NAT also apply, e.g. handling IP 1173 literals in application payloads. The ultimate choice of which 1174 translation mechanism to chose will be dictated mostly by existing 1175 operational policies pertaining to application support, logging 1176 requirements, etc. 1178 There is additional work being done in the area of address 1179 translation to enhance and/or optimize current mechanisms. For 1180 example, [I-D.xli-behave-divi] describes limitations with the current 1181 stateless translation, such as IPv4 address sharing and application 1182 layer gateway (ALG) problems, and presents the concept and 1183 implementation of dual-stateless IPv4/IPv6 translation (dIVI) to 1184 address those issues. 1186 It is worth noting that for IPv6-only access networks that use 1187 technologies such as NAT64, the more content providers (and 1188 enterprises) that make their content available over IPv6, the less 1189 the requirement to apply NAT64 to traffic leaving the access network. 1190 This particular point is important for enterprises which may start 1191 their IPv6 deployment well into the global IPv6 transition. As time 1192 progresses, and given the current growth in availability of IPv6 1193 content, IPv6-only operation using NAT64 to manage some flows will 1194 become less expensive to run versus the traditional NAT44 deployments 1195 since only IPv6 to IPv4 flows need translation. [RFC6883] provides 1196 guidance and suggestions for Internet Content Providers and 1197 Application Service Providers in this context. 1199 Enterprises should also be aware that networks may be subject to 1200 future convergence with other networks (i.e. mergers, acquisitions, 1201 etc). An enterprise considering IPv6-only operation may need to be 1202 aware that additional transition technologies and/or connectivity 1203 strategies may be required depending on the level of IPv6 readiness 1204 and deployment in the merging networking. 1206 6. Considerations For Specific Enterprises 1208 6.1. Content Delivery Networks 1210 Some guidance for Internet Content and Application Service Providers 1211 can be found in [RFC6883], which includes a dedicated section on 1212 CDNs. An enterprise that relies on CDN to deliver a 'better' 1213 e-commerce experience needs to ensure that their CDN provider also 1214 supports IPv4/IPv6 traffic selection so that they can ensure 'best' 1215 access to the content. 1217 6.2. Data Center Virtualization 1219 IPv6 Data Center considerations are described in 1220 [I-D.ietf-v6ops-dc-ipv6]. 1222 6.3. University Campus Networks 1224 A number of campus networks around the world have made some initial 1225 IPv6 deployment. This has been encouraged by their National Research 1226 and Education Network (NREN) backbones having made IPv6 available 1227 natively since the early 2000's. Universities are a natural place for 1228 IPv6 deployment to be considered at an early stage, perhaps compared 1229 to other enterprises, as they are involved by their very nature in 1230 research and education. 1232 Campus networks can deploy IPv6 at their own pace; their is no need 1233 to deploy IPv6 across the entire enterprise from day one, rather 1234 specific projects can be identified for an initial deployment, that 1235 are both deep enough to give the university experience, but small 1236 enough to be a realistic first step. There are generally three areas 1237 in which such deployments are currently made. 1239 In particular those initial areas commonly approached are: 1241 o External-facing services. Typically the campus web presence and 1242 commonly also external-facing DNS and MX services. This ensures 1243 early IPv6-only adopters elsewhere can access the campus services 1244 as simply and as robustly as possible. 1246 o Computer science department. This is where IPv6-related research 1247 and/or teaching is most likely to occur, and where many of the 1248 next generation of network engineers are studying, so enabling 1249 some or all of the campus computer science department network is a 1250 sensible first step. 1252 o The eduroam wireless network. Eduroam [I-D.wierenga-ietf-eduroam] 1253 is the de facto wireless roaming system for academic networks, and 1254 uses 802.1X-based authentication, which is agnostic to the IP 1255 version used (unlike web-redirection gateway systems). Making a 1256 campus' eduroam network dual-stack is a very viable early step. 1258 The general IPv6 deployment model in a campus enterprise will still 1259 follow the general principles described in this document. While the 1260 above early stage projects are commonly followed, these still require 1261 the campus to acquire IPv6 connectivity and address space from their 1262 NREN (or other provider in some parts of the world), and to enable 1263 IPv6 on the wire on at least part of the core of the campus network. 1264 This implies a requirement to have an initial address plan, and to 1265 ensure appropriate monitoring and security measures are in place, as 1266 described elsewhere in this document. 1268 Campuses which have deployed to date do not use ULAs, nor do they use 1269 NPTv6. In general, campuses have very stable PA-based address 1270 allocations from their NRENs (or their equivalent). However, campus 1271 enterprises may consider applying for IPv6 PI; some have already done 1272 so. The discussions earlier in this text about PA vs. PI still 1273 apply. 1275 Finally, campuses may be more likely than many other enterprises to 1276 run multicast applications, such as IP TV or live lecture or seminar 1277 streaming, so may wish to consider support for specific IPv6 1278 multicast functionality, e.g. Embedded-RP [RFC3956] in routers and 1279 MLDv1 and MLDv2 snooping in switches. 1281 7. Security Considerations 1283 This document has multiple security sections detailing how to 1284 securely deploy an IPv6 network within an enterprise network. 1286 8. Acknowledgements 1288 The authors would like to thank Chris Grundemann, Ray Hunter, Brian 1289 Carpenter, Tina Tsou, Christian Jaquenet, and Fred Templin for their 1290 substantial comments and contributions. 1292 9. IANA Considerations 1294 There are no IANA considerations or implications that arise from this 1295 document. 1297 10. Informative References 1299 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 1300 converting network protocol addresses to 48.bit Ethernet 1301 address for transmission on Ethernet hardware", STD 37, 1302 RFC 826, November 1982. 1304 [RFC1687] Fleischman, E., "A Large Corporate User's View of IPng", 1305 RFC 1687, August 1994. 1307 [RFC1817] Rekhter, Y., "CIDR and Classful Routing", RFC 1817, August 1308 1995. 1310 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1311 E. Lear, "Address Allocation for Private Internets", BCP 1312 5, RFC 1918, February 1996. 1314 [RFC2011] McCloghrie, K., "SNMPv2 Management Information Base for 1315 the Internet Protocol using SMIv2", RFC 2011, November 1316 1996. 1318 [RFC2096] Baker, F., "IP Forwarding Table MIB", RFC 2096, January 1319 1997. 1321 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1322 Defeating Denial of Service Attacks which employ IP Source 1323 Address Spoofing", BCP 38, RFC 2827, May 2000. 1325 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1326 and M. Carney, "Dynamic Host Configuration Protocol for 1327 IPv6 (DHCPv6)", RFC 3315, July 2003. 1329 [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous 1330 Point (RP) Address in an IPv6 Multicast Address", RFC 1331 3956, November 2004. 1333 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 1334 Neighbor Discovery (SEND)", RFC 3971, March 2005. 1336 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 1337 RFC 3972, March 2005. 1339 [RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E. 1340 Castro, "Application Aspects of IPv6 Transition", RFC 1341 4038, March 2005. 1343 [RFC4057] Bound, J., "IPv6 Enterprise Network Scenarios", RFC 4057, 1344 June 2005. 1346 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1347 Addresses", RFC 4193, October 2005. 1349 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 1350 for IPv6 Hosts and Routers", RFC 4213, October 2005. 1352 [RFC4293] Routhier, S., "Management Information Base for the 1353 Internet Protocol (IP)", RFC 4293, April 2006. 1355 [RFC4296] Bailey, S. and T. Talpey, "The Architecture of Direct Data 1356 Placement (DDP) and Remote Direct Memory Access (RDMA) on 1357 Internet Protocols", RFC 4296, December 2005. 1359 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1360 Networks (VPNs)", RFC 4364, February 2006. 1362 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 1363 Message Protocol (ICMPv6) for the Internet Protocol 1364 Version 6 (IPv6) Specification", RFC 4443, March 2006. 1366 [RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur, 1367 "BGP-MPLS IP Virtual Private Network (VPN) Extension for 1368 IPv6 VPN", RFC 4659, September 2006. 1370 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1371 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1372 September 2007. 1374 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1375 Address Autoconfiguration", RFC 4862, September 2007. 1377 [RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering 1378 ICMPv6 Messages in Firewalls", RFC 4890, May 2007. 1380 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 1381 Extensions for Stateless Address Autoconfiguration in 1382 IPv6", RFC 4941, September 2007. 1384 [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation 1385 of Type 0 Routing Headers in IPv6", RFC 5095, December 1386 2007. 1388 [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. 1389 Meyer, "Information Model for IP Flow Information Export", 1390 RFC 5102, January 2008. 1392 [RFC5157] Chown, T., "IPv6 Implications for Network Scanning", RFC 1393 5157, March 2008. 1395 [RFC5211] Curran, J., "An Internet Transition Plan", RFC 5211, July 1396 2008. 1398 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 1399 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 1400 March 2008. 1402 [RFC5375] Van de Velde, G., Popoviciu, C., Chown, T., Bonness, O., 1403 and C. Hahn, "IPv6 Unicast Address Assignment 1404 Considerations", RFC 5375, December 2008. 1406 [RFC5722] Krishnan, S., "Handling of Overlapping IPv6 Fragments", 1407 RFC 5722, December 2009. 1409 [RFC5798] Nadas, S., "Virtual Router Redundancy Protocol (VRRP) 1410 Version 3 for IPv4 and IPv6", RFC 5798, March 2010. 1412 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 1413 Address Text Representation", RFC 5952, August 2010. 1415 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 1416 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 1417 October 2010. 1419 [RFC6104] Chown, T. and S. Venaas, "Rogue IPv6 Router Advertisement 1420 Problem Statement", RFC 6104, February 2011. 1422 [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. 1423 Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, 1424 February 2011. 1426 [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 1427 "IPv6 Router Advertisement Options for DNS Configuration", 1428 RFC 6106, November 2010. 1430 [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 1431 IPv4/IPv6 Translation", RFC 6144, April 2011. 1433 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 1434 Algorithm", RFC 6145, April 2011. 1436 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 1437 NAT64: Network Address and Protocol Translation from IPv6 1438 Clients to IPv4 Servers", RFC 6146, April 2011. 1440 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 1441 Beijnum, "DNS64: DNS Extensions for Network Address 1442 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 1443 April 2011. 1445 [RFC6177] Narten, T., Huston, G., and L. Roberts, "IPv6 Address 1446 Assignment to End Sites", BCP 157, RFC 6177, March 2011. 1448 [RFC6164] Kohno, M., Nitzan, B., Bush, R., Matsuzaki, Y., Colitti, 1449 L., and T. Narten, "Using 127-Bit IPv6 Prefixes on Inter- 1450 Router Links", RFC 6164, April 2011. 1452 [RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the 1453 Router Control Plane", RFC 6192, March 2011. 1455 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 1456 Translation", RFC 6296, June 2011. 1458 [RFC6302] Durand, A., Gashinsky, I., Lee, D., and S. Sheppard, 1459 "Logging Recommendations for Internet-Facing Servers", BCP 1460 162, RFC 6302, June 2011. 1462 [RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node 1463 Requirements", RFC 6434, December 2011. 1465 [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with 1466 Dual-Stack Hosts", RFC 6555, April 2012. 1468 [RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational 1469 Neighbor Discovery Problems", RFC 6583, March 2012. 1471 [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, 1472 "Default Address Selection for Internet Protocol Version 6 1473 (IPv6)", RFC 6724, September 2012. 1475 [RFC6866] Carpenter, B. and S. Jiang, "Problem Statement for 1476 Renumbering IPv6 Hosts with Static Addresses in Enterprise 1477 Networks", RFC 6866, February 2013. 1479 [RFC6879] Jiang, S., Liu, B., and B. Carpenter, "IPv6 Enterprise 1480 Network Renumbering Scenarios, Considerations, and 1481 Methods", RFC 6879, February 2013. 1483 [RFC6883] Carpenter, B. and S. Jiang, "IPv6 Guidance for Internet 1484 Content Providers and Application Service Providers", RFC 1485 6883, March 2013. 1487 [RFC6959] McPherson, D., Baker, F., and J. Halpern, "Source Address 1488 Validation Improvement (SAVI) Threat Scope", RFC 6959, May 1489 2013. 1491 [RFC6964] Templin, F., "Operational Guidance for IPv6 Deployment in 1492 IPv4 Sites Using the Intra-Site Automatic Tunnel 1493 Addressing Protocol (ISATAP)", RFC 6964, May 2013. 1495 [I-D.xli-behave-divi] 1496 Bao, C., Li, X., Zhai, Y., and W. Shang, "dIVI: Dual- 1497 Stateless IPv4/IPv6 Translation", draft-xli-behave-divi-05 1498 (work in progress), June 2013. 1500 [I-D.wierenga-ietf-eduroam] 1501 Wierenga, K., Winter, S., and T. Wolniewicz, "The eduroam 1502 architecture for network roaming", draft-wierenga-ietf- 1503 eduroam-01 (work in progress), July 2013. 1505 [I-D.ietf-v6ops-dc-ipv6] 1506 Lopez, D., Chen, Z., Tsou, T., Zhou, C., and A. Servin, 1507 "IPv6 Operational Guidelines for Datacenters", draft-ietf- 1508 v6ops-dc-ipv6-00 (work in progress), August 2013. 1510 [I-D.ietf-6man-ext-transmit] 1511 Carpenter, B. and S. Jiang, "Transmission and Processing 1512 of IPv6 Extension Headers", draft-ietf-6man-ext- 1513 transmit-04 (work in progress), September 2013. 1515 [I-D.ietf-v6ops-design-choices] 1516 Matthews, P., "Design Choices for IPv6 Networks", draft- 1517 ietf-v6ops-design-choices-00 (work in progress), February 1518 2013. 1520 [I-D.ietf-opsec-v6] 1521 Chittimaneni, K., Kaeo, M., and E. Vyncke, "Operational 1522 Security Considerations for IPv6 Networks", draft-ietf- 1523 opsec-v6-03 (work in progress), July 2013. 1525 [I-D.ietf-opsec-ipv6-host-scanning] 1526 Gont, F. and T. Chown, "Network Reconnaissance in IPv6 1527 Networks", draft-ietf-opsec-ipv6-host-scanning-02 (work in 1528 progress), July 2013. 1530 [I-D.ietf-opsec-ipv6-implications-on-ipv4-nets] 1531 Gont, F. and W. Liu, "Security Implications of IPv6 on 1532 IPv4 Networks", draft-ietf-opsec-ipv6-implications-on- 1533 ipv4-nets-05 (work in progress), July 2013. 1535 [I-D.ietf-v6ops-ra-guard-implementation] 1536 Gont, F., "Implementation Advice for IPv6 Router 1537 Advertisement Guard (RA-Guard)", draft-ietf-v6ops-ra- 1538 guard-implementation-07 (work in progress), November 2012. 1540 [I-D.liu-bonica-dhcpv6-slaac-problem] 1541 Liu, B. and R. Bonica, "DHCPv6/SLAAC Address Configuration 1542 Interaction Problem Statement", draft-liu-bonica-dhcpv6 1543 -slaac-problem-02 (work in progress), September 2013. 1545 [I-D.ietf-v6ops-ula-usage-recommendations] 1546 Liu, B., Jiang, S., and C. Byrne, "Recommendations of 1547 Using Unique Local Addresses", draft-ietf-v6ops-ula-usage- 1548 recommendations-00 (work in progress), May 2013. 1550 [SMURF] , "CERT Advisory CA-1998-01 Smurf IP Denial-of-Service 1551 Attacks", , 1552 . 1554 [CYMRU] , "THE BOGON REFERENCE", , 1555 . 1557 Authors' Addresses 1558 Kiran K. Chittimaneni 1559 Google Inc. 1560 1600 Amphitheater Pkwy 1561 Mountain View, California CA 94043 1562 USA 1564 Email: kk@google.com 1566 Tim Chown 1567 University of Southampton 1568 Highfield 1569 Southampton, Hampshire SO17 1BJ 1570 United Kingdom 1572 Email: tjc@ecs.soton.ac.uk 1574 Lee Howard 1575 Time Warner Cable 1576 13820 Sunrise Valley Drive 1577 Herndon, VA 20171 1578 US 1580 Phone: +1 703 345 3513 1581 Email: lee.howard@twcable.com 1583 Victor Kuarsingh 1584 Dyn Inc 1585 150 Dow Street 1586 Manchester, NH 1587 US 1589 Email: victor@jvknet.com 1591 Yanick Pouffary 1592 Hewlett Packard 1593 950 Route Des Colles 1594 Sophia-Antipolis 06901 1595 France 1597 Email: Yanick.Pouffary@hp.com 1598 Eric Vyncke 1599 Cisco Systems 1600 De Kleetlaan 6a 1601 Diegem 1831 1602 Belgium 1604 Phone: +32 2 778 4677 1605 Email: evyncke@cisco.com