idnits 2.17.1 draft-ietf-v6ops-wireline-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 (September 10, 2012) is 4240 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-09) exists of draft-donley-behave-deterministic-cgn-04 == Outdated reference: A later version (-06) exists of draft-donley-nat444-impacts-04 == Outdated reference: A later version (-10) exists of draft-ietf-behave-lsn-requirements-09 == Outdated reference: A later version (-08) exists of draft-ietf-softwire-dslite-deployment-06 == Outdated reference: A later version (-10) exists of draft-ietf-v6ops-464xlat-07 == Outdated reference: A later version (-12) exists of draft-ietf-v6ops-6204bis-10 -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 3068 (Obsoleted by RFC 7526) -- Obsolete informational reference (is this intentional?): RFC 3484 (Obsoleted by RFC 6724) Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 v6ops V. Kuarsingh, Ed. 3 Internet-Draft Rogers Communications 4 Intended status: Informational L. Howard 5 Expires: March 14, 2013 Time Warner Cable 6 September 10, 2012 8 Wireline Incremental IPv6 9 draft-ietf-v6ops-wireline-incremental-ipv6-06 11 Abstract 13 Operators worldwide are in various stages of preparing for, or 14 deploying IPv6 into their networks. The operators often face 15 difficult challenges related to both IPv6 introduction along with 16 those related to IPv4 run out. Operators will need to meet the 17 simultaneous needs of IPv6 connectivity and continue support for IPv4 18 connectivity for legacy devices with a stagnant supply of IPv4 19 addresses. The IPv6 transition will take most networks from an IPv4- 20 only environment to an IPv6 dominant environment with long transition 21 period varying by operator. This document helps provide a framework 22 for wireline providers who are faced with the challenges of 23 introducing IPv6 along with meeting the legacy needs of IPv4 24 connectivity utilizing well defined and commercially available IPv6 25 transition technologies. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on March 14, 2013. 44 Copyright Notice 46 Copyright (c) 2012 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2. Operator Assumptions . . . . . . . . . . . . . . . . . . . . . 4 63 3. Reasons and Considerations for a Phased Approach . . . . . . . 5 64 3.1. Relevance of IPv6 and IPv4 . . . . . . . . . . . . . . . . 6 65 3.2. IPv4 Resource Challenges . . . . . . . . . . . . . . . . . 6 66 3.3. IPv6 Introduction and Operational Maturity . . . . . . . . 7 67 3.4. Service Management . . . . . . . . . . . . . . . . . . . . 8 68 3.5. Sub-Optimal Operation of Transition Technologies . . . . . 8 69 3.6. Future IPv6 Network . . . . . . . . . . . . . . . . . . . 9 70 4. IPv6 Transition Technology Analysis . . . . . . . . . . . . . 9 71 4.1. Automatic Tunneling using 6to4 and Teredo . . . . . . . . 9 72 4.2. Carrier Grade NAT (NAT444) . . . . . . . . . . . . . . . . 10 73 4.3. 6RD . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 74 4.4. Native Dual Stack . . . . . . . . . . . . . . . . . . . . 11 75 4.5. DS-Lite . . . . . . . . . . . . . . . . . . . . . . . . . 11 76 4.6. NAT64 . . . . . . . . . . . . . . . . . . . . . . . . . . 12 77 5. IPv6 Transition Phases . . . . . . . . . . . . . . . . . . . . 12 78 5.1. Phase 0 - Foundation . . . . . . . . . . . . . . . . . . . 13 79 5.1.1. Phase 0 - Foundation: Training . . . . . . . . . . . . 13 80 5.1.2. Phase 0 - Foundation: System Capabilities . . . . . . 14 81 5.1.3. Phase 0 - Foundation: Routing . . . . . . . . . . . . 14 82 5.1.4. Phase 0 - Foundation: Network Policy and Security . . 14 83 5.1.5. Phase 0 - Foundation: Transition Architecture . . . . 14 84 5.1.6. Phase 0- Foundation: Tools and Management . . . . . . 15 85 5.2. Phase 1 - Tunneled IPv6 . . . . . . . . . . . . . . . . . 15 86 5.2.1. 6RD Deployment Considerations . . . . . . . . . . . . 17 87 5.3. Phase 2: Native Dual Stack . . . . . . . . . . . . . . . . 19 88 5.3.1. Native Dual Stack Deployment Considerations . . . . . 19 89 5.4. Intermediate Phase for CGN . . . . . . . . . . . . . . . . 20 90 5.4.1. CGN Deployment Considerations . . . . . . . . . . . . 21 91 5.5. Phase 3 - IPv6-Only . . . . . . . . . . . . . . . . . . . 22 92 5.5.1. DS-Lite . . . . . . . . . . . . . . . . . . . . . . . 23 93 5.5.2. DS-Lite Deployment Considerations . . . . . . . . . . 23 94 5.5.3. NAT64 Deployment Considerations . . . . . . . . . . . 24 95 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 96 7. Security Considerations . . . . . . . . . . . . . . . . . . . 25 97 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26 98 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 99 9.1. Normative References . . . . . . . . . . . . . . . . . . . 26 100 9.2. Informative References . . . . . . . . . . . . . . . . . . 26 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 103 1. Introduction 105 This draft sets out to help wireline operators in planning their IPv6 106 deployments while ensuring continued support for IPv6-incapable 107 consumer devices and applications. This document identifies which 108 technologies can be used incrementally to transition from IPv4-only 109 to an IPv6 dominant environment with support for dual stack 110 operation. The end state goal for most operators will be IPv6-only, 111 but the path to this final state will heavily depend on the amount of 112 legacy equipment resident in end networks and management of long tail 113 IPv4-only content. Although no single plan will work for all 114 operators, options listed herein provide a baseline which can be 115 included in many plans. 117 This draft is intended for wireline environments which include Cable, 118 DSL and/or fiber as the access method to the end consumer. This 119 document attempts to follow the principles laid out in [RFC6180] 120 which provides guidance on using IPv6 transition mechanisms. This 121 document will focus on technologies which enable and mature IPv6 122 within the operator's network, but will also include a cursory view 123 of IPv4 connectivity continuance. The focal transition technologies 124 include 6RD [RFC5969], DS-Lite [RFC6333], NAT64 [RFC6146] and Dual 125 Stack operation which may also include a CGN/NAT444 deployment. 126 Focus on these technologies is based on their inclusion in many off- 127 the-shelf CPEs and availability in commercially available equipment. 129 2. Operator Assumptions 131 For the purposes of this document, the authors assume: 133 - The operator is considering deploying IPv6 or is in the progress 134 in deploying IPv6 136 - The operator has a legacy IPv4 subscriber base that will 137 continue to exist for a period of time 139 - The operator will want to minimize the level of disruption to 140 the existing and new subscribers 142 - The operator may also want to minimize the number of 143 technologies and functions that are needed to mediate any given 144 set of subscribers flows (overall preference for Native IP flows) 146 - The operator is able to run Dual Stack on their own core network 147 and is able to transition their own services to support IPv6 149 Based on these assumptions, an operator will want to utilize 150 technologies that minimize the need to tunnel, translate or mediate 151 flows to help optimize traffic flow and lower the cost impacts of 152 transition technologies. Transition technology selections should be 153 made to mediate the non-dominant IP family flows and allow native 154 routing (IPv4 and/or IPv6) to forward the dominant traffic whenever 155 possible. This allows the operator to minimize the cost of IPv6 156 transition technologies by minimizing the transition technology 157 deployment size. 159 An operator may also choose to prefer more IPv6 focused models where 160 the use of transition technologies are based on an effort to enable 161 IPv6 at the base layer as soon as possible. Some operators may want 162 to promote IPv6 early on in the deployment and have IPv6 traffic 163 perform optimally from the outset. This desire would need to be 164 weighed against the cost and support impacts of such a choice and the 165 quality of experience offered to subscribers. 167 3. Reasons and Considerations for a Phased Approach 169 When faced with the challenges described in the introduction, 170 operators may want to consider a phased approach when adding IPv6 to 171 an existing subscriber base. A phased approach allows the operator 172 to add in IPv6 while not ignoring legacy IPv4 connection 173 requirements. Some of the main challenges the operator will face 174 include: 176 - IPv4 exhaustion may occur long before all traffic is able to be 177 delivered over IPv6, necessitating IPv4 address sharing 179 - IPv6 will pose operational challenges since some of the software 180 is quite new and has had short run time in large production 181 environments and organizations are also not acclimatized to 182 supporting IPv6 as a service 184 - Connectivity modes will move from IPv4-only to Dual Stack in the 185 home, changing functional behaviors in the consumer network and 186 increasing support requirements for the operator 188 - Although IPv6 support on CPEs is a newer phenomenon, there is a 189 strong push by operators and the industry as a whole to enable 190 IPv6 on devices. As demand grows, IPv6 enablement will no longer 191 be optional, but necessary on CPEs. Documents like [RFC6540] 192 provide useful tools in the short term to help vendors and 193 implementors understand what "IPv6 support" means. 195 These challenges will occur over a period of time, which means that 196 the operator's plans need to address the ever changing requirements 197 of the network and subscriber demand. Although phases will be 198 presented in this document, not all operators may need to enable each 199 discrete phase. It is possible that characteristics in individual 200 networks may allow certain operators to skip or jump to various 201 phases. 203 3.1. Relevance of IPv6 and IPv4 205 The delivery of high-quality unencumbered Internet service should be 206 the primary goal for operators. With the imminent exhaustion of 207 IPv4, IPv6 will offer the highest quality of experience in the long 208 term. Even though the operator may be focused on IPv6 delivery, they 209 should be aware that both IPv4 and IPv6 will play a role in the 210 Internet experience during transition. The Internet is made of many 211 interconnecting systems, networks, hardware, software and content 212 sources - all of which will move to IPv6 at different rates. 214 Many subscribers use older operating systems and hardware which 215 support IPv4-only operation. Internet subscribers don't buy IPv4 or 216 IPv6 connections; they buy Internet connections, which demands the 217 need to support both IPv4 and IPv6 for as long at the subscriber's 218 home network demands such support. The operator may be able to 219 leverage one or the other protocol to help bridge connectivity on the 220 operator's network, but the home network will likely demand both IPv4 221 and IPv6 for some time. 223 3.2. IPv4 Resource Challenges 225 Since connectivity to IPv4-only endpoints and/or content will remain 226 common, IPv4 resource challenges are of key concern to operators. 227 The lack of new IPv4 addresses for additional devices means that 228 meeting the growth in demand of IPv4 connections in some networks 229 will require address sharing. 231 Networks are growing at different rates including those in emerging 232 markets and established networks based on the proliferation of 233 Internet based services and devices. IPv4 address constraints will 234 likely affect many if not most operators at some point, increasing 235 the benefits of IPv6. IPv4 address exhaustion is a consideration 236 when selecting technologies which rely on IPv4 to supply IPv6 237 services, such as 6RD. Additionally, if native Dual Stack is 238 considered by the operator, challenges related to IPv4 address 239 exhaustion remain a concern. 241 Some operators may be able to reclaim small amounts IPv4 addresses 242 through addressing efficiencies in the network, although this will 243 have little lasting benefits to the network and not meet longer term 244 connectivity needs. Secondary markets for IPv4 addresses have also 245 begun to arise, but it's not well understood how this will complement 246 overall demand for Internet growth. Address transfers will also be 247 subject to market prices and transfer rules governed by the Regional 248 Registries. 250 The lack of new global IPv4 address allocations will therefore force 251 operators to support some form of IPv4 address sharing and may impact 252 technological options for transition once the operator runs out of 253 new IPv4 addresses for assignment. 255 3.3. IPv6 Introduction and Operational Maturity 257 The introduction of IPv6 will require new operational practices. The 258 IPv4 environment we have today was built over many years and matured 259 by experience. Although many of these experiences are transferable 260 from IPv4 to IPv6, new experience and practices specific to IPv6 will 261 be needed. 263 Engineering and Operational staff will need to develop experience 264 with IPv6. Inexperience may lead to early IPv6 deployment 265 instability, and operators should consider this when selecting 266 technologies for initial transition. Operators may not want to 267 subject their mature IPv4 service to a "new IPv6" path initially 268 while it may be going through growing pains. DS-Lite [RFC6333] and 269 NAT64 [RFC6146] are both technologies which requires IPv6 to support 270 connectivity to IPv4 endpoints or content over an IPv6-only access 271 network. 273 Further, some of these transition technologies are new and require 274 refinement within running code. Deployment experience is required to 275 expose bugs and stabilize software in production environments. Many 276 supporting systems are also under development and have newly 277 developed IPv6 functionality including vendor implementations of 278 DHCPv6, management tools, monitoring systems, diagnostic systems, 279 logging, along with other elements. 281 Although the base technological capabilities exist to enable and run 282 IPv6 in most environments, organizational experience is low. Until 283 such time as each key technical member of an operator's organization 284 can identify IPv6, understand its relevance to the IP service 285 offering, how it operates and how to troubleshoot it, the deployment 286 needs to mature, and may be subject to subscriber-impacting events. 287 This fact should not incline operators to delay their IPv6 288 deployment, but should drive them to deploy IPv6 sooner to gain the 289 much needed experience before IPv6 is the only viable way to connect 290 new hosts to the network. 292 It should also be noted that although many transition technologies 293 may be new, and some code related to access environments may be new, 294 there is a large segment of the networking fabric which has had IPv6 295 available for a long period of time and has had extended exposure in 296 production. Operators may use this to their advantage by first 297 enabling IPv6 in the core of their network then work outward towards 298 the subscriber edge. 300 3.4. Service Management 302 Services are managed within most networks and are often based on the 303 gleaning and monitoring of IPv4 addresses assigned to endpoints. 304 Operators will need to address such management tools, troubleshooting 305 methods and storage facilities (such as databases) to deal with not 306 just a new address type containing a 128-bit IPv6 address [RFC2460], 307 but often both IPv4 and IPv6 at the same time. Examination of 308 address type, and recording delegated prefixes along with single 309 address assignments, will likely require additional development. 311 With any Dual Stack service - whether Native, 6RD-based, DS-Lite, 312 NAT64 or otherwise - two address families may need to be managed 313 simultaneously to help provide for the full Internet experience. 314 This would indicate that IPv6 management is not just a simple add in, 315 but needs to be well integrated into the service management 316 infrastructure. In the early transition phases, it's quite likely 317 that many systems will be missed and that IPv6 services will go un- 318 monitored and impairments undetected. 320 These issues may be of consideration when selecting technologies that 321 require IPv6 as the base protocol to deliver IPv4 connectivity. 322 Instability on the IPv6 service in such a case would impact IPv4 323 services. 325 3.5. Sub-Optimal Operation of Transition Technologies 327 Native delivery of IPv4 and IPv6 provides a solid foundation for 328 delivery of Internet services to subscribers since native IP paths 329 are well understood and networks are often optimized to send such 330 traffic efficiently. Transition technologies however, may alter the 331 normal path of traffic or reduce the path MTU, removing many network 332 efficiencies built for native IP flows. Tunneling and translation 333 devices may not be located on the most optimal path in line with the 334 natural traffic flow (based on route computation) and therefore may 335 increase latency. These paths may also add additional points of 336 failure. 338 Generally, the operator will want to deliver native IPv6 as soon as 339 possible and utilize transition technologies only when required. 340 Transition technologies may be used to provide continued access to 341 IPv4 via tunneling and/or translation or may be used to deliver IPv6 342 connectivity. The delivery of Internet or internal services should 343 be considered by the operator, since supplying connections using a 344 transition technology will reduce the overall performance for the 345 subscriber. 347 When choosing between various transition technologies, operators 348 should consider the benefits and drawbacks of each option. Some 349 technologies like CGN/NAT444 utilize many existing addressing and 350 management practices. Other options such as DS-Lite and NAT64 remove 351 the IPv4 addressing requirement to the subscriber premise device but 352 require IPv6 to be operational and well supported. 354 3.6. Future IPv6 Network 356 An operator should also be aware that longer-term plans may include 357 IPv6-only operation in all or much of the network. The IPv6-only 358 operation may be complemented by technologies such as NAT64 for long- 359 tail IPv4 content reach. This longer term view may be distant to 360 some, but should be considered when planning out networks, addressing 361 and services. The needs and costs of maintaining two IP stacks will 362 eventually become burdensome and simplification will be desirable. 363 The operators should plan for this state and not make IPv6 inherently 364 dependent on IPv4 as this would unnecessarily constrain the network. 366 Other design considerations and guidelines for running an IPv6 367 network should also be considered by the operator. Guidance on 368 designing an IPv6 network can be found in 369 [draft-matthews-v6ops-design-guidelines] and 370 [draft-ietf-v6ops-icp-guidance]. 372 4. IPv6 Transition Technology Analysis 374 Operators should understand the main transition technologies for IPv6 375 deployment and IPv4 run out. This draft provides a brief description 376 of some of the mainstream and commercially available options. This 377 analysis is focused on the applicability of technologies to deliver 378 residential services and less focused on commercial access, wireless, 379 or infrastructure support. 381 The technologies in focus for this document are targeted on those 382 commercially available and in deployment. 384 4.1. Automatic Tunneling using 6to4 and Teredo 386 Even when operators may not be actively deploying IPv6, automatic 387 mechanisms exist on subscriber operating systems and CPE hardware. 389 Such technologies include 6to4 [RFC3056], which is most commonly used 390 with anycast relays [RFC3068]. Teredo [RFC4380] is also used widely 391 by many Internet hosts. 393 Documents such as [RFC6343] have been written to help operators 394 understand observed problems with 6to4 deployments and provides 395 guidelines on how to improve its performance. An operator may want 396 to provide local relays for 6to4 and/or Teredo to help improve the 397 protocol's performance for ambient traffic utilizing these IPv6 398 connectivity methods. Experiences such as those described in 399 [I-D.jjmb-v6ops-comcast-ipv6-experiences] show that local relays have 400 proved beneficial to 6to4 protocol performance. 402 Operators should also be aware of breakage cases for 6to4 if non- 403 RFC1918 addresses are used within CGN/NAT444 zones. Many off-the- 404 shelf CPEs and operating systems may turn on 6to4 without a valid 405 return path to the originating (local) host. This particular use 406 case can occur if any space other than [RFC1918] is used, including 407 Shared Address Space [RFC6598] or space registered to another 408 organization (squat space). The operator can use 6to4-PMT 409 [I-D.kuarsingh-v6ops-6to4-provider-managed-tunnel] or attempt to 410 block 6to4 operation entirely by blocking the anycast ranges 411 associated with [RFC3068]. 413 4.2. Carrier Grade NAT (NAT444) 415 Carrier Grade NAT (CGN), specifically as deployed in a NAT444 416 scenario [I-D.ietf-behave-lsn-requirements], may prove beneficial for 417 those operators who offer Dual Stack services to subscriber endpoints 418 once they exhaust their pools of IPv4 addresses. CGNs, and address 419 sharing overall, are known to cause certain challenges for the IPv4 420 service [RFC6269][I-D.donley-nat444-impacts], but may be necessary 421 depending on how an operator has chosen to deal with IPv6 transition 422 and legacy IPv4 connectivity requirements. 424 In a network where IPv4 address availability is low, CGN/NAT444, may 425 provide continued access to IPv4 endpoints. Some of the advantages 426 of using CGN/NAT444 include the similarities in provisioning and 427 activation models. IPv4 hosts in a CGN/NAT444 deployment will likely 428 inherit the same addressing and management procedures as legacy IPv4, 429 globally addressed hosts (i.e. DHCPv4, DNSv4, TFTP, TR-069 etc). 431 4.3. 6RD 433 6RD [RFC5969] provides a way of offering IPv6 connectivity to 434 subscriber endpoints when native IPv6 addressing on the access 435 network is not yet possible. 6RD provides tunneled connectivity for 436 IPv6 over the existing IPv4 path. As the access edge is upgraded and 437 subscriber premise equipment is replaced, 6RD can be replace by 438 native IPv6 connectivity. 6RD can be delivered over top a CGN/NAT444 439 deployment, but this would cause all traffic to be subject to some 440 type of transition technology. 442 6RD may also be advantageous during the early transition while IPv6 443 traffic volumes are low. During this period, the operator can gain 444 experience with IPv6 on the core and improve their peering framework 445 to match those of the IPv4 service. 6RD scales by adding relays to 446 the operator's network. Another advantage for 6RD is that the 447 operator does not need a DHCPv6 address assignment infrastructure and 448 does not need to support IPv6 routing to the CPE to support a 449 delegated prefix (as it's derived from the IPv4 address and other 450 configuration parameters). 452 Client support is required for 6RD operation and may not be available 453 on deployed hardware. 6RD deployments may require the subscriber or 454 operator to replace the CPE. 6RD will also require parameter 455 configuration which can be powered by the operator through DHCPv4, 456 manually provisioned on the CPE or automatically through some other 457 means. Manual provisioning would likely limit deployment scale. 459 4.4. Native Dual Stack 461 Native Dual Stack is often referred to as the "gold standard" of IPv6 462 and IPv4 delivery. It is a method of service delivery that is 463 already used in many existing IPv6 deployments. Native Dual Stack 464 does, however, require that Native IPv6 be delivered through the 465 access network to the subscriber premise. This technology option is 466 desirable in many cases and can be used immediately if the access 467 network and subscriber premise equipment supports native IPv6. 469 An operator who runs out of IPv4 addresses to assign to subscribers 470 will not be able to provide traditional native Dual Stack 471 connectivity for new subscribers. In Dual Stack deployments where 472 sufficient IPv4 addresses are not available, CGN/NAT444 can be used 473 on the IPv4 path. 475 Delivering native Dual Stack would require the operator's core and 476 access network to support IPv6. Other systems like DHCP, DNS, and 477 diagnostic/management facilities need to be upgraded to support IPv6 478 as well. The upgrade of such systems may often be non-trivial and 479 costly. 481 4.5. DS-Lite 483 Dual-Stack Lite (DS-Lite, [RFC6333]) is based on a native IPv6 484 connection model where IPv4 services are supported. DS-Lite provides 485 tunneled connectivity for IPv4 over the IPv6 path between the 486 subscriber's network device and a provider managed gateway (AFTR). 488 DS-Lite can only be used where there is a native IPv6 connection 489 between the AFTR and the CPE. This may mean that the technology's 490 use may not be viable during early transition if the core or access 491 network lacks IPv6 support. During the early transition period, a 492 significant amount of content and services may by IPv4-only. 493 Operators may be sensitive to this and may not want the newer IPv6 494 path to be the only bridge to IPv4 at that time given the potential 495 impact. The operator may also want to make sure that most of its 496 internal services and a significant amount of external content is 497 available over IPv6 before deploying DS-Lite. The availability of 498 services on IPv6 would help lower the demand on the AFTRs. 500 By sharing IPv4 addresses among multiple endpoints, like CGN/NAT444, 501 DS-Lite can facilitate continued support of legacy IPv4 services even 502 after IPv4 address run out. There are some functional considerations 503 to take into account with DS-Lite, such as those described in 504 [I-D.donley-nat444-impacts]and in [I-D.ietf-softwire-dslite- 505 deployment]. 507 DS-Lite requires client support on the CPE to function. The ability 508 to utilize DS-Lite will be dependent on the operator providing DS- 509 Lite capable CPEs or retail availability of the supported client for 510 subscriber-acquired endpoints. 512 4.6. NAT64 514 NAT64 [RFC6146] provides the ability to connect IPv6-only connected 515 clients and hosts to IPv4 servers without any tunneling. NAT64 516 requires that the host and home network support IPv6-only modes of 517 operation. Home networks do not commonly contain equipment that is 518 100% IPv6-capable. It is also not anticipated that common home 519 networks will be ready for IPv6-only operation for a number of years. 520 However, IPv6-only networking can be deployed by early adopters or 521 highly controlled networks [RFC6586]. 523 Viability of NAT64 will increase in wireline networks as consumer 524 equipment is replaced by IPv6 capable versions. There are incentives 525 for operators to move to IPv6-only operation, when feasible, which 526 includes the simplicity of a single stack access network. 528 5. IPv6 Transition Phases 530 The Phases described in this document are not provided as a rigid set 531 of steps, but are considered a guideline which should be analyzed by 532 operators planning their IPv6 transition. Operators may choose to 533 skip steps based on technological capabilities within their specific 534 networks, (residential/corporate, fixed/mobile), their business 535 development perspectives (which may affect the pace of migration 536 towards full IPv6), or a combination thereof. 538 The phases are based on the expectation that IPv6 traffic volume may 539 initially be low, and operator staff will gain experience with IPv6 540 over time. As traffic volumes of IPv6 increase, IPv4 traffic volumes 541 will decline (in percentage relative to IPv6), until IPv6 is the 542 dominant address family used. Operators may want to keep the traffic 543 flow for the dominant traffic class (IPv4 vs. IPv6) native to help 544 manage costs related to transition technologies. The cost of using 545 multiple technologies in succession to optimize each stage of the 546 transition should also be compared against the cost of changing and 547 upgrading subscriber connections. 549 Additional guidance and information on utilizing IPv6 transition 550 mechanisms can be found in [RFC6180]. Also, guidance on incremental 551 CGN for IPv6 transition can also be found in [RFC6264]. 553 5.1. Phase 0 - Foundation 555 5.1.1. Phase 0 - Foundation: Training 557 Training is one of the most important steps in preparing an 558 organization to support IPv6. Most people have little experience 559 with IPv6, and many do not even have a solid grounding in IPv4. The 560 implementation of IPv6 will likely produce many challenges due to 561 immature code on hardware, and the evolution of many applications and 562 systems to support IPv6. To properly deal with these impending or 563 current challenges, organizations must train their staff on IPv6. 565 Training should also be provided within reasonable timelines from the 566 actual IPv6 deployment. This means the operator needs to plan in 567 advance as it trains the various parts of its organization. New 568 Technology and Engineering staff often receive little training 569 because of their depth of knowledge, but must at least be provided 570 opportunities to read documentation, architectural white papers, and 571 RFCs. Operations personnel who support the network and other systems 572 need to be trained closer to the deployment timeframes, so they 573 immediately use their new-found knowledge before forgetting. 575 Subscriber support staff would require much more basic but large 576 scale training since many organizations have massive call centers to 577 support the subscriber base. Tailored training will also be required 578 for marketing and sales staff to help them understand IPv6 and build 579 it into the product development and sales process. 581 5.1.2. Phase 0 - Foundation: System Capabilities 583 An important component with any IPv6 network architecture and 584 implementation is the assessment of the hardware and operating 585 capabilities of the deployed equipment (and software). The 586 assessment needs to be conducted irrespective of how the operator 587 plans to transition their network. The capabilities of the install 588 base will however impact what technologies and modes of operation may 589 be supported and therefore what technologies can be considered for 590 the transition. If some systems do not meet the needs of the 591 operator's IPv6 deployment and/or transition plan, the operator may 592 need to plan for replacement and/or upgrade. 594 5.1.3. Phase 0 - Foundation: Routing 596 The network infrastructure will need to be in place to support IPv6. 597 This includes the routed infrastructure along with addressing 598 principles, routing principles, peering policy and related network 599 functions. Since IPv6 is quite different from IPv4 in several ways 600 including the number of addresses which are made available, careful 601 attention to a scalable and manageable architecture needs to be made. 602 One such change is the notion of a delegated prefix, which deviates 603 from the common single address phenomenon in IPv4-only deployments. 604 Deploying prefixes per CPE can load the routing tables and require a 605 routing protocol or route gleaning to manage connectivity to the 606 subscriber's network. Delegating prefixes can be of specific 607 importance in access network environments where downstream 608 subscribers often move between access nodes, raising the concern of 609 frequent renumbering and/or managing movement of routed prefixes 610 within the network (common in cable based networks). 612 5.1.4. Phase 0 - Foundation: Network Policy and Security 614 Many, but not all, security policies will map easily from IPv4 to 615 IPv6. Some new policies may be required for issues specific to IPv6 616 operation. This document does not highlight these specific issues, 617 but raises the awareness they are of consideration and should be 618 addressed when delivering IPv6 services. Other IETF documents such 619 as [RFC4942], [RFC6092], and [RFC6169] are excellent resources. 621 5.1.5. Phase 0 - Foundation: Transition Architecture 623 The operators should plan out their transition architecture in 624 advance (with room for flexibility) to help optimize how they will 625 build out and scale their networks. Should the operator consider 626 multiple technologies like CGN/NAT444, DS-Lite, NAT64 and 6RD, they 627 may want to plan out where network resident equipment may be located 628 and potentially choose locations which can be used for all functional 629 roles (i.e. Placement of NAT44 translator, AFTR, NAT64 gateway and 630 6RD relays). Although these functions are not inherently connected, 631 additional management, diagnostic and monitoring functions can be 632 deployed along side the transition hardware without the need to 633 distribute these to an excessive or divergent number of locations. 635 This approach may also prove beneficial if traffic patterns change 636 rapidly in the future as the operators may need to evolve their 637 transition infrastructure faster than originally anticipated. One 638 such example may be the movement from a CGN/NAT44 model (dual stack) 639 to DS-Lite. Since both traffic sets require a translation function 640 (NAT44), synchronized pool management, routing and management system 641 positioning can allow rapid movement (notwithstanding the 642 technological means to re-provision the subscriber). 644 Operators should inform their vendors of what technologies they plan 645 to support over the course of the transition to make sure the 646 equipment is suited to support those modes of operation. This is 647 important for both network gear and subscriber premise equipment. 649 The operator should also plan their overall strategy to meet the 650 target needs of an IPv6-only deployment. As traffic moves to IPv6, 651 the benefits of only a single stack on the access network may 652 eventually justify the removal of IPv4 for simplicity. Planning for 653 this eventual model, no matter how far off this may be, will help the 654 operator embrace this end state when needed. 656 5.1.6. Phase 0- Foundation: Tools and Management 658 The operator should thoroughly analyze all provisioning and 659 management systems to develop requirements for each phase. This will 660 include concepts related to the 128-bit IPv6 address, the notation of 661 an assigned IPv6 prefix (Prefix Delegation) and the ability to detect 662 either or both address families when determining if a subscriber has 663 full Internet service. 665 If an operator stores usage information, this would need to be 666 aggregated to include both the IPv4 and IPv6 as both address families 667 are assigned to the same subscriber. Tools that verify connectivity 668 may need to query the IPv4 and IPv6 addresses. 670 5.2. Phase 1 - Tunneled IPv6 672 Tunneled access to IPv6 can be regarded as an early stage transition 673 option by operators. Many network operators can deploy native IPv6 674 from the access edge to the peering edge fairly quickly but may not 675 be able to offer IPv6 natively to the subscriber edge device. During 676 this period of time, tunneled access to IPv6 is a viable alternative 677 to native IPv6. It is also possible that operators may be rolling 678 out IPv6 natively to the subscriber edge but the time involved may be 679 long due to logistics and other factors. Even while carefully 680 rolling out native IPv6, operators can deploy relays for automatic 681 tunneling technologies like 6to4 and Teredo. Where native IPv6 to 682 the access edge is a longer-term project, operators can consider 6RD 683 [RFC5969] as an option to offer in-home IPv6 access. Note that 6to4 684 and Teredo have different address selection behaviors than 6RD 685 [RFC3484]. Additional guidelines on deploying and supporting 6to4 686 can be found in [RFC6343]. 688 The operator can deploy 6RD relays into the network and scale them as 689 needed to meet the early subscriber needs of IPv6. Since 6RD 690 requires the upgrade or replacement of CPE devices, the operator may 691 want to ensure that the CPE devices support not just 6RD but native 692 Dual Stack and other tunneling technologies if possible such as DS- 693 Lite [I-D.ietf-v6ops-6204bis]. 6RD clients are becoming available in 694 some retail channel products and within the OEM market. Retail 695 availability of 6RD is important since not all operators control or 696 have influence over what equipment is deployed in the consumer home 697 network. The operator can support 6RD access with unmanaged devices 698 using DHCPv4 option 212 (OPTION_6RD) [RFC5969]. 700 +--------+ ----- 701 | | / \ 702 Encap IPv6 Flow | 6RD | | IPv6 | 703 - - -> | BR | <- > | Net | 704 +---------+ / | | \ / 705 | | / +--------+ ----- 706 | 6RD + <----- ----- 707 | | / \ 708 | Client | IPv4 Flow | IPv4 | 709 | + < - - - - - - - - - - - - - - -> | Net | 710 | | \ / 711 +---------+ ----- 713 Figure 1: 6RD Basic Model 715 6RD used as an initial transition technology also provides the added 716 benefit of a deterministic IPv6 prefix based on the IPv4 assigned 717 address. Many operational tools are available or have been built to 718 identify what IPv4 (often dynamic) address was assigned to a 719 subscriber CPE. So, a simple tool and/or method can be built to help 720 identify the IPv6 prefix using the knowledge of the assigned IPv4 721 address. 723 An operator may choose to not offer internal services over IPv6 if 724 tunneled access to IPv6 is used since some services generate a large 725 amount of traffic. Such traffic may include Video content like IPTV. 726 By limiting how much traffic is delivered over the 6RD connection (if 727 possible), the operator can avoid costly and complex scaling of the 728 relay infrastructure. 730 5.2.1. 6RD Deployment Considerations 732 Deploying 6RD can greatly speed up an operator's ability to support 733 IPv6 to the subscriber network if native IPv6 connectivity cannot be 734 supplied. The speed at which 6RD can be deployed is highlighted in 735 [RFC5569]. 737 The first core consideration is deployment models. 6RD requires the 738 CPE (6RD client) to send traffic to a 6RD relay. These relays can 739 share a common anycast address, or can use unique addresses. Using 740 an anycast model, the operator can deploy all the 6RD relays using 741 the same IPv4 interior service address. As the load increases on the 742 deployed relays, the operator can deploy more relays into the 743 network. The one drawback is that it may be difficult to manage the 744 traffic volume among additional relays, since all 6RD traffic will 745 find the nearest (in terms of IGP cost) relay. Use of multiple relay 746 addresses can help provide more control but has the disadvantage of 747 being more complex to provision. Subsets of CPEs across the network 748 will require and contain different relay information. An alternative 749 approach is to use a hybrid model using multiple anycast service IP 750 Addresses for clusters of 6RD relays, should the operator anticipate 751 massive scaling of the environment. Thus, the operator has multiple 752 vectors by which to scale the service. 754 +--------+ 755 | | 756 IPv4 Addr.X | 6RD | 757 - - - > | BR | 758 +-----------+ / | | 759 | Client A | <- - - +--------+ 760 +-----------+ 761 Separate IPv4 Service Addresses 762 +-----------+ 763 | Client B | < - - +--------+ 764 +-----------+ \ | | 765 - - - > | 6RD | 766 IPv4 Addr.Y | BR | 767 | | 768 +--------+ 770 Figure 2: 6RD Multiple IPv4 Service Address Model 772 +--------+ 773 | | 774 IPv4 Addr.X | 6RD | 775 - - - > | BR | 776 +-----------+ / | | 777 | Client A |- - - - +--------+ 778 +-----------+ 779 Common (Anycast) IPv4 Service Addresses 780 +-----------+ 781 | Client B | - - - +--------+ 782 +-----------+ \ | | 783 - - - > | 6RD | 784 IPv4 Addr.X | BR | 785 | | 786 +--------+ 788 Figure 3: 6RD Anycast IPv4 Service Address Model 790 Provisioning of the 6RD endpoints is affected by the deployment model 791 chosen (i.e. anycast vs. specific service IP Addresses). Using 792 multiple IP Addresses may require more planning and management, as 793 subscriber equipment will have different sets of data to be 794 provisioned into the devices. The operator may use DHCPv4, manual 795 provisioning or other mechanisms to provide parameters to subscriber 796 equipment. 798 If the operator manages the CPE, support personnel will need tools 799 able to report the status of the 6RD tunnel. Usage information can 800 be counted on the operator edge, but if it requires source/ 801 destination flow details, data must be collected after the 6RD relay 802 (IPv6 side of connection). 804 6RD [RFC5969], as any tunneling option, is subject to a reduced MTU 805 so operators need to plan to manage this environment. 807 +---------+ IPv4 Encapsulation +------------+ 808 | +- - - - - - - - - - - + | 809 | 6RD +----------------------+ 6RD +--------- 810 | | IPv6 Packet | Relay | IPv6 Packet 811 | Client +----------------------+ +--------- 812 | +- - - - - - - - - - - + | ^ 813 +---------+ ^ +------------+ | 814 | | 815 | | 816 IPv4 IP (Tools/Mgmt) IPv6 Flow Analysis 818 Figure 4: 6RD Tools and Flow Management 820 5.3. Phase 2: Native Dual Stack 822 Either as a follow-up phase to "Tunneled IPv6" or as an initial step, 823 the operator may deploy native IPv6 down to the CPEs. This phase 824 would then allow for both IPv6 and IPv4 to be natively accessed by 825 the subscriber home network without translation or tunneling. The 826 native Dual Stack phase can be rolled out across the network while 827 the tunneled IPv6 service remains operational, if used. As areas 828 begin to support native IPv6, subscriber home equipment will 829 generally prefer using the IPv6 addresses derived from the delegated 830 IPv6 prefix versus tunneling options such as 6to4 and Teredo as 831 defined in [RFC3484]. Specific care is needed when moving to native 832 Dual Stack from 6RD as documented in 833 [I-D.townsley-v6ops-6rd-sunsetting]. 835 Native Dual Stack is the best option at this point in the transition, 836 and should be sought as soon as possible. During this phase, the 837 operator can confidently move both internal and external services to 838 IPv6. Since there are no translation devices needed for this mode of 839 operation, it transports both protocols (IPv6 and IPv4) efficiently 840 within the network. 842 5.3.1. Native Dual Stack Deployment Considerations 844 Native Dual Stack is a very desirable option for the IPv6 transition, 845 if feasible. The operator must enable IPv6 on the network core and 846 peering edge before they attempt to turn on native IPv6 services. 847 Additionally, provisioning and support systems such as DHCPv6, DNS 848 and other functions that support the subscriber's IPv6 Internet 849 connection need to be in place. 851 The operator must treat IPv6 connectivity with the same operational 852 importance as IPv4. A poor IPv6 service may be worse than not 853 offering an IPv6 service at all as it will negatively impact the 854 subscriber's Internet experience. This may cause users or support 855 personnel to disable IPv6, limiting the subscriber from the benefits 856 of IPv6 connectivity as the network performance improves. New code 857 and IPv6 functionality may cause instability at first. The operator 858 will need to monitor, troubleshoot and resolve issues promptly. 860 Prefix assignment and routing are new for common residential 861 services. Prefix assignment is straightforward (DHCPv6 using 862 IA_PDs), but installation and propagation of routing information for 863 the prefix, especially during access layer instability, is often 864 poorly understood. The operator should develop processes for 865 renumbering subscribers who move to new access nodes. 867 Operators need to keep track of both the dynamically assigned IPv4 868 address along with the IPv6 address and prefix. Any additional 869 dynamic elements, such as auto-generated host names, need to be 870 considered and planned for. 872 5.4. Intermediate Phase for CGN 874 Acquiring more IPv4 addresses is already challenging, if not 875 impossible; therefore address sharing may be required on the IPv4 876 path of a Dual Stack deployment. The operator may have a preference 877 to move directly to a transition technology such as DS-Lite [RFC6333] 878 or may use Dual Stack with CGN/NAT444 to facilitate IPv4 connections. 880 CGN/NAT444 requires IPv4 addressing between the subscriber premise 881 equipment and the operator's translator which may be facilitated by 882 shared address [RFC6598], private address [RFC1918] or other address 883 space. CGN/NAT444 is only recommended to be used along side IPv6 in 884 a Dual Stack deployment and not on it's own. Figure 5 provides a 885 comparative view of a traditional IPv4 path versus one which uses 886 CGN/NAT444. 888 +--------+ ----- 889 | | / \ 890 IPv4 Flow | CGN | | | 891 - - -> + + < -> | | 892 +---------+ / | | | | 893 | CPE | <- - - / +--------+ | IPv4 | 894 |---------+ | Net | 895 | | 896 +---------+ IPv4 Flow | | 897 | CPE | <- - - - - - - - - - - - - - - > | | 898 |---------+ \ / 899 ----- 901 Figure 5: Overlay CGN Deployment 903 In the case of native Dual Stack, CGN/NAT444 can be used to assist in 904 extending connectivity for the IPv4 path while the IPv6 path remains 905 native. For endpoints operating in a IPv6+CGN/NAT444 model, the 906 native IPv6 path is available for higher quality connectivity, 907 helping host operation over the network. At the same time, the CGN 908 path may offer a less than optimal performance. These points are 909 also true for DS-Lite. 911 +--------+ ----- 912 | | / \ 913 IPv4 Flow | CGN | | IPv4 | 914 - - -> + + < -> | Net | 915 +---------+ / | | \ / 916 | | <- - - / +--------+ ------- 917 | Dual | 918 | Stack | ----- 919 | CPE | IPv6 Flow / IPv6 \ 920 | | <- - - - - - - - - - - - - - - > | Net | 921 |---------+ \ / 922 ----- 924 Figure 6: Dual Stack with CGN 926 CGN/NAT444 deployments may make use of a number of address options, 927 which include [RFC1918] or Shared Address Space [RFC6598]. It is 928 also possible that operators may use part of their own RIR assigned 929 address space for CGN zone addressing if [RFC1918] addresses pose 930 technical challenges in their network. It is not recommended that 931 operators use 'squat space', as it may pose additional challenges 932 with filtering and policy control [RFC6598]. 934 5.4.1. CGN Deployment Considerations 936 CGN is often considered undesirable by operators but required in many 937 cases. An operator who needs to deploy CGN capabilities should 938 consider the impacts of the function to the network. CGN is often 939 deployed in addition to running IPv4 services and should not 940 negatively impact the already working Native IPv4 service. CGNs will 941 be needed at low scale at first and grow to meet the demands based on 942 traffic and connection dynamics of the subscriber, content and 943 network peers. 945 The operator may want to deploy CGNs more centrally at first and then 946 scale the system as needed. This approach can help conserve costs of 947 the system limiting the deployed base and scaling it based on actual 948 traffic demand. The operator should use a deployment model and 949 architecture which allows the system to scale as needed. 951 +--------+ ----- 952 | | / \ 953 | CGN | | | 954 - - -> + + < -> | | 955 +---------+ / | | | | 956 | CPE | <- - - / +--------+ | IPv4 | 957 | | ^ | | 958 |---------+ | | Net | 959 +--------+ Centralized | | 960 +---------+ | | CGN | | 961 | | | CGN | | | 962 | CPE | <- > + + <- - - - - - - > | | 963 |---------+ | | \ / 964 +--------+ ----- 965 ^ 966 | 967 Distributed CGN 969 Figure 7: CGN Deployment: Centralized vs. Distributed 971 The operator may be required to log translation information 972 [I-D.ietf-behave-lsn-requirements]. This logging may require 973 significant investment in external systems which ingest, aggregate 974 and report on such information [I-D.donley-behave-deterministic-cgn]. 976 Since CGN has noticeable impacts on certain applications [I-D.donley- 977 nat444-impacts], operators may deploy CGN only for those subscribers 978 who may be less affected by CGN (if possible). 980 5.5. Phase 3 - IPv6-Only 982 Once Native IPv6 is widely deployed in the network and well-supported 983 by tools, staff, and processes, an operator may consider supporting 984 only IPv6 to all or some subscriber endpoints. During this final 985 phase, IPv4 connectivity may or may not need to be supported, 986 depending on the conditions of the network, subscriber demand and 987 legacy device requirements. If legacy IPv4 connectivity is still 988 demanded (e.g. for older nodes), DS-Lite [RFC6333] may be used to 989 tunnel the traffic. If IPv4 connectivity is not required, but access 990 to legacy IPv4 content is, then NAT64 [RFC6144][RFC6146] can be used. 992 5.5.1. DS-Lite 994 DS-Lite allows continued access for the IPv4 subscriber base using 995 address sharing for IPv4 Internet connectivity, but with only a 996 single layer of translation, compared to CGN/NAT444. This mode of 997 operation also removes the need to directly supply subscriber 998 endpoints with an IPv4 address, potentially simplifying the 999 connectivity to the customer (single address family) and supporting 1000 IPv6 only addressing to the CPE. 1002 The operator can also move Dual Stack endpoints to DS-Lite 1003 retroactively to help optimize the IPv4 address sharing deployment by 1004 removing the IPv4 address assignment and routing component. To 1005 minimize traffic needing translation, the operator should have 1006 already moved most content to IPv6 before the IPv6-only phase is 1007 implemented. 1008 +--------+ ----- 1009 | | / \ 1010 Encap IPv4 Flow | AFTR | | IPv4 | 1011 -------+ +---+ Net | 1012 +---------+ / | | \ / 1013 | | / +--------+ ----- 1014 | DS-Lite +------- ----- 1015 | | / \ 1016 | Client | IPv6 Flow | IPv6 | 1017 | +-------------------------------| Net | 1018 | | \ / 1019 +---------+ ----- 1021 Figure 8: DS-Lite Basic Model 1023 If the operator had previously decided to enable a CGN/NAT444 1024 deployment, it may be able to co-locate the AFTR and CGN/NAT444 1025 processing functions within a common network location to simplify 1026 capacity management and the engineering of flows. This case may be 1027 evident in a later transition stages when an operator chooses to 1028 optimize its network and IPv6-only operation is feasible. 1030 5.5.2. DS-Lite Deployment Considerations 1032 The same deployment considerations associated with Native IPv6 1033 deployments apply to DS-Lite and NAT64. IPv4 will now be dependent 1034 on IPv6 service quality, so the IPv6 network and services must be 1035 running well to ensure a quality experience for the end subscriber. 1036 Tools and processes will be needed to manage the encapsulated IPv4 1037 service. If flow analysis is required for IPv4 traffic, this may be 1038 enabled at a point beyond the AFTR (after de-capsulation) or DS-Lite 1039 [RFC6333] aware equipment is used to process traffic midstream. 1041 +---------+ IPv6 Encapsulation +------------+ 1042 | + - - - - - - - - - - -+ | 1043 | AFTR +----------------------+ AFTR +--------- 1044 | | IPv4 Packet | | IPv4 Packet 1045 | Client +----------------------+ +--------- 1046 | + - - - - - - - - - - -+ | ^ 1047 +---------+ ^ ^ +------------+ | 1048 | | | 1049 | | | 1050 IPv6 IP (Tools/Mgmt) | IPv4 Packet Flow Analysis 1051 | 1052 Midstream IPv4 Packet Flow Analysis (Encapsulation Aware) 1054 Figure 9: DS-Lite Tools and Flow Analysis 1056 DS-Lite [RFC6333] also requires client support on the subscriber 1057 premises device. The operator must clearly articulate to vendors 1058 which technologies will be used at which points, how they interact 1059 with each other at the CPE, and how they will be provisioned. As an 1060 example, an operator may use 6RD in the outset of the transition, 1061 then move to Native Dual Stack followed by DS-Lite. 1063 DS-Lite [RFC6333], as any tunneling option, is subject to a reduced 1064 MTU so operators need to plan to manage this environment. Additional 1065 considerations for DS-Lite deployments can be found in. 1066 [I-D.ietf-softwire-dslite-deployment] 1068 5.5.3. NAT64 Deployment Considerations 1070 The deployment of NAT64 assumes the network assigns an IPv6 address 1071 to a network endpoint that is translated to an IPv4 address to 1072 provide connectivity to IPv4 Internet services and content. 1073 Experiments such as the one described in [RFC6586] highlight issues 1074 related to IPv6-only deployments due to legacy IPv4 APIs and IPv4 1075 literals. Many of these issues will be resolved by the eventual 1076 removal of this undesired legacy behavior. Operational deployment 1077 models, considerations and experiences related to NAT64 have been 1078 documented in [I-D.chen-v6ops-nat64-experience]. 1080 +--------+ ----- 1081 | | / \ 1082 IPv6 Flow | NAT64 | | IPv4 | 1083 -------+ DNS64 +---+ Net | 1084 +---------+ / | | \ / 1085 | | / +--------+ ----- 1086 | IPv6 +------- ----- 1087 | | / \ 1088 | Only | IPv6 Flow | IPv6 | 1089 | +-------------------------------| Net | 1090 | | \ / 1091 +---------+ ----- 1093 Figure 10: NAT64/DNS64 Basic Model 1095 To navigate around some of the limitations of NAT64 when dealing with 1096 legacy IPv4 applications, the operator may choose to implement 1097 464XLAT [I-D.ietf-v6ops-464xlat] if possible. As support for IPv6 on 1098 subscriber equipment and content increases, the efficiency of NAT64 1099 increases by reducing the need to translate traffic. The NAT64 1100 deployment would see an overall decline in usage as more traffic is 1101 promoted to IPv6-to-IPv6 native communication. NAT64 may play an 1102 important part of an operator's late stage transition, as it removes 1103 the need to support IPv4 on the access network and provides a solid 1104 go-forward networking model. 1106 It should be noted, as with any technology which utilizes address 1107 sharing, that the IPv4 public pool sizes (IPv4 transport addresses 1108 per [RFC6146]) can pose limits to IPv4 server connectivity for the 1109 subscriber base. Operators should be aware that some IPv4 growth in 1110 the near term is possible, so IPv4 translation pools need to be 1111 monitored. 1113 6. IANA Considerations 1115 No IANA considerations are defined at this time. 1117 7. Security Considerations 1119 Operators should review the documentation related to the technologies 1120 selected for IPv6 transition. In those reviews, operators should 1121 understand what security considerations are applicable to the chosen 1122 technologies. As an example, [RFC6169] should be reviewed to 1123 understand security considerations around tunnelling technologies. 1125 8. Acknowledgements 1127 Special thanks to Wes George, Chris Donley, Christian Jacquenet and 1128 John Brzozowski for their extensive review and comments. 1130 Thanks to the following people for their textual contributions, 1131 guidance and comments: Jason Weil, Gang Chen, Nik Lavorato, John 1132 Cianfarani, Chris Donley, Tina TSOU, Fred Baker and Randy Bush. 1134 9. References 1136 9.1. Normative References 1138 [RFC6180] Arkko, J. and F. Baker, "Guidelines for Using IPv6 1139 Transition Mechanisms during IPv6 Deployment", RFC 6180, 1140 May 2011. 1142 9.2. Informative References 1144 [I-D.chen-v6ops-nat64-experience] 1145 Chen, G., Cao, Z., Byrne, C., Xie, C., and D. Binet, 1146 "NAT64 Operational Experiences", 1147 draft-chen-v6ops-nat64-experience-03 (work in progress), 1148 July 2012. 1150 [I-D.donley-behave-deterministic-cgn] 1151 Donley, C., Grundemann, C., Sarawat, V., and K. 1152 Sundaresan, "Deterministic Address Mapping to Reduce 1153 Logging in Carrier Grade NAT Deployments", 1154 draft-donley-behave-deterministic-cgn-04 (work in 1155 progress), June 2012. 1157 [I-D.donley-nat444-impacts] 1158 Donley, C., Howard, L., Kuarsingh, V., Berg, J., and U. 1159 Colorado, "Assessing the Impact of Carrier-Grade NAT on 1160 Network Applications", draft-donley-nat444-impacts-04 1161 (work in progress), May 2012. 1163 [I-D.ietf-behave-lsn-requirements] 1164 Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., 1165 and H. Ashida, "Common requirements for Carrier Grade NATs 1166 (CGNs)", draft-ietf-behave-lsn-requirements-09 (work in 1167 progress), June 2012. 1169 [I-D.ietf-softwire-dslite-deployment] 1170 Lee, Y., Maglione, R., Williams, C., Jacquenet, C., and M. 1171 Boucadair, "Deployment Considerations for Dual-Stack 1172 Lite", draft-ietf-softwire-dslite-deployment-06 (work in 1173 progress), March 2012. 1175 [I-D.ietf-v6ops-464xlat] 1176 Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: 1177 Combination of Stateful and Stateless Translation", 1178 draft-ietf-v6ops-464xlat-07 (work in progress), July 2012. 1180 [I-D.ietf-v6ops-6204bis] 1181 Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic 1182 Requirements for IPv6 Customer Edge Routers", 1183 draft-ietf-v6ops-6204bis-10 (work in progress), May 2012. 1185 [I-D.jjmb-v6ops-comcast-ipv6-experiences] 1186 Brzozowski, J. and C. Griffiths, "Comcast IPv6 Trial/ 1187 Deployment Experiences", 1188 draft-jjmb-v6ops-comcast-ipv6-experiences-02 (work in 1189 progress), October 2011. 1191 [I-D.kuarsingh-v6ops-6to4-provider-managed-tunnel] 1192 Kuarsingh, V., Lee, Y., and O. Vautrin, "6to4 Provider 1193 Managed Tunnels", 1194 draft-kuarsingh-v6ops-6to4-provider-managed-tunnel-07 1195 (work in progress), July 2012. 1197 [I-D.townsley-v6ops-6rd-sunsetting] 1198 Cassen, A. and M. Townsley, "6rd Sunsetting", 1199 draft-townsley-v6ops-6rd-sunsetting-00 (work in progress), 1200 November 2011. 1202 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1203 E. Lear, "Address Allocation for Private Internets", 1204 BCP 5, RFC 1918, February 1996. 1206 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1207 (IPv6) Specification", RFC 2460, December 1998. 1209 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 1210 via IPv4 Clouds", RFC 3056, February 2001. 1212 [RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", 1213 RFC 3068, June 2001. 1215 [RFC3484] Draves, R., "Default Address Selection for Internet 1216 Protocol version 6 (IPv6)", RFC 3484, February 2003. 1218 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 1219 Network Address Translations (NATs)", RFC 4380, 1220 February 2006. 1222 [RFC4942] Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/ 1223 Co-existence Security Considerations", RFC 4942, 1224 September 2007. 1226 [RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 1227 Infrastructures (6rd)", RFC 5569, January 2010. 1229 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 1230 Infrastructures (6rd) -- Protocol Specification", 1231 RFC 5969, August 2010. 1233 [RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in 1234 Customer Premises Equipment (CPE) for Providing 1235 Residential IPv6 Internet Service", RFC 6092, 1236 January 2011. 1238 [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 1239 IPv4/IPv6 Translation", RFC 6144, April 2011. 1241 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 1242 NAT64: Network Address and Protocol Translation from IPv6 1243 Clients to IPv4 Servers", RFC 6146, April 2011. 1245 [RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, "Security 1246 Concerns with IP Tunneling", RFC 6169, April 2011. 1248 [RFC6264] Jiang, S., Guo, D., and B. Carpenter, "An Incremental 1249 Carrier-Grade NAT (CGN) for IPv6 Transition", RFC 6264, 1250 June 2011. 1252 [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 1253 Roberts, "Issues with IP Address Sharing", RFC 6269, 1254 June 2011. 1256 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 1257 Stack Lite Broadband Deployments Following IPv4 1258 Exhaustion", RFC 6333, August 2011. 1260 [RFC6343] Carpenter, B., "Advisory Guidelines for 6to4 Deployment", 1261 RFC 6343, August 2011. 1263 [RFC6540] George, W., Donley, C., Liljenstolpe, C., and L. Howard, 1264 "IPv6 Support Required for All IP-Capable Nodes", BCP 177, 1265 RFC 6540, April 2012. 1267 [RFC6586] Arkko, J. and A. Keranen, "Experiences from an IPv6-Only 1268 Network", RFC 6586, April 2012. 1270 [RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and 1271 M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address 1272 Space", BCP 153, RFC 6598, April 2012. 1274 Authors' Addresses 1276 Victor Kuarsingh (editor) 1277 Rogers Communications 1278 8200 Dixie Road 1279 Brampton, Ontario L6T 0C1 1280 Canada 1282 Email: victor.kuarsingh@gmail.com 1283 URI: http://www.rogers.com 1285 Lee Howard 1286 Time Warner Cable 1287 13820 Sunrise Valley Drive 1288 Herndon, VA 20171 1289 US 1291 Email: lee.howard@twcable.com 1292 URI: http://www.timewarnercable.com