idnits 2.17.1 draft-kuarsingh-wireline-incremental-ipv6-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 9, 2011) is 4582 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-v6ops-v4v6tran-framework' is defined on line 1107, but no explicit reference was found in the text == Unused Reference: 'I-D.donley-nat444-impacts' is defined on line 1119, but no explicit reference was found in the text == Unused Reference: 'I-D.jjmb-v6ops-comcast-ipv6-experiences' is defined on line 1131, but no explicit reference was found in the text == Unused Reference: 'I-D.kuarsingh-v6ops-6to4-provider-managed-tunnel' is defined on line 1137, but no explicit reference was found in the text == Unused Reference: 'I-D.weil-shared-transition-space-request' is defined on line 1143, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-donley-nat444-impacts-01 == Outdated reference: A later version (-10) exists of draft-ietf-behave-lsn-requirements-03 == Outdated reference: A later version (-07) exists of draft-kuarsingh-v6ops-6to4-provider-managed-tunnel-04 == Outdated reference: A later version (-15) exists of draft-weil-shared-transition-space-request-07 -- 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 (~~), 10 warnings (==), 3 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 October 9, 2011 5 Expires: April 11, 2012 7 Wireline Incremental IPv6 8 draft-kuarsingh-wireline-incremental-ipv6-02 10 Abstract 12 Operators worldwide are in various stages of preparing for, or 13 deploying IPv6 into their networks. The operators often face 14 challenges related to both IPv6 introduction along with a growing 15 risk of IPv4 run out within their organizations. The overall problem 16 for many of there operators will be to meet the simultaneous needs of 17 IPv6 connectivity and continue support for IPv4 connectivity for 18 legacy devices and systems with a depleting supply of IPv4 addresses. 19 The overall transition will take most networks form an IPv4-Only 20 environment to a dual stack network environment and potentially an 21 IPv6-Only operating mode. This document helps provide a framework 22 for Wireline providers who may be faced with many of these challenges 23 as they consider what IPv6 transition technologies to use, how to use 24 the selected technologies and when to use them. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on April 11, 2012. 43 Copyright Notice 45 Copyright (c) 2011 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Operator Assumptions . . . . . . . . . . . . . . . . . . . . . 5 63 4. Reasons and Considerations for a Phased Approach . . . . . . . 5 64 4.1. Relevance of IPv6 and IPv4 . . . . . . . . . . . . . . . . 6 65 4.2. IPv4 Resource Challenges . . . . . . . . . . . . . . . . . 6 66 4.3. IPv6 Introduction and Maturity . . . . . . . . . . . . . . 7 67 4.4. Service Management . . . . . . . . . . . . . . . . . . . . 8 68 4.5. Sub-Optimal Operation of Transition Technologies . . . . . 8 69 5. IPv6 Transition Technology Analysis . . . . . . . . . . . . . 9 70 5.1. Automatic Tunnelling using 6to4 and Teredo . . . . . . . . 9 71 5.2. Carrier Grade NAT (NAT444) . . . . . . . . . . . . . . . . 10 72 5.3. 6RD . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 73 5.4. Native Dual Stack . . . . . . . . . . . . . . . . . . . . 12 74 5.5. DS-Lite . . . . . . . . . . . . . . . . . . . . . . . . . 12 75 5.6. NAT64 . . . . . . . . . . . . . . . . . . . . . . . . . . 13 76 6. IPv6 Transition Phases . . . . . . . . . . . . . . . . . . . . 13 77 6.1. Phase 0 - Foundation . . . . . . . . . . . . . . . . . . . 14 78 6.1.1. Phase 0 - Foundation: Training . . . . . . . . . . . . 14 79 6.1.2. Phase 0 - Foundation: Routing . . . . . . . . . . . . 15 80 6.1.3. Phase 0 - Foundation: Network Policy and Security . . 15 81 6.1.4. Phase 0 - Foundation: Transition Architecture . . . . 15 82 6.1.5. Phase 0- Foundation: Tools and Management . . . . . . 16 83 6.2. Phase 1 - Tunnelled IPv6 . . . . . . . . . . . . . . . . . 16 84 6.2.1. 6RD Deployment Considerations . . . . . . . . . . . . 17 85 6.3. Phase 2: Native Dual Stack . . . . . . . . . . . . . . . . 20 86 6.3.1. Native Dual Stack Deployment Considerations . . . . . 20 87 6.4. Intermediate Phase for CGN . . . . . . . . . . . . . . . . 21 88 6.4.1. CGN Deployment Considerations . . . . . . . . . . . . 22 89 6.5. Phase 3 - Tunnelled IPv4 . . . . . . . . . . . . . . . . . 23 90 6.5.1. DS-Lite Deployment Considerations . . . . . . . . . . 24 91 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 92 8. Security Considerations . . . . . . . . . . . . . . . . . . . 25 93 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 94 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 95 10.1. Normative References . . . . . . . . . . . . . . . . . . . 25 96 10.2. Informative References . . . . . . . . . . . . . . . . . . 26 97 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 27 99 1. Introduction 101 IPv6 represents the strategic IP protocol version which will meet the 102 addressing needs of the Internet into the future. Many operators are 103 already working on implementing IPv6 within their networks, and other 104 operators may just be starting this process. A solid IPv6 plan will 105 need to include both the baseline requirements to enable IPv6 within 106 the network, but must also include facilities to provide continued 107 support for IPv4 connectivity. Given the vast number of 108 technological options now available to operators for transition to 109 IPv6, the task may seem daunting when attempting to identify which 110 technologies are appropriate for a given network, and how these 111 technologies can be introduced. 113 This draft sets out to help operators who may be just starting the 114 evaluation process or well underway, by identifying which 115 technologies can be used in an incremental fashion to transition from 116 an IPv4-only environment to an efficient IPv6/IPv4 dual stack 117 environment. Some plans may also include IPv6-Only end state 118 targets, but there is not clear consensus on how long IPv4 support is 119 required. Although no single plan will work for for all operators, 120 generically, options listed herein provide a baseline which can be 121 included in many plans. 123 This draft is specifically catered towards wireline environments 124 which may use technologies such as Cable, DSL and/or Fibre as the 125 access method to the end consumer. This draft also attempts to 126 follow the methodologies set out in [I-D.ietf-v6ops-v4v6tran- 127 framework] to identify how the technologies can be used individual 128 and in combination. This document also attempts to follow the 129 principles laid out in [RFC6180] which provides guidance on using 130 IPv6 transition mechanisms. This document does not show the IPv6- 131 Only end state architecture since it is years away from existing 132 mainstream Internet service connections. This document will show how 133 tunnelling using 6RD [RFC5969] and DS-Lite [RFC6333] as well as 134 translation via CGN can be used with Native Dual Stack to deliver 135 effective IPv4 and IPv6 services in an evolving wireline network. 137 2. Motivation 139 Wireline Operators are increasingly becoming aware of the need to 140 support IPv6. The depletion of unassigned IPv4 addresses within IANA 141 and the RIRs has highlighted the need to move beyond IPv4-Only 142 operation. In many operator environments, the main task will be the 143 addition of IPv6 into the network. As straightforward as this task 144 may seem, it will require forethought and planning. However, of 145 greater concern is that the introduction of IPv6 may need to take 146 place in a volatile environment where IPv4 resources are depleted 147 complicating what technologies can be used, and how Dual Stack 148 services may be offered to customers. 150 Operators will want to understand which of the prevailing 151 technologies can be used in a changing network environment while 152 adapting to the needs and conditions of the network. IPv6 will be a 153 focal point in the Operators plans, but the realities of IPv4, and 154 it's demand by legacy equipment and system needs to be acknowledged 155 and managed. The Operator's main goal will be to maintain quality IP 156 services to Internet customers while the world moves from a 157 predominately IPv4 centric system to a Dual Dtack IPv6/IPv4 system 158 and eventually to an IPv6 centric world. The IPv6 centric world may 159 not preclude the use of IPv4 altogether, but focuses on a time where 160 most functions and and will be delivered over IPv6. 162 3. Operator Assumptions 164 For the purposes of this document, it's assumed the operator is 165 considering deploying IPv6. It is also assumed that the operator has 166 a legacy IPv4 customer base which will continue to exist and for a 167 long period of time (years). Other assumptions include that that 168 operator will want to minimize the level of disruption to the 169 existing and new customers by minimizing number of technologies and 170 functions that are needed to mediate any given set of customer flows 171 (overall preference for Native IP flows). 173 These assumptions translate into analyzing technologies and 174 subsequently selecting technologies which minimize how many flows 175 must be tunnelled, translated or intercepted at any given time. 176 Technology selections would be made to manage the non dominant flows 177 and allow Native IP routing (IPv4 and/or IPv6) to manage the bulk of 178 the traffic. This allows the operator to minimize the cost of IPv6 179 transition technologies by containing the scale required by the 180 relevant systems. 182 Not all operators may see these assumptions as valid, but most 183 operators who have built and optimized their networks for efficient 184 delivery of IP traffic from their customer base to the Internet (and 185 vice versa) would typically agree with the approch suggested herein. 187 4. Reasons and Considerations for a Phased Approach 189 When faced with the challenges described in the Introductory portion 190 of this document, operators may need to consider a phased approach to 191 IPv6 service introduction and IPv4 service continuance. Both IPv4 192 and IPv6 play critical role in connectivity throughout the IPv6 193 transition yet each protocol will be based with challenges as time 194 progresses. Some of these challenges include the depletion of IPv4 195 which will occur in many networks long before most traffic is able to 196 delivered over IPv6. IPv6 will also be added into many networks and 197 pose many operational challenges to organizations and customers since 198 much of the hardware, software and processes will be relatively new. 199 Connectivity modes will move from single stack to dual stack in the 200 home further challenging the transition as operators contend with 201 many functional behaviours in the home network. 203 These challenges, as noted, will occur over time which means the 204 operator's plans need to address the every changing requirements of 205 the network and customer demand. The following few sections 206 highlight some of the key reasons why a phase approach to IPv6 207 transition may be warranted and desired. 209 4.1. Relevance of IPv6 and IPv4 211 The reality for operators over the next few years will be that both 212 IPv4 and IPv6 will play a role in the Internet experience. Although 213 many IPv6 advocates seek to move the Internet to IPv6 quickly, the 214 fact that many older operating systems and hardware support IPv4-Only 215 operating modes will need to be accepted and managed. Internet 216 customers don't buy IPv4 or IPv6 connections, they buy Internet 217 connections, which demands the need to support both IPv4 and IPv6 for 218 as long at the customer's home network demands such support. 220 The Internet is made of of many interconnecting systems, networks, 221 hardware, software and content sources - all of which will move to 222 IPv6 at different rates. The Operator's mandate during this time of 223 transition will be to support connectivity to both IPv6 and IPv4 224 through various technological means. The operator may be able to 225 leverage one or the other protocol to help bridge connectivity, but 226 the home network will demand both IPv4 and IPv6 for the foreseeable 227 future. 229 4.2. IPv4 Resource Challenges 231 Since connectivity to IPv4-Only endpoints and/or content will remain 232 prevalent for a long period of time, IPv4 resource challenges are of 233 key concern to operators. The lack of new IPv4 addressees for 234 additional endpoints means that growth in demand of IPv4 connections 235 in some networks will be based on address sharing. 237 Networks are growing at different rates based on a number of factors 238 which may be related to emerging markets and/or proliferation of 239 Internet based services and endpoints. Given that reality, growth on 240 the Internet will continue. IPv4 address constraints will likely 241 impact many if not most operators at some point. This will play an 242 important role when considering what technologies are viable as the 243 transition period moves on. Of note will be any use of technologies 244 which rely on IPv4 as the mechanism to supply IPv6 services such as 245 6RD. Also, if Native Dual Stack is considered by the operator, 246 challenges on the IPv4 path is also of concern. 248 Some operators may be able to achieve some level of IPv4 address 249 reclamation through various levels of efficiency in the network and 250 replacement of GUA assignments with private addresses such as those 251 in [RFC1918], but these measures are tactical in nature and do not 252 support a longer term strategic option. The lack of new IPv4 253 addresses will therefore force operators to support some form of IPv4 254 address sharing and may impact technological options for transition 255 once the operator runs out of new IPv4 addresses for assignment. 257 4.3. IPv6 Introduction and Maturity 259 Operators will want to or be forced to support IPv6 at some point. 260 The introduction of IPv6 will require the operationalization of IPv6. 261 The IPv4 environment we have today was built over many years and was 262 matured by experience. Although many of these experiences are 263 transferable from IPv4 to IPv6, new experience specific to IPv6 will 264 be needed. 266 Engineering and Operational staff will need to become acclimatized to 267 IPv6 which and gain this needed experience. During this ramp up 268 period, Operators will need to be aware that instability may occur in 269 the IPv6 deployment and should be taking this into account when 270 selecting what technologies are viable during early transition. 271 Operators may not want to subject their mature IPv4 service to a "new 272 IPv6" path initially while it may be going through growing pains. 273 This plays a role during initial transition when considering 274 technologies which require IPv6 to support IPv4 services such as DS- 275 Lite. 277 Of consideration as well will be the reality that some of these 278 technologies are new and require refinement within running code and 279 operations. Deployment experience may be needed to vet these 280 technologies out and stabilize them in production environments. Many 281 supporting systems are also under development and have newly 282 developed IPv6 functionality including vendor implementations of 283 DHCPv6, Management Tools, Monitoring Systems, Diagnostic systems, 284 along with other systems. 286 Although the base technological capabilities exist to enable and run 287 IPv6 in most environments; until such time as each key technical 288 member of an operator's organization can identify IPv6, understand 289 it's relevance to the IP Service offering, how it operates and how to 290 troubleshoot it - it's still maturing. 292 4.4. Service Management 294 Services are managed within most networks and is often based on the 295 gleaning and monitoring of IPv4 addresses. Operators will need to 296 address such management tools, troubleshooting methods and storage 297 facilities (such as databases) to deal with not just a new address 298 type containing 128-bits, but often both IPv4 and IPv6 at the same 299 time. 301 With any Dual Stack service - whether Native, 6RD based, DS-Lite 302 based or otherwise - two address families need to be managed 303 simultaneously to help provide for the full Internet experience. In 304 the early transition phases, it's quite likely that many systems will 305 be missed and that IPv6 services will go un-monitored and impairments 306 undetected. 308 These issues may be of consideration when selecting technologies 309 which require IPv6 as the base protocol to delivery IPv4. 310 Instability on the IPv6 service in such case would impact IPv4 311 services. 313 4.5. Sub-Optimal Operation of Transition Technologies 315 Yet another important concept for an operator to understand is the 316 difference between a native path and a path which requires a 317 transition technology to bridge certain connectivity. Native paths 318 are often well understood and most networks are optimized to send 319 traffic to and from the customer (to/from Internet) in an efficient 320 manner. 322 The addition of transition technologies may alter the normal path of 323 traffic and delay or hinder the IP flows due to tunnelling and 324 translation operation. New logical nodes in the network will be 325 needed to supply the full IP path, all of which will be slower and 326 less agile then the native alternative. 328 The consideration for this issue may be that an operator minimize the 329 amount of traffic that needs to be delivered over a transition 330 technology platform by optimizing the technologies deployed over 331 time. During earlier phases of transition, IPv6 traffic volumes may 332 be lower, so tunnelling of IPv6 traffic may be reasonable. Over 333 time, these traffic volumes will increase, raising the benefits of 334 native delivery of this traffic. Also, as IPv4 content diminishes, 335 translation and tunnelling of this protocol may become more tolerable 336 when considering performance. 338 Operators may wish to align their own internal service delivery with 339 the deployment of transition technologies including Native IPv6 and 340 potential CGN deployments. An operator may not want to enable many 341 of their services, especially high traffic flow services, for IPv6 342 delivery if IPv6 tunnelling is used. The operator may which to 343 constrain such customers to IPv4 delivery until Native IPv6 is 344 available. Also, the operation may likewise which to constrain 345 customers to IPv6 content versus IPv4 if CGN is deployed in the 346 future to deal with IPv4 address depletion. 348 5. IPv6 Transition Technology Analysis 350 Understanding the main IPv6 transition technologies and those related 351 to dealing with IPv4 run out should be a primary goal of any 352 operator. Although this draft is not designed to list all options or 353 to provide a full technical analysis of each of the identified 354 technologies, it provides a brief description and explains some of 355 the mainstream technological options can be used in an operator 356 network. 358 In this analysis, common automatic tunnelling, provider controlled 359 tunnelling, translation and native modes of operations are 360 considered. The analysis also includes technologies such as NAT64 361 which may not be appropriate for near term wireline transition due to 362 the nature of the home network. This analysis is also focused 363 primarily on the applicability of technologies to deliver residential 364 services and less focused on commercial or support for the provider's 365 infrastructure. It is assume the operator is able to Dual Stack 366 their own core network and transition their own services to support 367 IPv6. 369 5.1. Automatic Tunnelling using 6to4 and Teredo 371 Operators may not be actively deploying IPv6, but automatic 372 mechanisms do exist on deployed operating systems and hardware that 373 should be of note. Such technologies include 6to4 described within 374 [RFC3056] which is mostly commonly used in a deployment mode using 375 anycast relays as described in [RFC3068]. Additionally, Teredo 376 [RFC4380] is also used widely by many Internet hosts as a means to 377 reach the IPv6 world when no native or operator provided path is made 378 present. 380 The operator may not want or have intended for these technologies to 381 be active in their networks, but should be aware that the traffic 382 exists. The operator may be inclined to provide the best possible 383 experience for endpoints using automatic tunnelling technologies. 384 Documents such as [RFC6343] have been written to help operators 385 understand observed problems and provide guidelines on how to manage 386 such protocols. An Operator may want to incrementally provide local 387 relays for 6to4 and/or Teredo to help improve the protocol's 388 performance for ambient traffic utilizing these IPv6 connectivity 389 methods. Experiences such as those described in [I-D.jjmb-v6ops- 390 comcast-ipv6-experiences] show that local relays have proved 391 beneficial to 6to4 protocol performance. 393 Operators should also be aware of breakage cases for 6to4 if non- 394 RFC1918 address are used for CGN zones. Many off the shelf CPEs and 395 operating systems may turn on 6to4 without a valid return path to the 396 originating (local) host. This particular use can is likely to occur 397 if squat space (not assigned to local operator) is used in place of 398 RFC1918 space or if Shared CGN Space is used [I-D.weil-shared- 399 transition-space-request]. The operator can used options such as 400 6to4-PMT to help mitigate this issue as described in [I-D.kuarsingh- 401 v6ops-6to4-provider-managed-tunnel] or attempt to block 6to4 402 operation entirely. 404 5.2. Carrier Grade NAT (NAT444) 406 Carrier Grade NAT (GGN), specifically as deployed in a NAT444 407 scenario [I-D.ietf-behave-lsn-requirements], is also a relevant 408 technology. Although CGN is not a IPv6 specific function, it may 409 prove beneficial for those operators who offer Dual Stack services to 410 customer endpoints once they exhaust their pools of IPv4 addresses. 411 CGNs, and address sharing overall, are known to cause certain 412 challenges for the IPv4 service path as described in documents like 413 [RFC6269], but will often be necessary for a time. 415 In a network where IPv4 address availability is low or no new 416 addressees can be assigned to Internet hosts, a CGN deployment may be 417 a viable way to provide continued access to the IPv4 path. Other 418 technologies may also be used, but a provider may choose to use this 419 method earlier on since it's a well understood method of delivering 420 IPv4 connectivity - notwithstanding the challenges of CGN and address 421 sharing. Some of the advantages of using CGN include the 422 similarities in provisioning and activation IPv4 hosts within a 423 network and operational procedures in managing such hosts or CPEs 424 (i.e. DHCPv6, DNSv4, TFTP, TR-069 etc). 426 When considered in the overall IPv6 transition, CGN may play a vital 427 role in the delivery of Internet services. 429 5.3. 6RD 431 6RD as described in [RFC5969] does provide a quick and effective way 432 to deliver IPv6 services to access network endpoints which do not yet 433 support Native IPv6 on the operator's access network (WAN Side 434 connection). 6RD provides tunnelled connectivity to IPv6 over the 435 existing IPv4 path. The lack of Native IPv6 support at customer 436 premise may be related to technological challenges of delivering IPv6 437 on a given access type or related to other operational or technical 438 impediments that may existing in the operator's network. 440 6RD defiantly offers a solid early transition option to operators by 441 eliminating the bottle neck of needing to deploy Native IPv6 to the 442 access edge and customer CPE. Over time, as the access edge is 443 upgraded and customer premise equipment is replaced, 6RD can be 444 superseded by Native IPv6 access. 6RD can be delivered along with 445 CGN, but this mode of operation would be a sub-optimal way of 446 delivering service since the operator would then need to relay all 447 IPv6 traffic as well as provide NAT functionally for all Internet 448 bound IPv4 flows. 450 6RD may also be seen as advantageous during early transition while 451 IPv6 traffic volumes are low. During this period, the operator can 452 gain experience with IPv6 on the core and improve their peering 453 framework to match those of the IPv4 service. Scaling of 6RD may be 454 required by adding relays to the operator's network, but since 6RD is 455 stateless, this task is quite manageable. In the case where CGN is 456 used, there are stateful considerations to be made on the NATed IPv4 457 path. 459 Operators may want to use 6RD, as noted, while traffic volumes are 460 low and while internal services are mainly on IPv4. As higher 461 capacities are reached on the IPv6 path, the operator may want to 462 move away from delivering heavy loads on a tunnelled connection. 6RD 463 can continue to run indefinitely if the operator wishes to continue 464 this service, but over time, Native IPv6 would be a much more 465 efficient way of delivering robust IPv6 services. 467 Of specific consideration for 6RD is the client support required 468 needed at the CPE. Most currently deployed CPEs do not have 6RD 469 client functionality built into them and may or may not be 470 upgradable. 6RD deployments would most likely require the replacement 471 of the home CPE. An advantage of this technology over DS-Lite is 472 that the WAN side interface does not need to implement IPv6 to 473 function correctly which may make it easier to deploy to field 474 hardware which is restricted in memory footprint, processing power 475 and storage space. 6RD will also require parameter configuration 476 which can be powered by the operator through DHCPv4, manually 477 provisioned on the CPE or automatically through some other means. 478 Manual provisioning would likely limit deployment scale. 480 5.4. Native Dual Stack 482 Native Dual Stack is often referred to as the "Gold Standard" of IPv6 483 and IPv4 delivery. It is a method of service delivery which is 484 already used in many existing IPv6 deployments. Native Dual Stack 485 does however require that Native IPv6 be delivered to the customer 486 premise. This technology option is desirable in many cases and can 487 be used immediately if the access network and customer premise 488 equipment supports Native IPv6 to the operators access network. 490 As time progresses, continued delivery new Native Dual Stack service 491 connections may be challenging should the operator run out of free 492 IPv4 addresses to assign to CPEs. For a sub-set of the IPv6 Native 493 Dual Stack Customers, operators may include NATed IPv4 path as an 494 assist, leveraging CGN. Delivering Native Dual Stack would require 495 the operator's core and access network support IPv6. Additionally, 496 other systems like DHCPv6, DNS, and diagnostic/management facilities 497 need to be upgraded to support IPv6. The upgrade of such systems may 498 often not be trivial. 500 5.5. DS-Lite 502 DS-Lite, as described in [RFC6333], is an architecturally desirable 503 way of delivery both IPv4 and IPv6 services in an IPv4 constrained 504 environment. DS-Lite is able to provide IPv4 services to customer 505 networks which are only addressed with IPv6. DS-Lite uses tunnelling 506 mechanisms to pass IPv4 traffic between the customer's network device 507 (often a CPE) and the IPv4 internet using a provider managed AFTR. 509 DS-Lite however can only be used where there are native IPv6 510 facilities to the customer premise endpoint. This may mean that the 511 technology's use may not be viable during early transition. The 512 operator may also not want to use DS-Lite immediately after IPv6 513 introduction as the organization may be development and maturing 514 their IPv6 environment and may not want to subject the customers IPv4 515 connection to the IPv6 path. This is likely an early transition 516 consideration and would diminish over time as IPv6 service delivery 517 is matured. The provider may also want to make sure that most of 518 their internal services, and external provider content is available 519 over IPv6 before deploying DS-Lite. This would lower the overall 520 load on the AFTR devices helping reduce cost and load on that layer 521 of the network. Nothing precludes an operator from using DS-Lite 522 earlier in the transition, but the operator needs to be aware of the 523 challenges that can arise. If DS-Lite is used during early 524 transition the operator will face scenario where they have support 525 personnel learning to troubleshoot IPv6 while this new protocol is 526 supporting the legacy IPv4 service. 528 One of the strongest benefits of DS-Lite is the technology's ability 529 to facilitate continued growth of IPv4 services if required without 530 the need to deploy more IPv4 addressees to customer endpoints. This 531 is quite advantageous as the transition period progresses and IPv4 532 resources become more and more challenging to secure. 534 Similar to 6RD, DS-Lite requires client support on the CPE to 535 function. Client functionality is likely to be more prevalent in the 536 future as IPv6 capable (WAN side) CPEs begin to penetrate the market. 537 This includes both retail and operator provided gateways. 539 5.6. NAT64 541 NAT64 as described in [RFC6146] provides the ability to connection 542 IPv6-Only connected clients and hosts to IPv4 Servers (or other like 543 hosts). This technology, although useful in many circumstances, is 544 not considered viable by many operators during early transition. 545 NAT64 requires that the client, host or by extension the home 546 network, supports IPv6-Only modes of operation. This type of 547 environment is not considered typical in most traditional Wireline 548 connections. 550 It is possible that in the future, NAT64 may become more viable for 551 Wireline provides as home networking environments support IPv6-Only 552 attachment modes, but until then, this technology is less useful for 553 mass deployments in Wireline networks. As noted earlier, alternate 554 technologies such as DS-Lite which still provide in-home IPv4 555 services though an IPv6-Only network (WAN) attachment are still of 556 strong consideration. 558 6. IPv6 Transition Phases 560 The Phases described in this document are not provided as a ridged 561 set of steps, but are considered a guideline which should be analyzed 562 by an operator planning their IPv6 transition. The phases presented 563 reflect the need to support IPv4 and IPv6 during the early to mid- 564 term transition. The phased approach as presented in this document, 565 attempts to match the most appropriate technologies for the various 566 phases of the transition. The other key point of note with respect 567 to this position on transition is the relationship between selected 568 IPv6 transition technologies and overall traffic flow volumes. 570 During early transition, it is possible IPv6 traffic volumes will be 571 present in most operator networks serving the Internet. As time 572 moves on more content is becoming available over IPv6 so this 573 variable must be monitored by the operator. The early low volume 574 conditions will most likely be attributable to IPv4-Only equipment in 575 the home network and the Operator's access network. During these 576 earlier time periods, technologies which "tunnel" IPv6 may be quite 577 appropriate as operators attempt to provide IPv6 before the access 578 network supports it . As time progresses and IPv6 traffic volumes 579 rise, it may be desirable to provide a Native path for IPv6 service 580 to better deal with the increased traffic volumes. Over time, IPv4 581 traffic volumes may be reduced as IPv6 traffic becomes the primary 582 load in the Network. As the IPv4 traffic volumes lower, the operator 583 may consider tunnelling this traffic if IPv4 resources are depleted 584 or in short supply. Since the traffic levels are low, the scale 585 needs to support this type of configuration would also be lower. 587 The overall objective with the phases provided is to also make sure 588 the operator has prepared a solid foundation for IPv6 Services and is 589 able to supply this in a timely manor to the customer base. Not all 590 technologies which are technical available to the operator are 591 included in this document and additional guidelines and information 592 on utilizing IPv6 transition mechanisms can also be found in 593 [RFC6180]. 595 6.1. Phase 0 - Foundation 597 An operator considering an IPv6 service offering must initially be 598 prepared to support it. These preparation steps are likely be to 599 somewhat unique to each operator, but some basic items are well 600 known, or at least common to most environments. These foundational 601 steps include those listed below. 603 6.1.1. Phase 0 - Foundation: Training 605 Training is one of the most important steps in preparing an 606 organization to support IPv6. Most resources in an organization have 607 little to no experience with IPv6. Resources in organizations may 608 only have a trivial understanding of IPv4 and given it's long history 609 on the Internet, most may not be familiar with the intricacies of IP. 610 Since there is likely to be many challenges with implementing IPv6 611 due to immature code on hardware and the evolution of many 612 applications and systems to support IPv6 - it is of utmost important 613 that organizations train their staff on IPv6 (and IP in general to 614 that point). 616 Training should also be provided within reasonable timelines from 617 actual IPv6 deployment. This means the operator needs to plan in 618 advance as they train the various parts of their organization. New 619 Technology and Engineering staff will require upfront training as 620 they plan and draw the designs for the network. Operation staff 621 which support the network and other systems need to be trained closer 622 to the deployment timeframes allowing them to more immediately use 623 their new found knowledge and limiting memory loss issues. Customer 624 support staff would require much more basic, but large scale training 625 as may organizations have massive call centres to support the 626 customer base. 628 6.1.2. Phase 0 - Foundation: Routing 630 The network infrastructure will need to be in place to support IPv6. 631 This includes the routed infrastructure along with addressing 632 principles, routing principles, peering and related network 633 functions. Since IPv6 is quite different from IPv4 in number of ways 634 including the number of addresses which are made available, careful 635 attention to a scalable and manageable architecture needs to be made. 636 Also, given that home networks environments will no longer receive a 637 token single address as is common in IPv4, operators will need to 638 understand the impacts of delegating larges sums of addresses 639 (Prefixes) to consumer endpoints. Delegating prefixes can be of 640 specific importance in access network environments where downstream 641 customers often move between access nodes, raising the concern of 642 frequent renumbering and/or managing movement of routed prefixes 643 within the network (common in Cable based networks). 645 6.1.3. Phase 0 - Foundation: Network Policy and Security 647 Like many principles, network policy and security needs to be 648 considered for IPv6. Although it is possible that many of the IPv4 649 policies may transfer transparently over to the IPv6 world, others 650 may not be straight forward. There is also a potential that new 651 policies need to be made to deal with issues specifically related to 652 IPv6. This document does not highlight these specific issues, but 653 raises the awareness they are of consideration and should be 654 addressed when delivering IPv6 services. 656 6.1.4. Phase 0 - Foundation: Transition Architecture 658 The operator may want to plan out their transition architecture in 659 advance (with obvious room for flexibility) to help optimize how they 660 will build out and scale their networks. If the operator should want 661 to use multiple technologies like CGN, DS-Lite and 6RD, they may want 662 to plan out where such equipment may be located and potentially 663 choose locations which can be used for all three functional roles 664 (i.e. placement of NAT44 translator, AFTR and 6RD relays). This 665 would allow for the least disruption as the operator evolves the 666 transition environment to meet the needs of the network. This 667 approach may also prove beneficial if traffic patterns change rapidly 668 in the future and the operator may need to evolve their network quick 669 then originally anticipated. 671 Operators should inform their vendors of what technologies they plan 672 to support over the course of the transition to make sure the 673 equipment is suited to support those modes of operation. This is of 674 importance for both network resident gear and more importantly CPEs. 675 Once deployed it's difficult and expensive to replace equipment. 676 Vendors need to be brief and ready to pre-load or upgrade their 677 systems to support the technology suites planned for deployment. 679 6.1.5. Phase 0- Foundation: Tools and Management 681 Although many of the tools and and service management systems may 682 change over the course of the IPv6 transition, this area is of 683 specific note. The operator may want to do a thorough analysis in 684 advance as to what systems will need to be modified to deal with the 685 interowrking models related to IPv6 service delivery. This will 686 include address concepts related to the 128-bit addressing field, the 687 notation of an assigned IPv6 prefix (PD) and the ability to detect 688 either or both address families when determining if a customer has 689 full Internet service. 691 If an operator stores usage information, this would need to be 692 aggregated to include both the IPv4 and IPv6 traffic flows. Also, 693 tools. that verify connectivity may need to query or interrogate the 694 IPv4 and IPv6 addresses. 696 6.2. Phase 1 - Tunnelled IPv6 698 During the initial phase of transition the operator may want to 699 support IPv6 Services before Native IPv6 can be supported by the 700 access network. During this period of time, tunnelled access to IPv6 701 is a viable alternative to Native IPv6. Providers can deploy relays 702 for automatic tunnelling technologies like 6to4 and Teredo, and can 703 more importantly deploy technologies like 6RD. It should be noted 704 that technologies like 6to4 and Teredo do not share the same address 705 selection behaviours as those like 6RD as per address [RFC3484]. 706 Additional guidelines on deploying and supporting 6to4 can be found 707 in [RFC6343]. 709 The operator can deploy 6RD relays quite easily and scale them as 710 needed to meet the early customer needs of IPv6. Since 6RD requires 711 the upgrade or replacement of most CPEs, the operator may want ensure 712 that the CPEs support not just 6RD but Native Dual Stack and other 713 tunnelling technologies if possible. 6RD client side deployments are 714 now available in some retail channel products and within the OEM 715 market making it a viable option for a wide range of operators. 717 Retail availability of 6RD is important since not all operators 718 control or have influence over what equipment is deployed in the 719 consumer home network which connects to the operator's network. 721 +--------+ ----- 722 | | / \ 723 Encap IPv6 Flow | 6RD | | IPv6 | 724 - - -> | BR | <- > | Net | 725 +---------+ / | | \ / 726 | | / +--------+ ----- 727 | 6RD + <----- ----- 728 | | / \ 729 | Client | IPv4 Flow | IPv4 | 730 | + < - - - - - - - - - - - - - - -> | Net | 731 | | \ / 732 +---------+ ----- 734 Figure 1: 6RD Basic Model 736 If the operator is able to support Native IPv6 right away, they may 737 want to skip this phase. However, the operator may still want to 738 deploy 6to4 and/or Teredo relays to assist connectivity for IPv4-Only 739 connected customers which may have hosts using those protocols. 6RD 740 used as an initial phase technology also provides the added benefit 741 of a deterministic IPv6 prefix which is based on the IPv4 assigned 742 address. Many operational tools are available or have been built to 743 identify what IPv4 (often dynamic) address was assigned to a customer 744 host/CPE. So a simple tool and/or method can be built to help the 745 operational folks in an organization know what the IPv6 prefix is for 746 6RD based on to knowledge of the IPv4 address. 748 An operator may choose to not offer internal services over IPv6 if 749 such services generate a large amount of traffic. This mode of 750 operation should avoid the need to greatly increase the scale of the 751 6RD Relay environment. 753 6.2.1. 6RD Deployment Considerations 755 Deploying 6RD can greatly speed up an operators ability to support 756 IPv6 to the customer network. If considering deploying 6RD, an 757 operator may want to consider who the system would be deployed, 758 provisioned, scaled and managed. The operator may have additional 759 considerations particular to their environment but these represent 760 the core items which should be addressed. 762 The first core consideration is deployment models. 6RD requires the 763 CPE (6RD client) to send traffic to a 6RD relay. These relays can 764 often share a common anycast address or use unique addresses. Both 765 of these options are viable but each share benefits and challenges. 766 Anycast options exist since 6RD is stateless by nature. Using an 767 anycast model, the operator can deploy all the 6RD relays using the 768 same IPv4 interior service address. As the load increases on the 769 deployed relays, the operator can deploy more relays into the 770 network. The one drawback here is that it may be difficult to 771 control large segments (or small segments) of the 6RD customer base 772 as placement of the relays (in proximity to client) is the only way 773 to steer traffic to new or alternate nodes. Proximity in this case 774 actually refers to netowrk cost (i.e. in IGP) and not necessarily 775 actual physical distance (although these can often be related). Use 776 of specific addresses can help provide more control but has the 777 disadvantage of being more complex to provision as CPEs will contain 778 different information. An alternative approach is to use a hybrid 779 model using multiple anycast service IPs for clusters of 6RD relays 780 should the operator anticipate massive scaling of the environment. 781 This way, the operator has multiple vectors by which to scale the 782 service. 784 +--------+ 785 | | 786 IPv4 Addr.X | 6RD | 787 - - - > | BR | 788 +-----------+ / | | 789 | Client A | <- - - +--------+ 790 +-----------+ 791 Separate IPv4 Service Addresses 792 +-----------+ 793 | Client B | < - - +--------+ 794 +-----------+ \ | | 795 - - - > | 6RD | 796 IPv4 Addr.Y | BR | 797 | | 798 +--------+ 800 Figure 2: 6RD Multiple IPv4 Service Address Model 801 +--------+ 802 | | 803 IPv4 Addr.X | 6RD | 804 - - - > | BR | 805 +-----------+ / | | 806 | Client A |- - - - +--------+ 807 +-----------+ 808 Common (Anycast) IPv4 Service Addresses 809 +-----------+ 810 | Client B | - - - +--------+ 811 +-----------+ \ | | 812 - - - > | 6RD | 813 IPv4 Addr.X | BR | 814 | | 815 +--------+ 817 Figure 3: 6RD Anycast IPv4 Service Address Model 819 Provisioning of the endpoints is of consideration to the operator. 820 This provisioning is also impacted by the deployment model chose 821 (i.e. Anycast vs. specific service IPs). Using multiple IPs may 822 require more planning and management as CPEs will have different sets 823 of data to be provisioned into the devices. The operator will also 824 need to decide if they will use DHCPv4, manual provisioning or other 825 mechanisms to set the parameters into the CPEs. 827 If the operator wishes to managed the CPEs they will need to have 828 access to new management tools or functions which are able to report 829 the status of the 6RD tunnel to the inquiring support personnel. 830 Also, if an operator needs to collect usage information, they would 831 need to understand where this operation can take place. If the usage 832 information includes understanding actual source/destination flow 833 details, this information would likley be best collected after the 834 6RD relay (IPv6 side of connection). The operator will also need to 835 be mindful of what tools they will need to manage such connections. 837 +---------+ IPv4 Encapsulation +------------+ 838 | +- - - - - - - - - - - + | 839 | 6RD +----------------------+ 6RD +--------- 840 | | IPv6 Packet | Relay | IPv6 Packet 841 | Client +----------------------+ +--------- 842 | +- - - - - - - - - - - + | ^ 843 +---------+ ^ +------------+ | 844 | | 845 | | 846 IPv4 IP (Tools/Mgmt) IPv6 Flow Analysis 847 Figure 4: 6RD Tools and Flow Management 849 6.3. Phase 2: Native Dual Stack 851 Either as a follow-up phase to "Tunnelled IPv6" or as an initial 852 step, the operator may deploy Native IPv6 to the customer premise. 853 This phase would then allow for both IPv6 and IPv4 to be natively 854 accessed by the customer home gateway/CPE. The Native Dual Stack 855 phase be rolled out across the network while the tunnelled IPv6 856 service remains running. As areas begin to support Native IPv6, 857 customer home equipment can be set to use it in place of technologies 858 like 6RD. If 6to4 and/or Teredo was the sole method of connectivity 859 prior to IPv6 service deliver then the internal home network hosts 860 will naturally prefer the IPv6 address delivered via Native IPv6 861 (assumed to be a Delegated Prefix as per [RFC3769]). 863 As one of the most desirable options, Native Dual Stack should be 864 sought as soon as possible if the operator's network allows. During 865 this phase, the operator can confidently move both internal and 866 external services to IPv6. Since there are no translation devices 867 needed for this mode of operation, it allows both protocols (IPv6 and 868 IPv4) to work efficiently within the network. Efficiency in this 869 context refers to the need (or lack there of) to translate, tunnel, 870 incrementally route or relay customer traffic within the operator's 871 network. 873 6.3.1. Native Dual Stack Deployment Considerations 875 Native Dual Stack is a very desirable option for deployment. That 876 said, it also requires a number of things to be in place before IPv6 877 it should be turned on. The operator is assumed to have a fully 878 operational IPv6 network core and peering before they attempt to turn 879 on Native IPv6 services. Additionally, supporting systems such as 880 DHCPv6, DNS6 and other functions which support the customers IPv6 881 Internet connection need to be in place. 883 The operator will need make sure the IPv6 environment is stable and 884 secure to ensure fluid operation. Poor IPv6 service may be worse 885 then not offering an IPv6 service at all. Given that many platforms 886 have very recent code which has enabled IPv6 or other functions which 887 support IPv6 operation, instability may be experienced at first. The 888 operator will need to be fully aware of the IPv6 service and it's 889 attributes to make sure they catch erroneous behaviour and address it 890 promptly. 892 Of particular importance is the management of delegated prefixes. 893 Prefix assignment and routing is a new concept for common residential 894 services. The ability to assign the IPv6 prefix may be somewhat 895 strait forward (DHCPv6 using IA_PDs) but installation and propagation 896 of this information is not. Operators who may see access layer 897 instability impacting service if the route is not re-installed. 898 Incrementally the operator may often re-assign customers to new IP 899 Access nodes (such as in a Cable network) may need to consider this 900 as PD information may not be transferable to the new location. 902 Operators will also needs to build new tools that help managed the 903 IPv6 connection and will need to update systems to keep track of both 904 the dynamically assigned IPv4 and IPv6 addresses. Any additional 905 dynamic elements, such as auto-generated DNS names, need to be 906 considered and planed for. 908 6.4. Intermediate Phase for CGN 910 As some point during the first two phases, acquiring more IPv4 911 addresses may become challenging or impossible, therefore CGN may be 912 required on the IPv4 path. The CGN infrastructure can be enabled if 913 needed during either phase. CGN is less optimal in a 6RD deployment 914 (if used with 6RD to a given endpoint) since all traffic must 915 transverse some type of operator service node (relay and translator). 917 +--------+ ----- 918 | | / \ 919 IPv4 Flow | CGN | | | 920 - - -> + + < -> | | 921 +---------+ / | | | | 922 | CPE | <- - - / +--------+ | IPv4 | 923 |---------+ | Net | 924 | | 925 +---------+ IPv4 Flow | | 926 | CPE | <- - - - - - - - - - - - - - - > | | 927 |---------+ \ / 928 ----- 930 Figure 5: Overlay CGN Deployment 932 In the case of Native Dual Stack, CGN can be used to assist in 933 extending connectivity for the IPv4 path while the IPv6 path remains 934 native. For endpoints operating in a IPv6+CGN model the Native IPv6 935 path is available for higher quality connectivity helping host 936 operation over the network while the CGN path may offer a less then 937 optimal performance. 939 +--------+ ----- 940 | | / \ 941 IPv4 Flow | CGN | | IPv4 | 942 - - -> + + < -> | Net | 943 +---------+ / | | \ / 944 | | <- - - / +--------+ ------- 945 | Dual | 946 | Stack | ----- 947 | CPE | IPv6 Flow / IPv6 \ 948 | | <- - - - - - - - - - - - - - - > | Net | 949 |---------+ \ / 950 ----- 952 Figure 6: Dual Stack with CGN 954 CGN deployments may make use of a number of address options which 955 include RFC1918 or Shared CGN Address Space [I-D.weil-shared- 956 transition-space-request]. It is also possible that operators may 957 use part of their own RIR assigned address space for CGN zone 958 addressing if RFC918 address pose technical challenges in their 959 network. It is not recommended that operators use squat space as it 960 may pose additional challenges with filtering and policy control. 962 6.4.1. CGN Deployment Considerations 964 CGN is often considered undesirable by operators but required in many 965 cases. An operator who needs to deploy CGN services should consider 966 it's impacts to the network. CGN is often deployed in addition to 967 running IPv4 services and should not negatively impact the already 968 working Native IPv4 service. CGNs will also be needed at low scale 969 at first and grown to meet future demands based on traffic and 970 connection dynamics of the customer, content and network peers. 972 The operator may want to deploy CGNs more centrally at first and then 973 scale the system as needed. This approach can help conserve costs of 974 the system and only spend money on equipment with the actual growth 975 of traffic (demand on CGN system). The operator will need a 976 deployment model and architecture which allows the system to scale as 977 needed. 979 +--------+ ----- 980 | | / \ 981 | CGN | | | 982 - - -> + + < -> | | 983 +---------+ / | | | | 984 | CPE | <- - - / +--------+ | IPv4 | 985 | | ^ | | 986 |---------+ | | Net | 987 +--------+ Centralized | | 988 +---------+ | | CGN | | 989 | | | CGN | | | 990 | CPE | <- > + + <- - - - - - - > | | 991 |---------+ | | \ / 992 +--------+ ----- 993 ^ 994 | 995 Distributed CGN 997 Figure 7: CGN Deployment: Centralized vs. Distributed 999 CGNs also increase the demands (potentially) for operators due to new 1000 phenomenon related to shared addressing. This includes logging of 1001 translation information for lawful response. This logging may 1002 require significant investment in external systems which ingest, 1003 aggregate and report on such information. 1005 6.5. Phase 3 - Tunnelled IPv4 1007 Over time, the operator will mature the IPv6 service and have more 1008 ubiquitous coverage within the network. Once the operator is 1009 familiar with IPv6, tools have been developed and operational 1010 procedures refined, more efficient modes of connectivity can be 1011 enabled. Once such technology is DS-Lite. DS-Lite allows the 1012 operator to grow the IPv4 customer base if needed without the need to 1013 deploy more IPv4 addresses to customer home networks. DS-Lite still 1014 requires IPv4 address sharing for IPv4 Internet connectivity, but 1015 this is seen as no worse and often more advantageous then CGN (NAT44) 1016 because only a single layer of NAT is required. 1018 The operator can also move endpoints (Dual Stack) to DS-Lite 1019 retroactively in an attempt to reclaim IPv4 addresses for 1020 redeployment. Redeployment of addressees may be desirable if IPv4 1021 resources are needed for legacy equipment and service connections 1022 which cannot be upgraded to IPv4 and no new IPv4 addressees can be 1023 acquired otherwise. The operator may want to have already moved most 1024 external content and internal content to IPv6 before this phase 1025 implemented. By having a significant amount of traffic on IPv6, the 1026 operator would limit the amount of translation resources which are 1027 needed at the AFTR layer to support IPv4 flows. This would also be a 1028 benefit to the customer as their traffic need not be translated by a 1029 operator device improving performance. 1030 +--------+ ----- 1031 | | / \ 1032 Encap IPv4 Flow | AFTR | | IPv4 | 1033 -------+ +---+ Net | 1034 +---------+ / | | \ / 1035 | | / +--------+ ----- 1036 | DS-Lite +------- ----- 1037 | | / \ 1038 | Client | IPv6 Flow | IPv6 | 1039 | +-------------------------------| Net | 1040 | | \ / 1041 +---------+ ----- 1043 Figure 8: DS-Lite Basic Model 1045 If the operator was forced to enable CGN for a NAT444 deployment, 1046 they may be able to co-locate the AFTR and CGN functions within the 1047 network to simplify capacity management and the engineering of flows. 1048 This phase can also co-exist with Native Dual Stack if desired since 1049 the same basic foundation is needed for both technologies on the IPv6 1050 side. DS-Lite however requires incremental functions in the network 1051 such as the programming of the CPE and the implementation of the 1052 AFTRs'. 1054 6.5.1. DS-Lite Deployment Considerations 1056 DS-Lite although quite useful has a number of considerations for the 1057 operator. First all the same deployment considerations associated 1058 with Native IPv6 deployments are applicable to DS-LIte. The IPv6 1059 network and service must be running well to ensure a quality 1060 experience for the end customer. IPv4 will now be subject to IPv6 1061 service quality - this is a very important point. Tools will need be 1062 written or used to help manage the encapsulated IPv4 service which to 1063 not likely exist in most operators arsenal today. If flow analysis 1064 is required for IPv4 traffic, this may need to be enabled at a point 1065 beyond the AFTR or the operator will need equipment that can 1066 decapsulate DS-Lite to see inside the packets. 1068 +---------+ IPv4 Encapsulation +------------+ 1069 | + - - - - - - - - - - -+ | 1070 | DS-Lite +----------------------+ AFTR +--------- 1071 | | IPv4 Packet | | IPv4 Packet 1072 | Client +----------------------+ +--------- 1073 | + - - - - - - - - - - -+ | ^ 1074 +---------+ ^ +------------+ | 1075 | | 1076 | | 1077 IPv6 IP (Tools/Mgmt) IPv4 Packet Flow Analysis 1079 Figure 9: DS-Lite Tools and Flow Analysis 1081 DS-Lite also requires client support. If the operator has chose to 1082 have a vendor support multiple transition technologies, the 1083 activation logic will need to be clearly articulated such that the 1084 correct behaviour is manifest in the network. As an example, an 1085 operator may use 6RD in the outset of the transition, then move to 1086 Native Dual Stack followed by DS-LIte. 1088 7. IANA Considerations 1090 No IANA considerations are defined at this time. 1092 8. Security Considerations 1094 No Additional Security Considerations are made in this document. 1096 9. Acknowledgements 1098 Thanks to the following people for their textual contributions and/or 1099 guidance on IPv6 deployment considerations: John Brzozowski, Lee 1100 Howard, Jason Weil, Nik Lavorato, John Cianfarani, Chris Donley, 1101 Wesley George and Tina TSOU. 1103 10. References 1105 10.1. Normative References 1107 [I-D.ietf-v6ops-v4v6tran-framework] 1108 Carpenter, B., Jiang, S., and V. Kuarsingh, "Framework for 1109 IP Version Transition Scenarios", 1110 draft-ietf-v6ops-v4v6tran-framework-02 (work in progress), 1111 July 2011. 1113 [RFC6180] Arkko, J. and F. Baker, "Guidelines for Using IPv6 1114 Transition Mechanisms during IPv6 Deployment", RFC 6180, 1115 May 2011. 1117 10.2. Informative References 1119 [I-D.donley-nat444-impacts] 1120 Donley, C., Howard, L., Kuarsingh, V., Chandrasekaran, A., 1121 and V. Ganti, "Assessing the Impact of NAT444 on Network 1122 Applications", draft-donley-nat444-impacts-01 (work in 1123 progress), October 2010. 1125 [I-D.ietf-behave-lsn-requirements] 1126 Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., 1127 and H. Ashida, "Common requirements for Carrier Grade NAT 1128 (CGN)", draft-ietf-behave-lsn-requirements-03 (work in 1129 progress), August 2011. 1131 [I-D.jjmb-v6ops-comcast-ipv6-experiences] 1132 Brzozowski, J. and C. Griffiths, "Comcast IPv6 Trial/ 1133 Deployment Experiences", 1134 draft-jjmb-v6ops-comcast-ipv6-experiences-02 (work in 1135 progress), October 2011. 1137 [I-D.kuarsingh-v6ops-6to4-provider-managed-tunnel] 1138 Kuarsingh, V., Lee, Y., and O. Vautrin, "6to4 Provider 1139 Managed Tunnels", 1140 draft-kuarsingh-v6ops-6to4-provider-managed-tunnel-04 1141 (work in progress), September 2011. 1143 [I-D.weil-shared-transition-space-request] 1144 Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and 1145 M. Azinger, "IANA Reserved IPv4 Prefix for Shared CGN 1146 Space", draft-weil-shared-transition-space-request-07 1147 (work in progress), October 2011. 1149 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1150 E. Lear, "Address Allocation for Private Internets", 1151 BCP 5, RFC 1918, February 1996. 1153 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 1154 via IPv4 Clouds", RFC 3056, February 2001. 1156 [RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", 1157 RFC 3068, June 2001. 1159 [RFC3484] Draves, R., "Default Address Selection for Internet 1160 Protocol version 6 (IPv6)", RFC 3484, February 2003. 1162 [RFC3769] Miyakawa, S. and R. Droms, "Requirements for IPv6 Prefix 1163 Delegation", RFC 3769, June 2004. 1165 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 1166 Network Address Translations (NATs)", RFC 4380, 1167 February 2006. 1169 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 1170 Infrastructures (6rd) -- Protocol Specification", 1171 RFC 5969, August 2010. 1173 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 1174 NAT64: Network Address and Protocol Translation from IPv6 1175 Clients to IPv4 Servers", RFC 6146, April 2011. 1177 [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 1178 Roberts, "Issues with IP Address Sharing", RFC 6269, 1179 June 2011. 1181 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 1182 Stack Lite Broadband Deployments Following IPv4 1183 Exhaustion", RFC 6333, August 2011. 1185 [RFC6343] Carpenter, B., "Advisory Guidelines for 6to4 Deployment", 1186 RFC 6343, August 2011. 1188 Author's Address 1190 Victor Kuarsingh (editor) 1191 Rogers Communications 1192 8200 Dixie Road 1193 Brampton, Ontario L6T 0C1 1194 Canada 1196 Email: victor.kuarsingh@gmail.com 1197 URI: http://www.rogers.com