idnits 2.17.00 (12 Aug 2021) /tmp/idnits51561/draft-lee-v4v6tran-problem-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 : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 17, 2010) is 4257 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 397, but no explicit reference was found in the text == Unused Reference: 'RFC3315' is defined on line 413, but no explicit reference was found in the text == Unused Reference: 'RFC3769' is defined on line 417, but no explicit reference was found in the text == Unused Reference: 'RFC4862' is defined on line 423, but no explicit reference was found in the text == Outdated reference: draft-arkko-ipv6-transition-guidelines has been published as RFC 6180 == Outdated reference: A later version (-08) exists of draft-howard-isp-ip6rdns-04 == Outdated reference: draft-ietf-v6ops-incremental-cgn has been published as RFC 6264 -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Operations Area Y. Lee, Ed. 3 Internet-Draft Comcast 4 Intended status: Informational V. Kuarsingh 5 Expires: March 21, 2011 Rogers Communications 6 G. Yang 7 China Telecom 8 G. Chen 9 China Mobile 10 September 17, 2010 12 Problem Statements of IPv6 Transition of ISP 13 draft-lee-v4v6tran-problem-02 15 Abstract 17 The IETF has defined a number of technologies and techniques that 18 targets the transition from IPv4 to IPv6. Documented techniques 19 identify high level use cases and generalized options for networks. 20 Operators may have difficulty attempting to apply the documented 21 techniques to their networks since each network and system operates 22 uniquely within the global Internet. Operators may require guidance 23 on how to identify the appropriate technology, or technologies, and 24 apply them to their specific environments. This memo describes the 25 problem statements related to the transition of operator's networks 26 to IPv6. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on March 21, 2011. 45 Copyright Notice 47 Copyright (c) 2010 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Network Problems . . . . . . . . . . . . . . . . . . . . . . . 4 64 2.1. Address Architecture . . . . . . . . . . . . . . . . . . . 4 65 2.2. Connectivity . . . . . . . . . . . . . . . . . . . . . . . 5 66 2.3. High Availability . . . . . . . . . . . . . . . . . . . . 6 67 2.4. DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 3. CPE Problems . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 4. Application Problems . . . . . . . . . . . . . . . . . . . . . 7 70 5. Network Management and Operation Problems . . . . . . . . . . 8 71 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 72 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 74 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 75 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 76 10.1. Normative References . . . . . . . . . . . . . . . . . . . 9 77 10.2. Informative References . . . . . . . . . . . . . . . . . . 10 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 80 1. Problem Statement 82 IPv4 addresses are a limited resource which are expected to exhaust 83 in the near future. As of the time of this writing, the IANA free 84 pool has been reduced to 14 /8 blocks. The current projection [ref 85 to ipv4.potaroo.net] is that IANA will exhaust this pool in less than 86 a year, with the RIRs allocating all their remaining blocks in 87 January 2012. IPv6 is the next generation IP protocol which will 88 solve the address exhaustion problem. IPv4 and IPv6 are not 89 interoperable and the uptake of IPv6 in client and server nodes will 90 be gradual. An ISP will need to take steps to ensure service 91 continuity and transparency to the customers at all times during 92 transition and coexistence. 94 It is very important that the transition to IPv6 is stable and non- 95 interruptive to existing services. It is critical to operators to 96 have a clear picture of how they will transition to IPv6. As we are 97 approaching to the initial phase of the transition, operators must 98 understand the risks and challenges ahead of time before they start 99 the transition. Each operator should have a list of items (s)he 100 should find the answers to. This item list is different from 101 operator to operator. Some may focus more on IPv6 green field 102 design, some may focus on IPv4 and IPv6 coexistence, some may focus 103 more on IPv4 constrained network environments. Many operators are 104 seeking advices, guidelines and common practices to address their 105 needs and begin the transition process. 106 [I-D.arkko-ipv6-transition-guidelines] is a good summary of the 107 existing transition technologies and techniques. It covers general 108 guidelines of transitioning. The next step would be detailed 109 guidelines for specific use case and network scenario. 111 The IETF has been developing tools for transiting to IPv6 for more 112 than a decade. However, many operators have yet to begin 113 transitioning. One possible reason is that operators face lags in 114 the IPv6 development in applications, hosts, CPEs, network equipment 115 and contents. Another possible reason is that operators didn't know 116 how to apply the technologies and techniques in their networks 117 without causing service interruption. Even IPv4 address is projected 118 to be depleted in couple years, the IPv6 adoption rate is still far 119 from desire. The IETF v6ops working group successfully addresses 120 many individual IPv6 operation issues. In the transition phase, 121 operators are seeking detailed guidelines that provide "howto" 122 information for the transition. Operators would like these 123 guidelines produced by IETF since IETF invented IPv6 and continues 124 improving it. The v4v6trans work items target to produce these 125 guidelines to assist the operators to start the transition. 127 Numbers of RFC have been published to describe mechanisms for IPv6 128 deployment, but not every RFC addresses the operation concerns. For 129 example: [RFC4213] suggests to use tunnel to connect IPv4 islands 130 over an IPv6 core network. [RFC5565] describes the protocol to 131 exchange the tunnel endpoint information. One requirement of 132 [RFC5565] is that the operator must build a full mesh to interconnect 133 all the IPv4 islands. This may cause some scaling issue. Operators 134 would like to have some guidelines and best practice to assess a 135 transition technique. 137 There exists RFCs that describes some transition mechanisms. For 138 example: [RFC4213] provides good mechanisms to transition to hosts 139 and routes to IPv6. But it doesn't address the new transition 140 techniques such as 6rd, NAT444, NAT64, DS-lite, etc. Also, there is 141 no existing memo to give tactical and strategic analyzes of these 142 techniques. For example: NAT64 requires much consideration of ALG 143 but no specific requirements to IPv6 CPE. Another example: No 144 exiting memo has discussed how multiple transition technologies fit 145 together in a given network scenario. 147 This memo attempts to describe the common problems and concerns which 148 may hinder an operator from building an IPv6 transition plan and/or 149 executing it. The memo attempts to call out the key challenges faced 150 by the providers which will require separate drafts to outline the 151 guidance to the questions and challenges raised. 153 We separate the transition problem into four areas: Network, 154 Connectivity, Applications, and Network Management and Operation. 155 Each area has its own challenges and problems. IETF may have already 156 published answers for individual problems. But it is lack of 157 collective effort that presents scenarios and recommendations for the 158 transition. In the transition phase, these guidelines and framework 159 documents are useful for operators to prioritize timelines to address 160 the transition problems. 162 2. Network Problems 164 2.1. Address Architecture 166 IPv6 by nature is a much larger address space when compared to IPv4. 167 IPv6 is intended to maintain a strong hierarchy and the address space 168 allows for many new use cases for address assignments to customers 169 and networks. Due to the shear size of the IPv6 address space, 170 special attention is required when designing the IPv6 network since 171 it will differ from the fragmented and smaller IPv4 address design. 172 Operators will need to plan in advance for IPv6 since, unlike the 173 IPv4 counterpart, will provide them with an enormous address space 174 which requires careful architectural consideration. Some basic 175 questions a operator may ask include: 177 o How to decide the IPv6 address architecture in the network? 179 o What is the recommended prefix length for a large operator? 181 o What is the recommended prefix length for a medium operator? 183 o What is the recommended prefix length to hand out to customers? 185 o What is the recommended longest prefix length an operator should 186 accept from customers? 188 o If privacy is a concern and an operator wants to use ULA in the 189 network, what are the guidelines? 191 2.2. Connectivity 193 When an operator starts transitioning to IPv6, the engineers must 194 design a network to offer service continuity to customers. Native 195 dual-stack is the natural approach. However, due to IPv4 address 196 exhaustion and cost associated to operate dual-stack network, 197 operators may consider to upgrade part of their network to IPv6-only. 198 They want to know the techniques and guidelines. Some basic 199 questions a operator may ask include: 201 o What techniques should be applied when multiple transition 202 techniques are available? 204 o What is the matrix of the different transition techniques to the 205 network and applications? 207 o How to deploy an IPv4 access network over an IPv6 core network? 209 o How to deploy an IPv6 access network over an IPv4 core network? 211 o Under what considerations, IS-IS should be used? 213 o Under what considerations, OSPFv3 should be used? 215 o What is the longest prefix to be allowed for peering? 217 o How to support traffic engineering and QoS in tunneling 218 technologies? 220 2.3. High Availability 222 High Availability (HA) is a major requirement for every service and 223 network service. Operators have accumulated tremendous experience of 224 operating HA in IPv4 using mature protocols such as VRRP and OSPF 225 Graceful Restart. Compared to IPv4, HA for IPv6 is less known. 226 During transitioning, an application running on IPv6 may need to 227 failover to IPv4 network due to network failure. New work may need 228 to be done in this area. In addition, the new transition techniques 229 require new HA models. Operators will normally deploy a transition 230 technique if HA is supported. Some basic questions a operator may 231 ask include: 233 1. What are the requirements for deploying HA in IPv6? 235 2. What are the available techniques available for IPv6? 237 3. How to failover an application from IPv6 to IPv4 (or vice versa)? 239 4. What is the HA architecture for the new transition techniques 240 such as NAT444, NAT64, DS-lite, etc. 242 2.4. DNS 244 Despite the similarity of DNS operation in IPv4 and IPv6, there are 245 some substantial differences. Most widely discussed is the usage of 246 Reverse DNS in IPv6 [I-D.howard-isp-ip6rdns]. Many applications such 247 as some email server implementations rely on Reverse DNS to operate 248 probably. Operators must find an answer to manage Reverse DNS in 249 IPv6. Some basic questions a operator may ask include: 251 1. How to support Reverse DNS in IPv6? 253 2. How to use DDNS to manage customer's IPv6 CPEs? 255 3. How to avoid unnecessary DNS translation in NAT64 scenario? 257 3. CPE Problems 259 CPE provisioning is very important for operators. operators must 260 provide a manageable and reliable provisioning mechanism to provision 261 IPv6 service to the customers. In the IPv4 world, most customers are 262 given a public address via DHCP or IPCP. Customer home network is 263 manage by a CPE and uses private address space in the home network. 264 In the IPv6 world, things work differently. Most CPEs are still 265 given an IPv6 address. However, the home network is given an IPv6 266 prefix and all the hosts behind the CPE can have public IPv6 address. 268 This changes the existing CPE provisioning model. Some basic 269 questions a operator may ask include: 271 o What provisioning mechanism should be used. DHCP or Auto- 272 configuration, or mix of two? 274 o What is the recommended length for customer prefix? 276 o How to inject the customer's PD to the access router? 278 o Should the prefix be stable? 280 o How does the home CPE manage the prefix? 282 o What is the basic model for home security? 284 o Some legacy OS don't support PPPoEv6. What other alternatives to 285 provision these devices? 287 o How to support the legacy CPEs while transitioning to IPv6? 289 4. Application Problems 291 During transitioning, IPv4 and IPv6 applications will coexist in the 292 network. Regardless to what technology or multiple technologies an 293 operator choose to use, the operator must provide service continuity. 294 These are some common questions: 296 o What is the best way to give IPv4 access to the IPv4 applications 297 over an IPv6 access and/or core network? 299 o What is the best way to enable an IPv6-only application to 300 communicate to an IPv4 application? 302 o What are the impacts of NAT444 and NAT64 to applications? 304 o How to support Single Sign-On which relies on IPv4 address in a 305 shared address environment in the operator's network? 307 o When multiple translation techniques are available, how the 308 network communicates to the applications to choose the best 309 technique? 311 5. Network Management and Operation Problems 313 In theory, managing an IPv6 network should be similar to managing an 314 IPv4 network. For example: SNMP works over IPv6 without 315 modification. During transition, new technologies and techniques may 316 be introduced to the network. These new technologies and techniques 317 require new operation models. Some basic questions a operator may 318 ask include: 320 o What is the most effective mechanism to log NAT binding in shared 321 address environment? 323 o How to scale these techniques? 325 o What is the IP sharing ratio for IPv4 address to customers? 327 o How does address sharing mechanism impact enterprise customers? 329 o How to enable an IPv6 application to communicate to a legacy IPv4 330 application? 332 6. Security Considerations 334 Security is always important and must be addressed. Some basic 335 questions a operator may ask include: 337 o What are the minimal requirements for IPv6 security? 339 o What are the additional security risks with IPv6 compared to IPv4? 341 o What IPv4 risks do not apply to IPv6? 343 o What are the known issues with existing security solutions when 344 applied to IPv6? 346 o What is involved in configuring IPv6 security? 348 7. Conclusion 350 Many operators either started or will start the transition this year 351 and next year. This memo presents some high-level questions which 352 operators encounter during the early phase of the transition. Some 353 problems are business oriented and may not be answered by the IETF. 354 But this memo explains why operators seek guidelines from the IETF 355 and want to apply them to their use cases and network scenarios. The 356 goal of these guidelines will serve as "howto" to the transition 357 process. The guidelines should also consider and discuss time 358 sequence and steps during transitioning. 359 [I-D.ietf-v6ops-incremental-cgn] is a good example to provide 360 transition steps for CGN deployment. The next 18 months are critical 361 for the transition because IPv4 addresses may be exhausted in 18 362 months. We would like to recommend the IETF to dedicate resources in 363 next few months to: 365 1. Generate individual use cases that describes the network 366 scenarios. 368 2. Generate guidelines of each use case/network scenario that 369 explain the procedures to transition to IPv6. 371 With this work effort, operators will have authoritative references 372 to design the transition process most fit to their services, networks 373 and operations. 375 8. Acknowledgements 377 The editor gathered the information from various individuals and 378 presented it in this memo. All the credits of this memo go to the 379 following contributors: Can-Can Huang, Ed Jankiewicz, Tina Tsou, 380 Cathy Zhou, Sheng Jiang, Brian Carpenter, Remi Despres, and Seiichi 381 Kawamura. 383 9. IANA Considerations 385 This memo includes no request to IANA. 387 10. References 389 10.1. Normative References 391 [I-D.arkko-ipv6-transition-guidelines] 392 Arkko, J. and F. Baker, "Guidelines for Using IPv6 393 Transition Mechanisms during IPv6 Deployment", 394 draft-arkko-ipv6-transition-guidelines-06 (work in 395 progress), August 2010. 397 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 398 Requirement Levels", BCP 14, RFC 2119, March 1997. 400 10.2. Informative References 402 [I-D.howard-isp-ip6rdns] 403 Howard, L. and A. Durand, "Reverse DNS in IPv6 for 404 Internet Service Providers", draft-howard-isp-ip6rdns-04 405 (work in progress), September 2010. 407 [I-D.ietf-v6ops-incremental-cgn] 408 Jiang, S., Guo, D., and B. Carpenter, "An Incremental 409 Carrier-Grade NAT (CGN) for IPv6 Transition", 410 draft-ietf-v6ops-incremental-cgn-01 (work in progress), 411 June 2010. 413 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 414 and M. Carney, "Dynamic Host Configuration Protocol for 415 IPv6 (DHCPv6)", RFC 3315, July 2003. 417 [RFC3769] Miyakawa, S. and R. Droms, "Requirements for IPv6 Prefix 418 Delegation", RFC 3769, June 2004. 420 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 421 for IPv6 Hosts and Routers", RFC 4213, October 2005. 423 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 424 Address Autoconfiguration", RFC 4862, September 2007. 426 [RFC5565] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh 427 Framework", RFC 5565, June 2009. 429 Authors' Addresses 431 Yiu L. Lee (editor) 432 Comcast 433 One Comcast Center 434 Philadelphia, PA 19103 435 U.S.A. 437 Email: yiu_lee@cable.comcast.com 438 URI: http://www.comcast.com 439 Victor Kuarsingh 440 Rogers Communications 441 8200 Dixie Road 442 Brampton, Ontario L6T 0C1 443 Canada 445 Email: victor.kuarsingh@rci.rogers.com 446 URI: http://www.rogers.com 448 Guoliang Yang 449 China Telecom 450 109 Zhong San Da Dao Xi 451 Guangzhou 510630 452 P.R. China 454 Email: yanggl@gsta.com 455 URI: http://www.gsta.com 457 Gang Chen 458 China Mobile 459 53A Xibianmennei Avenue 460 Beijing 100053 461 P.R. China 463 Email: chengang@chinamobile.com 464 URI: http://www.chinamobile.com