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