Operations Area Y. Lee, Ed. Internet-Draft Comcast Intended status: Informational V. Kuarsingh Expires: March 21, 2011 Rogers Communications G. Yang China Telecom G. Chen China Mobile September 17, 2010 Problem Statements of IPv6 Transition of ISP draft-lee-v4v6tran-problem-02 Abstract The IETF has defined a number of technologies and techniques that targets the transition from IPv4 to IPv6. Documented techniques identify high level use cases and generalized options for networks. Operators may have difficulty attempting to apply the documented techniques to their networks since each network and system operates uniquely within the global Internet. Operators may require guidance on how to identify the appropriate technology, or technologies, and apply them to their specific environments. This memo describes the problem statements related to the transition of operator's networks to IPv6. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on March 21, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. Lee, et al. Expires March 21, 2011 [Page 1] Internet-Draft IPv6 Transition September 2010 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 2. Network Problems . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Address Architecture . . . . . . . . . . . . . . . . . . . 4 2.2. Connectivity . . . . . . . . . . . . . . . . . . . . . . . 5 2.3. High Availability . . . . . . . . . . . . . . . . . . . . 6 2.4. DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. CPE Problems . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Application Problems . . . . . . . . . . . . . . . . . . . . . 7 5. Network Management and Operation Problems . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 10.1. Normative References . . . . . . . . . . . . . . . . . . . 9 10.2. Informative References . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Lee, et al. Expires March 21, 2011 [Page 2] Internet-Draft IPv6 Transition September 2010 1. Problem Statement IPv4 addresses are a limited resource which are expected to exhaust in the near future. As of the time of this writing, the IANA free pool has been reduced to 14 /8 blocks. The current projection [ref to ipv4.potaroo.net] is that IANA will exhaust this pool in less than a year, with the RIRs allocating all their remaining blocks in January 2012. IPv6 is the next generation IP protocol which will solve the address exhaustion problem. IPv4 and IPv6 are not interoperable and the uptake of IPv6 in client and server nodes will be gradual. An ISP will need to take steps to ensure service continuity and transparency to the customers at all times during transition and coexistence. It is very important that the transition to IPv6 is stable and non- interruptive to existing services. It is critical to operators to have a clear picture of how they will transition to IPv6. As we are approaching to the initial phase of the transition, operators must understand the risks and challenges ahead of time before they start the transition. Each operator should have a list of items (s)he should find the answers to. This item list is different from operator to operator. Some may focus more on IPv6 green field design, some may focus on IPv4 and IPv6 coexistence, some may focus more on IPv4 constrained network environments. Many operators are seeking advices, guidelines and common practices to address their needs and begin the transition process. [I-D.arkko-ipv6-transition-guidelines] is a good summary of the existing transition technologies and techniques. It covers general guidelines of transitioning. The next step would be detailed guidelines for specific use case and network scenario. The IETF has been developing tools for transiting to IPv6 for more than a decade. However, many operators have yet to begin transitioning. One possible reason is that operators face lags in the IPv6 development in applications, hosts, CPEs, network equipment and contents. Another possible reason is that operators didn't know how to apply the technologies and techniques in their networks without causing service interruption. Even IPv4 address is projected to be depleted in couple years, the IPv6 adoption rate is still far from desire. The IETF v6ops working group successfully addresses many individual IPv6 operation issues. In the transition phase, operators are seeking detailed guidelines that provide "howto" information for the transition. Operators would like these guidelines produced by IETF since IETF invented IPv6 and continues improving it. The v4v6trans work items target to produce these guidelines to assist the operators to start the transition. Numbers of RFC have been published to describe mechanisms for IPv6 Lee, et al. Expires March 21, 2011 [Page 3] Internet-Draft IPv6 Transition September 2010 deployment, but not every RFC addresses the operation concerns. For example: [RFC4213] suggests to use tunnel to connect IPv4 islands over an IPv6 core network. [RFC5565] describes the protocol to exchange the tunnel endpoint information. One requirement of [RFC5565] is that the operator must build a full mesh to interconnect all the IPv4 islands. This may cause some scaling issue. Operators would like to have some guidelines and best practice to assess a transition technique. There exists RFCs that describes some transition mechanisms. For example: [RFC4213] provides good mechanisms to transition to hosts and routes to IPv6. But it doesn't address the new transition techniques such as 6rd, NAT444, NAT64, DS-lite, etc. Also, there is no existing memo to give tactical and strategic analyzes of these techniques. For example: NAT64 requires much consideration of ALG but no specific requirements to IPv6 CPE. Another example: No exiting memo has discussed how multiple transition technologies fit together in a given network scenario. This memo attempts to describe the common problems and concerns which may hinder an operator from building an IPv6 transition plan and/or executing it. The memo attempts to call out the key challenges faced by the providers which will require separate drafts to outline the guidance to the questions and challenges raised. We separate the transition problem into four areas: Network, Connectivity, Applications, and Network Management and Operation. Each area has its own challenges and problems. IETF may have already published answers for individual problems. But it is lack of collective effort that presents scenarios and recommendations for the transition. In the transition phase, these guidelines and framework documents are useful for operators to prioritize timelines to address the transition problems. 2. Network Problems 2.1. Address Architecture IPv6 by nature is a much larger address space when compared to IPv4. IPv6 is intended to maintain a strong hierarchy and the address space allows for many new use cases for address assignments to customers and networks. Due to the shear size of the IPv6 address space, special attention is required when designing the IPv6 network since it will differ from the fragmented and smaller IPv4 address design. Operators will need to plan in advance for IPv6 since, unlike the IPv4 counterpart, will provide them with an enormous address space which requires careful architectural consideration. Some basic Lee, et al. Expires March 21, 2011 [Page 4] Internet-Draft IPv6 Transition September 2010 questions a operator may ask include: o How to decide the IPv6 address architecture in the network? o What is the recommended prefix length for a large operator? o What is the recommended prefix length for a medium operator? o What is the recommended prefix length to hand out to customers? o What is the recommended longest prefix length an operator should accept from customers? o If privacy is a concern and an operator wants to use ULA in the network, what are the guidelines? 2.2. Connectivity When an operator starts transitioning to IPv6, the engineers must design a network to offer service continuity to customers. Native dual-stack is the natural approach. However, due to IPv4 address exhaustion and cost associated to operate dual-stack network, operators may consider to upgrade part of their network to IPv6-only. They want to know the techniques and guidelines. Some basic questions a operator may ask include: o What techniques should be applied when multiple transition techniques are available? o What is the matrix of the different transition techniques to the network and applications? o How to deploy an IPv4 access network over an IPv6 core network? o How to deploy an IPv6 access network over an IPv4 core network? o Under what considerations, IS-IS should be used? o Under what considerations, OSPFv3 should be used? o What is the longest prefix to be allowed for peering? o How to support traffic engineering and QoS in tunneling technologies? Lee, et al. Expires March 21, 2011 [Page 5] Internet-Draft IPv6 Transition September 2010 2.3. High Availability High Availability (HA) is a major requirement for every service and network service. Operators have accumulated tremendous experience of operating HA in IPv4 using mature protocols such as VRRP and OSPF Graceful Restart. Compared to IPv4, HA for IPv6 is less known. During transitioning, an application running on IPv6 may need to failover to IPv4 network due to network failure. New work may need to be done in this area. In addition, the new transition techniques require new HA models. Operators will normally deploy a transition technique if HA is supported. Some basic questions a operator may ask include: 1. What are the requirements for deploying HA in IPv6? 2. What are the available techniques available for IPv6? 3. How to failover an application from IPv6 to IPv4 (or vice versa)? 4. What is the HA architecture for the new transition techniques such as NAT444, NAT64, DS-lite, etc. 2.4. DNS Despite the similarity of DNS operation in IPv4 and IPv6, there are some substantial differences. Most widely discussed is the usage of Reverse DNS in IPv6 [I-D.howard-isp-ip6rdns]. Many applications such as some email server implementations rely on Reverse DNS to operate probably. Operators must find an answer to manage Reverse DNS in IPv6. Some basic questions a operator may ask include: 1. How to support Reverse DNS in IPv6? 2. How to use DDNS to manage customer's IPv6 CPEs? 3. How to avoid unnecessary DNS translation in NAT64 scenario? 3. CPE Problems CPE provisioning is very important for operators. operators must provide a manageable and reliable provisioning mechanism to provision IPv6 service to the customers. In the IPv4 world, most customers are given a public address via DHCP or IPCP. Customer home network is manage by a CPE and uses private address space in the home network. In the IPv6 world, things work differently. Most CPEs are still given an IPv6 address. However, the home network is given an IPv6 prefix and all the hosts behind the CPE can have public IPv6 address. Lee, et al. Expires March 21, 2011 [Page 6] Internet-Draft IPv6 Transition September 2010 This changes the existing CPE provisioning model. Some basic questions a operator may ask include: o What provisioning mechanism should be used. DHCP or Auto- configuration, or mix of two? o What is the recommended length for customer prefix? o How to inject the customer's PD to the access router? o Should the prefix be stable? o How does the home CPE manage the prefix? o What is the basic model for home security? o Some legacy OS don't support PPPoEv6. What other alternatives to provision these devices? o How to support the legacy CPEs while transitioning to IPv6? 4. Application Problems During transitioning, IPv4 and IPv6 applications will coexist in the network. Regardless to what technology or multiple technologies an operator choose to use, the operator must provide service continuity. These are some common questions: o What is the best way to give IPv4 access to the IPv4 applications over an IPv6 access and/or core network? o What is the best way to enable an IPv6-only application to communicate to an IPv4 application? o What are the impacts of NAT444 and NAT64 to applications? o How to support Single Sign-On which relies on IPv4 address in a shared address environment in the operator's network? o When multiple translation techniques are available, how the network communicates to the applications to choose the best technique? Lee, et al. Expires March 21, 2011 [Page 7] Internet-Draft IPv6 Transition September 2010 5. Network Management and Operation Problems In theory, managing an IPv6 network should be similar to managing an IPv4 network. For example: SNMP works over IPv6 without modification. During transition, new technologies and techniques may be introduced to the network. These new technologies and techniques require new operation models. Some basic questions a operator may ask include: o What is the most effective mechanism to log NAT binding in shared address environment? o How to scale these techniques? o What is the IP sharing ratio for IPv4 address to customers? o How does address sharing mechanism impact enterprise customers? o How to enable an IPv6 application to communicate to a legacy IPv4 application? 6. Security Considerations Security is always important and must be addressed. Some basic questions a operator may ask include: o What are the minimal requirements for IPv6 security? o What are the additional security risks with IPv6 compared to IPv4? o What IPv4 risks do not apply to IPv6? o What are the known issues with existing security solutions when applied to IPv6? o What is involved in configuring IPv6 security? 7. Conclusion Many operators either started or will start the transition this year and next year. This memo presents some high-level questions which operators encounter during the early phase of the transition. Some problems are business oriented and may not be answered by the IETF. But this memo explains why operators seek guidelines from the IETF and want to apply them to their use cases and network scenarios. The goal of these guidelines will serve as "howto" to the transition Lee, et al. Expires March 21, 2011 [Page 8] Internet-Draft IPv6 Transition September 2010 process. The guidelines should also consider and discuss time sequence and steps during transitioning. [I-D.ietf-v6ops-incremental-cgn] is a good example to provide transition steps for CGN deployment. The next 18 months are critical for the transition because IPv4 addresses may be exhausted in 18 months. We would like to recommend the IETF to dedicate resources in next few months to: 1. Generate individual use cases that describes the network scenarios. 2. Generate guidelines of each use case/network scenario that explain the procedures to transition to IPv6. With this work effort, operators will have authoritative references to design the transition process most fit to their services, networks and operations. 8. Acknowledgements The editor gathered the information from various individuals and presented it in this memo. All the credits of this memo go to the following contributors: Can-Can Huang, Ed Jankiewicz, Tina Tsou, Cathy Zhou, Sheng Jiang, Brian Carpenter, Remi Despres, and Seiichi Kawamura. 9. IANA Considerations This memo includes no request to IANA. 10. References 10.1. Normative References [I-D.arkko-ipv6-transition-guidelines] Arkko, J. and F. Baker, "Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment", draft-arkko-ipv6-transition-guidelines-06 (work in progress), August 2010. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Lee, et al. Expires March 21, 2011 [Page 9] Internet-Draft IPv6 Transition September 2010 10.2. Informative References [I-D.howard-isp-ip6rdns] Howard, L. and A. Durand, "Reverse DNS in IPv6 for Internet Service Providers", draft-howard-isp-ip6rdns-04 (work in progress), September 2010. [I-D.ietf-v6ops-incremental-cgn] Jiang, S., Guo, D., and B. Carpenter, "An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition", draft-ietf-v6ops-incremental-cgn-01 (work in progress), June 2010. [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [RFC3769] Miyakawa, S. and R. Droms, "Requirements for IPv6 Prefix Delegation", RFC 3769, June 2004. [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005. [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007. [RFC5565] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh Framework", RFC 5565, June 2009. Authors' Addresses Yiu L. Lee (editor) Comcast One Comcast Center Philadelphia, PA 19103 U.S.A. Email: yiu_lee@cable.comcast.com URI: http://www.comcast.com Lee, et al. Expires March 21, 2011 [Page 10] Internet-Draft IPv6 Transition September 2010 Victor Kuarsingh Rogers Communications 8200 Dixie Road Brampton, Ontario L6T 0C1 Canada Email: victor.kuarsingh@rci.rogers.com URI: http://www.rogers.com Guoliang Yang China Telecom 109 Zhong San Da Dao Xi Guangzhou 510630 P.R. China Email: yanggl@gsta.com URI: http://www.gsta.com Gang Chen China Mobile 53A Xibianmennei Avenue Beijing 100053 P.R. China Email: chengang@chinamobile.com URI: http://www.chinamobile.com Lee, et al. Expires March 21, 2011 [Page 11]