idnits 2.17.1 draft-arkko-ipv6-transition-guidelines-14.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 (December 28, 2010) is 4840 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC5218' is defined on line 862, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3484 (Obsoleted by RFC 6724) == Outdated reference: A later version (-05) exists of draft-arkko-dual-stack-extra-lite-03 == Outdated reference: A later version (-05) exists of draft-arkko-ipv6-only-experience-00 == Outdated reference: A later version (-12) exists of draft-ietf-behave-ftp64-05 == Outdated reference: A later version (-05) exists of draft-ietf-intarea-shared-addressing-issues-02 == Outdated reference: A later version (-11) exists of draft-ietf-softwire-dual-stack-lite-06 -- Obsolete informational reference (is this intentional?): RFC 6036 (Obsoleted by RFC 9386) -- Obsolete informational reference (is this intentional?): RFC 2766 (Obsoleted by RFC 4966) == Outdated reference: A later version (-04) exists of draft-ietf-v6ops-tunnel-security-concerns-03 == Outdated reference: A later version (-05) exists of draft-ietf-v6ops-v6-in-mobile-networks-02 Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Arkko 3 Internet-Draft Ericsson 4 Intended status: Informational F. Baker 5 Expires: July 1, 2011 Cisco Systems 6 December 28, 2010 8 Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment 9 draft-arkko-ipv6-transition-guidelines-14 11 Abstract 13 The Internet continues to grow beyond the capabilities of IPv4. An 14 expansion in the address space is clearly required. With its 15 increase in the number of available prefixes and addresses in a 16 subnet, and improvements in address management, IPv6 is the only real 17 option on the table. Yet, IPv6 deployment requires some effort, 18 resources, and expertise. The availability of many different 19 deployment models is one reason why expertise is required. This 20 document discusses the IPv6 deployment models and migration tools, 21 and recommends ones that have been found to work well in operational 22 networks in many common situations. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on July 1, 2011. 41 Copyright Notice 43 Copyright (c) 2010 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. Principles . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 3.2. Choosing a Deployment Model . . . . . . . . . . . . . . . 6 63 4. Guidelines for IPv6 Deployment . . . . . . . . . . . . . . . . 8 64 4.1. Native Dual Stack . . . . . . . . . . . . . . . . . . . . 8 65 4.2. Crossing IPv4 Islands . . . . . . . . . . . . . . . . . . 10 66 4.3. IPv6-Only Core Network . . . . . . . . . . . . . . . . . . 11 67 4.4. IPv6-only Deployment . . . . . . . . . . . . . . . . . . . 12 68 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 14 69 6. Further Reading . . . . . . . . . . . . . . . . . . . . . . . 15 70 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 71 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 72 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 73 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 74 9.2. Informative References . . . . . . . . . . . . . . . . . . 17 75 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 20 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 78 1. Introduction 80 The Internet continues to grow beyond the capabilities of IPv4. The 81 tremendous success of the Internet has strained the IPv4 address 82 space, which is no longer sufficient to fuel future growth. At the 83 time of this writing, August 2010, the IANA "free pool" contains only 84 14 unallocated unicast IPv4 /8 prefixes. Credible estimates based on 85 past behavior suggest that the RIRs will exhaust their remaining 86 address space by early 2012, apart from the development of a market 87 in IPv4 address space. An expansion in the address space is clearly 88 required. With its increase in the number of available prefixes and 89 addresses in a subnet, and improvements in address management, IPv6 90 is the only real option on the table. 92 John Curran, in his Internet Transition Plan [RFC5211], gives 93 estimated dates for significant points in the transition; while the 94 tail of the process will likely be long, it is clear that deployment 95 is a present reality and requirement. 97 Accordingly, many organizations have employed or are planning to 98 employ IPv6 in their networks. Yet, IPv6 deployment requires some 99 effort, resources, and expertise. This is largely a natural part of 100 maintaining and evolving a network: changing requirements are taken 101 into account in normal planning, procurement and update cycles. Very 102 large networks have successfully adopted IPv6 alongside IPv4, with 103 surprisingly little effort. 105 However, in order to successfully make this transition, some amount 106 of new expertise is required. Different types of experience will be 107 required: basic understanding of IPv6 mechanisms, debugging tools, 108 product capabilities and caveats when used with IPv6, and so on. The 109 availability of many different IPv6 deployment models and tools is an 110 additional reason why expertise is required. These models and tools 111 have been developed over the years at the IETF, some for specific 112 circumstances and others for more general use. They differ greatly 113 in their principles of operation. Over time, views about the best 114 ways to employ the tools have evolved. Given the number of options, 115 network managers are understandably confused. They need guidance on 116 recommended approaches to IPv6 deployment. 118 The rest of this document is organized as follows. Section 2 119 introduces some terminology, Section 3 discusses some of the general 120 principles behind choosing particular deployment models and tools, 121 Section 4 goes through the recommended deployment models for common 122 situations, and Section 5 provides some concluding remarks about the 123 choice between these models. 125 Many networks can follow one of the four scenarios described in this 126 document. However, variations will certainly occur in the details, 127 and there will be questions such as the particular choice of 128 tunneling solution for which there is no "one size fits all" answer. 129 Network managers must each take the responsibility of choosing the 130 best solution for their own case. This document does not attempt to 131 provide guidance for all possible networking situations. Also, a 132 systematic operational plan for the transition is required, but the 133 details depend entirely on the individual network. 135 2. Terminology 137 In this document, the following terms are used. 139 IPv4/IPv4 NAT: refers to any IPv4-to-IPv4 network address 140 translation algorithm, both "Basic NAT" and "Network Address/Port 141 Translator (NAPT)", as defined by [RFC2663]. 143 Dual Stack: refers to a technique for providing complete support for 144 both Internet protocols -- IPv4 and IPv6 -- in hosts and routers 145 [RFC4213]. 147 Dual Stack Lite: also called "DS-Lite", refers to a technique that 148 employs tunneling and IPv4/IPv4 NAT to provide IPv4 connectivity 149 over IPv6 networks [I-D.ietf-softwire-dual-stack-lite]. 151 IPv4-only domain: as defined in [I-D.ietf-behave-v6v4-framework], a 152 routing domain in which applications can only use IPv4 to 153 communicate, whether due to host limitations, application 154 limitations, or network limitations. 156 IPv6-only domain: as defined in [I-D.ietf-behave-v6v4-framework], a 157 routing domain in which applications can only use IPv6 to 158 communicate, whether due to host limitations, application 159 limitations, or network limitations. 161 NAT-PT: refers to a specific, old design of a Network Address 162 Translator - Protocol Translator defined in [RFC2766] and 163 deprecated due to the reasons stated in [RFC4966]. 165 3. Principles 167 The primary goal is to facilitate the continued growth of the 168 networking industry and deployment of Internet technology at 169 relatively low capital and operational expense without destabilizing 170 deployed services or degrading customer experience. This is at risk 171 with IPv4 due to the address runout; economics teaches us that a 172 finite resource, when stressed, becomes expensive, either in the 173 actual cost of the resource or in the complexity of the technology 174 and processes required to manage it. It is also at risk while both 175 IPv4 and IPv6 are deployed in parallel, as it costs more to run two 176 technologies than one. To this end, since IPv4 clearly will not 177 scale to meet our insatiable requirements, the primary technical 178 goals are the global deployment of IPv6 both in the network, in its 179 service infrastructure, and by applications, resulting in the end of 180 the requirement to deploy two IP versions and the obsolescence of 181 transitional mechanisms. Temporary goals in support of this focus on 182 enabling parts of the Internet to employ IPv6 and disable IPv4 before 183 the entire Internet has done so. 185 3.1. Goals 187 The end goal is network-wide native IPv6 deployment, resulting in the 188 obsolescence of transitional mechanisms based on encapsulation, 189 tunnels, or translation, and also resulting in the obsolescence of 190 IPv4. Transition mechanisms, taken as a class, are a means to an 191 end, to simplify the process for the network administration. 193 However, the goals, constraints, and opportunities for IPv6 194 deployment differ from one case to another. There is no single right 195 model for IPv6 deployment, just like there is no one and only model 196 for IPv4 network design. Some guidelines can be given, however. 197 Common deployment models that have been found to work well are 198 discussed in Section 4, and the small set of standardized IETF 199 migration tools support these models. But first it may be useful to 200 discuss some general principles that guide our thinking about what is 201 a good deployment model. 203 It is important to start the deployment process in a timely manner. 204 Most of the effort is practical -- network audit, network component 205 choices, network management, planning, implementation -- and at the 206 time of this writing, reasonably easily achievable. There is no 207 particular advantage to avoiding dealing with IPv6 as part of the 208 normal network planning cycle. The migration tools already exist, 209 and while additional features continue to be developed it is not 210 expected that they radically change what networks have to do. In 211 other words, there is no point in waiting for an improved design. 213 There are only a few exceptional networks where co-existence with 214 IPv4 is not a consideration at all. These networks are typically new 215 deployments, strictly controlled by a central authority, and have no 216 need to deal with legacy devices. For example, specialized machine- 217 to-machine networks that communicate only to designated servers, such 218 as Smart Grids, can easily be deployed as IPv6-only networks. Mobile 219 telephone network operators, especially those using 3GPP, have 220 seriously considered IPv6-only operation, and some have deployed it. 221 Research networks that can be separated from the IPv4 Internet to 222 find out what happens are also a candidate. In most other networks 223 IPv4 has to be considered. A typical requirement is that older, 224 IPv4-only applications, systems, or services must be accommodated. 225 Most networks that cross administrative boundaries or allow end user 226 equipment have such requirements. Even in situations where the 227 network consists of only new, IPv6-capable devices it is typically 228 required that the devices can communicate with the IPv4 Internet. 230 It is expected that after a period of supporting both IPv4 and IPv6, 231 IPv4 can eventually be turned off. This should happen gradually. 232 For instance, a service provider network might stop providing IPv4 233 service within its own network, while still allowing its IPv6 234 customers to access the rest of the IPv4 Internet through overlay, 235 proxy, or translation services. Regardless of progress in supporting 236 IPv6, it is widely expected that some legacy applications and some 237 networks will continue to run only over IPv4 for many years. All 238 deployment scenarios need to deal with this situation. 240 3.2. Choosing a Deployment Model 242 The first requirement is that the model or tool actually allows 243 communications to flow and services to appropriately be delivered to 244 customers without perceived degradation. While this sounds too 245 obvious to even state, it is sometimes not easy to ensure that a 246 proposed model does not have failure modes related to supporting 247 older devices, for instance. A network that is not serving all of 248 its users is not fulfilling its task. 250 The ability to communicate is also far more important than fine- 251 grained performance differences. In general, it is not productive to 252 focus on optimization of a design that is designed to be temporary, 253 such as a migration solution necessarily is. Consequently, existing 254 tools are often preferred over new ones, even if for some specific 255 circumstance it would be possible to construct a slightly more 256 efficient design. 258 Similarly, migration tools that can be disposed after a period of co- 259 existence are preferred over tools that require more permanent 260 changes. Such permanent changes may incur costs even after the 261 transition to IPv6 has been completed. 263 Looking back on the deployment of Internet technology, some of the 264 factors that have been important for success include 265 [RFC5218, Baker.Shanghai] 266 o The ability to offer a valuable service. In the case of the 267 Internet, connectivity has been this service. 269 o The ability to deploy the solution in an incremental fashion. 271 o Simplicity. This has been a key factor in making it possible for 272 all types of devices to support the Internet protocols. 274 o Openly available implementations. These make it easier for 275 researchers, start-ups and others to build on or improve existing 276 components. 278 o The ability to scale. The IPv4 Internet grew far larger than its 279 original designers had anticipated, and scaling limits only became 280 apparent 20-30 years later. 282 o The design supports robust interoperability rather than mere 283 correctness. This is important in order to ensure that the 284 solution works in different circumstances and in an imperfectly 285 controlled world. 287 Similar factors are also important when choosing IPv6 migration 288 tools. Success factors should be evaluated in the context of a 289 migration solution. For instance, incremental deployability and lack 290 of dependencies to components that are under someone else's control 291 are key factors. 293 It is also essential that any chosen designs allow the network to be 294 maintained, serviced, diagnosed and measured. The ability of the 295 network to operate under many different circumstances and surprising 296 conditions is a key. Any large network that employs brittle 297 components will incur significant support costs. 299 Properly executed IPv6 deployment normally involves a step-wise 300 approach where individual functions or parts of the network are 301 updated at different times. For instance, IPv6 connectivity has to 302 be established and tested before DNS entries with IPv6 addresses can 303 be provisioned. Or specific services can be moved to support IPv6 304 earlier than others. In general, most deployment models employ a 305 very similar network architecture for both IPv4 and IPv6. The 306 principle of changing only the minimum amount necessary is applied 307 here. As a result, some features of IPv6, such as the ability to 308 have an effectively unlimited number of hosts on a subnet, may not be 309 available in the short term. 311 4. Guidelines for IPv6 Deployment 313 This section presents a number of common scenarios along with 314 recommended deployment tools for them. We start from the most 315 obvious deployment situation where native connectivity is available 316 and both IP versions are used. Since native IPv6 connectivity is not 317 available in all networks, our second scenario looks at ways of 318 arranging such connectivity over the IPv4 Internet. The third 319 scenario is more advanced and looks at a service provider network 320 that runs only on IPv6 but which is still capable of providing both 321 IPv6 and IPv4 services. The fourth and most advanced scenario 322 focuses on translation, at the application or the network layer. 324 Note that there are many other possible deployment models and 325 existing specifications to support such models. These other models 326 are not necessarily frowned upon. However, they are not expected to 327 be the mainstream deployment models, and consequently, the associated 328 specifications are typically not IETF standards track RFCs. Network 329 managers should not adopt these non-mainstream models lightly, 330 however, as there is little guarantee that they work well. There are 331 also models that are believed to be problematic. An older model to 332 IPv6 - IPv4 translation (NAT-PT) [RFC2766] suffers from a number of 333 drawbacks arising from, for example, its attempt to capture DNS 334 queries on path [RFC4966]. Another example regarding the preference 335 to employ tunneling instead of double translation will be discussed 336 later in this document. 338 4.1. Native Dual Stack 340 The simplest deployment model is Dual Stack: one turns on IPv6 341 throughout one's existing IPv4 network and allows applications using 342 the two protocols to operate as ships in the night. This model is 343 applicable to most networks - home, enterprise, service provider, or 344 content provider network. 346 The purpose of this model is to support any type of device and 347 communication, and to make it an end-to-end choice which IP version 348 is used between the peers. There are minimal assumptions about the 349 capabilities and configuration of hosts in these networks. Native 350 connectivity avoids problems associated with the configuration of 351 tunnels and Maximum Transfer Unit (MTU) settings. As a result, these 352 networks are robust and reliable. Accordingly, this is the 353 recommended deployment model for most networks, and supported by IETF 354 standards such as dual stack [RFC4213] and address selection 355 [RFC3484]. Similarly, while there are some remaining challenges, 356 this model is also preferred by many service providers and network 357 managers [RFC6036] [I-D.arkko-ipv6-only-experience]. 359 The challenges associated with this model are two-fold. First, while 360 dual-stack allows each individual network to deploy IPv6 on their 361 own, actual use still requires participation from all parties between 362 the peers. For instance, the peer must be reachable over IPv6, have 363 an IPv6 address to itself, and advertise such an address in the 364 relevant naming service (such as the DNS). This can create a 365 situation where IPv6 has been turned on in a network but there is 366 little actual traffic. One direct way to affect this situation is to 367 ensure that major destinations of traffic are prepared to receive 368 IPv6 traffic. Current Internet traffic is highly concentrated on 369 selected content provider networks, and making a change in even a 370 small number of these networks can have significant effects. This 371 was recently observed when YouTube started supporting IPv6 372 [networkworld.youtube]. There are scenarios where these means are 373 insufficient. The following sections discuss deployment models that 374 enable parts of the network deploy IPv6 faster than other parts. 376 The second challenge is that not all applications deal gracefully 377 with situations where one of the alternative destination addresses 378 works unreliably. For instance, if IPv6 connectivity is unreliable 379 it may take a long time for some applications to switch over to IPv4. 380 As a result, many content providers are shying away from advertising 381 IPv6 addresses in DNS. This in turn exacerbates the first challenge. 382 Long term, the use of modern application toolkits and APIs solves 383 this problem. In the short term some content providers and user 384 network managers have made a mutual agreement to resolve names to 385 IPv6 addresses. Such agreements are similar to peering agreements 386 and have been seen as necessary by many content providers. These 387 "whitelisting" practices have some downsides as well, however. In 388 particular, they create a dependency on an external party for moving 389 traffic to IPv6. Nevertheless, there are many types of traffic in 390 the Internet and only some of it requires such careful coordination. 391 Popular peer-to-peer systems can automatically and reliably employ 392 IPv6 connectivity where it is available, for instance. 394 Despite these challenges the native dual stack connectivity model 395 remains the recommended approach. It is responsible for a large part 396 of the progress on world-wide IPv6 deployment to date. The largest 397 IPv6 networks; notably national research and education networks, 398 Internet II, Renater, and others, employ this approach. 400 The original intent of dual stack was to deploy both IP versions 401 alongside each other before IPv4 addresses were to run out. As we 402 know, this never happened and deployment now has to take place with 403 limited IPv4 addresses. Employing dual stack together with a 404 traditional IPv4 address translator (IPv4/IPv4 NAT) is a very common 405 configuration. If the address translator is acceptable for the 406 network from a pure IPv4 perspective, this model can be recommended 407 from a dual stack perspective as well. The advantage of IPv6 in this 408 model is that it allows direct addressing of specific nodes in the 409 network, creating a contrast to the translated IPv4 service as noted 410 in [RFC2993] and [I-D.ietf-intarea-shared-addressing-issues]. As a 411 result, it allows the construction of IPv6-based applications that 412 offer more functionality. 414 There may also be situations where a traditional IPv4 address 415 translator is no longer sufficient. For instance, in typical 416 residential networks, each subscriber is given one global IPv4 417 address, and the subscriber's IPv4/IPv4 NAT device may use this 418 address with as many devices as it can handle. As IPv4 address space 419 becomes more constrained and without substantial movement to IPv6, it 420 is expected that service providers will be pressured to assign a 421 single global IPv4 address to multiple subscribers. Indeed, in some 422 deployments this is already the case. The dual stack model is still 423 applicable even in these networks, but the IPv4/IPv4 Network Address 424 Transition (NAT) functionality may need to be relocated and enhanced. 425 On some networks it is possible to employ overlapping private address 426 space [I-D.miles-behave-l2nat] [I-D.arkko-dual-stack-extra-lite]. 427 Other networks may require a combination of IPv4/IPv4 NAT 428 enhancements and tunneling. These scenarios are discussed further in 429 Section 4.3. 431 4.2. Crossing IPv4 Islands 433 Native IPv6 connectivity is not always available, but fortunately it 434 can be established using tunnels. Tunneling introduces some 435 additional complexity and has a risk of MTU or other mis- 436 configurations. However, its benefit is that it decouples addressing 437 inside and outside the tunnel, making it easy to deploy IPv6 without 438 having to modify routers along the path. Tunneling should be used 439 when native connectivity can not be established, such as when 440 crossing another administrative domain or a router that cannot be 441 easily re-configured. 443 There are several types of tunneling mechanisms, including manually 444 configured IPv6-over-IPv4 tunnels [RFC4213], 6to4 [RFC3056], 445 automatic host-based tunnels [RFC4380], tunnel brokers [RFC3053], 446 running IPv6 over MPLS with IPv6 Provider Edge Routers (6PE) 447 [RFC4798], the use of Virtual Private Network (VPN) or mobility 448 tunnels to carry both IPv4 and IPv6 [RFC4301] [RFC5454] [RFC5555] 449 [RFC5844] and many others. More advanced solutions provide a mesh- 450 based framework of tunnels [RFC5565]. 452 On a managed network, there are no major challenges with tunneling 453 beyond the possible configuration and MTU problems. Tunneling is 454 very widely deployed both for IPv6 connectivity and other reasons, 455 and well understood. In general, the IETF recommends that tunneling 456 be used if it is necessary to cross a segment of IP version X when 457 communicating from IP version Y to Y. An alternative design would be 458 to employ protocol translation twice. However, this design involves 459 problems similar to those created by IPv4 address translation and is 460 largely untried technology in any larger scale. 462 On an unmanaged network there have been a number of problems, 463 however. In general, solutions aimed at early adopters (such as 464 6to4) have at times caused IPv6 connectivity to appear to be 465 available on a network when in fact there is no connectivity. This 466 in turn has lead to need by the content providers to serve IPv6 467 results for DNS queries only for trusted peers with known high- 468 quality connectivity. 470 The IPv6 Rapid Deployment (6RD) [RFC5969] approach is a newer version 471 of the 6to4 tunneling solution without the above drawbacks. It 472 offers systematic IPv6 tunneling over IPv4 across an ISP, 473 correspondence between IPv4 and IPv6 routing, and can be deployed 474 within an ISP without the need to rely on other parties. 476 4.3. IPv6-Only Core Network 478 An emerging deployment model uses IPv6 as the dominant protocol at a 479 service provider network, and tunnels IPv4 through this network in a 480 manner converse to the one described in the previous section. There 481 are several motivations for choosing this deployment model: 483 o There may not be enough public or private IPv4 addresses to 484 support network management functions in an end-to-end fashion, 485 without segmenting the network into small parts with overlapping 486 address space. 488 o IPv4 address sharing among subscribers may involve new address 489 translation nodes within the service provider's network. IPv6 can 490 be used to reach these nodes. Normal IPv4 routing is insufficient 491 for this purpose, as the same addresses would be used in several 492 parts of the network. 494 o It may be simpler for the service provider to employ a single- 495 version network. 497 The recommended tool for this model is Dual Stack Lite 498 [I-D.ietf-softwire-dual-stack-lite]. Dual Stack Lite provides both 499 relief for IPv4 address shortage and makes forward progress on IPv6 500 deployment, by moving service provider networks and IPv4 traffic over 501 IPv6. Given the IPv6 connectivity that Dual Stack Lite runs over, it 502 becomes easy to provide IPv6 connectivity all the way to the end 503 users as well. 505 4.4. IPv6-only Deployment 507 Our final deployment model breaks the requirement that all parties 508 must upgrade to IPv6 before any end-to-end communications use IPv6. 509 This model makes sense when the following conditions are met: 511 o There is a fact or requirement that there be an IPv4-only domain 512 and an IPv6-only domain. 514 o There is a requirement that hosts in the IPv4-only domain access 515 servers or peers in the IPv6-only domain and vice versa. 517 This deployment model would fit well, for instance, a corporate or 518 mobile network that offers IPv6-only networking but where users still 519 wish to access content from the IPv4 Internet. 521 When we say "IPv4-only" or "IPv6-only", we mean that the applications 522 can communicate only using IPv4 or IPv6; this might be due to lack of 523 capabilities in the applications, host stacks, or the network; the 524 effect is the same. The reason to switch to an IPv6-only network may 525 be a desire to test such a configuration, or to simplify the network. 526 It is expected that as IPv6 deployment progresses, the second reason 527 will become more prevalent. One particular reason for considering an 528 IPv6-only domain is the effect of overlapping private address space 529 to applications. This is important in networks that have exhausted 530 both public and private IPv4 address space and where arranging an 531 IPv6-only network is easier than dealing with the overlapping address 532 space in applications. 534 Note that the existence of an IPv6-only domain requires that all 535 devices are indeed IPv6-capable. In today's mixed networking 536 environments with legacy devices this can not always be guaranteed. 537 But it can be arranged in networks where all devices are controlled 538 by a central authority. For instance, newly built corporate networks 539 can ensure that the latest device versions are in use. Some networks 540 can also be engineered to support different services over an 541 underlying network and as such, can support IPv6-only networking more 542 easily. For instance, a cellular network may support IPv4-only 543 connectivity for the installed based of existing devices and IPv6- 544 only connectivity for incremental growth with newer IPv6 capable 545 handsets. Similarly, a broadband ISP may support dual stack 546 connectivity for customers that require both IPv4 and IPv6, and offer 547 IPv6-only and NAT64 service for others. In the case of 3GPP and 548 DOCSIS 3.0 access networks, the underling access network architecture 549 allows the flexibility to run different services in parallel to suit 550 the various needs of the customer and the network operator. 552 It is also necessary for the network operator to have some level of 553 understanding of what applications are used in the network, enabling 554 him to ensure that any communication exchange is in fact predictable, 555 capable of using IPv6, and translatable. In such a case, full 556 interoperability can be expected. This has been demonstrated with 557 some mobile devices, for instance. Note that the requirements on 558 applications are similar to those in networks employing IPv4 NAT 559 technology. 561 One obvious IPv6-only deployment approach applies to applications 562 that include proxies or relays. One might position a web proxy, a 563 mail server, or a SIP (Session Initiation Protocol) and media stream 564 back-to-back user agent across the boundary between IPv4 and IPv6 565 domains, so that the application terminates IPv4 sessions on one side 566 and IPv6 sessions on the other. Doing this preserves the end-to-end 567 nature of communications from the gateway to the communicating peer. 568 For obvious reasons, this solution is preferable to the 569 implementation of Application Layer Gateways in network layer 570 translators. 572 The other approach is network layer IPv4/IPv6 translation as 573 described in IPv4/IPv6 Translation [I-D.ietf-behave-v6v4-framework] 574 [I-D.ietf-behave-v6v4-xlate] [I-D.ietf-behave-v6v4-xlate-stateful] 575 [RFC6052] [I-D.ietf-behave-dns64] [I-D.ietf-behave-ftp64]. IPv4/IPv6 576 translation at the network layer is similar in its advantages and 577 disadvantages to IPv4/IPv4 translation. It allows a network to 578 provide two types of services to IPv6-only hosts: 580 o a relatively small set of systems may be configured with IPv4- 581 mapped addresses, enabling stateless interoperation between IPv4- 582 only and IPv6-only domains, each of which can use the other as 583 peers or servers, and 585 o a larger set of systems with global IPv6 addresses, which can 586 access IPv4 servers using stateful translation but which are 587 inaccessible as peers or servers from the IPv4-only domain. 589 The former service is used today in some university networks, and the 590 latter in some corporate and mobile networks. The stateless service 591 is naturally better suited for servers, and the stateful service for 592 large numbers of client devices. The latter case occurs typically in 593 a public network access setting. The two services can of course also 594 be used together. In this scenario, network layer translation 595 provides for straightforward services for most applications crossing 596 the IPv4-only/IPv6-only boundary. 598 One challenge in this model is that as long as IPv4 addresses are 599 still shared, issues similar to those caused by IPv4 NATs will still 600 appear [I-D.ietf-intarea-shared-addressing-issues]. Another 601 challenge relates to communications involving IPv4 referrals. IPv4- 602 literals within certain protocols and formats such at HTML, will fail 603 when passed to IPv6-only hosts since the host does not have an IPv4 604 address to source the IPv4 communications or an IPv4 route. 605 Measurements on the public internet show that literals appear in a 606 tiny but measurable part of web pages 607 [I-D.arkko-ipv6-only-experience], though whether this poses a 608 practical problem is debatable. If this poses a particular problem 609 for the types of applications in use, proxy configurations could be 610 modified to use a proxy for the traffic in question, hosts could be 611 modified to understand how they can map IPv4 literals to IPv6 612 addresses, or native dual stack could be employed instead. 614 5. Conclusions 616 The fundamental recommendation is to turn IPv6 on. Section 4 617 described four deployment models to do that, presented in rough order 618 of occurrence in the world at the time of this writing. The first 619 models are the most widely deployed today. All four models are 620 recommended by the IETF, though again the first models should be 621 considered first. 623 As noted in Section 1, variations occur in details and network 624 managers are ultimately in charge of choosing the best solution for 625 their own case. Benefits and challenges discussed in the previous 626 sections should be considered when weighing deployment alternatives. 627 The transition mechanisms that operators have deployed have been a 628 mixed blessing; native dual stack deployments are not used to their 629 full extent if peers have not upgraded, tunnel mechanisms that don't 630 follow the routing of the underlying network have been problematic, 631 and translation has its faults as well. Nevertheless, operators have 632 successfully deployed very large networks with these models. 634 Some additional considerations are discussed below. 636 o There is a tradeoff between ability to connect as many different 637 types of devices as possible and the ability to move forward with 638 deployment as independently as possible. As an example, native 639 dual stack ensures best connectivity but requires updates in peer 640 systems before actual traffic flows over IPv6. Conversely, IPv6- 641 only networks are very sensitive to what kind of devices they can 642 support, but can be deployed without any expectation of updates on 643 peer systems. 645 o Greenfield networks and networks with existing IPv4 devices and 646 users need to be treated differently. In the latter case turning 647 on IPv6 in addition to IPv4 seems the rational choice. In the 648 former case an IPv6-only model may make sense. 650 o The right deployment model choices also vary as time goes by. For 651 instance, a tunneling solution that makes sense today may become a 652 native dual stack solution as the network and devices in the 653 network evolve. Or an IPv6-only network becomes feasible when a 654 sufficient fraction of client devices become IPv6-enabled. 656 No matter which deployment model is chosen, many of the important 657 implications of IPv6 deployment are elsewhere within the network: 658 IPv6 needs to be taken into account in network management systems and 659 operations, address assignments, service agreements, firewalls and 660 intrusion detection systems, and so on. 662 6. Further Reading 664 Various aspects of IPv6 deployment have been covered in several 665 documents. Of particular interest may be the basic dual stack 666 definition [RFC4213], application aspects [RFC4038], deployment in 667 Internet Service Provider Networks [RFC4029] [RFC6036], deployment in 668 enterprise networks [RFC4057] [RFC4852], IPv6-only deployment 669 [I-D.arkko-ipv6-only-experience], and considerations in specific 670 access networks such as cellular networks [RFC3314] [RFC3574] 671 [RFC4215] [I-D.ietf-v6ops-v6-in-mobile-networks] or 802.16 networks 672 [RFC5181]. 674 This document provides general guidance on IPv6 deployment models 675 that have been found suitable for most organizations. The purpose of 676 this document is not to enumerate all special circumstances that may 677 warrant other types of deployment models or the details of the 678 necessary transition tools. Many of the special cases and details 679 have been discussed in the above documents. 681 7. Security Considerations 683 While there are detailed differences between the security properties 684 and vulnerabilities between IPv4 and IPv6, in general they provide a 685 very similar level of security, and are subject to the same threats. 686 With both protocols, specific security issues are more likely to be 687 found at the practical level than in the specifications. The 688 practical issues include, for instance, bugs or available security 689 mechanisms on a given product. When deploying IPv6, it is important 690 to ensure that the necessary security capabilities exist on the 691 network components even when dealing with IPv6 traffic. For 692 instance, firewall capabilities have often been a challenge in IPv6 693 deployments. 695 This document has no impact on the security properties of specific 696 IPv6 transition tools. The security considerations relating to the 697 transition tools are described in the relevant documents, for 698 instance, [RFC4213] [I-D.ietf-behave-dns64] 699 [I-D.ietf-softwire-dual-stack-lite] 700 [I-D.ietf-v6ops-tunnel-security-concerns]. 702 8. IANA Considerations 704 This document has no IANA implications. 706 9. References 708 9.1. Normative References 710 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 711 Translator (NAT) Terminology and Considerations", 712 RFC 2663, August 1999. 714 [RFC3484] Draves, R., "Default Address Selection for Internet 715 Protocol version 6 (IPv6)", RFC 3484, February 2003. 717 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 718 for IPv6 Hosts and Routers", RFC 4213, October 2005. 720 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 721 Internet Protocol", RFC 4301, December 2005. 723 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 724 Network Address Translations (NATs)", RFC 4380, 725 February 2006. 727 [RFC5454] Tsirtsis, G., Park, V., and H. Soliman, "Dual-Stack Mobile 728 IPv4", RFC 5454, March 2009. 730 [RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and 731 Routers", RFC 5555, June 2009. 733 [RFC5565] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh 734 Framework", RFC 5565, June 2009. 736 9.2. Informative References 738 [I-D.arkko-dual-stack-extra-lite] 739 Arkko, J. and L. Eggert, "Scalable Operation of Address 740 Translators with Per-Interface Bindings", 741 draft-arkko-dual-stack-extra-lite-03 (work in progress), 742 October 2010. 744 [I-D.arkko-ipv6-only-experience] 745 Arkko, J. and A. Keranen, "Experiences from an IPv6-Only 746 Network", draft-arkko-ipv6-only-experience-00 (work in 747 progress), July 2010. 749 [I-D.arkko-townsley-coexistence] 750 Arkko, J. and M. Townsley, "IPv4 Run-Out and IPv4-IPv6 Co- 751 Existence Scenarios", draft-arkko-townsley-coexistence-06 752 (work in progress), October 2010. 754 [I-D.ietf-behave-v6v4-framework] 755 Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 756 IPv4/IPv6 Translation", 757 draft-ietf-behave-v6v4-framework-10 (work in progress), 758 August 2010. 760 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 761 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 762 October 2010. 764 [I-D.ietf-behave-v6v4-xlate] 765 Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 766 Algorithm", draft-ietf-behave-v6v4-xlate-23 (work in 767 progress), September 2010. 769 [I-D.ietf-behave-v6v4-xlate-stateful] 770 Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful 771 NAT64: Network Address and Protocol Translation from IPv6 772 Clients to IPv4 Servers", 773 draft-ietf-behave-v6v4-xlate-stateful-12 (work in 774 progress), July 2010. 776 [I-D.ietf-behave-dns64] 777 Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum, 778 "DNS64: DNS extensions for Network Address Translation 779 from IPv6 Clients to IPv4 Servers", 780 draft-ietf-behave-dns64-11 (work in progress), 781 October 2010. 783 [I-D.ietf-behave-ftp64] 784 Beijnum, I., "An FTP ALG for IPv6-to-IPv4 translation", 785 draft-ietf-behave-ftp64-05 (work in progress), 786 September 2010. 788 [I-D.ietf-intarea-shared-addressing-issues] 789 Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 790 Roberts, "Issues with IP Address Sharing", 791 draft-ietf-intarea-shared-addressing-issues-02 (work in 792 progress), October 2010. 794 [I-D.ietf-softwire-dual-stack-lite] 795 Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 796 Stack Lite Broadband Deployments Following IPv4 797 Exhaustion", draft-ietf-softwire-dual-stack-lite-06 (work 798 in progress), August 2010. 800 [RFC6036] Carpenter, B. and S. Jiang, "Emerging Service Provider 801 Scenarios for IPv6 Deployment", RFC 6036, October 2010. 803 [I-D.miles-behave-l2nat] 804 Miles, D. and M. Townsley, "Layer2-Aware NAT", 805 draft-miles-behave-l2nat-00 (work in progress), 806 March 2009. 808 [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address 809 Translation - Protocol Translation (NAT-PT)", RFC 2766, 810 February 2000. 812 [RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, 813 November 2000. 815 [RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6 816 Tunnel Broker", RFC 3053, January 2001. 818 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 819 via IPv4 Clouds", RFC 3056, February 2001. 821 [RFC3314] Wasserman, M., "Recommendations for IPv6 in Third 822 Generation Partnership Project (3GPP) Standards", 823 RFC 3314, September 2002. 825 [RFC3574] Soininen, J., "Transition Scenarios for 3GPP Networks", 826 RFC 3574, August 2003. 828 [RFC4029] Lind, M., Ksinant, V., Park, S., Baudot, A., and P. 829 Savola, "Scenarios and Analysis for Introducing IPv6 into 830 ISP Networks", RFC 4029, March 2005. 832 [RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E. 833 Castro, "Application Aspects of IPv6 Transition", 834 RFC 4038, March 2005. 836 [RFC4057] Bound, J., "IPv6 Enterprise Network Scenarios", RFC 4057, 837 June 2005. 839 [RFC4215] Wiljakka, J., "Analysis on IPv6 Transition in Third 840 Generation Partnership Project (3GPP) Networks", RFC 4215, 841 October 2005. 843 [RFC4798] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur, 844 "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 845 Provider Edge Routers (6PE)", RFC 4798, February 2007. 847 [RFC4852] Bound, J., Pouffary, Y., Klynsma, S., Chown, T., and D. 848 Green, "IPv6 Enterprise Network Analysis - IP Layer 3 849 Focus", RFC 4852, April 2007. 851 [RFC4966] Aoun, C. and E. Davies, "Reasons to Move the Network 852 Address Translator - Protocol Translator (NAT-PT) to 853 Historic Status", RFC 4966, July 2007. 855 [RFC5181] Shin, M-K., Han, Y-H., Kim, S-E., and D. Premec, "IPv6 856 Deployment Scenarios in 802.16 Networks", RFC 5181, 857 May 2008. 859 [RFC5211] Curran, J., "An Internet Transition Plan", RFC 5211, 860 July 2008. 862 [RFC5218] Thaler, D. and B. Aboba, "What Makes For a Successful 863 Protocol?", RFC 5218, July 2008. 865 [RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy 866 Mobile IPv6", RFC 5844, May 2010. 868 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 869 Infrastructures (6rd) -- Protocol Specification", 870 RFC 5969, August 2010. 872 [Baker.Shanghai] 873 Baker, F., "The view from IPv6 Operations WG (and we'll 874 talk about translation)", Presentation in the China Mobile 875 Workshop on IPv6 Deployment in Cellular Networks, http:// 876 ipv6ws.arkko.com/presentations/ 877 3GPP-IETF-V6OPS-Discussion.pdf, Shanghai, China, 878 November 2009. 880 [networkworld.youtube] 881 Marsan, C., "YouTube support of IPv6 seen in dramatic 882 traffic spike", Network World article http:// 883 www.networkworld.com/news/2010/020110-youtube-ipv6.html, 884 February 2010. 886 [I-D.ietf-v6ops-tunnel-security-concerns] 887 Krishnan, S., Thaler, D., and J. Hoagland, "Security 888 Concerns With IP Tunneling", 889 draft-ietf-v6ops-tunnel-security-concerns-03 (work in 890 progress), October 2010. 892 [I-D.ietf-v6ops-v6-in-mobile-networks] 893 Koodli, R., "Mobile Networks Considerations for IPv6 894 Deployment", draft-ietf-v6ops-v6-in-mobile-networks-02 895 (work in progress), October 2010. 897 Appendix A. Acknowledgments 899 The authors would like to thank the many people who have engaged in 900 discussions around this topic over the years. Some of the material 901 in this document comes originally from Fred Baker's presentation in a 902 workshop in Shanghai [Baker.Shanghai]. In addition, the authors 903 would like to thank Mark Townsley with whom the Jari Arkko wrote an 904 earlier document [I-D.arkko-townsley-coexistence]. Brian Carpenter 905 submitted an in-depth review and provided significant new text. 906 Cameron Byrne provided significant feedback on the key 907 recommendations in this memo. The authors would also like thank Dave 908 Thaler, Alain Durand, Randy Bush, and Dan Wing who have always 909 provided valuable guidance in this field. Finally, the authors would 910 like to thank Suresh Krishnan, Fredrik Garneij, Mohamed Boucadair, 911 Remi Despres, Kurtis Lindqvist, Shawn Emery, Dan Romascanu, Tim Polk, 912 Ralph Droms, Sean Turner, Tina Tsou, Nevil Brownlee, and Joel Jaeggli 913 who have commented on early versions of this memo. 915 Authors' Addresses 917 Jari Arkko 918 Ericsson 919 Jorvas 02420 920 Finland 922 Email: jari.arkko@piuha.net 923 Fred Baker 924 Cisco Systems 925 Santa Barbara, California 93117 926 USA 928 Email: fred@cisco.com