idnits 2.17.1 draft-ietf-v6ops-enterprise-incremental-ipv6-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- 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 (July 31, 2014) is 3556 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-03 == Outdated reference: A later version (-12) exists of draft-ietf-v6ops-design-choices-01 == 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-04 == Outdated reference: A later version (-05) exists of draft-ietf-v6ops-ula-usage-recommendations-03 Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Chittimaneni 3 Internet-Draft Dropbox Inc. 4 Intended status: Informational T. Chown 5 Expires: February 1, 2015 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 July 31, 2014 16 Enterprise IPv6 Deployment Guidelines 17 draft-ietf-v6ops-enterprise-incremental-ipv6-06 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 February 1, 2015. 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 . . . . . . . . . . . . . . . . . . . . . 7 75 2.2.1. Network infrastructure readiness assessment . . . . . 7 76 2.2.2. Applications readiness assessment . . . . . . . . . . 8 77 2.2.3. Importance of readiness validation and testing . . . 8 78 2.3. Training . . . . . . . . . . . . . . . . . . . . . . . . 9 79 2.4. Security Policy . . . . . . . . . . . . . . . . . . . . . 9 80 2.4.1. IPv6 is no more secure than IPv4 . . . . . . . . . . 9 81 2.4.2. Similarities between IPv6 and IPv4 security . . . . . 10 82 2.4.3. Specific Security Issues for IPv6 . . . . . . . . . . 10 83 2.5. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 12 84 2.6. Address Plan . . . . . . . . . . . . . . . . . . . . . . 13 85 2.7. Tools Assessment . . . . . . . . . . . . . . . . . . . . 15 86 3. External Phase . . . . . . . . . . . . . . . . . . . . . . . 16 87 3.1. Connectivity . . . . . . . . . . . . . . . . . . . . . . 16 88 3.2. Security . . . . . . . . . . . . . . . . . . . . . . . . 17 89 3.3. Monitoring . . . . . . . . . . . . . . . . . . . . . . . 19 90 3.4. Servers and Applications . . . . . . . . . . . . . . . . 19 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 . . . . . . . . . . . . . . . . . . . . 22 96 4.4. Corporate Systems . . . . . . . . . . . . . . . . . . . . 23 98 5. IPv6-only . . . . . . . . . . . . . . . . . . . . . . . . . . 23 99 6. Considerations For Specific Enterprises . . . . . . . . . . . 25 100 6.1. Content Delivery Networks . . . . . . . . . . . . . . . . 25 101 6.2. Data Center Virtualization . . . . . . . . . . . . . . . 25 102 6.3. University Campus Networks . . . . . . . . . . . . . . . 25 103 7. Security Considerations . . . . . . . . . . . . . . . . . . . 27 104 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 105 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 106 10. Informative References . . . . . . . . . . . . . . . . . . . 27 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 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, 117 mobile devices, other computing devices and related peripherals, a 118 server network, consisting of accounting and business application 119 servers, and an external network, consisting of Internet-accessible 120 services such as web servers, email servers, VPN systems, and 121 customer applications. This document is intended as guidance for 122 enterprise network architects and administrators in planning their 123 IPv6 deployments. 125 The business reasons for spending time, effort, and money on IPv6 126 will be unique to each enterprise. The most common drivers are due 127 to the fact that when Internet service providers, including mobile 128 wireless carriers, run out of IPv4 addresses, they will provide 129 native IPv6 and non-native IPv4. The non-native IPv4 service may be 130 NAT64, NAT444, Dual-stack Lite, MAP-T, MAP-E, or other transition 131 technologies. Compared to tunneled or translated service, native 132 traffic typically performs better and more reliably than non-native. 133 For example, for client networks trying to reach enterprise networks, 134 the IPv6 experience will be better than the transitional IPv4 if the 135 enterprise deploys IPv6 in its public- facing services. The native 136 IPv6 network path should also be simpler to manage and, if necessary, 137 troubleshoot. Further, enterprises doing business in growing parts 138 of the world may find IPv6 growing faster there, where again 139 potential new customers, employees and partners are using IPv6. It 140 is thus in the enterprise's interests to deploy native IPv6, at the 141 very least in its public-facing services, but ultimately across the 142 majority or all of its scope. 144 The text in this document provides specific guidance for enterprise 145 networks, and complements other related work in the IETF, including 146 [I-D.ietf-v6ops-design-choices] and [RFC5375]. 148 1.1. Enterprise Assumptions 150 For the purpose of this document, we assume: 152 o The administrator is considering deploying IPv6 (but see 153 Section 1.2 below). 155 o The administrator has existing IPv4 networks and devices which 156 will continue to operate and be supported. 158 o The administrator will want to minimize the level of disruption to 159 the users and services by minimizing number of technologies and 160 functions that are needed to mediate any given application. In 161 other words: provide native IP wherever possible. 163 Based on these assumptions, an administrator will want to use 164 technologies which minimize the number of flows being tunnelled, 165 translated or intercepted at any given time. The administrator will 166 choose transition technologies or strategies which allow most traffic 167 to be native, and will manage non-native traffic. This will allow 168 the administrator to minimize the cost of IPv6 transition 169 technologies, by containing the number and scale of transition 170 systems. 172 Tunnels used for IPv6/IPv4 transition are expected as near/mid- term 173 mechanisms, while IPv6 tunneling will be used for many long-term 174 operational purposes such as security, routing control, mobility, 175 multi-homing, traffic engineering, etc. We refer to the former class 176 of tunnels as "transition tunnels" 178 1.2. IPv4-only Considerations 180 As described in [RFC6302] administrators should take certain steps 181 even if they are not considering IPv6. Specifically, Internet-facing 182 servers should log the source port number, timestamp (from a reliable 183 source), and the transport protocol. This will allow investigation 184 of malefactors behind address-sharing technologies such as NAT444, 185 MAP, or Dual-stack Lite. Such logs should be protected for 186 integrity, safeguarded for privacy and periodically purged within 187 applicable regulations for log retention. 189 Other IPv6 considerations may impact ostensibly IPv4-only networks, 190 e.g. [RFC6104] describes the rogue IPv6 RA problem, which may cause 191 problems in IPv4-only networks where IPv6 is enabled in end systems 192 on that network. Further discussion of the security implications of 193 IPv6 in IPv4-only networks can be found in [RFC7123]). 195 1.3. Reasons for a Phased Approach 197 Given the challenges of transitioning user workstations, corporate 198 systems, and Internet-facing servers, a phased approach allows 199 incremental deployment of IPv6, based on the administrator's own 200 determination of priorities. This document outlines suggested 201 phases: a Preparation and Assessment Phase, an Internal Phase, and an 202 External Phase. The Preparation Phase is highly recommended to all 203 administrators, as it will save errors and complexity in later 204 phases. Each administrator must decide whether to begin with an 205 External Phase (enabling IPv6 for Internet-facing systems, as 206 recommended in [RFC5211]) or an Internal Phase (enabling IPv6 for 207 internal interconnections first). 209 Each scenario is likely to be different to some extent, but we can 210 highlight some considerations: 212 o In many cases, customers outside the network will have IPv6 before 213 the internal enterprise network. For these customers, IPv6 may 214 well perform better, especially for certain applications, than 215 translated or tunneled IPv4, so the administrator may want to 216 prioritize the External Phase such that those customers have the 217 simplest and most robust connectivity to the enterprise, or at 218 least its external-facing elements. 220 o Employees who access internal systems by VPN may find that their 221 ISPs provide translated IPv4, which does not support the required 222 VPN protocols. In these cases, the administrator may want to 223 prioritize the External Phase, and any other remotely-accessible 224 internal systems. It is worth noting that a number of emerging 225 VPN solutions provide dual-stack connectivity; thus a VPN service 226 may be useful for employees in IPv4-only access networks to access 227 IPv6 resources in the enterprise network (much like many public 228 tunnel broker services, but specifically for the enterprise). 229 Some security considerations are described in 230 [I-D.ietf-opsec-vpn-leakages]. 232 o Internet-facing servers cannot be managed over IPv6 unless the 233 management systems are IPv6-capable. These might be Network 234 Management Systems (NMS), monitoring systems, or just remote 235 management desktops. Thus in some cases, the Internet-facing 236 systems are dependent on IPv6-capable internal networks. However, 237 dual-stack Internet-facing systems can still be managed over IPv4. 239 o Virtual machines may enable a faster rollout once initial system 240 deployment is complete. Management of VMs over IPv6 is still 241 dependent on the management software supporting IPv6. 243 o IPv6 is enabled by default on all modern operating systems, so it 244 may be more urgent to manage and have visibility on the internal 245 traffic. It is important to manage IPv6 for security purposes, 246 even in an ostensibly IPv4-only network, as described in 247 [RFC7123]. 249 o In many cases, the corporate accounting, payroll, human resource, 250 and other internal systems may only need to be reachable from the 251 internal network, so they may be a lower priority. As enterprises 252 require their vendors to support IPv6, more internal applications 253 will support IPv6 by default and it can be expected that 254 eventually new applications will only support IPv6. The 255 inventory, as described in Section 2.2, will help determine the 256 systems' readiness, as well as the readiness of the supporting 257 network elements and security, which will be a consideration in 258 prioritization of these corporate systems. 260 o Some large organizations (even when using private IPv4 261 addresses[RFC1918]) are facing IPv4 address exhaustion because of 262 the internal network growth (for example the vast number of 263 virtual machines) or because of the acquisition of other companies 264 that often raise private IPv4 address overlapping issues. 266 o IPv6 restores end to end transparency even for internal 267 applications (of course security policies must still be enforced). 268 When two organizations or networks merge [RFC6879], the unique 269 addressing of IPv6 can make the merger much easier and faster. A 270 merger may, therefore, prioritize IPv6 for the affected systems. 272 These considerations are in conflict; each administrator must 273 prioritize according to their company's conditions. It is worth 274 noting that the reasons given in one "Large Corporate User's View of 275 IPng", described in [RFC1687], for reluctance to deploy have largely 276 been satisfied or overcome in the intervening years. 278 2. Preparation and Assessment Phase 280 2.1. Program Planning 282 Since enabling IPv6 is a change to the most fundamental Internet 283 Protocol, and since there are so many interdependencies, having a 284 professional project manager organize the work is highly recommended. 285 In addition, an executive sponsor should be involved in determining 286 the goals of enabling IPv6 (which will establish the order of the 287 phases), and should receive regular updates. 289 It may be necessary to complete the Preparation Phase before 290 determining whether to prioritized the Internal or External Phase, 291 since needs and readiness assessments are part of that phase. For a 292 large enterprise, it may take several iterations to really understand 293 the level of effort required. Depending on the required schedule, it 294 may be useful to roll IPv6 projects into other architectural 295 upgrades--this can be an excellent way to improve the network and 296 reduce costs. However, by increasing the scope of projects, the 297 schedule is often affected. For instance, a major systems upgrade 298 may take a year to complete, where just patching existing systems may 299 take only a few months. 301 The deployment of IPv6 will not generally stop all other technology 302 work. Once IPv6 has been identified as an important initiative, all 303 projects, both new and in-progress, will need to be reviewed to 304 ensure IPv6 support. 306 It is normal for assessments to continue in some areas while 307 execution of the project begins in other areas. This is fine, as 308 long as recommendations in other parts of this document are 309 considered, especially regarding security (for instance, one should 310 not deploy IPv6 on a system before security has been evaluated). 312 2.2. Inventory Phase 314 To comprehend the scope of the inventory phase we recommend dividing 315 the problem space in two: network infrastructure readiness and 316 applications readiness. 318 2.2.1. Network infrastructure readiness assessment 320 The goal of this assessment is to identify the level of IPv6 321 readiness of network equipment. This will identify the effort 322 required to move to an infrastructure that supports IPv6 with the 323 same functional service capabilities as the existing IPv4 network. 324 This may also require a feature comparison and gap analysis between 325 IPv4 and IPv6 functionality on the network equipment and software. 326 IPv6 support will require testing; features often work differently in 327 vendors' labs than production networks. Some devices and software 328 will require IPv4 support for IPv6 to work. 330 The inventory will show which network devices are already capable, 331 which devices can be made IPv6 ready with a code/firmware upgrade, 332 and which devices will need to be replaced. The data collection 333 consists of a network discovery to gain an understanding of the 334 topology and inventory network infrastructure equipment and code 335 versions with information gathered from static files and IP address 336 management, DNS and DHCP tools. 338 Since IPv6 might already be present in the environment, through 339 default configurations or VPNs, an infrastructure assessment (at 340 minimum) is essential to evaluate potential security risks. 342 2.2.2. Applications readiness assessment 344 Just like network equipment, application software needs to support 345 IPv6. This includes OS, firmware, middleware and applications 346 (including internally developed applications). Vendors will 347 typically handle IPv6 enablement of off-the-shelf products, but often 348 enterprises need to request this support from vendors. For 349 internally developed applications it is the responsibility of the 350 enterprise to enable them for IPv6. Analyzing how a given 351 application communicates over the network will dictate the steps 352 required to support IPv6. Applications should avoid instructions 353 specific to a given IP address family. Any applications that use 354 APIs, such as the C language, that expose the IP version 355 specifically, need to be modified to also work with IPv6. 357 There are two ways to IPv6-enable applications. The first approach 358 is to have separate logic for IPv4 and IPv6, thus leaving the IPv4 359 code path mainly untouched. This approach causes the least 360 disruption to the existing IPv4 logic flow, but introduces more 361 complexity, since the application now has to deal with two logic 362 loops with complex race conditions and error recovery mechanisms 363 between these two logic loops. The second approach is to create a 364 combined IPv4/IPv6 logic, which ensures operation regardless of the 365 IP version used on the network. Knowing whether a given 366 implementation will use IPv4 or IPv6 in a given deployment is a 367 matter of some art; see Source Address Selection [RFC6724] and Happy 368 Eyeballs [RFC6555]. It is generally recommended that the application 369 developer use industry IPv6-porting tools to locate the code that 370 needs to be updated. Some discussion of IPv6 application porting 371 issues can be found in [RFC4038]. 373 2.2.3. Importance of readiness validation and testing 375 Lastly IPv6 introduces a completely new way of addressing endpoints, 376 which can have ramifications at the network layer all the way up to 377 the applications. So to minimize disruption during the transition 378 phase we recommend complete functionality, scalability and security 379 testing to understand how IPv6 impacts the services and networking 380 infrastructure. 382 2.3. Training 384 Many organizations falter in IPv6 deployment because of a perceived 385 training gap. Training is important for those who work with 386 addresses regularly, as with anyone whose work is changing. Better 387 knowledge of the reasons IPv6 is being deployed will help inform the 388 assessment of who needs training, and what training they need. 390 2.4. Security Policy 392 It is obvious that IPv6 networks should be deployed in a secure way. 393 The industry has learnt a lot about network security with IPv4, so, 394 network operators should leverage this knowledge and expertise when 395 deploying IPv6. IPv6 is not so different than IPv4: it is a 396 connectionless network protocol using the same lower layer service 397 and delivering the same service to the upper layer. Therefore, the 398 security issues and mitigation techniques are mostly identical with 399 same exceptions that are described further. 401 2.4.1. IPv6 is no more secure than IPv4 403 Some people believe that IPv6 is inherently more secure than IPv4 404 because it is new. Nothing can be more wrong. Indeed, being a new 405 protocol means that bugs in the implementations have yet to be 406 discovered and fixed and that few people have the operational 407 security expertise needed to operate securely an IPv6 network. This 408 lack of operational expertise is the biggest threat when deploying 409 IPv6: the importance of training is to be stressed again. 411 One security myth is that thanks to its huge address space, a network 412 cannot be scanned by enumerating all IPv6 address in a /64 LAN hence 413 a malevolent person cannot find a victim. [RFC5157] describes some 414 alternate techniques to find potential targets on a network, for 415 example enumerating all DNS names in a zone. Additional advice in 416 this area is also given in [I-D.ietf-opsec-ipv6-host-scanning]. 418 Another security myth is that IPv6 is more secure because it mandates 419 the use of IPsec everywhere. While the original IPv6 specifications 420 may have implied this, [RFC6434] clearly states that IPsec support is 421 not mandatory. Moreover, if all the intra-enterprise traffic is 422 encrypted, both malefactors and security tools that rely on payload 423 inspection (IPS, firewall, ACL, IPFIX ([RFC7011] and [RFC7012]), etc) 424 will be thwarted. Therefore, IPsec is as useful in IPv6 as in IPv4 425 (for example to establish a VPN overlay over a non-trusted network or 426 reserved for some specific applications). 428 The last security myth is that amplification attacks (such as 429 [SMURF]) do not exist in IPv6 because there is no more broadcast. 431 Alas, this is not true as ICMP error (in some cases) or information 432 messages can be generated by routers and hosts when forwarding or 433 receiving a multicast message (see Section 2.4 of [RFC4443]). 434 Therefore, the generation and the forwarding rate of ICMPv6 messages 435 must be limited as in IPv4. 437 It should be noted that in a dual-stack network the security 438 implementation for both IPv4 and IPv6 needs to be considered, in 439 addition to security considerations related to the interaction of 440 (and transition between) the two, while they coexist. 442 2.4.2. Similarities between IPv6 and IPv4 security 444 As mentioned earlier, IPv6 is quite similar to IPv4, therefore 445 several attacks apply for both protocol families, including: 447 o Application layer attacks: such as cross-site scripting or SQL 448 injection 450 o Rogue device: such as a rogue Wi-Fi Access Point 452 o Flooding and all traffic-based denial of services (including the 453 use of control plane policing for IPv6 traffic see [RFC6192]) 455 A specific case of congruence is IPv6 Unique Local Addresses (ULAs) 456 [RFC4193] and IPv4 private addressing [RFC1918], which do not provide 457 any security by 'magic'. In both cases, the edge router must apply 458 strict filters to block those private addresses from entering and, 459 just as importantly, leaving the network. This filtering can be done 460 by the enterprise or by the ISP, but the cautious administrator will 461 prefer to do it in the enterprise. 463 IPv6 addresses can be spoofed as easily as IPv4 addresses and there 464 are packets with bogon IPv6 addresses (see [CYMRU]). Anti-bogon 465 filtering must be done in the data and routing planes. It can be 466 done by the enterprise or by the ISP, or both, but again the cautious 467 administrator will prefer to do it in the enterprise. 469 2.4.3. Specific Security Issues for IPv6 471 Even if IPv6 is similar to IPv4, there are some differences that 472 create some IPv6-only vulnerabilities or issues. We give examples of 473 such differences in this section. 475 Privacy extension addresses [RFC4941] are usually used to protect 476 individual privacy by periodically changing the interface identifier 477 part of the IPv6 address to avoid tracking a host by its otherwise 478 always identical and unique MAC-based EUI-64. While this presents a 479 real advantage on the Internet, moderated by the fact that the prefix 480 part remains the same, it complicates the task of following an audit 481 trail when a security officer or network operator wants to trace back 482 a log entry to a host in their network, because when the tracing is 483 done the searched IPv6 address could have disappeared from the 484 network. Therefore, the use of privacy extension addresses usually 485 requires additional monitoring and logging of the binding of the IPv6 486 address to a data-link layer address (see also the monitoring section 487 of [I-D.ietf-opsec-v6]). Some early enterprise deployments have 488 taken the approach of using tools that harvest IP/MAC address 489 mappings from switch and router devices to provide address 490 accountability; this approach has been shown to work, though it can 491 involve gathering significantly more address data than in equivalent 492 IPv4 networks. An alternative is to try to prevent the use of 493 privacy extension addresses by enforcing the use of DHCPv6, such that 494 hosts only get addresses assigned by a DHCPv6 server. This can be 495 done by configuring routers to set the M-bit in Router 496 Advertisements, combined with all advertised prefixes being included 497 without the A-bit set (to prevent the use of stateless auto- 498 configuration). This technique of course requires that all hosts 499 support stateful DHCPv6. It is important to note that not all 500 operating systems exhibit the same behavior when processing RAs with 501 the M-Bit set. The varying OS behavior is related to the lack of 502 prescriptive definition around the A, M and O-bits within the ND 503 protocol. [I-D.liu-bonica-dhcpv6-slaac-problem] provides a much more 504 detailed analysis on the interaction of the M-Bit and DHCPv6. 506 Extension headers complicate the task of stateless packet filters 507 such as ACLs. If ACLs are used to enforce a security policy, then 508 the enterprise must verify whether its ACL (but also stateful 509 firewalls) are able to process extension headers (this means 510 understand them enough to parse them to find the upper layers 511 payloads) and to block unwanted extension headers (e.g., to implement 512 [RFC5095]). This topic is discussed further in [RFC7045]. 514 Fragmentation is different in IPv6 because it is done only by source 515 host and never during a forwarding operation. This means that ICMPv6 516 packet-too-big messages must be allowed to pass through the network 517 and not be filtered [RFC4890]. Fragments can also be used to evade 518 some security mechanisms such as RA-guard [RFC6105]. See also 519 [RFC5722], and [RFC7113]. 521 One of the biggest differences between IPv4 and IPv6 is the 522 introduction of the Neighbor Discovery Protocol [RFC4861], which 523 includes a variety of important IPv6 protocol functions, including 524 those provided in IPv4 by ARP [RFC0826]. NDP runs over ICMPv6 (which 525 as stated above means that security policies must allow some ICMPv6 526 messages to pass, as described in RFC 4890), but has the same lack of 527 security as, for example, ARP, in that there is no inherent message 528 authentication. While Secure Neighbour Discovery (SeND) [RFC3971] 529 and CGA [RFC3972] have been defined, they are not widely 530 implemented). The threat model for Router Advertisements within the 531 NDP suite is similar to that of DHCPv4 (and DHCPv6), in that a rogue 532 host could be either a rogue router or a rogue DHCP server. An IPv4 533 network can be made more secure with the help of DHCPv4 snooping in 534 edge switches, and likewise RA snooping can improve IPv6 network 535 security (in IPv4-only networks as well). Thus enterprises using 536 such techniques for IPv4 should use the equivalent techniques for 537 IPv6, including RA-guard [RFC6105] and all work in progress from the 538 SAVI WG, e.g. [RFC6959], which is similar to the protection given by 539 dynamic ARP monitoring in IPv4. Other DoS vulnerabilities are 540 related to NDP cache exhaustion, and mitigation techniques can be 541 found in ([RFC6583]). 543 As stated previously, running a dual-stack network doubles the attack 544 exposure as a malevolent person has now two attack vectors: IPv4 and 545 IPv6. This simply means that all routers and hosts operating in a 546 dual-stack environment with both protocol families enabled (even if 547 by default) must have a congruent security policy for both protocol 548 versions. For example, permit TCP ports 80 and 443 to all web 549 servers and deny all other ports to the same servers must be 550 implemented both for IPv4 and IPv6. It is thus important that the 551 tools available to administrators readily support such behaviour. 553 2.5. Routing 555 An important design choice to be made is what IGP to use inside the 556 network. A variety of IGPs (IS-IS, OSPFv3 and RIPng) support IPv6 557 today and picking one over the other is a design choice that will be 558 dictated mostly by existing operational policies in an enterprise 559 network. As mentioned earlier, it would be beneficial to maintain 560 operational parity between IPv4 and IPv6 and therefore it might make 561 sense to continue using the same protocol family that is being used 562 for IPv4. For example, in a network using OSPFv2 for IPv4, it might 563 make sense to use OSPFv3 for IPv6. It is important to note that 564 although OSPFv3 is similar to OSPFv2, they are not the same. On the 565 other hand, some organizations may chose to run different routing 566 protocols for different IP versions. For example, one may chose to 567 run OSPFv2 for IPv4 and IS-IS for IPv6. An important design question 568 to consider here is whether to support one IGP or two different IGPs 569 in the longer term. [I-D.ietf-v6ops-design-choices] presents advice 570 on the design choices that arise when considering IGPs and discusses 571 the advantages and disadvantages to different approaches in detail. 573 2.6. Address Plan 575 The most common problem encountered in IPv6 networking is in applying 576 the same principles of conservation that are so important in IPv4. 577 IPv6 addresses do not need to be assigned conservatively. In fact, a 578 single larger allocation is considered more conservative than 579 multiple non-contiguous small blocks, because a single block occupies 580 only a single entry in a routing table. The advice in [RFC5375] is 581 still sound, and is recommended to the reader. If considering ULAs, 582 give careful thought to how well it is supported, especially in 583 multiple address and multicast scenarios, and assess the strength of 584 the requirement for ULA. [I-D.ietf-v6ops-ula-usage-recommendations] 585 provides much more detailed analysis and recommendations on the usage 586 of ULAs. 588 The enterprise administrator will want to evaluate whether the 589 enterprise will request address space from a LIR (Local Internet 590 Registry, such as an ISP), a RIR (Regional Internet Registry, such as 591 AfriNIC, APNIC, ARIN, LACNIC, or RIPE-NCC) or a NIR (National 592 Internet Registry, operated in some countries). The normal 593 allocation is Provider Aggregatable (PA) address space from the 594 enterprise's ISP, but use of PA space implies renumbering when 595 changing provider. Instead, an enterprise may request Provider 596 Independent (PI) space; this may involve an additional fee, but the 597 enterprise may then be better able to be multihomed using that 598 prefix, and will avoid a renumbering process when changing ISPs 599 (though it should be noted that renumbering caused by outgrowing the 600 space, merger, or other internal reason would still not be avoided 601 with PI space). 603 The type of address selected (PI vs. PA) should be congruent with the 604 routing needs of the enterprise. The selection of address type will 605 determine if an operator will need to apply new routing techniques 606 and may limit future flexibility. There is no right answer, but the 607 needs of the external phase may affect what address type is selected. 609 Each network location or site will need a prefix assignment. 610 Depending on the type of site/location, various prefix sizes may be 611 used. In general, historical guidance suggests that each site should 612 get at least a /48, as documented in RFC 5375 and [RFC6177]. In 613 addition to allowing for simple planning, this can allow a site to 614 use its prefix for local connectivity, should the need arise, and if 615 the local ISP supports it. 617 When assigning addresses to end systems, the enterprise may use 618 manually-configured addresses (common on servers) or SLAAC or DHCPv6 619 for client systems. Early IPv6 enterprise deployments have used 620 SLAAC, both for its simplicity but also due to the time DHCPv6 has 621 taken to mature. However, DHCPv6 is now very mature, and thus 622 workstations managed by an enterprise may use stateful DHCPv6 for 623 addressing on corporate LAN segments. DHCPv6 allows for the 624 additional configuration options often employed by enterprise 625 administrators, and by using stateful DHCPv6, administrators 626 correlating system logs know which system had which address at any 627 given time. Such an accountability model is familiar from IPv4 628 management, though for DHCPv6 hosts are identified by DUID rather 629 than MAC address. For equivalent accountability with SLAAC (and 630 potentially privacy addresses), a monitoring system that harvests IP/ 631 MAC mappings from switch and router equipment could be used. 633 A common deployment consideration for any enterprise network is how 634 to get host DNS records updated. Commonly, either the host will send 635 DNS updates or the DHCP server will update records. If there is 636 sufficient trust between the hosts and the DNS server, the hosts may 637 update (and the enterprise may use SLAAC for addressing). Otherwise, 638 the DHCPv6 server can be configured to update the DNS server. Note 639 that an enterprise network with this more controlled environment will 640 need to disable SLAAC on network segments and force end hosts to use 641 DHCPv6 only. 643 In the data center or server room, assume a /64 per VLAN. This 644 applies even if each individual system is on a separate VLAN. In a 645 /48 assignment, typical for a site, there are then still 65,535 /64 646 blocks. Some administrators reserve a /64 but configure a small 647 subnet, such as /112, /126, or /127, to prevent rogue devices from 648 attaching and getting numbers; an alternative is to monitor traffic 649 for surprising addresses or ND tables for new entries. Addresses are 650 either configured manually on the server, or reserved on a DHCPv6 651 server, which may also synchronize forward and reverse DNS (though 652 see [RFC6866] for considerations on static addressing). SLAAC is not 653 recommended for servers, because of the need to synchronize RA timers 654 with DNS TTLs so that the DNS entry expires at the same time as the 655 address. 657 All user access networks should be a /64. Point-to-point links where 658 Neighbor Discovery Protocol is not used may also utilize a /127 (see 659 [RFC6164]). 661 Plan to aggregate at every layer of network hierarchy. There is no 662 need for VLSM [RFC1817] in IPv6, and addressing plans based on 663 conservation of addresses are short-sighted. Use of prefixes longer 664 then /64 on network segments will break common IPv6 functions such as 665 SLAAC[RFC4862]. Where multiple VLANs or other layer two domains 666 converge, allow some room for expansion. Renumbering due to 667 outgrowing the network plan is a nuisance, so allow room within it. 668 Generally, plan to grow to about twice the current size that can be 669 accommodated; where rapid growth is planned, allow for twice that 670 growth. Also, if DNS (or reverse DNS) authority may be delegated to 671 others in the enterprise, assignments need to be on nibble boundaries 672 (that is, on a multiple of 4 bits, such as /64, /60, /56, ..., /48, 673 /44), to ensure that delegated zones align with assigned prefixes. 675 If using ULAs, it is important to note that AAAA and PTR records for 676 ULA are not recommended to be installed in the global DNS. 677 Similarly, reverse (address-to-name) queries for ULA must not be sent 678 to name servers outside of the organization, due to the load that 679 such queries would create for the authoritative name servers for the 680 ip6.arpa zone. For more details please refer to section 4.4 of 681 [RFC4193]. 683 Enterprise networks more and more include virtual networks where a 684 single physical node may host many virtualized addressable devices. 685 It is imperative that the addressing plans assigned to these virtual 686 networks and devices be consistent and non-overlapping with the 687 addresses assigned to real networks and nodes. For example, a 688 virtual network established within an isolated lab environment may at 689 a later time become attached to the production enterprise network. 691 2.7. Tools Assessment 693 Enterprises will often have a number of operational tools and support 694 systems which are used to provision, monitor, manage and diagnose the 695 network and systems within their environment. These tools and 696 systems will need to be assessed for compatibility with IPv6. The 697 compatibility may be related to the addressing and connectivity of 698 various devices as well as IPv6 awareness of the tools and processing 699 logic. 701 The tools within the organization fall into two general categories, 702 those which focus on managing the network, and those which are 703 focused on managing systems and applications on the network. In 704 either instance, the tools will run on platforms which may or may not 705 be capable of operating in an IPv6 network. This lack in 706 functionality may be related to Operating System version, or based on 707 some hardware constraint. Those systems which are found to be 708 incapable of utilizing an IPv6 connection, or which are dependent on 709 an IPv4 stack, may need to be replaced or upgraded. 711 In addition to devices working on an IPv6 network natively, or via a 712 transition tunnel, many tools and support systems may require 713 additional software updates to be IPv6 aware, or even a hardware 714 upgrade (usually for additional memory: IPv6 addresses are larger and 715 for a while, IPv4 and IPv6 addresses will coexist in the tool). This 716 awareness may include the ability to manage IPv6 elements and/or 717 applications in addition to the ability to store and utilize IPv6 718 addresses. 720 Considerations when assessing the tools and support systems may 721 include the fact that IPv6 addresses are significantly larger than 722 IPv4, requiring data stores to support the increased size. Such 723 issues are among those discussed in [RFC5952]. Many organizations 724 may also run dual-stack networks, therefore the tools need to not 725 only support IPv6 operation, but may also need to support the 726 monitoring, management and intersection with both IPv6 and IPv4 727 simultaneously. It is important to note that managing IPv6 is not 728 just constrained to using large IPv6 addresses, but also that IPv6 729 interfaces and nodes are likely to use two or more addresses as part 730 of normal operation. Updating management systems to deal with these 731 additional nuances will likely consume time and considerable effort. 733 For networking systems, like node management systems, it is not 734 always necessary to support local IPv6 addressing and connectivity. 735 Operations such as SNMP MIB polling can occur over IPv4 transport 736 while seeking responses related to IPv6 information. Where this may 737 seem advantageous to some, it should be noted that without local IPv6 738 connectivity, the management system may not be able to perform all 739 expected functions - such as reachability and service checks. 741 Organizations should be aware that changes to older IPv4-only SNMP 742 MIB specifications have been made by the IETF related to legacy 743 operation in [RFC2096] and [RFC2011]. Updated specifications are now 744 available in [RFC4292] and [RFC4293] which modified the older MIB 745 framework to be IP protocol agnostic, supporting both IPv4 and IPv6. 746 Polling systems will need to be upgraded to support these updates as 747 well as the end stations which are polled. 749 3. External Phase 751 The external phase for enterprise IPv6 adoption covers topics which 752 deal with how an organization connects its infrastructure to the 753 external world. These external connections may be toward the 754 Internet at large, or to other networks. The external phase covers 755 connectivity, security and monitoring of various elements and outward 756 facing or accessible services. 758 3.1. Connectivity 760 The enterprise will need to work with one or more Service Providers 761 to gain connectivity to the Internet or transport service 762 infrastructure such as a BGP/MPLS IP VPN as described in [RFC4364] 763 and [RFC4659]. One significant factor that will guide how an 764 organization may need to communicate with the outside world will 765 involve the use of PI (Provider Independent) and/or PA (Provider 766 Aggregatable) IPv6 space. 768 Enterprises should be aware that depending on which address type they 769 selected (PI vs. PA) in their planning phase, they may need to 770 implement new routing functions and/or behaviours to support their 771 connectivity to the ISP. In the case of PI, the upstream ISP may 772 offer options to route the prefix (typically a /48) on the 773 enterprise's behalf and update the relevant routing databases. 774 Otherwise, the enterprise may need to perform this task on their own 775 and use BGP to inject the prefix into the global BGP system. 777 Note that the rules set by the RIRs for an enterprise acquiring PI 778 address space have changed over time. For example, in the European 779 region the RIPE-NCC no longer requires an enterprise to be multihomed 780 to be eligible for an IPv6 PI allocation. Requests can be made 781 directly or via a LIR. It is possible that the rules may change 782 again, and may vary between RIRs. 784 When seeking IPv6 connectivity to a Service Provider, Native IPv6 785 connectivity is preferred since it provides the most robust and 786 efficient form of connectivity. If native IPv6 connectivity is not 787 possible due to technical or business limitations, the enterprise may 788 utilize readily available transition tunnel IPv6 connectivity. There 789 are IPv6 transit providers which provide robust tunnelled IPv6 790 connectivity which can operate over IPv4 networks. It is important 791 to understand the transition tunnel mechanism used, and to consider 792 that it will have higher latency than native IPv4 or IPv6, and may 793 have other problems, e.g. related to MTUs. 795 It is important to evaluate MTU considerations when adding IPv6 to an 796 existing IPv4 network. It is generally desirable to have the IPv6 797 and IPv4 MTU congruent to simplify operations (so the two address 798 families behave similarly, that is, as expected). If the enterprise 799 uses transition tunnels inside or externally for IPv6 connectivity, 800 then modification of the MTU on hosts/routers may be needed as mid- 801 stream fragmentation is no longer supported in IPv6. It is preferred 802 that pMTUD is used to optimize the MTU, so erroneous filtering of the 803 related ICMPv6 message types should be monitored. Adjusting the MTU 804 may be the only option if undesirable upstream ICMPv6 filtering 805 cannot be removed. 807 3.2. Security 809 The most important part of security for external IPv6 deployment is 810 filtering and monitoring. Filtering can be done by stateless ACLs or 811 a stateful firewall. The security policies must be consistent for 812 IPv4 and IPv6 (else the attacker will use the less protected protocol 813 stack), except that certain ICMPv6 messages must be allowed through 814 and to the filtering device (see [RFC4890]): 816 o Packet Too Big: essential to allow Path MTU discovery to work 818 o Parameter Problem 820 o Time Exceeded 822 In addition, Neighbor Discovery Protocol messages (including Neighbor 823 Solicitation, Router Advertisements, etc.) are required for local 824 hosts. 826 It could also be safer to block all fragments where the transport 827 layer header is not in the first fragment to avoid attacks as 828 described in [RFC5722]. Some filtering devices allow this filtering. 829 Ingress filters and firewalls should follow [RFC5095] in handling 830 routing extension header type 0, dropping the packet and sending 831 ICMPv6 Parameter Problem, unless Segments Left = 0 (in which case, 832 ignore the header). 834 If an Intrusion Prevention System (IPS) is used for IPv4 traffic, 835 then an IPS should also be used for IPv6 traffic. In general, make 836 sure IPv6 security is at least as good as IPv4. This also includes 837 all email content protection (anti-spam, content filtering, data 838 leakage prevention, etc.). 840 The edge router must also implement anti-spoofing techniques based on 841 [RFC2827] (also known as BCP 38). 843 In order to protect the networking devices, it is advised to 844 implement control plane policing as per [RFC6192]. 846 The potential NDP cache exhaustion attack (see [RFC6583]) can be 847 mitigated by two techniques: 849 o Good NDP implementation with memory utilization limits as well as 850 rate-limiters and prioritization of requests. 852 o Or, as the external deployment usually involves just a couple of 853 exposed statically configured IPv6 addresses (virtual addresses of 854 web, email, and DNS servers), then it is straightforward to build 855 an ingress ACL allowing traffic for those addresses and denying 856 traffic to any other addresses. This actually prevents the attack 857 as a packet for a random destination will be dropped and will 858 never trigger a neighbor resolution. 860 3.3. Monitoring 862 Monitoring the use of the Internet connectivity should be done for 863 IPv6 as it is done for IPv4. This includes the use of IP Flow 864 Information eXport (IPFIX) [RFC7012] to report abnormal traffic 865 patterns (such as port scanning, SYN-flooding, related IP source 866 addresses) from monitoring tools and evaluating data read from SNMP 867 MIBs [RFC4293] (some of which also enable the detection of abnormal 868 bandwidth utilization) and syslogs (finding server and system 869 errors). Where Netflow is used, version 9 is required for IPv6 870 support. Monitoring systems should be able to examine IPv6 traffic, 871 use IPv6 for connectivity, record IPv6 address, and any log parsing 872 tools and reporting need to support IPv6. Some of this data can be 873 sensitive (including personally identifiable information) and care in 874 securing it should be taken, with periodic purges. Integrity 875 protection on logs and sources of log data is also important to 876 detect unusual behavior (misconfigurations or attacks). Logs may be 877 used in investigations, which depend on trustworthy data sources 878 (tamper resistant). 880 In addition, monitoring of external services (such as web sites) 881 should be made address-specific, so that people are notified when 882 either the IPv4 or IPv6 version of a site fails. 884 3.4. Servers and Applications 886 The path to the servers accessed from the Internet usually involves 887 security devices (firewall, IPS), server load balancing (SLB) and 888 real physical servers. The latter stage is also multi-tiered for 889 scalability and security between presentation and data storage. The 890 ideal transition is to enable native dual-stack on all devices; but 891 as part of the phased approach, operators have used the following 892 techniques with success: 894 o Use a network device to apply NAT64 and basically translate an 895 inbound TCP connection (or any other transport protocol) over IPv6 896 into a TCP connection over IPv4. This is the easiest to deploy as 897 the path is mostly unchanged but it hides all IPv6 remote users 898 behind a single IPv4 address which leads to several audit trail 899 and security issues (see [RFC6302]). 901 o Use the server load balancer which acts as an application proxy to 902 do this translation. Compared to the NAT64, it has the potential 903 benefit of going through the security devices as native IPv6 (so 904 more audit and trace abilities) and is also able to insert a HTTP 905 X-Forward-For header which contains the remote IPv6 address. The 906 latter feature allows for logging, and rate-limiting on the real 907 servers based on the IPV6 address even if those servers run only 908 IPv4. 910 In either of these cases, care should be taken to secure logs for 911 privacy reasons, and to periodically purge them. 913 3.5. Network Prefix Translation for IPv6 915 Network Prefix Translation for IPv6, or NPTv6 as described in 916 [RFC6296] provides a framework to utilize prefix ranges within the 917 internal network which are separate (address-independent) from the 918 assigned prefix from the upstream provider or registry. As mentioned 919 above, while NPTv6 has potential use-cases in IPv6 networks, the 920 implications of its deployment need to be fully understood, 921 particularly where any applications might embed IPv6 addresses in 922 their payloads. 924 Use of NPTv6 can be chosen independently from how addresses are 925 assigned and routed within the internal network, how prefixes are 926 routed towards the Internet, or whether PA or PI addresses are used. 928 4. Internal Phase 930 This phase deals with the delivery of IPv6 to the internal user- 931 facing side of the IT infrastructure, which comprises various 932 components such as network devices (routers, switches, etc.), end 933 user devices and peripherals (workstations, printers, etc.), and 934 internal corporate systems. 936 An important design paradigm to consider during this phase is "dual- 937 stack when you can, tunnel when you must". Dual-stacking allows a 938 more robust, production-quality IPv6 network than is typically 939 facilitated by internal use of transition tunnels that are harder to 940 troubleshoot and support, and that may introduce scalability and 941 performance issues. Tunnels may of course still be used in 942 production networks, but their use needs to be carefully considered, 943 e.g. where the transition tunnel may be run through a security or 944 filtering device. Tunnels do also provide a means to experiment with 945 IPv6 and gain some operational experience with the protocol. 946 [RFC4213] describes various transition mechanisms in more detail. 947 [RFC6964] suggests operational guidance when using ISATAP tunnels 948 [RFC5214], though we would recommend use of dual-stack wherever 949 possible. 951 4.1. Security 953 IPv6 must be deployed in a secure way. This means that all existing 954 IPv4 security policies must be extended to support IPv6; IPv6 955 security policies will be the IPv6 equivalent of the existing IPv4 956 ones (taking into account the difference for ICMPv6 [RFC4890]). As 957 in IPv4, security policies for IPv6 will be enforced by firewalls, 958 ACL, IPS, VPN, and so on. 960 Privacy extension addresses [RFC4941] raise a challenge for an audit 961 trail as explained in section Section 2.4.3. The enterprise may 962 choose to attempt to enforce use of DHCPv6, or deploy monitoring 963 tools that harvest accountability data from switches and routers 964 (thus making the assumption that devices may use any addresses inside 965 the network). 967 One major issue is threats against Neighbor Discovery. This means, 968 for example, that the internal network at the access layer (where 969 hosts connect to the network over wired or wireless) should implement 970 RA-guard [RFC6105] and the techniques being specified by SAVI WG 971 [RFC6959]; see also Section 2.4.3 for more information. 973 4.2. Network Infrastructure 975 The typical enterprise network infrastructure comprises a combination 976 of the following network elements - wired access switches, wireless 977 access points, and routers (although it is fairly common to find 978 hardware that collapses switching and routing functionality into a 979 single device). Basic wired access switches and access points 980 operate only at the physical and link layers, and don't really have 981 any special IPv6 considerations other than being able to support IPv6 982 addresses themselves for management purposes. In many instances, 983 these devices possess a lot more intelligence than simply switching 984 packets. For example, some of these devices help assist with link 985 layer security by incorporating features such as ARP inspection and 986 DHCP Snooping, or they may help limit where multicast floods by using 987 IGMP (or, in the case of IPv6, MLD) snooping. 989 Another important consideration in enterprise networks is first hop 990 router redundancy. This directly ties into network reachability from 991 an end host's point of view. IPv6 Neighbor Discovery (ND), 992 [RFC4861], provides a node with the capability to maintain a list of 993 available routers on the link, in order to be able to switch to a 994 backup path should the primary be unreachable. By default, ND will 995 detect a router failure in 38 seconds and cycle onto the next default 996 router listed in its cache. While this feature provides a basic 997 level of first hop router redundancy, most enterprise IPv4 networks 998 are designed to fail over much faster. Although this delay can be 999 improved by adjusting the default timers, care must be taken to 1000 protect against transient failures and to account for increased 1001 traffic on the link. Another option to provide robust first hop 1002 redundancy is to use the Virtual Router Redundancy Protocol for IPv6 1003 (VRRPv3), [RFC5798]. This protocol provides a much faster switchover 1004 to an alternate default router than default ND parameters. Using 1005 VRRPv3, a backup router can take over for a failed default router in 1006 around three seconds (using VRRPv3 default parameters). This is done 1007 without any interaction with the hosts and a minimum amount of VRRP 1008 traffic. 1010 Last but not the least, one of the most important design choices to 1011 make while deploying IPv6 on the internal network is whether to use 1012 Stateless Automatic Address Configuration (SLAAC), [RFC4862], or 1013 Dynamic Host Configuration Protocol for IPv6 (DHCPv6), [RFC3315], or 1014 a combination thereof. Each option has advantages and disadvantages, 1015 and the choice will ultimately depend on the operational policies 1016 that guide each enterprise's network design. For example, if an 1017 enterprise is looking for ease of use, rapid deployment, and less 1018 administrative overhead, then SLAAC makes more sense for 1019 workstations. Manual or DHCPv6 assignments are still needed for 1020 servers, as described in the External Phase and Address Plan sections 1021 of this document. However, if the operational policies call for 1022 precise control over IP address assignment for auditing then DHCPv6 1023 may be preferred. DHCPv6 also allows you to tie into DNS systems for 1024 host entry updates and gives you the ability to send other options 1025 and information to clients. It is worth noting that in general 1026 operation RAs are still needed in DHCPv6 networks, as there is no 1027 DHCPv6 Default Gateway option. Similarly, DHCPv6 is needed in RA 1028 networks for other configuration information, e.g. NTP servers or, 1029 in the absence of support for DNS resolvers in RAs [RFC6106], DNS 1030 resolver information. 1032 4.3. End user devices 1034 Most operating systems (OSes) that are loaded on workstations and 1035 laptops in a typical enterprise support IPv6 today. However, there 1036 are various out-of-the-box nuances that one should be mindful about. 1037 For example, the default behavior of OSes vary; some may have IPv6 1038 turned off by default, some may only have certain features such as 1039 privacy extensions to IPv6 addresses (RFC 4941) turned off while 1040 others have IPv6 fully enabled. Further, even when IPv6 is enabled, 1041 the choice of which address is used may be subject to Source Address 1042 Selection (RFC 6724) and Happy Eyeballs (RFC 6555). Therefore, it is 1043 advised that enterprises investigate the default behavior of their 1044 installed OS base and account for it during the Inventory phases of 1045 their IPv6 preparations. Furthermore, some OSes may have some 1046 transition tunneling mechanisms turned on by default and in such 1047 cases it is recommended to administratively shut down such interfaces 1048 unless required. 1050 It is important to note that it is recommended that IPv6 be deployed 1051 at the network and system infrastructure level before it is rolled 1052 out to end user devices; ensure IPv6 is running and routed on the 1053 wire, and secure and correctly monitored, before exposing IPv6 to end 1054 users. 1056 Smartphones and tablets are significant IPv6-capable platforms, 1057 depending on the support of the carrier's data network. 1059 IPv6 support for peripherals varies. Much like servers, printers are 1060 generally configured with a static address (or DHCP reservation) so 1061 clients can discover them reliably. 1063 4.4. Corporate Systems 1065 No IPv6 deployment will be successful without ensuring that all the 1066 corporate systems that an enterprise uses as part of its IT 1067 infrastructure support IPv6. Examples of such systems include, but 1068 are not limited to, email, video conferencing, telephony (VoIP), DNS, 1069 RADIUS, etc. All these systems must have their own detailed IPv6 1070 rollout plan in conjunction with the network IPv6 rollout. It is 1071 important to note that DNS is one of the main anchors in an 1072 enterprise deployment, since most end hosts decide whether or not to 1073 use IPv6 depending on the presence of IPv6 AAAA records in a reply to 1074 a DNS query. It is recommended that system administrators 1075 selectively turn on AAAA records for various systems as and when they 1076 are IPv6 enabled; care must be taken though to ensure all services 1077 running on that host name are IPv6-enabled before adding the AAAA 1078 record. Care with web proxies is advised; a mismatch in the level of 1079 IPv6 support between the client, proxy, and server can cause 1080 communication problems. All monitoring and reporting tools across 1081 the enterprise will need to be modified to support IPv6. 1083 5. IPv6-only 1085 Early IPv6 enterprise deployments have generally taken a dual-stack 1086 approach to enabling IPv6, i.e. the existing IPv4 services have not 1087 been turned off. Although IPv4 and IPv6 networks will coexist for a 1088 long time, the long term enterprise network roadmap should include 1089 steps to simplify engineering and operations by deprecating IPv4 from 1090 the dual-stack network. In some extreme cases, deploying dual-stack 1091 networks may not even be a viable option for very large enterprises 1092 due to the RFC 1918 address space not being large enough to support 1093 the network's growth. In such cases, deploying IPv6-only networks 1094 might be the only choice available to sustain network growth. In 1095 other cases, there may be elements of an otherwise dual-stack network 1096 that may be run IPv6-only. 1098 If nodes in the network don't need to talk to an IPv4-only node, then 1099 deploying IPv6-only networks should be straightforward. However, 1100 most nodes will need to communicate with some IPv4-only nodes; an 1101 IPv6-only node may therefore require a translation mechanism. As 1102 [RFC6144] points out, it is important to look at address translation 1103 as a transition strategy towards running an IPv6-only network. 1105 There are various stateless and stateful IPv4/IPv6 translation 1106 methods available today that help IPv6 to IPv4 communication. RFC 1107 6144 provides a framework for IPv4/IPv6 translation and describes in 1108 detail various scenarios in which such translation mechanisms could 1109 be used. [RFC6145] describes stateless address translation. In this 1110 mode, a specific IPv6 address range will represent IPv4 systems 1111 (IPv4-converted addresses), and the IPv6 systems have addresses 1112 (IPv4-translatable addresses) that can be algorithmically mapped to a 1113 subset of the service provider's IPv4 addresses. [RFC6146], NAT64, 1114 describes stateful address translation. As the name suggests, the 1115 translation state is maintained between IPv4 address/port pairs and 1116 IPv6 address/port pairs, enabling IPv6 systems to open sessions with 1117 IPv4 systems. [RFC6147], DNS64, describes a mechanism for 1118 synthesizing AAAA resource records (RRs) from A RRs. Together, RFCs 1119 6146 and RFC 6147 provide a viable method for an IPv6-only client to 1120 initiate communications to an IPv4-only server. As described in the 1121 assumptions section, the administrator will usually want most traffic 1122 or flows to be native, and only translate as needed. 1124 The address translation mechanisms for the stateless and stateful 1125 translations are defined in [RFC6052]. It is important to note that 1126 both of these mechanisms have limitations as to which protocols they 1127 support. For example, RFC 6146 only defines how stateful NAT64 1128 translates unicast packets carrying TCP, UDP, and ICMP traffic only. 1129 The classic problems of IPv4 NAT also apply, e.g. handling IP 1130 literals in application payloads. The ultimate choice of which 1131 translation mechanism to chose will be dictated mostly by existing 1132 operational policies pertaining to application support, logging 1133 requirements, etc. 1135 There is additional work being done in the area of address 1136 translation to enhance and/or optimize current mechanisms. For 1137 example, [I-D.xli-behave-divi] describes limitations with the current 1138 stateless translation, such as IPv4 address sharing and application 1139 layer gateway (ALG) problems, and presents the concept and 1140 implementation of dual-stateless IPv4/IPv6 translation (dIVI) to 1141 address those issues. 1143 It is worth noting that for IPv6-only access networks that use 1144 technologies such as NAT64, the more content providers (and 1145 enterprises) that make their content available over IPv6, the less 1146 the requirement to apply NAT64 to traffic leaving the access network. 1147 This particular point is important for enterprises which may start 1148 their IPv6 deployment well into the global IPv6 transition. As time 1149 progresses, and given the current growth in availability of IPv6 1150 content, IPv6-only operation using NAT64 to manage some flows will 1151 become less expensive to run versus the traditional NAT44 deployments 1152 since only IPv6 to IPv4 flows need translation. [RFC6883] provides 1153 guidance and suggestions for Internet Content Providers and 1154 Application Service Providers in this context. 1156 Enterprises should also be aware that networks may be subject to 1157 future convergence with other networks (i.e. mergers, acquisitions, 1158 etc). An enterprise considering IPv6-only operation may need to be 1159 aware that additional transition technologies and/or connectivity 1160 strategies may be required depending on the level of IPv6 readiness 1161 and deployment in the merging networking. 1163 6. Considerations For Specific Enterprises 1165 6.1. Content Delivery Networks 1167 Some guidance for Internet Content and Application Service Providers 1168 can be found in [RFC6883], which includes a dedicated section on 1169 Content Delivery Networks (CDNs). An enterprise that relies on a CDN 1170 to deliver a 'better' e-commerce experience needs to ensure that 1171 their CDN provider also supports IPv4/IPv6 traffic selection so that 1172 they can ensure 'best' access to the content. A CDN could enable 1173 external IPv6 content delivery even if the enterprise provides that 1174 content over IPv4. 1176 6.2. Data Center Virtualization 1178 IPv6 Data Center considerations are described in 1179 [I-D.ietf-v6ops-dc-ipv6]. 1181 6.3. University Campus Networks 1183 A number of campus networks around the world have made some initial 1184 IPv6 deployment. This has been encouraged by their National Research 1185 and Education Network (NREN) backbones having made IPv6 available 1186 natively since the early 2000's. Universities are a natural place 1187 for IPv6 deployment to be considered at an early stage, perhaps 1188 compared to other enterprises, as they are involved by their very 1189 nature in research and education. 1191 Campus networks can deploy IPv6 at their own pace; there is no need 1192 to deploy IPv6 across the entire enterprise from day one, rather 1193 specific projects can be identified for an initial deployment, that 1194 are both deep enough to give the university experience, but small 1195 enough to be a realistic first step. There are generally three areas 1196 in which such deployments are currently made. 1198 In particular those initial areas commonly approached are: 1200 o External-facing services. Typically the campus web presence and 1201 commonly also external-facing DNS and MX services. This ensures 1202 early IPv6-only adopters elsewhere can access the campus services 1203 as simply and as robustly as possible. 1205 o Computer science department. This is where IPv6-related research 1206 and/or teaching is most likely to occur, and where many of the 1207 next generation of network engineers are studying, so enabling 1208 some or all of the campus computer science department network is a 1209 sensible first step. 1211 o The eduroam wireless network. Eduroam [I-D.wierenga-ietf-eduroam] 1212 is the de facto wireless roaming system for academic networks, and 1213 uses 802.1X-based authentication, which is agnostic to the IP 1214 version used (unlike web-redirection gateway systems). Making a 1215 campus' eduroam network dual-stack is a very viable early step. 1217 The general IPv6 deployment model in a campus enterprise will still 1218 follow the general principles described in this document. While the 1219 above early stage projects are commonly followed, these still require 1220 the campus to acquire IPv6 connectivity and address space from their 1221 NREN (or other provider in some parts of the world), and to enable 1222 IPv6 on the wire on at least part of the core of the campus network. 1223 This implies a requirement to have an initial address plan, and to 1224 ensure appropriate monitoring and security measures are in place, as 1225 described elsewhere in this document. 1227 Campuses which have deployed to date do not use ULAs, nor do they use 1228 NPTv6. In general, campuses have very stable PA-based address 1229 allocations from their NRENs (or their equivalent). However, campus 1230 enterprises may consider applying for IPv6 PI; some have already done 1231 so. The discussions earlier in this text about PA vs. PI still 1232 apply. 1234 Finally, campuses may be more likely than many other enterprises to 1235 run multicast applications, such as IP TV or live lecture or seminar 1236 streaming, so may wish to consider support for specific IPv6 1237 multicast functionality, e.g. Embedded-RP [RFC3956] in routers and 1238 MLDv1 and MLDv2 snooping in switches. 1240 7. Security Considerations 1242 This document has multiple security sections detailing how to 1243 securely deploy an IPv6 network within an enterprise network. 1245 8. Acknowledgements 1247 The authors would like to thank Robert Sparks, Steve Hanna, Tom 1248 Taylor, Brian Haberman, Stephen Farrell, Chris Grundemann, Ray 1249 Hunter, Kathleen Moriarty, Benoit Claise, Brian Carpenter, Tina Tsou, 1250 Christian Jaquenet, and Fred Templin for their substantial comments 1251 and contributions. 1253 9. IANA Considerations 1255 There are no IANA considerations or implications that arise from this 1256 document. 1258 10. Informative References 1260 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 1261 converting network protocol addresses to 48.bit Ethernet 1262 address for transmission on Ethernet hardware", STD 37, 1263 RFC 826, November 1982. 1265 [RFC1687] Fleischman, E., "A Large Corporate User's View of IPng", 1266 RFC 1687, August 1994. 1268 [RFC1817] Rekhter, Y., "CIDR and Classful Routing", RFC 1817, August 1269 1995. 1271 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1272 E. Lear, "Address Allocation for Private Internets", BCP 1273 5, RFC 1918, February 1996. 1275 [RFC2011] McCloghrie, K., "SNMPv2 Management Information Base for 1276 the Internet Protocol using SMIv2", RFC 2011, November 1277 1996. 1279 [RFC2096] Baker, F., "IP Forwarding Table MIB", RFC 2096, January 1280 1997. 1282 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1283 Defeating Denial of Service Attacks which employ IP Source 1284 Address Spoofing", BCP 38, RFC 2827, May 2000. 1286 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1287 and M. Carney, "Dynamic Host Configuration Protocol for 1288 IPv6 (DHCPv6)", RFC 3315, July 2003. 1290 [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous 1291 Point (RP) Address in an IPv6 Multicast Address", RFC 1292 3956, November 2004. 1294 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 1295 Neighbor Discovery (SEND)", RFC 3971, March 2005. 1297 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 1298 RFC 3972, March 2005. 1300 [RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E. 1301 Castro, "Application Aspects of IPv6 Transition", RFC 1302 4038, March 2005. 1304 [RFC4057] Bound, J., "IPv6 Enterprise Network Scenarios", RFC 4057, 1305 June 2005. 1307 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1308 Addresses", RFC 4193, October 2005. 1310 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 1311 for IPv6 Hosts and Routers", RFC 4213, October 2005. 1313 [RFC4293] Routhier, S., "Management Information Base for the 1314 Internet Protocol (IP)", RFC 4293, April 2006. 1316 [RFC4292] Haberman, B., "IP Forwarding Table MIB", RFC 4292, April 1317 2006. 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, December 1346 2007. 1348 [RFC7012] Claise, B. and B. Trammell, "Information Model for IP Flow 1349 Information Export (IPFIX)", RFC 7012, September 2013. 1351 [RFC5157] Chown, T., "IPv6 Implications for Network Scanning", RFC 1352 5157, March 2008. 1354 [RFC5211] Curran, J., "An Internet Transition Plan", RFC 5211, July 1355 2008. 1357 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 1358 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 1359 March 2008. 1361 [RFC5375] Van de Velde, G., Popoviciu, C., Chown, T., Bonness, O., 1362 and C. Hahn, "IPv6 Unicast Address Assignment 1363 Considerations", RFC 5375, December 2008. 1365 [RFC5722] Krishnan, S., "Handling of Overlapping IPv6 Fragments", 1366 RFC 5722, December 2009. 1368 [RFC5798] Nadas, S., "Virtual Router Redundancy Protocol (VRRP) 1369 Version 3 for IPv4 and IPv6", RFC 5798, March 2010. 1371 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 1372 Address Text Representation", RFC 5952, August 2010. 1374 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 1375 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 1376 October 2010. 1378 [RFC6104] Chown, T. and S. Venaas, "Rogue IPv6 Router Advertisement 1379 Problem Statement", RFC 6104, February 2011. 1381 [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. 1382 Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, 1383 February 2011. 1385 [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 1386 "IPv6 Router Advertisement Options for DNS Configuration", 1387 RFC 6106, November 2010. 1389 [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 1390 IPv4/IPv6 Translation", RFC 6144, April 2011. 1392 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 1393 Algorithm", RFC 6145, April 2011. 1395 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 1396 NAT64: Network Address and Protocol Translation from IPv6 1397 Clients to IPv4 Servers", RFC 6146, April 2011. 1399 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 1400 Beijnum, "DNS64: DNS Extensions for Network Address 1401 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 1402 April 2011. 1404 [RFC6177] Narten, T., Huston, G., and L. Roberts, "IPv6 Address 1405 Assignment to End Sites", BCP 157, RFC 6177, March 2011. 1407 [RFC6164] Kohno, M., Nitzan, B., Bush, R., Matsuzaki, Y., Colitti, 1408 L., and T. Narten, "Using 127-Bit IPv6 Prefixes on Inter- 1409 Router Links", RFC 6164, April 2011. 1411 [RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the 1412 Router Control Plane", RFC 6192, March 2011. 1414 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 1415 Translation", RFC 6296, June 2011. 1417 [RFC6302] Durand, A., Gashinsky, I., Lee, D., and S. Sheppard, 1418 "Logging Recommendations for Internet-Facing Servers", BCP 1419 162, RFC 6302, June 2011. 1421 [RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node 1422 Requirements", RFC 6434, December 2011. 1424 [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with 1425 Dual-Stack Hosts", RFC 6555, April 2012. 1427 [RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational 1428 Neighbor Discovery Problems", RFC 6583, March 2012. 1430 [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, 1431 "Default Address Selection for Internet Protocol Version 6 1432 (IPv6)", RFC 6724, September 2012. 1434 [RFC6866] Carpenter, B. and S. Jiang, "Problem Statement for 1435 Renumbering IPv6 Hosts with Static Addresses in Enterprise 1436 Networks", RFC 6866, February 2013. 1438 [RFC6879] Jiang, S., Liu, B., and B. Carpenter, "IPv6 Enterprise 1439 Network Renumbering Scenarios, Considerations, and 1440 Methods", RFC 6879, February 2013. 1442 [RFC6883] Carpenter, B. and S. Jiang, "IPv6 Guidance for Internet 1443 Content Providers and Application Service Providers", RFC 1444 6883, March 2013. 1446 [RFC6959] McPherson, D., Baker, F., and J. Halpern, "Source Address 1447 Validation Improvement (SAVI) Threat Scope", RFC 6959, May 1448 2013. 1450 [RFC6964] Templin, F., "Operational Guidance for IPv6 Deployment in 1451 IPv4 Sites Using the Intra-Site Automatic Tunnel 1452 Addressing Protocol (ISATAP)", RFC 6964, May 2013. 1454 [RFC7011] Claise, B., Trammell, B., and P. Aitken, "Specification of 1455 the IP Flow Information Export (IPFIX) Protocol for the 1456 Exchange of Flow Information", STD 77, RFC 7011, September 1457 2013. 1459 [RFC7113] Gont, F., "Implementation Advice for IPv6 Router 1460 Advertisement Guard (RA-Guard)", RFC 7113, February 2014. 1462 [RFC7123] Gont, F. and W. Liu, "Security Implications of IPv6 on 1463 IPv4 Networks", RFC 7123, February 2014. 1465 [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing 1466 of IPv6 Extension Headers", RFC7045 , December 2013, 1467 . 1469 [I-D.xli-behave-divi] 1470 Bao, C., Li, X., Zhai, Y., and W. Shang, "dIVI: Dual- 1471 Stateless IPv4/IPv6 Translation", draft-xli-behave-divi-06 1472 (work in progress), January 2014. 1474 [I-D.wierenga-ietf-eduroam] 1475 Wierenga, K., Winter, S., and T. Wolniewicz, "The eduroam 1476 architecture for network roaming", draft-wierenga-ietf- 1477 eduroam-03 (work in progress), February 2014. 1479 [I-D.ietf-v6ops-dc-ipv6] 1480 Lopez, D., Chen, Z., Tsou, T., Zhou, C., and A. Servin, 1481 "IPv6 Operational Guidelines for Datacenters", draft-ietf- 1482 v6ops-dc-ipv6-01 (work in progress), February 2014. 1484 [I-D.ietf-v6ops-design-choices] 1485 Matthews, P. and V. Kuarsingh, "Design Choices for IPv6 1486 Networks", draft-ietf-v6ops-design-choices-01 (work in 1487 progress), March 2014. 1489 [I-D.ietf-opsec-v6] 1490 Chittimaneni, K., Kaeo, M., and E. Vyncke, "Operational 1491 Security Considerations for IPv6 Networks", draft-ietf- 1492 opsec-v6-04 (work in progress), October 2013. 1494 [I-D.ietf-opsec-ipv6-host-scanning] 1495 Gont, F. and T. Chown, "Network Reconnaissance in IPv6 1496 Networks", draft-ietf-opsec-ipv6-host-scanning-04 (work in 1497 progress), June 2014. 1499 [I-D.liu-bonica-dhcpv6-slaac-problem] 1500 Liu, B. and R. Bonica, "DHCPv6/SLAAC Address Configuration 1501 Interaction Problem Statement", draft-liu-bonica-dhcpv6- 1502 slaac-problem-02 (work in progress), September 2013. 1504 [I-D.ietf-v6ops-ula-usage-recommendations] 1505 Liu, B. and S. Jiang, "Considerations of Using Unique 1506 Local Addresses", draft-ietf-v6ops-ula-usage- 1507 recommendations-03 (work in progress), July 2014. 1509 [I-D.ietf-opsec-vpn-leakages] 1510 Gont, F., "Layer-3 Virtual Private Network (VPN) tunnel 1511 traffic leakages in dual- stack hosts/networks", draft- 1512 ietf-opsec-vpn-leakages-06 (work in progress), April 2014. 1514 [SMURF] "CERT Advisory CA-1998-01 Smurf IP Denial-of-Service 1515 Attacks", 1516 . 1518 [CYMRU] "THE BOGON REFERENCE", 1519 . 1521 Authors' Addresses 1522 Kiran K. Chittimaneni 1523 Dropbox Inc. 1524 1600 Amphitheater Pkwy 1525 Mountain View, California CA 94043 1526 USA 1528 Email: kk@dropbox.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 1538 Lee Howard 1539 Time Warner Cable 1540 13820 Sunrise Valley Drive 1541 Herndon, VA 20171 1542 US 1544 Phone: +1 703 345 3513 1545 Email: lee.howard@twcable.com 1547 Victor Kuarsingh 1548 Dyn Inc 1549 150 Dow Street 1550 Manchester, NH 1551 US 1553 Email: victor@jvknet.com 1555 Yanick Pouffary 1556 Hewlett Packard 1557 950 Route Des Colles 1558 Sophia-Antipolis 06901 1559 France 1561 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