idnits 2.17.1 draft-ietf-v6ops-wireline-incremental-ipv6-00.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 (November 27, 2011) is 4524 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 916, but no explicit reference was found in the text == Unused Reference: 'I-D.donley-nat444-impacts' is defined on line 928, but no explicit reference was found in the text == Unused Reference: 'I-D.jjmb-v6ops-comcast-ipv6-experiences' is defined on line 940, but no explicit reference was found in the text == Unused Reference: 'I-D.weil-shared-transition-space-request' is defined on line 952, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-donley-nat444-impacts-03 == Outdated reference: A later version (-10) exists of draft-ietf-behave-lsn-requirements-04 == 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-09 -- 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 (~~), 9 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 L. Howard 5 Expires: May 30, 2012 Time Warner Cable 6 November 27, 2011 8 Wireline Incremental IPv6 9 draft-ietf-v6ops-wireline-incremental-ipv6-00 11 Abstract 13 Operators worldwide are in various stages of preparing for, or 14 deploying IPv6 into their networks. The operators often face 15 challenges related to both IPv6 introduction along with a growing 16 risk of IPv4 run out within their organizations. The overall problem 17 for many operators will be to meet the simultaneous needs of IPv6 18 connectivity and continue support for IPv4 connectivity for legacy 19 devices and systems with a depleting supply of IPv4 addresses. The 20 overall transition will take most networks from an IPv4-Only 21 environment to a dual stack network environment and potentially an 22 IPv6-Only operating mode. This document helps provide a framework 23 for Wireline providers who may be faced with many of these challenges 24 as they consider what IPv6 transition technologies to use, how to use 25 the selected technologies and when to use them. 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 May 30, 2012. 44 Copyright Notice 46 Copyright (c) 2011 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 . . . . . . . . . . . . . . . . 5 65 3.2. IPv4 Resource Challenges . . . . . . . . . . . . . . . . . 6 66 3.3. IPv6 Introduction and Maturity . . . . . . . . . . . . . . 6 67 3.4. Service Management . . . . . . . . . . . . . . . . . . . . 7 68 3.5. Sub-Optimal Operation of Transition Technologies . . . . . 7 69 4. IPv6 Transition Technology Analysis . . . . . . . . . . . . . 8 70 4.1. Automatic Tunnelling using 6to4 and Teredo . . . . . . . . 8 71 4.2. Carrier Grade NAT (NAT444) . . . . . . . . . . . . . . . . 8 72 4.3. 6RD . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 4.4. Native Dual Stack . . . . . . . . . . . . . . . . . . . . 9 74 4.5. DS-Lite . . . . . . . . . . . . . . . . . . . . . . . . . 10 75 4.6. NAT64 . . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 5. IPv6 Transition Phases . . . . . . . . . . . . . . . . . . . . 11 77 5.1. Phase 0 - Foundation . . . . . . . . . . . . . . . . . . . 11 78 5.1.1. Phase 0 - Foundation: Training . . . . . . . . . . . . 11 79 5.1.2. Phase 0 - Foundation: Routing . . . . . . . . . . . . 12 80 5.1.3. Phase 0 - Foundation: Network Policy and Security . . 12 81 5.1.4. Phase 0 - Foundation: Transition Architecture . . . . 12 82 5.1.5. Phase 0- Foundation: Tools and Management . . . . . . 13 83 5.2. Phase 1 - Tunnelled IPv6 . . . . . . . . . . . . . . . . . 13 84 5.2.1. 6RD Deployment Considerations . . . . . . . . . . . . 14 85 5.3. Phase 2: Native Dual Stack . . . . . . . . . . . . . . . . 16 86 5.3.1. Native Dual Stack Deployment Considerations . . . . . 16 87 5.4. Intermediate Phase for CGN . . . . . . . . . . . . . . . . 17 88 5.4.1. CGN Deployment Considerations . . . . . . . . . . . . 18 89 5.5. Phase 3 - Tunnelled IPv4 . . . . . . . . . . . . . . . . . 19 90 5.5.1. DS-Lite Deployment Considerations . . . . . . . . . . 20 91 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 92 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 93 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 94 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 95 9.1. Normative References . . . . . . . . . . . . . . . . . . . 21 96 9.2. Informative References . . . . . . . . . . . . . . . . . . 21 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 99 1. Introduction 101 This draft sets out to help wireline operators in planning their IPv6 102 deployments, while ensuring continued support for IPv6-incapable 103 consumer devices and applications. We will identify which 104 technologies can be used incrementally to transition from IPv4-only 105 to an efficient IPv6/IPv4 dual stack environment. Some plans may 106 also include IPv6-Only end state targets, but there is not clear 107 consensus on how long IPv4 support is required, and IPv6-Only 108 generally means withdrawing IPv4 mechanisms. Although no single plan 109 will work for for all operators, options listed herein provide a 110 baseline which can be included in many plans. 112 This draft is intended for wireline environments including Cable, DSL 113 and/or Fibre as the access method to the end consumer. This draft 114 also attempts to follow the methodologies set out in [I-D.ietf-v6ops- 115 v4v6tran-framework] to identify how the technologies can be used 116 individually and in combination. This document also attempts to 117 follow the principles laid out in [RFC6180] which provides guidance 118 on using IPv6 transition mechanisms. This document will show how 119 well defined technologies such as 6RD [RFC5969], DS-Lite [RFC6333] 120 and Carrier Grade NAT (NAT44 without tunnelling as distinct from DS- 121 Lite) used with native dual stack to deliver effective IPv4 and IPv6 122 services in an evolving wireline network. 124 2. Operator Assumptions 126 For the purposes of this document, assume: 128 - The operator is considering deploying IPv6 130 - The operator has a legacy IPv4 customer base which will continue 131 to exist 133 - The operator will want to minimize the level of disruption to 134 the existing and new customers by minimizing number of 135 technologies and functions that are needed to mediate any given 136 set of customer flows (overall preference for Native IP flows) 138 - The operator is able to run Dual Stack on their own core network 139 and to transition their own services to support IPv6 141 Based on these assumptions, an operator will want to use technologies 142 which minimize the number of flows being tunnelled, translated or 143 intercepted at any given time. Technology selections would be made 144 to manage the non dominant flows and allow Native IP routing (IPv4 145 and/or IPv6) for the dominant traffic. This allows the operator to 146 minimize the cost of IPv6 transition technologies by containing the 147 scale required by the relevant systems. 149 3. Reasons and Considerations for a Phased Approach 151 When faced with the challenges described in the Introduction, 152 operators may need to consider a phased approach when adding IPv6 to 153 an existing IPv4 service. A phased approach addresses many 154 challenges: 156 - IPv4 exhaustion may occur long before most traffic is able to 157 delivered over IPv6 159 - IPv6 will pose operational challenges, since much of the 160 software, and in some cases the hardware to run it at scale, will 161 be new. Further, the operational processes will be relatively new 163 - Connectivity modes will move from single stack to dual stack in 164 the Home Changing functional behaviours in the home network add 165 complexity to user support 167 These challenges will likely occur over time which means the 168 operator's plans need to address the every changing requirements of 169 the network and customer demand. The following few sections 170 highlight some of the key reasons why a phased approach to IPv6 171 transition may be warranted and desired. 173 Although phases will be presented in this document, not all operators 174 may need to enable each desecrate phase. It is possible that 175 characteristics in individual networks may allow certain operators to 176 skip various phases. 178 3.1. Relevance of IPv6 and IPv4 180 Over the next few years, both IPv4 and IPv6 will play a role in the 181 Internet experience. Many customers use older operating systems and 182 hardware which support IPv4-Only. Internet customers don't buy IPv4 183 or IPv6 connections, they buy Internet connections, which demands the 184 need to support both IPv4 and IPv6 for as long at the customer's home 185 network demands such support. 187 The Internet is made of of many interconnecting systems, networks, 188 hardware, software and content sources - all of which will move to 189 IPv6 at different rates. The Operator's mandate during this time of 190 transition will be to support connectivity to both IPv6 and IPv4 191 through various technological means. The operator may be able to 192 leverage one or the other protocol to help bridge connectivity, but 193 the home network will demand both IPv4 and IPv6 for some time. 195 3.2. IPv4 Resource Challenges 197 Since connectivity to IPv4-Only endpoints and/or content will remain 198 common, IPv4 resource challenges are of key concern to operators. 199 The lack of new IPv4 addressees for additional endpoints means that 200 growth in demand of IPv4 connections in some networks will be based 201 on address sharing. 203 Networks are growing at different rates based on emerging markets 204 and/or proliferation of Internet based services and endpoints: growth 205 on the Internet will continue. IPv4 address constraints will likely 206 affect many if not most operators at some point. IPv4 exhaustion is 207 a primary consideration for technologies which rely on IPv4 to supply 208 IPv6 services, such as 6RD. Also, if Native Dual Stack is considered 209 by the operator, challenges on the IPv4 path is also of concern. 211 Some operators may be able to reclaim some IPv4 addresses through 212 efficiency in the network and replacement of globally-unique IPv4 213 assignments with private addresses [RFC1918]. These measures are 214 tactical and do not support a longer term strategic option. The lack 215 of new IPv4 addresses will therefore force operators to support some 216 form of IPv4 address sharing and may impact technological options for 217 transition once the operator runs out of new IPv4 addresses for 218 assignment. 220 3.3. IPv6 Introduction and Maturity 222 The introduction of IPv6 will require the operationalization of IPv6. 223 The IPv4 environment we have today was built over many years and 224 matured by experience. Although many of these experiences are 225 transferable from IPv4 to IPv6, new experience specific to IPv6 will 226 be needed. 228 Engineering and Operational staff will need to develop experience 229 with IPv6. Inexperience may lead to instability, and Operators 230 should consider this when selecting technologies for early 231 transition. Operators may not want to subject their mature IPv4 232 service to a "new IPv6" path initially while it may be going through 233 growing pains. DS-Lite is one such technology, which requires IPv6 234 to support IPv4. 236 Further, some of these technologies are new and require refinement 237 within running code and support. Deployment experience may be needed 238 to expose bugs and stabilize software in production environments. 239 Many supporting systems are also under development and have newly 240 developed IPv6 functionality including vendor implementations of 241 DHCPv6, Management Tools, Monitoring Systems, Diagnostic systems, 242 along with other systems. 244 Although the base technological capabilities exist to enable and run 245 IPv6 in most environments, it may not be as robust as IPv4, and until 246 such time as each key technical member of an operator's organization 247 can identify IPv6, understand its relevance to the IP Service 248 offering, how it operates and how to troubleshoot it - it's still 249 maturing. 251 3.4. Service Management 253 Services are managed within most networks and are often based on the 254 gleaning and monitoring of IPv4 addresses. Operators will need to 255 address such management tools, troubleshooting methods and storage 256 facilities (such as databases) to deal with not just a new address 257 type containing 128-bits, but often both IPv4 and IPv6 at the same 258 time. Examination of address type, and recording CIDR blocks instead 259 of single addresses, may require additional development. 261 With any Dual Stack service - whether Native, 6RD based, DS-Lite 262 based or otherwise - two address families need to be managed 263 simultaneously to help provide for the full Internet experience. In 264 the early transition phases, it's quite likely that many systems will 265 be missed and that IPv6 services will go un-monitored and impairments 266 undetected. 268 These issues may be of consideration when selecting technologies 269 which require IPv6 as the base protocol to delivery IPv4. 270 Instability on the IPv6 service in such case would impact IPv4 271 services. 273 3.5. Sub-Optimal Operation of Transition Technologies 275 When considering native dual-stack versus a transition technology, 276 note that native paths are well understood and networks are optimized 277 to send traffic efficiently. Transition technologies may alter the 278 normal path of traffic. Tunnel servers or translation relays may not 279 be located on the shortest path, may increase latency, and may add a 280 single point of failure. 282 To minimize risk, an operator should use transition technologies for 283 the lesser-used address family. During earlier phases of transition, 284 IPv6 traffic volumes may be lower, so tunnelling of IPv6 traffic may 285 be reasonable. Over time, these traffic volumes will increase, 286 raising the benefits of native delivery of this traffic. Then, as 287 IPv4 content diminishes, translation and tunnelling of IPv4 may be 288 acceptable. 290 When IPv6 tunnelling is used, an operator may not want to enable IPv6 291 for their services, especially high traffic services. Likewise, when 292 CGN is deployed, the operation may wish to promote IPv6 access. 294 4. IPv6 Transition Technology Analysis 296 Operators should understand the main transition technologies for IPv6 297 deployment and IPv4 runout. This draft provides a brief description 298 of some of the mainstream options. This analysis is focused on the 299 applicability of technologies to deliver residential services and 300 less focused on commercial access or infrastructure support. 302 The technologies in focus for this document are targeted on those 303 commercially available and in deployment. 305 4.1. Automatic Tunnelling using 6to4 and Teredo 307 Even when operators may not be actively deploying IPv6, automatic 308 mechanisms exist on customer operating systems and hardware . Such 309 technologies include 6to4 [RFC3056] which is most commonly used with 310 anycast relays [RFC3068]. Teredo [RFC4380] is also used widely by 311 many Internet hosts. 313 Documents such as [RFC6343] have been written to help operators 314 understand observed problems and provide guidelines on how to manage 315 such protocols. An Operator may want to provide local relays for 316 6to4 and/or Teredo to help improve the protocol's performance for 317 ambient traffic utilizing these IPv6 connectivity methods. 318 Experiences such as those described in [I-D.jjmb-v6ops-comcast-ipv6- 319 experiences] show that local relays have proved beneficial to 6to4 320 protocol performance. 322 Operators should also be aware of breakage cases for 6to4 if non- 323 RFC1918 address are used for CGN zones. Many off the shelf CPEs and 324 operating systems may turn on 6to4 without a valid return path to the 325 originating (local) host. This particular use is likely to occur if 326 any space other than [RFC1918] is used, including Shared CGN Space[I- 327 D.weil-shared-transition-space-request] or space registered to 328 another organization (squatted space). The operator can use 6to4-PMT 329 [I-D.kuarsingh-v6ops-6to4-provider-managed-tunnel] or attempt to 330 block 6to4 operation entirely by blocking 2002::/16 at its edges. 332 4.2. Carrier Grade NAT (NAT444) 334 Carrier Grade NAT (GGN), specifically as deployed in a NAT444 335 scenario [I-D.ietf-behave-lsn-requirements], may prove beneficial for 336 those operators who offer Dual Stack services to customer endpoints 337 once they exhaust their pools of IPv4 addresses. CGNs, and address 338 sharing overall, are known to cause certain challenges for the IPv4 339 service [RFC6269], but will often be necessary for a time. 341 In a network where IPv4 address availability is low, CGN may provide 342 continued access to IPv4 endpoints. Other technologies (4rd, IVI) 343 may also be used in place of the NAT444 model with CGN. Some of the 344 advantages of using CGN include the similarities in provisioning and 345 activation of IPv4 hosts within a network and operational procedures 346 in managing such hosts or CPEs (i.e. DHCPv6, DNSv4, TFTP, TR-069 347 etc). 349 When considered in the overall IPv6 transition, CGN may play a vital 350 role in the delivery of Internet services. 352 4.3. 6RD 354 6RD [RFC5969] does provide a quick and effective way to deliver IPv6 355 services to customers who do not yet support Native. 6RD provides 356 tunnelled connectivity for IPv6 over the existing IPv4 path. As the 357 access edge is upgraded and customer premise equipment is replaced, 358 6RD can be superseded by Native IPv6 access. 6RD can be delivered 359 along with CGN, but then no traffic would be native; all traffic 360 would be intermediated. 362 6RD may also be advantageous during the early transition while IPv6 363 traffic volumes are low. During this period, the operator can gain 364 experience with IPv6 on the core and improve their peering framework 365 to match those of the IPv4 service. 6RD scales easily by adding 366 relays. As IPv6 traffic volume grows, the operator can gradually 367 replace 6RD with native IPv6. 369 6RD client support is required, but most currently deployed CPEs do 370 not have 6RD client functionality built into them and may not be 371 upgradable. 6RD deployments would most likely require the replacement 372 of the home CPE. An advantage of this technology over DS-Lite is 373 that the WAN side interface does not need to implement IPv6 to 374 function correctly which may make it easier to deploy to field 375 hardware which is restricted in memory footprint, processing power 376 and storage space. 6RD will also require parameter configuration 377 which can be powered by the operator through DHCPv4, manually 378 provisioned on the CPE or automatically through some other means. 379 Manual provisioning would likely limit deployment scale. 381 4.4. Native Dual Stack 383 Native Dual Stack is often referred to as the "Gold Standard" of IPv6 384 and IPv4 delivery. It is a method of service delivery which is 385 already used in many existing IPv6 deployments. Native Dual Stack 386 does however require that Native IPv6 be delivered to the customer 387 premise. This technology option is desirable in many cases and can 388 be used immediately if the access network and customer premise 389 equipment supports Native IPv6 to the operator's access network. 391 An operator who runs out of IPv4 addresses to assign to customers 392 will not be able to provide Native Dual Stack. For a sub-set of the 393 IPv6 Native Customers, operators may include IPv4 through a CGN. 395 Delivering Native Dual Stack would require the operator's core and 396 access network support IPv6. Additionally, other systems like 397 DHCPv6, DNS, and diagnostic/management facilities need to be upgraded 398 to support IPv6. The upgrade of such systems may often not be 399 trivial. 401 4.5. DS-Lite 403 Dual-Stack Lite (DS-Lite, [RFC6333]) provides IPv4 services to 404 customer networks which are only addressed with IPv6. DS-Lite 405 provides tunnelled connectivity for IPv4 over an IPv6 path between 406 the customer's network device and a provider managed gateway (AFTR). 408 DS-Lite can only be used where there is native IPv6 connectivity 409 between the AFTR and the customer premise endpoint. This may mean 410 that the technology's use may not be viable during early transition. 411 The operator may also not want to subject the customers' IPv4 412 connection to the IPv6 path. The provider may also want to make sure 413 that most of their internal services, and external content is 414 available over IPv6 before deploying DS-Lite. This would lower the 415 overall load on the AFTR devices helping reduce. 417 By sharing IPv4 addresses among multiple endpoints, like a CGN, DS- 418 Lite can facilitate continued growth of IPv4 services even at runout. 419 There are some functional considerations 420 [draft-donley-nat444-impacts]. 422 Similar to 6RD, DS-Lite requires client support on the CPE to 423 function. Client functionality is likely to be more prevalent in the 424 future as IPv6 capable (WAN side) CPEs begin to penetrate the market. 425 This includes both retail and operator provided gateways. 427 4.6. NAT64 429 NAT64 [RFC6146] provides the ability to connect IPv6-Only connected 430 clients and hosts to IPv4 Servers (or other like hosts). NAT64 431 requires that the host and home network supports IPv6-Only modes of 432 operation. This type of environment is not considered typical in 433 most traditional Wireline connections. 435 In the future, NAT64 may become more viable for Wireline providers as 436 home networking environments support IPv6-Only. In the meantime, DS- 437 Lite provides in-home IPv4 services over an IPv6-Only network (WAN). 439 5. IPv6 Transition Phases 441 The Phases described in this document are not provided as a rigid set 442 of steps, but are considered a guideline which should be analyzed by 443 an operator planning their IPv6 transition. Operators may choose to 444 skip steps based on technological capabilities within their specific 445 networks. 447 The phases are based on an expectation that IPv6 traffic volume will 448 initially be low, and operator staff will gain experience with IPv6 449 over time. As volume of IPv6 increases, IPv4 traffic volume will 450 correspondingly decrease, until IPv6 is predominant. For each phase, 451 the predominant address family should be native, while mediation 452 (tunnelling or translation) may be acceptable for the smaller traffic 453 volume. 455 Additional guidance and information on utilizing IPv6 transition 456 mechanisms can be found in [RFC6180]. Also, guidance on incremental 457 CGN for IPv6 transition can also be found in [RFC6264]. 459 5.1. Phase 0 - Foundation 461 5.1.1. Phase 0 - Foundation: Training 463 Training is one of the most important steps in preparing an 464 organization to support IPv6. Most people have little experience 465 with IPv6, and many do not even have a solid grounding in IPv4. 466 Since there are likely to be challenges with implementing IPv6 - due 467 to immature code on hardware, and the evolution of many applications 468 and systems to support IPv6 - organizations must train their staff on 469 IPv6. 471 Training should also be provided within reasonable timelines from 472 actual IPv6 deployment. This means the operator needs to plan in 473 advance as they train the various parts of their organization. New 474 Technology and Engineering staff often receive little training 475 because of their depth of knowledge, but must at least be provided 476 opportunities to read documentation, architectural white papers, and 477 RFCs. Operations staff who support the network and other systems 478 need to be trained closer to the deployment timeframes, so they 479 immediately use their new-found knowledge before forgetting. 481 Customer support staff would require much more basic, but large scale 482 training as many organizations have massive call centres to support 483 the customer base. 485 5.1.2. Phase 0 - Foundation: Routing 487 The network infrastructure will need to be in place to support IPv6. 488 This includes the routed infrastructure along with addressing 489 principles, routing principles, peering policy and related network 490 functions. Since IPv6 is quite different from IPv4 in number of ways 491 including the number of addresses which are made available, careful 492 attention to a scalable and manageable architecture needs to be made. 493 Also, given that home networks environments will no longer receive a 494 token single address as is common in IPv4, operators will need to 495 understand the impacts of delegating larges sums of addresses 496 (prefixes) to consumer endpoints. Delegating prefixes can be of 497 specific importance in access network environments where downstream 498 customers often move between access nodes, raising the concern of 499 frequent renumbering and/or managing movement of routed prefixes 500 within the network (common in cable based networks). 502 5.1.3. Phase 0 - Foundation: Network Policy and Security 504 Many, but not all, security policies will map easily from IPv4 to 505 IPv6. Some new policies may be required for issues specific to IPv6 506 operation. This document does not highlight these specific issues, 507 but raises the awareness they are of consideration and should be 508 addressed when delivering IPv6 services. Other IETF documents 509 ([RFC4942], [RFC6092], [RFC6169], for instance) are excellent 510 resources. 512 5.1.4. Phase 0 - Foundation: Transition Architecture 514 The operator should plan out their transition architecture in advance 515 (with room for flexibility) to help optimize how they will build out 516 and scale their networks. If the operator should want to use 517 multiple technologies like CGN, DS-Lite and 6RD, they may want to 518 plan out where such equipment may be located and potentially choose 519 locations which can be used for all three functional roles (i.e. 520 placement of NAT44 translator, AFTR and 6RD relays). This would 521 allow for the least disruption as the operator evolves the transition 522 environment to meet the needs of the network. This approach may also 523 prove beneficial if traffic patterns change rapidly in the future and 524 the operator may need to evolve their network faster than originally 525 anticipated. 527 Operators should inform their vendors of what technologies they plan 528 to support over the course of the transition to make sure the 529 equipment is suited to support those modes of operation. This is 530 important for both network gear and customer premise equipment. 532 5.1.5. Phase 0- Foundation: Tools and Management 534 The operator should thoroughly analyze all provisioning and 535 operations systems to develop requirements for each phase. This will 536 include address concepts related to the 128-bit addressing field, the 537 notation of an assigned IPv6 prefix (PD) and the ability to detect 538 either or both address families when determining if a customer has 539 full Internet service. 541 If an operator stores usage information, this would need to be 542 aggregated to include both the IPv4 and IPv6 traffic flows. Also, 543 tools that verify connectivity may need to query the IPv4 and IPv6 544 addresses. 546 5.2. Phase 1 - Tunnelled IPv6 548 Many network operators can deploy native IPv6 from access edge to 549 peering edge fairly quickly. Others, may want to support IPv6 550 services before they can support native IPv6. During this period of 551 time, tunnelled access to IPv6 is a viable alternative to Native 552 IPv6. Even while slowly rolling out native IPv6, operators can 553 deploy relays for automatic tunnelling technologies like 6to4 and 554 Teredo. Where native IPv6 is a longer-term project, operators can 555 consider 6RD [RFC5969]. Note that 6to4 and Teredo have different 556 address selection behaviours from 6RD [RFC3484]. Additional 557 guidelines on deploying and supporting 6to4 can be found in 558 [RFC6343]. 560 The operator can deploy 6RD relays easily and scale them as needed to 561 meet the early customer needs of IPv6. Since 6RD requires the 562 upgrade or replacement of CPE gateways, the operator may want ensure 563 that the gateways support not just 6RD but Native Dual Stack and 564 other tunnelling technologies if possible. 6RD clients are now 565 available in some retail channel products and within the OEM market. 566 Retail availability of 6RD is important since not all operators 567 control or have influence over what equipment is deployed in the 568 consumer home network. 570 +--------+ ----- 571 | | / \ 572 Encap IPv6 Flow | 6RD | | IPv6 | 573 - - -> | BR | <- > | Net | 574 +---------+ / | | \ / 575 | | / +--------+ ----- 576 | 6RD + <----- ----- 577 | | / \ 578 | Client | IPv4 Flow | IPv4 | 579 | + < - - - - - - - - - - - - - - -> | Net | 580 | | \ / 581 +---------+ ----- 583 Figure 1: 6RD Basic Model 585 6RD used as an initial phase technology also provides the added 586 benefit of a deterministic IPv6 prefix which is based on the IPv4 587 assigned address. Many operational tools are available or have been 588 built to identify what IPv4 (often dynamic) address was assigned to a 589 customer host/CPE. So a simple tool and/or method can be built to 590 help the operational staff in an organization know that the IPv6 591 prefix is for 6RD based on knowledge of the IPv4 address. 593 An operator may choose to not offer internal services over IPv6 if 594 such services generate a large amount of traffic. This mode of 595 operation should avoid the need to greatly increase the scale of the 596 6RD Relay environment. 598 5.2.1. 6RD Deployment Considerations 600 Deploying 6RD can greatly speed up an operator's ability to support 601 IPv6 to the customer network. Consider by whom the system would be 602 deployed, provisioned, scaled and managed. 604 The first core consideration is deployment models. 6RD requires the 605 CPE (6RD client) to send traffic to a 6RD relay. These relays can 606 share a common anycast address, or can use unique addresses. Using 607 an anycast model, the operator can deploy all the 6RD relays using 608 the same IPv4 interior service address. As the load increases on the 609 deployed relays, the operator can deploy more relays into the 610 network. The one drawback here is that it may be difficult manage 611 the traffic volume among additional relays, since all 6RD traffic 612 will find the nearest (in terms of IGP cost) relay. Use of specific 613 addresses can help provide more control but has the disadvantage of 614 being more complex to provision as CPEs will contain different 615 information. An alternative approach is to use a hybrid model using 616 multiple anycast service IPs for clusters of 6RD relays should the 617 operator anticipate massive scaling of the environment. This way, 618 the operator has multiple vectors by which to scale the service. 620 +--------+ 621 | | 622 IPv4 Addr.X | 6RD | 623 - - - > | BR | 624 +-----------+ / | | 625 | Client A | <- - - +--------+ 626 +-----------+ 627 Separate IPv4 Service Addresses 628 +-----------+ 629 | Client B | < - - +--------+ 630 +-----------+ \ | | 631 - - - > | 6RD | 632 IPv4 Addr.Y | BR | 633 | | 634 +--------+ 636 Figure 2: 6RD Multiple IPv4 Service Address Model 638 +--------+ 639 | | 640 IPv4 Addr.X | 6RD | 641 - - - > | BR | 642 +-----------+ / | | 643 | Client A |- - - - +--------+ 644 +-----------+ 645 Common (Anycast) IPv4 Service Addresses 646 +-----------+ 647 | Client B | - - - +--------+ 648 +-----------+ \ | | 649 - - - > | 6RD | 650 IPv4 Addr.X | BR | 651 | | 652 +--------+ 654 Figure 3: 6RD Anycast IPv4 Service Address Model 656 Provisioning of the endpoints is affected by the deployment model 657 chosen (i.e. anycast vs. specific service IPs). Using multiple IPs 658 may require more planning and management as customer equipment will 659 have different sets of data to be provisioned into the devices. The 660 operator may use DHCPv4, manual provisioning or other mechanisms to 661 provide parameters to customer equipment. 663 If the operator manages the CPE, support personnel will need tools 664 able to report the status of the 6RD tunnel. Usage information can 665 be counted on the operator edge, but if it requires source/ 666 destination flow details, data must be collected after the 6RD relay 667 (IPv6 side of connection). 669 +---------+ IPv4 Encapsulation +------------+ 670 | +- - - - - - - - - - - + | 671 | 6RD +----------------------+ 6RD +--------- 672 | | IPv6 Packet | Relay | IPv6 Packet 673 | Client +----------------------+ +--------- 674 | +- - - - - - - - - - - + | ^ 675 +---------+ ^ +------------+ | 676 | | 677 | | 678 IPv4 IP (Tools/Mgmt) IPv6 Flow Analysis 680 Figure 4: 6RD Tools and Flow Management 682 5.3. Phase 2: Native Dual Stack 684 Either as a follow-up phase to "Tunnelled IPv6" or as an initial 685 step, the operator may deploy Native IPv6 to the customer premise. 686 This phase would then allow for both IPv6 and IPv4 to be natively 687 accessed by the customer home gateway/CPE. The Native Dual Stack 688 phase be rolled out across the network while the tunnelled IPv6 689 service remains running. As areas begin to support Native IPv6, 690 customer home equipment can be set to use it in place of technologies 691 like 6RD. Hosts using 6to4 and/or Teredo will automatically prefer 692 [RFC3484] the IPv6 address delivered via Native IPv6 (assumed to be a 693 Delegated Prefix as per [RFC3769]). 695 Native Dual Stack is the best option, and should be sought as soon as 696 possible. During this phase, the operator can confidently move both 697 internal and external services to IPv6. Since there are no 698 translation devices needed for this mode of operation, it transports 699 both protocols (IPv6 and IPv4) efficiently within the network. 701 5.3.1. Native Dual Stack Deployment Considerations 703 Native Dual Stack is a very desirable option for deployment. The 704 operator must enable IPv6 at the network core and peering before they 705 attempt to turn on Native IPv6 services. Additionally, provisioning 706 and support systems such as DHCPv6, DNS and other functions which 707 support the customer's IPv6 Internet connection need to be in place. 709 The operator must treat IPv6 connectivity as seriously as IPv4. Poor 710 IPv6 service may be worse than not offering an IPv6 service at all, 711 since users will disable IPv6, which will be difficult for the 712 operator to reverse. New code and IPv6 functionality may cause 713 instability at first. The operator will need to monitor, 714 troubleshoot and resolve issues promptly. 716 Prefix assignment and routing are new for common residential 717 services. Prefix assignment is straightforward (DHCPv6 using 718 IA_PDs), but installation and propagation of routing information for 719 the prefix, especially during access layer instability, is often 720 poorly understood. The Operator should develop processes for 721 renumbering customers who they move to a new Access nodes. 723 Operators need to keep track of both the dynamically assigned IPv4 724 and IPv6 addresses. Any additional dynamic elements, such as auto- 725 generated DNS names, need to be considered and planned for. 727 5.4. Intermediate Phase for CGN 729 At some point during the first two phases, acquiring more IPv4 730 addresses may become challenging or impossible, therefore CGN may be 731 required on the IPv4 path. The CGN infrastructure can be enabled if 732 needed during either phase. CGN is less optimal in a 6RD deployment 733 (if used with 6RD to a given endpoint) since all traffic must 734 transverse some type of operator service node (relay and translator). 736 +--------+ ----- 737 | | / \ 738 IPv4 Flow | CGN | | | 739 - - -> + + < -> | | 740 +---------+ / | | | | 741 | CPE | <- - - / +--------+ | IPv4 | 742 |---------+ | Net | 743 | | 744 +---------+ IPv4 Flow | | 745 | CPE | <- - - - - - - - - - - - - - - > | | 746 |---------+ \ / 747 ----- 749 Figure 5: Overlay CGN Deployment 751 In the case of Native Dual Stack, CGN can be used to assist in 752 extending connectivity for the IPv4 path while the IPv6 path remains 753 native. For endpoints operating in a IPv6+CGN model the Native IPv6 754 path is available for higher quality connectivity helping host 755 operation over the network while the CGN path may offer a less then 756 optimal performance. 758 +--------+ ----- 759 | | / \ 760 IPv4 Flow | CGN | | IPv4 | 761 - - -> + + < -> | Net | 762 +---------+ / | | \ / 763 | | <- - - / +--------+ ------- 764 | Dual | 765 | Stack | ----- 766 | CPE | IPv6 Flow / IPv6 \ 767 | | <- - - - - - - - - - - - - - - > | Net | 768 |---------+ \ / 769 ----- 771 Figure 6: Dual Stack with CGN 773 CGN deployments may make use of a number of address options which 774 include RFC1918 or Shared CGN Address Space [I-D.weil-shared- 775 transition-space-request]. It is also possible that operators may 776 use part of their own RIR assigned address space for CGN zone 777 addressing if RFC918 addresses pose technical challenges in their 778 network. It is not recommended that operators use squat space as it 779 may pose additional challenges with filtering and policy control. 781 5.4.1. CGN Deployment Considerations 783 CGN is often considered undesirable by operators but required in many 784 cases. An operator who needs to deploy CGN services should consider 785 it's impacts to the network. CGN is often deployed in addition to 786 running IPv4 services and should not negatively impact the already 787 working Native IPv4 service. CGNs will also be needed at low scale 788 at first and grown to meet future demands based on traffic and 789 connection dynamics of the customer, content and network peers. 791 The operator may want to deploy CGNs more centrally at first and then 792 scale the system as needed. This approach can help conserve costs of 793 the system and only spend money on equipment with the actual growth 794 of traffic (demand on CGN system). The operator will need a 795 deployment model and architecture which allows the system to scale as 796 needed. 798 +--------+ ----- 799 | | / \ 800 | CGN | | | 801 - - -> + + < -> | | 802 +---------+ / | | | | 803 | CPE | <- - - / +--------+ | IPv4 | 804 | | ^ | | 805 |---------+ | | Net | 806 +--------+ Centralized | | 807 +---------+ | | CGN | | 808 | | | CGN | | | 809 | CPE | <- > + + <- - - - - - - > | | 810 |---------+ | | \ / 811 +--------+ ----- 812 ^ 813 | 814 Distributed CGN 816 Figure 7: CGN Deployment: Centralized vs. Distributed 818 The operator may be required to log translation information 819 [draft-sivakumar-behave-nat-logging]. This logging may require 820 significant investment in external systems which ingest, aggregate 821 and report on such information 822 [draft-donley-behave-deterministic-cgn]. 824 Since CGN has impacts on some applications 825 [draft-donley-nat444-impacts], operators may deploy CGN only for 826 those customers who do not use affected applications. Affected 827 customers could be selected by observing usage, or by offering CGN 828 and Native IPv4 for different prices. 830 5.5. Phase 3 - Tunnelled IPv4 832 Once Native IPv6 is ubiquitous, and well-supported by tools, staff, 833 and processes, an operator may consider Dual-Stack Lite. DS-Lite 834 allows growth of the IPv4 customer base using IPv4 address sharing 835 for IPv4 Internet connectivity, but with only a single layer of 836 translation, compared to CGN (NAT44). This mode of operation also 837 removes the need to directly address customer endpoints with an IPv4 838 address simplifying the connectivity to the customer (single address 839 family). 841 The operator can also move IPv4 endpoints (Dual Stack) to DS-Lite 842 retroactively to reclaim IPv4 addresses for redeployment. To 843 minimize traffic needing translation, the operator should have 844 already moved most content to IPv6 before this phase. 846 +--------+ ----- 847 | | / \ 848 Encap IPv4 Flow | AFTR | | IPv4 | 849 -------+ +---+ Net | 850 +---------+ / | | \ / 851 | | / +--------+ ----- 852 | DS-Lite +------- ----- 853 | | / \ 854 | Client | IPv6 Flow | IPv6 | 855 | +-------------------------------| Net | 856 | | \ / 857 +---------+ ----- 859 Figure 8: DS-Lite Basic Model 861 If the operator was forced to enable CGN for a NAT444 deployment, 862 they may be able to co-locate the AFTR and CGN functions within the 863 network to simplify capacity management and the engineering of flows. 864 DS-Lite however requires configuration of the CPE and the 865 implementation of the AFTR. 867 5.5.1. DS-Lite Deployment Considerations 869 The same deployment considerations associated with Native IPv6 870 deployments apply to DS-LIte. IPv4 will now be dependent on IPv6 871 service quality, so the IPv6 network and service must be running well 872 to ensure a quality experience for the end customer. Tools and 873 processes will be needed to manage the encapsulated IPv4 service. If 874 flow analysis is required for IPv4 traffic, this should be enabled at 875 a point beyond the AFTR (after de-capsulation). 877 +---------+ IPv4 Encapsulation +------------+ 878 | + - - - - - - - - - - -+ | 879 | AFTR +----------------------+ AFTR +--------- 880 | | IPv4 Packet | | IPv4 Packet 881 | Client +----------------------+ +--------- 882 | + - - - - - - - - - - -+ | ^ 883 +---------+ ^ +------------+ | 884 | | 885 | | 886 IPv6 IP (Tools/Mgmt) IPv4 Packet Flow Analysis 888 Figure 9: DS-Lite Tools and Flow Analysis 890 DS-Lite also requires client support. The operator must clearly 891 articulate to vendors which technologies will be used at which 892 points, how they interact with each other at the CPE, and how they 893 will be provisioned. As an example, an operator may use 6RD in the 894 outset of the transition, then move to Native Dual Stack followed by 895 DS-Lite. 897 6. IANA Considerations 899 No IANA considerations are defined at this time. 901 7. Security Considerations 903 No Additional Security Considerations are made in this document. 905 8. Acknowledgements 907 Thanks to the following people for their textual contributions and/or 908 guidance on IPv6 deployment considerations: John Brzozowski, Jason 909 Weil, Nik Lavorato, John Cianfarani, Chris Donley, Wesley George and 910 Tina TSOU. 912 9. References 914 9.1. Normative References 916 [I-D.ietf-v6ops-v4v6tran-framework] 917 Carpenter, B., Jiang, S., and V. Kuarsingh, "Framework for 918 IP Version Transition Scenarios", 919 draft-ietf-v6ops-v4v6tran-framework-02 (work in progress), 920 July 2011. 922 [RFC6180] Arkko, J. and F. Baker, "Guidelines for Using IPv6 923 Transition Mechanisms during IPv6 Deployment", RFC 6180, 924 May 2011. 926 9.2. Informative References 928 [I-D.donley-nat444-impacts] 929 Donley, C., Howard, L., Kuarsingh, V., Berg, J., and U. 930 Colorado, "Assessing the Impact of Carrier-Grade NAT on 931 Network Applications", draft-donley-nat444-impacts-03 932 (work in progress), November 2011. 934 [I-D.ietf-behave-lsn-requirements] 935 Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., 936 and H. Ashida, "Common requirements for Carrier Grade NAT 937 (CGN)", draft-ietf-behave-lsn-requirements-04 (work in 938 progress), October 2011. 940 [I-D.jjmb-v6ops-comcast-ipv6-experiences] 941 Brzozowski, J. and C. Griffiths, "Comcast IPv6 Trial/ 942 Deployment Experiences", 943 draft-jjmb-v6ops-comcast-ipv6-experiences-02 (work in 944 progress), October 2011. 946 [I-D.kuarsingh-v6ops-6to4-provider-managed-tunnel] 947 Kuarsingh, V., Lee, Y., and O. Vautrin, "6to4 Provider 948 Managed Tunnels", 949 draft-kuarsingh-v6ops-6to4-provider-managed-tunnel-04 950 (work in progress), September 2011. 952 [I-D.weil-shared-transition-space-request] 953 Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and 954 M. Azinger, "IANA Reserved IPv4 Prefix for Shared CGN 955 Space", draft-weil-shared-transition-space-request-09 956 (work in progress), October 2011. 958 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 959 E. Lear, "Address Allocation for Private Internets", 960 BCP 5, RFC 1918, February 1996. 962 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 963 via IPv4 Clouds", RFC 3056, February 2001. 965 [RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", 966 RFC 3068, June 2001. 968 [RFC3484] Draves, R., "Default Address Selection for Internet 969 Protocol version 6 (IPv6)", RFC 3484, February 2003. 971 [RFC3769] Miyakawa, S. and R. Droms, "Requirements for IPv6 Prefix 972 Delegation", RFC 3769, June 2004. 974 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 975 Network Address Translations (NATs)", RFC 4380, 976 February 2006. 978 [RFC4942] Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/ 979 Co-existence Security Considerations", RFC 4942, 980 September 2007. 982 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 983 Infrastructures (6rd) -- Protocol Specification", 984 RFC 5969, August 2010. 986 [RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in 987 Customer Premises Equipment (CPE) for Providing 988 Residential IPv6 Internet Service", RFC 6092, 989 January 2011. 991 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 992 NAT64: Network Address and Protocol Translation from IPv6 993 Clients to IPv4 Servers", RFC 6146, April 2011. 995 [RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, "Security 996 Concerns with IP Tunneling", RFC 6169, April 2011. 998 [RFC6264] Jiang, S., Guo, D., and B. Carpenter, "An Incremental 999 Carrier-Grade NAT (CGN) for IPv6 Transition", RFC 6264, 1000 June 2011. 1002 [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 1003 Roberts, "Issues with IP Address Sharing", RFC 6269, 1004 June 2011. 1006 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 1007 Stack Lite Broadband Deployments Following IPv4 1008 Exhaustion", RFC 6333, August 2011. 1010 [RFC6343] Carpenter, B., "Advisory Guidelines for 6to4 Deployment", 1011 RFC 6343, August 2011. 1013 Authors' Addresses 1015 Victor Kuarsingh (editor) 1016 Rogers Communications 1017 8200 Dixie Road 1018 Brampton, Ontario L6T 0C1 1019 Canada 1021 Email: victor.kuarsingh@gmail.com 1022 URI: http://www.rogers.com 1023 Lee Howard 1024 Time Warner Cable 1025 13820 Sunrise Valley Drive 1026 Herndon, VA 20171 1027 US 1029 Email: lee.howard@twcable.com 1030 URI: http://www.timewarnercable.com