idnits 2.17.1 draft-ietf-v6ops-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 (May 9, 2012) is 4363 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.chen-v6ops-nat64-experience' is defined on line 1058, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-softwire-dslite-deployment' is defined on line 1083, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-chen-v6ops-nat64-experience-01 == Outdated reference: A later version (-09) exists of draft-donley-behave-deterministic-cgn-02 == 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-06 == Outdated reference: A later version (-08) exists of draft-ietf-softwire-dslite-deployment-03 == Outdated reference: A later version (-10) exists of draft-ietf-v6ops-464xlat-03 == Outdated reference: A later version (-07) exists of draft-kuarsingh-v6ops-6to4-provider-managed-tunnel-05 == Outdated reference: A later version (-06) exists of draft-sivakumar-behave-nat-logging-03 -- 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 (~~), 11 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: November 10, 2012 Time Warner Cable 6 May 9, 2012 8 Wireline Incremental IPv6 9 draft-ietf-v6ops-wireline-incremental-ipv6-02 11 Abstract 13 Operators worldwide are in various stages of preparing for, or 14 deploying IPv6 into their networks. The operators often face 15 difficult challenges related to both IPv6 introduction along with 16 those related to IPv4 run out. Operators will need to meet the 17 simultaneous needs of IPv6 connectivity and continue support for IPv4 18 connectivity for legacy devices with a stagnant supply of IPv4 19 addresses. The IPv6 transition will take most networks from an IPv4- 20 only environment to an IPv6 dominant environment with long transition 21 period varying by operator. This document helps provide a framework 22 for Wireline providers who are faced with the challenges of 23 introducing IPv6 along with meeting the legacy needs of IPv4 24 connectivity utilizing well defined and commercially available IPv6 25 transition technologies. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on November 10, 2012. 44 Copyright Notice 46 Copyright (c) 2012 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2. Operator Assumptions . . . . . . . . . . . . . . . . . . . . . 4 63 3. Reasons and Considerations for a Phased Approach . . . . . . . 5 64 3.1. Relevance of IPv6 and IPv4 . . . . . . . . . . . . . . . . 6 65 3.2. IPv4 Resource Challenges . . . . . . . . . . . . . . . . . 6 66 3.3. IPv6 Introduction and Operational Maturity . . . . . . . . 7 67 3.4. Service Management . . . . . . . . . . . . . . . . . . . . 7 68 3.5. Sub-Optimal Operation of Transition Technologies . . . . . 8 69 3.6. Future IPv6 Network . . . . . . . . . . . . . . . . . . . 9 70 4. IPv6 Transition Technology Analysis . . . . . . . . . . . . . 9 71 4.1. Automatic Tunnelling using 6to4 and Teredo . . . . . . . . 9 72 4.2. Carrier Grade NAT (NAT444) . . . . . . . . . . . . . . . . 10 73 4.3. 6RD . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 74 4.4. Native Dual Stack . . . . . . . . . . . . . . . . . . . . 11 75 4.5. DS-Lite . . . . . . . . . . . . . . . . . . . . . . . . . 11 76 4.6. NAT64 . . . . . . . . . . . . . . . . . . . . . . . . . . 12 77 5. IPv6 Transition Phases . . . . . . . . . . . . . . . . . . . . 12 78 5.1. Phase 0 - Foundation . . . . . . . . . . . . . . . . . . . 13 79 5.1.1. Phase 0 - Foundation: Training . . . . . . . . . . . . 13 80 5.1.2. Phase 0 - Foundation: Routing . . . . . . . . . . . . 13 81 5.1.3. Phase 0 - Foundation: Network Policy and Security . . 14 82 5.1.4. Phase 0 - Foundation: Transition Architecture . . . . 14 83 5.1.5. Phase 0- Foundation: Tools and Management . . . . . . 14 84 5.2. Phase 1 - Tunnelled IPv6 . . . . . . . . . . . . . . . . . 15 85 5.2.1. 6RD Deployment Considerations . . . . . . . . . . . . 16 86 5.3. Phase 2: Native Dual Stack . . . . . . . . . . . . . . . . 18 87 5.3.1. Native Dual Stack Deployment Considerations . . . . . 19 88 5.4. Intermediate Phase for CGN . . . . . . . . . . . . . . . . 19 89 5.4.1. CGN Deployment Considerations . . . . . . . . . . . . 21 90 5.5. Phase 3 - IPv6-Only . . . . . . . . . . . . . . . . . . . 22 91 5.5.1. DS-Lite Deployment Considerations . . . . . . . . . . 23 92 5.5.2. NAT64 Deployment Considerations . . . . . . . . . . . 23 93 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 94 7. Security Considerations . . . . . . . . . . . . . . . . . . . 24 95 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 96 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 97 9.1. Normative References . . . . . . . . . . . . . . . . . . . 24 98 9.2. Informative References . . . . . . . . . . . . . . . . . . 24 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 101 1. Introduction 103 This draft sets out to help Wireline operators in planning their IPv6 104 deployments while ensuring continued support for IPv6-incapable 105 consumer devices and applications. We will identify which 106 technologies can be used incrementally to transition from IPv4-only 107 to an IPv6 dominant environment with support for dual stack 108 operation. The end state goal for most operators will be IPv6-only, 109 but the path to this final state will heavily depend on the amount of 110 legacy equipment resident in end networks and management of long tail 111 IPv4-only content. Although no single plan will work for all 112 operators, options listed herein provide a baseline which can be 113 included in many plans. 115 This draft is intended for Wireline environments which include Cable, 116 DSL and/or Fibre as the access method to the end consumer. This 117 document attempts to follow the principles laid out in [RFC6180] 118 which provides guidance on using IPv6 transition mechanisms. This 119 document will focus on technologies which enable and mature IPv6 120 within the operator's network, but will also include a cursory view 121 of IPv4 connectivity continuance. The focal transition technologies 122 include 6RD [RFC5969], DS-Lite [RFC6333], NAT64 and Dual Stack 123 operation which may also include a CGN/NAT444 deployment. Focus on 124 these technologies is based on their inclusion in many off-the-shelf 125 CPEs and availability in commercially available equipment. 127 2. Operator Assumptions 129 For the purposes of this document, the authors assume: 131 - The operator is considering deploying IPv6 or is in progress in 132 deploying IPv6 134 - The operator has a legacy IPv4 customer base which will continue 135 to exist for a period of time 137 - The operator will want to minimize the level of disruption to 138 the existing and new customers by minimizing the number of 139 technologies and functions that are needed to mediate any given 140 set of customer flows (overall preference for Native IP flows) 142 - The operator is able to run Dual Stack on their own core network 143 and is able to transition their own services to support IPv6 145 Based on these assumptions, an operator will want to utilize 146 technologies which minimize the need to tunnel, translate or mediate 147 flows to help optimize traffic flow and lower the cost impacts of 148 transition technologies. Transition technology selections should be 149 made to mediate the non-dominant IP family flows and allow native 150 routing (IPv4 and/or IPv6) to forward the dominant traffic whenever 151 possible. This allows the operator to minimize the cost of IPv6 152 transition technologies by minimizing the transition technology 153 deployment size. 155 An operator may also choose to prefer more IPv6 focused models where 156 the use of transition technologies are based on an effort to enable 157 IPv6 at the base layer as soon as possible. Operators may want to 158 promote IPv6 early on in the deployment and have IPv6 traffic perform 159 optimally from the outset. This desire would need to be weighed 160 against the cost and support impacts of such an choice. 162 3. Reasons and Considerations for a Phased Approach 164 When faced with the challenges described in the Introduction, 165 operators may need to consider a phased approach when adding IPv6 to 166 an existing customer base. A phased approach allows the operator to 167 add in IPv6 while not ignoring legacy IPv4 connection requirements. 168 Some of the main challenges which the operator will face include: 170 - IPv4 exhaustion may occur long before all traffic is able to be 171 delivered over IPv6, necessitating IPv4 address sharing 173 - IPv6 will pose operational challenges since some of the software 174 is quite new and has had short run time in large production 175 environments and organizations are also not acclimatized to 176 supporting IPv6 as a service 178 - Many access network devices or customer controlled CPEs may not 179 support native IPv6 operation for a period of time 181 - Connectivity modes will move from IPv4-only to Dual Stack in the 182 home, changing functional behaviours in the consumer network 183 increasing support requirements for the operator 185 These challenges will occur over a period of time which means the 186 operator's plans need to address the ever changing requirements of 187 the network and customer demand. The following few sections 188 highlight some of the key reasons why a phased approach to IPv6 189 transition may be warranted and desired. 191 Although phases will be presented in this document, not all operators 192 may need to enable each desecrate phase. It is possible that 193 characteristics in individual networks may allow certain operators to 194 skip or jump to various phases. 196 3.1. Relevance of IPv6 and IPv4 198 The delivery of IPv6 connectivity should be the primary goal for 199 operators. Even though the operator may be focused on IPv6 delivery, 200 they should be aware that both IPv4 and IPv6 will play a role in the 201 Internet experience during transition. Many customers use older 202 operating systems and hardware which support IPv4-only operation. 203 Internet customers don't buy IPv4 or IPv6 connections, they buy 204 Internet connections, which demands the need to support both IPv4 and 205 IPv6 for as long at the customer's home network demands such support. 207 The Internet is made of of many interconnecting systems, networks, 208 hardware, software and content sources - all of which will move to 209 IPv6 at different rates. The Operator's mandate during this time of 210 transition will be to support connectivity to both IPv6 and IPv4 211 through various technological means. The operator may be able to 212 leverage one or the other protocol to help bridge connectivity, but 213 the home network will likely demand both IPv4 and IPv6 for some time. 215 3.2. IPv4 Resource Challenges 217 Since connectivity to IPv4-only endpoints and/or content will remain 218 common, IPv4 resource challenges are of key concern to operators. 219 The lack of new IPv4 addressees for additional devices means that 220 growth in demand of IPv4 connections in some networks will be 221 facilitated by address sharing. 223 Networks are growing at different rates including those in emerging 224 markets and established networks based on the proliferation of 225 Internet based services and devices. IPv4 address constraints will 226 likely affect many if not most operators at some point increasing the 227 benefits of IPv6. IPv4 address exhaustion is a consideration when 228 selecting technologies which rely on IPv4 to supply IPv6 services, 229 such as 6RD. Additionally, if native Dual Stack is considered by the 230 operator, challenges related to IPv4 address exhaustion remain a 231 concern. 233 Some operators may be able to reclaim small amounts IPv4 addresses 234 through addressing efficiencies in the network, although this will 235 have little lasting benefits to the network and not meet longer term 236 connectivity needs. The lack of new global IPv4 address allocations 237 will therefore force operators to support some form of IPv4 address 238 sharing and may impact technological options for transition once the 239 operator runs out of new IPv4 addresses for assignment. 241 3.3. IPv6 Introduction and Operational Maturity 243 The introduction of IPv6 will require the operationalization of IPv6. 244 The IPv4 environment we have today was built over many years and 245 matured by experience. Although many of these experiences are 246 transferable from IPv4 to IPv6, new experience specific to IPv6 will 247 be needed. 249 Engineering and Operational staff will need to develop experience 250 with IPv6. Inexperience may lead to early IPv6 deployment 251 instability, and Operators should consider this when selecting 252 technologies for initial transition. Operators may not want to 253 subject their mature IPv4 service to a "new IPv6" path initially 254 while it may be going through growing pains. DS-Lite [RFC6333] and 255 NAT64 are both technologies which requires IPv6 to support 256 connectivity to IPv4 endpoints or content over an IPv6-only access 257 network. 259 Further, some of these transition technologies are new and require 260 refinement within running code. Deployment experience is required to 261 expose bugs and stabilize software in production environments. Many 262 supporting systems are also under development and have newly 263 developed IPv6 functionality including vendor implementations of 264 DHCPv6, Management Tools, Monitoring Systems, Diagnostic systems, 265 along with other elements. 267 Although the base technological capabilities exist to enable and run 268 IPv6 in most environments, organizational experience is low. Until 269 such time as each key technical member of an operator's organization 270 can identify IPv6, understand its relevance to the IP Service 271 offering, how it operates and how to troubleshoot it - the deployment 272 is maturing. This fact should not incline operators to delay their 273 IPv6 deployment, but should drive them to deploy IPv6 sooner to gain 274 the much needed experience before IPv6 is the only viable way to 275 connect new hosts to the network. 277 It should also be noted that although many transition technologies 278 may be new, and some code related to access environments may be new, 279 there is a large segment of the networking fabric which has had IPv6 280 available for a long period of time and has had extended exposure in 281 production. Operators may use this to their advantage by first 282 enabling IPv6 in the core of their network then work outward towards 283 the customer edge. 285 3.4. Service Management 287 Services are managed within most networks and are often based on the 288 gleaning and monitoring of IPv4 addresses assigned to endpoints. 290 Operators will need to address such management tools, troubleshooting 291 methods and storage facilities (such as databases) to deal with not 292 just a new address type containing a 128-bit IPv6 address, but often 293 both IPv4 and IPv6 at the same time. Examination of address type, 294 and recording delegated prefixes along with single address 295 assignments, will likely require additional development. 297 With any Dual Stack service - whether Native, 6RD based, DS-Lite, 298 NAT64 or otherwise - two address families may need to be managed 299 simultaneously to help provide for the full Internet experience. 300 This would indicate that IPv6 management is not just a simple add in, 301 but needs to be well integrated into the service management 302 infrastructure. In the early transition phases, it's quite likely 303 that many systems will be missed and that IPv6 services will go un- 304 monitored and impairments undetected. 306 These issues may be of consideration when selecting technologies 307 which require IPv6 as the base protocol to delivery IPv4 308 connectivity. Instability on the IPv6 service in such a case would 309 impact IPv4 services. 311 3.5. Sub-Optimal Operation of Transition Technologies 313 When contrasting native Dual Stack versus other transition 314 technologies it should be noted that native IP paths are well 315 understood and networks are often optimized to send such traffic 316 efficiently. Transition technologies however, may alter the normal 317 path of traffic removing many network efficiencies built for native 318 IP flows. Tunnelling and translation devices may not be located on 319 the most optimal path in line with natural traffic flow (based on 320 route computation) and therefore may increase latency. These paths 321 may also add additional points of failure. 323 To minimize risk, an operator should use transition technologies for 324 the less dominant address family if possible. During earlier phases 325 of transition, IPv4 traffic volumes may still be dominant, so 326 tunnelling of IPv6 traffic is reasonable. Over time, as IPv6 traffic 327 volumes will increase, native delivery of IPv6 traffic becomes 328 advantageous. When IPv4 connectivity demands diminish, translation 329 and tunnelling of IPv4 over IPv6 may be acceptable and more optimal. 331 When IPv6 tunnelling is used, an operator may not want to enable IPv6 332 for their services, especially high traffic services like high 333 quality IP video. Likewise, if CGN is deployed, the operator may 334 wish to promote native IPv6 access for these services. 336 3.6. Future IPv6 Network 338 An operator should also be aware that longer term plans may include 339 IPv6-only operation in all or much of the network. This longer term 340 view may be distant to some, but should be considered when planning 341 out networks, addressing and services. The needs and costs of 342 maintaining two IP stacks will eventually become burdensome and 343 simplification will be desirable. The operators should plan for this 344 state and not make IPv6 inherently dependent on IPv4 as this would 345 unnecessarily constrain the network. 347 4. IPv6 Transition Technology Analysis 349 Operators should understand the main transition technologies for IPv6 350 deployment and IPv4 runout. This draft provides a brief description 351 of some of the mainstream and commercially available options. This 352 analysis is focused on the applicability of technologies to deliver 353 residential services and less focused on commercial access, Wireless 354 or infrastructure support. 356 The technologies in focus for this document are targeted on those 357 commercially available and in deployment. 359 4.1. Automatic Tunnelling using 6to4 and Teredo 361 Even when operators may not be actively deploying IPv6, automatic 362 mechanisms exist on customer operating systems and CPE hardware. 363 Such technologies include 6to4 [RFC3056] which is most commonly used 364 with anycast relays [RFC3068]. Teredo [RFC4380] is also used widely 365 by many Internet hosts. 367 Documents such as [RFC6343] have been written to help operators 368 understand observed problems with 6to4 deployments and provides 369 guidelines on how to improve it's performance. An Operator may want 370 to provide local relays for 6to4 and/or Teredo to help improve the 371 protocol's performance for ambient traffic utilizing these IPv6 372 connectivity methods. Experiences such as those described in 373 [I-D.jjmb-v6ops-comcast-ipv6-experiences] show that local relays have 374 proved beneficial to 6to4 protocol performance. 376 Operators should also be aware of breakage cases for 6to4 if non- 377 RFC1918 addresses are used within CGN/NAT444 zones. Many off the 378 shelf CPEs and operating systems may turn on 6to4 without a valid 379 return path to the originating (local) host. This particular usecase 380 is likely to occur if any space other than [RFC1918] is used, 381 including Shared Address Space [RFC6598] or space registered to 382 another organization (squat space). The operator can use 6to4-PMT 384 [I-D.kuarsingh-v6ops-6to4-provider-managed-tunnel] or attempt to 385 block 6to4 operation entirely by blocking the ancycast ranges 386 associated with [RFC3068]. 388 4.2. Carrier Grade NAT (NAT444) 390 Carrier Grade NAT (GGN), specifically as deployed in a NAT444 391 scenario [I-D.ietf-behave-lsn-requirements], may prove beneficial for 392 those operators who offer Dual Stack services to customer endpoints 393 once they exhaust their pools of IPv4 addresses. CGNs, and address 394 sharing overall, are known to cause certain challenges for the IPv4 395 service [RFC6269], but may be necessary depending on how an operator 396 has chosen to deal with IPv6 transition and legacy IPv4 connectivity 397 requirements. 399 In a network where IPv4 address availability is low, CGN/NAT444, may 400 provide continued access to IPv4 endpoints. Some of the advantages 401 of using CGN/NAT444 include the similarities in provisioning and 402 activation models. IPv4 hosts in a CGN/NAT444 deployment will likely 403 inherent the same addressing and management procedures as legacy 404 IPv4, globally addressed hosts (i.e. DHCPv6, DNSv4, TFTP, TR-069 405 etc). 407 4.3. 6RD 409 6RD [RFC5969] provides a way of offering IPv6 connectivity to 410 customer endpoints when native IPv6 addressing on the access network 411 is not yet possible. 6RD provides tunnelled connectivity for IPv6 412 over the existing IPv4 path. As the access edge is upgraded and 413 customer premise equipment is replaced, 6RD can be replace by native 414 IPv6 connectivity. 6RD can be delivered over top a CGN/NAT444 415 deployment, but this would cause all traffic to be subject to some 416 type of transition technology. 418 6RD may also be advantageous during the early transition while IPv6 419 traffic volumes are low. During this period, the operator can gain 420 experience with IPv6 on the core and improve their peering framework 421 to match those of the IPv4 service. 6RD scales by adding relays to 422 the operator's network. Another advantage for 6RD is that the 423 operator does not need a DHCPv6 address assignment infrastructure and 424 and does not need to support IPv6 routing to the CPE to support a 425 delegated prefix (as it's derived from the IPv4 address and other 426 configuration parameters). 428 Client support is required for 6RD operation and may not be available 429 on deployed hardware. 6RD deployments may require the customer or 430 operator to replace the CPE. 6RD will also require parameter 431 configuration which can be powered by the operator through DHCPv4, 432 manually provisioned on the CPE or automatically through some other 433 means. Manual provisioning would likely limit deployment scale. 435 4.4. Native Dual Stack 437 Native Dual Stack is often referred to as the "Gold Standard" of IPv6 438 and IPv4 delivery. It is a method of service delivery which is 439 already used in many existing IPv6 deployments. Native Dual Stack 440 does however require that Native IPv6 be delivered to the customer 441 premise. This technology option is desirable in many cases and can 442 be used immediately if the access network and customer premise 443 equipment supports native IPv6. 445 An operator who runs out of IPv4 addresses to assign to customers 446 will not be able to provide traditional native Dual Stack 447 connectivity for new customers. In Dual Stack deployments where 448 sufficient IPv4 addresses are not available, CGN/NAT444 can be used 449 on the IPv4 path. 451 Delivering native Dual Stack would require the operator's core and 452 access network to support IPv6. Other systems like DHCP, DNS, and 453 diagnostic/management facilities need to be upgraded to support IPv6 454 as well. The upgrade of such systems may often be non-trivial and 455 costly. 457 4.5. DS-Lite 459 Dual-Stack Lite (DS-Lite, [RFC6333]) is based on a native IPv6 460 connection model where IPv4 services are supported. DS-Lite provides 461 tunnelled connectivity for IPv4 over the IPv6 path between the 462 customer's network device and a provider managed gateway (AFTR). 464 DS-Lite can only be used where there is native IPv6 connection 465 between the AFTR and the CPE. This may mean that the technology's 466 use may not be viable during early transition if the core or access 467 network lacks IPv6 support. During the early transition period a 468 significant amount of content and services may by IPv4-only. 469 Operators may be sensitive to this and may not want the newer IPv6 470 path to be the only bridge to IPv4 at that time given the potential 471 impact. The operator may also want to make sure that most of their 472 internal services and a significant about of external content is 473 available over IPv6 before deploying DS-Lite. The availability of 474 services on IPv6 would help lower the demand on the AFTRs. 476 By sharing IPv4 addresses among multiple endpoints, like CGN/NAT444, 477 DS-Lite can facilitate continued support of legacy IPv4 services even 478 after IPv4 address run out. There are some functional considerations 479 to take into account even with DS-Lite such as those described in 481 [I-D.donley-nat444-impacts] and [I-D.ietf-softwire-dslite- 482 deployment]. 484 DS-Lite requires client support on the CPE to function. The ability 485 to utilize DS-Lite will be dependent on the operator providing DS- 486 Lite capable CPEs or retail availability of the supported client for 487 customer acquired endpoints. 489 4.6. NAT64 491 NAT64 [RFC6146] provides the ability to connect IPv6-only connected 492 clients and hosts to IPv4 servers without any tunnelling. NAT64 493 requires that the host and home network supports IPv6-only modes of 494 operation. Home networks do not commonly contain equipment which is 495 all IPv6-capable. It is also not anticipated that common home 496 networks will be ready for IPv6-only operation for a number of years. 497 However, IPv6-only networking can be deployed by early adopters or 498 highly controlled networks. 500 Viability of NAT64 will increase in Wireline networks as consumer 501 equipment is replaced by IPv6 capable versions. There are incentives 502 for operators to move to IPv6-only operation, when feasible, which 503 includes the simplicity of a single stack access network. 505 5. IPv6 Transition Phases 507 The Phases described in this document are not provided as a rigid set 508 of steps, but are considered a guideline which should be analyzed by 509 operators planning their IPv6 transition. Operators may choose to 510 skip steps based on technological capabilities within their specific 511 networks, (residential/corporate, fixed/mobile), their business 512 development perspectives (which may affect the pace of migration 513 towards full IPv6), or a combination thereof. 515 The phases are based on the expectation that IPv6 traffic volume may 516 initially be low, and operator staff will gain experience with IPv6 517 over time. As traffic volumes of IPv6 increase, IPv4 traffic volumes 518 will correspondingly decrease, until IPv6 is the predominant address 519 family used. Operators may want to keep the traffic flow for the 520 dominant traffic class (IPv4 vs. IPv6) native to help manage costs 521 related to transition technologies. The cost of using multiple 522 technologies in succession to optimize each stage of the transition 523 should also be compared against the cost of changing and upgrading 524 customer connections. 526 Additional guidance and information on utilizing IPv6 transition 527 mechanisms can be found in [RFC6180]. Also, guidance on incremental 528 CGN for IPv6 transition can also be found in [RFC6264]. 530 5.1. Phase 0 - Foundation 532 5.1.1. Phase 0 - Foundation: Training 534 Training is one of the most important steps in preparing an 535 organization to support IPv6. Most people have little experience 536 with IPv6, and many do not even have a solid grounding in IPv4. The 537 implementation of IPv6 will likely produce many challenges due to 538 immature code on hardware, and the evolution of many applications and 539 systems to support IPv6. To properly deal with these impending or 540 current challenges organizations must train their staff on IPv6. 542 Training should also be provided within reasonable timelines from the 543 actual IPv6 deployment. This means the operator needs to plan in 544 advance as they train the various parts of their organization. New 545 Technology and Engineering staff often receive little training 546 because of their depth of knowledge, but must at least be provided 547 opportunities to read documentation, architectural white papers, and 548 RFCs. Operations staff who support the network and other systems 549 need to be trained closer to the deployment timeframes, so they 550 immediately use their new-found knowledge before forgetting. 552 Customer support staff would require much more basic but large scale 553 training since many organizations have massive call centres to 554 support the customer base. Tailored training will also be required 555 for marketing and sales staff to help them understand IPv6 and build 556 it into the product development and sales process. 558 5.1.2. Phase 0 - Foundation: Routing 560 The network infrastructure will need to be in place to support IPv6. 561 This includes the routed infrastructure along with addressing 562 principles, routing principles, peering policy and related network 563 functions. Since IPv6 is quite different from IPv4 in several ways 564 including the number of addresses which are made available, careful 565 attention to a scalable and manageable architecture needs to be made. 566 One such change is the notion of a delegated prefix which deviates 567 from the common single address phenomenon in IPv4-only deployments. 568 Deploying prefixes per CPE can load the routing tables and require a 569 routing protocol or route gleaning to manage connectivity to the 570 customer's network. Delegating prefixes can be of specific 571 importance in access network environments where downstream customers 572 often move between access nodes, raising the concern of frequent 573 renumbering and/or managing movement of routed prefixes within the 574 network (common in cable based networks). 576 5.1.3. Phase 0 - Foundation: Network Policy and Security 578 Many, but not all, security policies will map easily from IPv4 to 579 IPv6. Some new policies may be required for issues specific to IPv6 580 operation. This document does not highlight these specific issues, 581 but raises the awareness they are of consideration and should be 582 addressed when delivering IPv6 services. Other IETF documents such 583 as [RFC4942], [RFC6092], and [RFC6169] are excellent resources. 585 5.1.4. Phase 0 - Foundation: Transition Architecture 587 The operators should plan out their transition architecture in 588 advance (with room for flexibility) to help optimize how they will 589 build out and scale their networks. Should the operator consider 590 multiple technologies like CGN/NAT444, DS-Lite, NAT64 and 6RD, they 591 may want to plan out where network resident equipment may be located 592 and potentially choose locations which can be used for all functional 593 roles (i.e. placement of NAT44 translator, AFTR, NAT64 gateway and 594 6RD relays). Although these functions are not inherently connected, 595 additional management, diagnostic and monitoring functions can be 596 deployed along side the transition hardware without the need to 597 distribute these to an excessive or divergent number of locations. 599 This approach may also prove beneficial if traffic patterns change 600 rapidly in the future as the operators may need to evolve their 601 transition infrastructure faster than originally anticipated. Once 602 such example may be the movement from a CGN/NAT44 model (dual stack) 603 to DS-Lite. Since both traffic sets require a translation function 604 (NAT44), synchronized pool management, routing and management system 605 positioning can allow rapid movement (notwithstanding the 606 technological means to re-provision the customers). 608 Operators should inform their vendors of what technologies they plan 609 to support over the course of the transition to make sure the 610 equipment is suited to support those modes of operation. This is 611 important for both network gear and customer premise equipment. 613 The operator should also plan their overall strategy to meet the 614 target needs of an IPv6-only deployment. As traffic moves to IPv6, 615 the benefits of only a single stack on the access network may justify 616 the removal of IPv4 for simplicity. Planning for this eventual 617 model, no matter how far off this may be, will help the operator 618 embrace this end state when needed. 620 5.1.5. Phase 0- Foundation: Tools and Management 622 The operator should thoroughly analyze all provisioning and 623 management systems to develop requirements for each phase. This will 624 include concepts related to the 128-bit IPv6 address, the notation of 625 an assigned IPv6 prefix (PD) and the ability to detect either or both 626 address families when determining if a customer has full Internet 627 service. 629 If an operator stores usage information, this would need to be 630 aggregated to include both the IPv4 and IPv6 traffic flows. Also, 631 tools that verify connectivity may need to query the IPv4 and IPv6 632 addresses. 634 5.2. Phase 1 - Tunnelled IPv6 636 Tunnelled access to IPv6 can be regarded as an early stage transition 637 option by operators. Many network operators can deploy native IPv6 638 from the access edge to the peering edge fairly quickly but may not 639 be able to offer IPv6 natively to the customer edge device. During 640 this period of time, tunnelled access to IPv6 is a viable alternative 641 to native IPv6. It is also possible that operators my be rolling out 642 IPv6 natively to the customer edge but the time involved may be long 643 due to logistics and other factors. Even while slowly rolling out 644 native IPv6, operators can deploy relays for automatic tunnelling 645 technologies like 6to4 and Teredo. Where native IPv6 to the access 646 edge is a longer-term project, operators can consider 6RD [RFC5969] 647 as an option to offer in-home IPv6 access. Note that 6to4 and Teredo 648 have different address selection behaviours than 6RD [RFC3484]. 649 Additional guidelines on deploying and supporting 6to4 can be found 650 in [RFC6343]. 652 The operator can deploy 6RD relays into the network and scale them as 653 needed to meet the early customer needs of IPv6. Since 6RD requires 654 the upgrade or replacement of CPE devices, the operator may want 655 ensure that the CPE devices support not just 6RD but native Dual 656 Stack and other tunnelling technologies if possible such as DS-Lite. 657 6RD clients are becoming available in some retail channel products 658 and within the OEM market. Retail availability of 6RD is important 659 since not all operators control or have influence over what equipment 660 is deployed in the consumer home network. The operator can support 661 6RD access with unmanaged devices using DHCPv4 option 212 662 (OPTION_6RD). 664 +--------+ ----- 665 | | / \ 666 Encap IPv6 Flow | 6RD | | IPv6 | 667 - - -> | BR | <- > | Net | 668 +---------+ / | | \ / 669 | | / +--------+ ----- 670 | 6RD + <----- ----- 671 | | / \ 672 | Client | IPv4 Flow | IPv4 | 673 | + < - - - - - - - - - - - - - - -> | Net | 674 | | \ / 675 +---------+ ----- 677 Figure 1: 6RD Basic Model 679 6RD used as an initial transition technology also provides the added 680 benefit of a deterministic IPv6 prefix which is based on the IPv4 681 assigned address. Many operational tools are available or have been 682 built to identify what IPv4 (often dynamic) address was assigned to a 683 customer CPE. So a simple tool and/or method can be built to help 684 the operational staff in an organization know that the IPv6 prefix is 685 for a 6RD serviced CPE based on knowledge of the IPv4 address. 687 An operator may choose to not offer internal services over IPv6 if 688 tunnelled access to IPv6 is used since some services generate a large 689 amount of traffic. Such traffic may include Video content like IPTV. 690 By limiting how much traffic is delivered over the 6RD connection (if 691 possible), the operator can avoid costly and complex scaling of the 692 relay infrastructure. 694 5.2.1. 6RD Deployment Considerations 696 Deploying 6RD can greatly speed up an operator's ability to support 697 IPv6 to the customer network if native IPv6 connectivity cannot be 698 supplied. The speed at which 6RD can be deployed is highlighted in 699 [RFC5569]. 701 The first core consideration is deployment models. 6RD requires the 702 CPE (6RD client) to send traffic to a 6RD relay. These relays can 703 share a common anycast address, or can use unique addresses. Using 704 an anycast model, the operator can deploy all the 6RD relays using 705 the same IPv4 interior service address. As the load increases on the 706 deployed relays, the operator can deploy more relays into the 707 network. The one drawback here is that it may be difficult to manage 708 the traffic volume among additional relays, since all 6RD traffic 709 will find the nearest (in terms of IGP cost) relay. Use of multiple 710 relay addresses can help provide more control but has the 711 disadvantage of being more complex to provision as subsets of CPEs 712 across the network will require and contain different relay 713 information. An alternative approach is to use a hybrid model using 714 multiple anycast service IPs for clusters of 6RD relays should the 715 operator anticipate massive scaling of the environment. Thus, the 716 operator has multiple vectors by which to scale the service. 718 +--------+ 719 | | 720 IPv4 Addr.X | 6RD | 721 - - - > | BR | 722 +-----------+ / | | 723 | Client A | <- - - +--------+ 724 +-----------+ 725 Separate IPv4 Service Addresses 726 +-----------+ 727 | Client B | < - - +--------+ 728 +-----------+ \ | | 729 - - - > | 6RD | 730 IPv4 Addr.Y | BR | 731 | | 732 +--------+ 734 Figure 2: 6RD Multiple IPv4 Service Address Model 736 +--------+ 737 | | 738 IPv4 Addr.X | 6RD | 739 - - - > | BR | 740 +-----------+ / | | 741 | Client A |- - - - +--------+ 742 +-----------+ 743 Common (Anycast) IPv4 Service Addresses 744 +-----------+ 745 | Client B | - - - +--------+ 746 +-----------+ \ | | 747 - - - > | 6RD | 748 IPv4 Addr.X | BR | 749 | | 750 +--------+ 752 Figure 3: 6RD Anycast IPv4 Service Address Model 754 Provisioning of the endpoints is affected by the deployment model 755 chosen (i.e. anycast vs. specific service IPs). Using multiple IPs 756 may require more planning and management as customer equipment will 757 have different sets of data to be provisioned into the devices. The 758 operator may use DHCPv4, manual provisioning or other mechanisms to 759 provide parameters to customer equipment. 761 If the operator manages the CPE, support personnel will need tools 762 able to report the status of the 6RD tunnel. Usage information can 763 be counted on the operator edge, but if it requires source/ 764 destination flow details, data must be collected after the 6RD relay 765 (IPv6 side of connection). 767 +---------+ IPv4 Encapsulation +------------+ 768 | +- - - - - - - - - - - + | 769 | 6RD +----------------------+ 6RD +--------- 770 | | IPv6 Packet | Relay | IPv6 Packet 771 | Client +----------------------+ +--------- 772 | +- - - - - - - - - - - + | ^ 773 +---------+ ^ +------------+ | 774 | | 775 | | 776 IPv4 IP (Tools/Mgmt) IPv6 Flow Analysis 778 Figure 4: 6RD Tools and Flow Management 780 5.3. Phase 2: Native Dual Stack 782 Either as a follow-up phase to "Tunnelled IPv6" or as an initial 783 step, the operator may deploy native IPv6 down to the CPEs. This 784 phase would then allow for both IPv6 and IPv4 to be natively accessed 785 by the customer home network without translation or tunnelling. The 786 native Dual Stack phase can be rolled out across the network while 787 the tunnelled IPv6 service remains operational, if used. As areas 788 begin to support native IPv6, customer home equipment will generally 789 prefer using the IPv6 addresses derived from the delegated IPv6 790 prefix versus tunnelling options such as 6to4, 6RD and Teredo as 791 defined in [RFC3484] 793 Native Dual Stack is the best option at this point in the transition, 794 and should be sought as soon as possible. During this phase, the 795 operator can confidently move both internal and external services to 796 IPv6. Since there are no translation devices needed for this mode of 797 operation, it transports both protocols (IPv6 and IPv4) efficiently 798 within the network. 800 5.3.1. Native Dual Stack Deployment Considerations 802 Native Dual Stack is a very desirable option for the IPv6 transition 803 if feasible. The operator must enable IPv6 on the network core and 804 peering edge before they attempt to turn on native IPv6 services. 805 Additionally, provisioning and support systems such as DHCPv6, DNS 806 and other functions which support the customer's IPv6 Internet 807 connection need to be in place. 809 The operator must treat IPv6 connectivity with the same operational 810 importance as IPv4. Poor IPv6 service may be worse than not offering 811 an IPv6 service at all, since users may cause users to disable IPv6 812 and negatively impact their Internet experience. New code and IPv6 813 functionality may cause instability at first. The operator will need 814 to monitor, troubleshoot and resolve issues promptly. 816 Prefix assignment and routing are new for common residential 817 services. Prefix assignment is straightforward (DHCPv6 using 818 IA_PDs), but installation and propagation of routing information for 819 the prefix, especially during access layer instability, is often 820 poorly understood. The Operator should develop processes for 821 renumbering customers who move to new Access nodes. 823 Operators need to keep track of both the dynamically assigned IPv4 824 address along with the IPv6 address and prefix. Any additional 825 dynamic elements, such as auto-generated host names, need to be 826 considered and planned for. 828 5.4. Intermediate Phase for CGN 830 Acquiring more IPv4 addresses is already challenging, if not 831 impossible, therefore address sharing may be required on the IPv4 832 path. The operator may have a preference to move directly to a more 833 efficient way of IPv4 address sharing such as DS-Lite, but conditions 834 may dictate that CGN/NAT444 is the only workable option. CGN/NAT444 835 is less optimal and should be used cautiously in a 6RD deployment (if 836 used with 6RD to a given endpoint) since all traffic must traverse 837 some type of operator service node (relay and translator). 839 +--------+ ----- 840 | | / \ 841 IPv4 Flow | CGN | | | 842 - - -> + + < -> | | 843 +---------+ / | | | | 844 | CPE | <- - - / +--------+ | IPv4 | 845 |---------+ | Net | 846 | | 847 +---------+ IPv4 Flow | | 848 | CPE | <- - - - - - - - - - - - - - - > | | 849 |---------+ \ / 850 ----- 852 Figure 5: Overlay CGN Deployment 854 In the case of native Dual Stack, CGN/NAT444 can be used to assist in 855 extending connectivity for the IPv4 path while the IPv6 path remains 856 native. For endpoints operating in a IPv6+CGN/NAT444 model the 857 native IPv6 path is available for higher quality connectivity helping 858 host operation over the network while the CGN path may offer a less 859 than optimal performance. These points are also true for DS-Lite. 861 +--------+ ----- 862 | | / \ 863 IPv4 Flow | CGN | | IPv4 | 864 - - -> + + < -> | Net | 865 +---------+ / | | \ / 866 | | <- - - / +--------+ ------- 867 | Dual | 868 | Stack | ----- 869 | CPE | IPv6 Flow / IPv6 \ 870 | | <- - - - - - - - - - - - - - - > | Net | 871 |---------+ \ / 872 ----- 874 Figure 6: Dual Stack with CGN 876 CGN/NAT444 deployments may make use of a number of address options 877 which include RFC1918 or Shared Address Space [RFC6598]. It is also 878 possible that operators may use part of their own RIR assigned 879 address space for CGN zone addressing if [RFC1918] addresses pose 880 technical challenges in their network. It is not recommended that 881 operators use squat space as it may pose additional challenges with 882 filtering and policy control, 884 5.4.1. CGN Deployment Considerations 886 CGN is often considered undesirable by operators but required in many 887 cases. An operator who needs to deploy CGN capabilities should 888 consider the impacts of the function to the network. CGN is often 889 deployed in addition to running IPv4 services and should not 890 negatively impact the already working Native IPv4 service. CGNs will 891 also be needed at low scale at first and grown to meet the demands 892 based on traffic and connection dynamics of the customer, content and 893 network peers. 895 The operator may want to deploy CGNs more centrally at first and then 896 scale the system as needed. This approach can help conserve costs of 897 the system and only spend money on equipment based on the actual 898 growth of traffic (demand on CGN system). The operator will need a 899 deployment model and architecture which allows the system to scale as 900 needed. 902 +--------+ ----- 903 | | / \ 904 | CGN | | | 905 - - -> + + < -> | | 906 +---------+ / | | | | 907 | CPE | <- - - / +--------+ | IPv4 | 908 | | ^ | | 909 |---------+ | | Net | 910 +--------+ Centralized | | 911 +---------+ | | CGN | | 912 | | | CGN | | | 913 | CPE | <- > + + <- - - - - - - > | | 914 |---------+ | | \ / 915 +--------+ ----- 916 ^ 917 | 918 Distributed CGN 920 Figure 7: CGN Deployment: Centralized vs. Distributed 922 The operator may be required to log translation information 923 [I-D.sivakumar-behave-nat-logging]. This logging may require 924 significant investment in external systems which ingest, aggregate 925 and report on such information [I-D.donley-behave-deterministic-cgn]. 927 Since CGN has noticeable impacts on certain applications [I.D.donley- 928 nat444-impacts], operators may deploy CGN only for those customers 929 who may not likely be affected by CGN (if possible). 931 5.5. Phase 3 - IPv6-Only 933 Once Native IPv6 is widely deployed in the network and well-supported 934 by tools, staff, and processes, an operator may consider supporting 935 only IPv6 to all or some customer endpoints. During this final 936 phase, IPv4 connectivity may or may not need to be supported 937 depending on the conditions of the network and customer demand. If 938 legacy IPv4 connectivity is still demanded, DS-Lite may be used to 939 tunnel the traffic. If IPv4 connectivity is not required, but access 940 to legacy IPv4 content is , then NAT64 can be used. 942 DS-Lite allows continued access for the IPv4 customer base using 943 address sharing for IPv4 Internet connectivity, but with only a 944 single layer of translation, compared to CGN/NAT444. This mode of 945 operation also removes the need to directly address customer 946 endpoints with an IPv4 address simplifying the connectivity to the 947 customer (single address family) and supporting IPv6 only addressing 948 to the CPE. 950 The operator can also move Dual Stack endpoints to DS-Lite 951 retroactively to help optimize the IPv4 address sharing deployment by 952 removing the IPv4 address assignment and routing component. To 953 minimize traffic needing translation, the operator should have 954 already moved most content to IPv6 before the IPv6-only phase is 955 implemented. 956 +--------+ ----- 957 | | / \ 958 Encap IPv4 Flow | AFTR | | IPv4 | 959 -------+ +---+ Net | 960 +---------+ / | | \ / 961 | | / +--------+ ----- 962 | DS-Lite +------- ----- 963 | | / \ 964 | Client | IPv6 Flow | IPv6 | 965 | +-------------------------------| Net | 966 | | \ / 967 +---------+ ----- 969 Figure 8: DS-Lite Basic Model 971 If the operator decided to enable a CGN/NAT444 deployment, they may 972 be able to co-locate the AFTR and CGN/NAT444 processing functions 973 within a common network location to simplify capacity management and 974 the engineering of flows. This case may be evident in a later 975 transition stages when an operator chooses to optimize their network 976 and IPv6-only operation is feasible. 978 5.5.1. DS-Lite Deployment Considerations 980 The same deployment considerations associated with Native IPv6 981 deployments apply to DS-LIte and NAT64. IPv4 will now be dependent 982 on IPv6 service quality, so the IPv6 network and services must be 983 running well to ensure a quality experience for the end customer. 984 Tools and processes will be needed to manage the encapsulated IPv4 985 service. If flow analysis is required for IPv4 traffic, this should 986 be enabled at a point beyond the AFTR (after de-capsulation). 988 +---------+ IPv4 Encapsulation +------------+ 989 | + - - - - - - - - - - -+ | 990 | AFTR +----------------------+ AFTR +--------- 991 | | IPv4 Packet | | IPv4 Packet 992 | Client +----------------------+ +--------- 993 | + - - - - - - - - - - -+ | ^ 994 +---------+ ^ +------------+ | 995 | | 996 | | 997 IPv6 IP (Tools/Mgmt) IPv4 Packet Flow Analysis 999 Figure 9: DS-Lite Tools and Flow Analysis 1001 DS-Lite also requires client support. The operator must clearly 1002 articulate to vendors which technologies will be used at which 1003 points, how they interact with each other at the CPE, and how they 1004 will be provisioned. As an example, an operator may use 6RD in the 1005 outset of the transition, then move to Native Dual Stack followed by 1006 DS-Lite. 1008 5.5.2. NAT64 Deployment Considerations 1010 The deployment of NAT64 assumes the network assigns an IPv6 addresses 1011 to an network endpoint which are translated to IPv4 addresses to 1012 provide connectivity to IPv4 Internet services and content. 1013 Experiments such as the one described in [RFC6586] highlight issues 1014 related to IPv6-only deployments due to legacy IPv4 APIs and IPv4 1015 literals. Many of these issues will be resolved by the eventual 1016 removal this undesired legacy behaviour. In the short term, 1017 technology options include the 464xlat [I-D.ietf-v6ops-464xlat] model 1018 which helps managed legacy IPv4 calls. Operational deployment models 1019 and experiences related to NAT64 have been documented in [I-D.chen- 1020 v6ops-nat64-experience]. 1022 As the support for IPv6 increased within content and network 1023 endpoints, the more efficient the IPv6-Only model becomes with NAT64. 1025 The NAT64 deployment would see an overall declined in usage as more 1026 traffic is promoted to IPv6 to IPv6 native communication. NAT64 may 1027 play an important part of an operators late stage transition as it 1028 removes the need to support IPv4 on the access network and provides a 1029 solid go-forward networking model. 1031 6. IANA Considerations 1033 No IANA considerations are defined at this time. 1035 7. Security Considerations 1037 No Additional Security Considerations are made in this document. 1039 8. Acknowledgements 1041 Special thanks to Wes George, Christian Jacquenet and John Brzozowski 1042 for their extensive review and comments. 1044 Thanks to the following people for their textual contributions and/or 1045 guidance on IPv6 deployment considerations: Jason Weil, Gang Chen, 1046 Nik Lavorato, John Cianfarani, Chris Donley, and Tina TSOU. 1048 9. References 1050 9.1. Normative References 1052 [RFC6180] Arkko, J. and F. Baker, "Guidelines for Using IPv6 1053 Transition Mechanisms during IPv6 Deployment", RFC 6180, 1054 May 2011. 1056 9.2. Informative References 1058 [I-D.chen-v6ops-nat64-experience] 1059 Chen, G., Cao, Z., Byrne, C., and Q. Niu, "NAT64 1060 Operational Experiences", 1061 draft-chen-v6ops-nat64-experience-01 (work in progress), 1062 March 2012. 1064 [I-D.donley-behave-deterministic-cgn] 1065 Donley, C., Grundemann, C., Sarawat, V., and K. 1066 Sundaresan, "Deterministic Address Mapping to Reduce 1067 Logging in Carrier Grade NAT Deployments", 1068 draft-donley-behave-deterministic-cgn-02 (work in 1069 progress), March 2012. 1071 [I-D.donley-nat444-impacts] 1072 Donley, C., Howard, L., Colorado, U., and V. Kuarsingh, 1073 "Assessing the Impact of Carrier-Grade NAT on Network 1074 Applications", draft-donley-nat444-impacts-03 (work in 1075 progress), November 2011. 1077 [I-D.ietf-behave-lsn-requirements] 1078 Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., 1079 and H. Ashida, "Common requirements for Carrier Grade NATs 1080 (CGNs)", draft-ietf-behave-lsn-requirements-06 (work in 1081 progress), May 2012. 1083 [I-D.ietf-softwire-dslite-deployment] 1084 Lee, Y., Maglione, R., Williams, C., Jacquenet, C., and M. 1085 Boucadair, "Deployment Considerations for Dual-Stack 1086 Lite", draft-ietf-softwire-dslite-deployment-03 (work in 1087 progress), March 2012. 1089 [I-D.ietf-v6ops-464xlat] 1090 Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: 1091 Combination of Stateful and Stateless Translation", 1092 draft-ietf-v6ops-464xlat-03 (work in progress), May 2012. 1094 [I-D.jjmb-v6ops-comcast-ipv6-experiences] 1095 Brzozowski, J. and C. Griffiths, "Comcast IPv6 Trial/ 1096 Deployment Experiences", 1097 draft-jjmb-v6ops-comcast-ipv6-experiences-02 (work in 1098 progress), October 2011. 1100 [I-D.kuarsingh-v6ops-6to4-provider-managed-tunnel] 1101 Kuarsingh, V., Lee, Y., and O. Vautrin, "6to4 Provider 1102 Managed Tunnels", 1103 draft-kuarsingh-v6ops-6to4-provider-managed-tunnel-05 1104 (work in progress), February 2012. 1106 [I-D.sivakumar-behave-nat-logging] 1107 Sivakumar, S., "Logging of NAT Events", 1108 draft-sivakumar-behave-nat-logging-03 (work in progress), 1109 October 2011. 1111 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1112 E. Lear, "Address Allocation for Private Internets", 1113 BCP 5, RFC 1918, February 1996. 1115 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 1116 via IPv4 Clouds", RFC 3056, February 2001. 1118 [RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", 1119 RFC 3068, June 2001. 1121 [RFC3484] Draves, R., "Default Address Selection for Internet 1122 Protocol version 6 (IPv6)", RFC 3484, February 2003. 1124 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 1125 Network Address Translations (NATs)", RFC 4380, 1126 February 2006. 1128 [RFC4942] Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/ 1129 Co-existence Security Considerations", RFC 4942, 1130 September 2007. 1132 [RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 1133 Infrastructures (6rd)", RFC 5569, January 2010. 1135 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 1136 Infrastructures (6rd) -- Protocol Specification", 1137 RFC 5969, August 2010. 1139 [RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in 1140 Customer Premises Equipment (CPE) for Providing 1141 Residential IPv6 Internet Service", RFC 6092, 1142 January 2011. 1144 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 1145 NAT64: Network Address and Protocol Translation from IPv6 1146 Clients to IPv4 Servers", RFC 6146, April 2011. 1148 [RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, "Security 1149 Concerns with IP Tunneling", RFC 6169, April 2011. 1151 [RFC6264] Jiang, S., Guo, D., and B. Carpenter, "An Incremental 1152 Carrier-Grade NAT (CGN) for IPv6 Transition", RFC 6264, 1153 June 2011. 1155 [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 1156 Roberts, "Issues with IP Address Sharing", RFC 6269, 1157 June 2011. 1159 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 1160 Stack Lite Broadband Deployments Following IPv4 1161 Exhaustion", RFC 6333, August 2011. 1163 [RFC6343] Carpenter, B., "Advisory Guidelines for 6to4 Deployment", 1164 RFC 6343, August 2011. 1166 [RFC6586] Arkko, J. and A. Keranen, "Experiences from an IPv6-Only 1167 Network", RFC 6586, April 2012. 1169 [RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and 1170 M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address 1171 Space", BCP 153, RFC 6598, April 2012. 1173 Authors' Addresses 1175 Victor Kuarsingh (editor) 1176 Rogers Communications 1177 8200 Dixie Road 1178 Brampton, Ontario L6T 0C1 1179 Canada 1181 Email: victor.kuarsingh@gmail.com 1182 URI: http://www.rogers.com 1184 Lee Howard 1185 Time Warner Cable 1186 13820 Sunrise Valley Drive 1187 Herndon, VA 20171 1188 US 1190 Email: lee.howard@twcable.com 1191 URI: http://www.timewarnercable.com