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