Network Working Group Q. Sun Internet-Draft China Telecom Intended status: Informational W. Liu Expires: April 24, 2014 C. Zhou Huawei Technologies October 21, 2013 Problem Statement for Openv6 Scheme draft-sun-openv6-problem-statement-00 Abstract The IPv6 transition has been an ongoing process throughout the world due to the exhaustion of the IPv4 address space. However, this transition leads to costly end-to-end network upgrades and poses new challenges of managing a large number of devices with a variety of transitioning protocols. While IPv6 transition tools exist, there are still new issues exist. Operators may need various types of IPv6 transition technologies depending on performance requirements, deployment scenarios, etc. To address these difficulties, a unifying approach would provide a unified way to deploy IPv6 in a cost-effective, flexible manner. This document describes issues for deploying multiple transition technologies during the whole IPv6 transition period. It also discusses potential technical gaps to achieve this work. 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 April 24, 2014. Copyright Notice Sun, et al. Expires April 24, 2014 [Page 1] Internet-Draft Openv6 Problem Statement October 2013 Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Unified Openv6 Use case . . . . . . . . . . . . . . . . . . . 3 3.1. Evolve from one Scenario to Another . . . . . . . . . . . 3 3.2. Multiple Transition Mechanisms Co-Exist . . . . . . . . . 4 3.3. Scattered Address Pool Management . . . . . . . . . . . . 5 3.4. Extensibility . . . . . . . . . . . . . . . . . . . . . . 5 4. Coexistence of IPv6 Transition Technologies . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 7.2. Informative References . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction The exhaustion of the IPv4 address space has been a practical problem that providers are facing today. Network address migration to IPv6 is ongoing or upcoming throughout the world. However, IPv6 requires costly end-to-end network upgrades and different network scenarios will co-exist during IPv6 transition. Therefore, operators have to upgrade network devices to support different transition tools, or buy new devices for different scenarios. Sun, et al. Expires April 24, 2014 [Page 2] Internet-Draft Openv6 Problem Statement October 2013 It is more efficient to unify the transition technologies thanks to a Transition Data Plane (TDP). The TDP deals with flow-table mapping and is unaware of specific transition technologies. The service- awareness is provided by a Transition Management Server (TMS). The TMS uses IPv6 Transition Service Modules (ITSM) to know the characteristics of each technology. Finally, the TMS provides a Northbound Interface (NBI) that enables the ITSM to manipulate the traffic for different scenarios. This approach unifies the variety of IPv6 transition mechanisms in a cost-effective, flexible manner. This document describes issues arising from deploying multiple transition technologies during the whole IPv6 transition period. It also discusses potential technical gaps for the unified solution. 2. Terminology 3. Unified Openv6 Use case 3.1. Evolve from one Scenario to Another During the IPv6 transition period, the network needs three stages of IPv4-only, dual-stack and IPv6-only. The networks should support both IPv4 services and IPv6 services at each stage.[One-vision-for-IPv6] There are multiple IPv6 transition technologies for different network scenarios (e.g. IPv4 network for IPv4/IPv6 user access, IPv6 network for IPv4/IPv6 user access, IPv4 servers for IPv6 visitors, etc.). Different network scenarios will co-exist during IPv6 transition which means the IPv6 transition device should support multiple IPv6 transition technologies. The following are possible scenarios in the whole IPv6 transition period. 1)Scenario 1: IPv6 host visit IPv6 servers via IPv4 access network 2)Scenario 2: IPv4 host visit IPv4 servers via IPv4 NAT Dual-stack network 3)Scenario 3: IPv6 host visit IPv6 servers via IPv6 network 4)Scenario 4: IPv4 host visit IPv4 servers via IPv6 access network 5)Scenario 5: IPv6 host visit IPv6 servers via IPv4 access network 6)Scenario 6: IPv4 host and IPv6 host interaction It is not necessary that every operator will go through each scenario one by one. For example, some operators may start from scenario 1, Sun, et al. Expires April 24, 2014 [Page 3] Internet-Draft Openv6 Problem Statement October 2013 and some may start directly from scenario 2 or scenario 4. However, since the final stage (target) is the IPv6-only access network, one still need to undergo multiple scenarios from the long term. In such a case, the operator should either upgrade existing devices to support new features, or replace them with new ones. In particular, when the operator's network consists of devices from different vendors, it is hard to guarantee that all the legacy devices can be upgraded at the same time. This is costly and complicated. The issues are: 1. How to manipulate Transition Data Plane(TDP) with different modes? 2. How to identify the capabilities of different transition devices ? 3. How does the Transition Data Plane (TDP) identify different modes in the unified platform ? 3.2. Multiple Transition Mechanisms Co-Exist In transition from one scenario to another, different transition mechanisms may have different impacts on user experience. For example, DS-Lite would have some impact due to address sharing compared to 6rd mechanisms, and NAT64 would have extra impact due to ALG issue. Operators may prepare a fallback mechanism to guarantee the same level of user experience when there are complaints from subscribers. Therefore, it is required to support multiple transition mechanisms in the same area. Another use case is that multiple scenarios may exist in the same stage. For example, if there are both IPv6-only devices and IPv4-only host in the same area with limited public IPv4 address, both NAT64 and NAT44 (or DS-Lite) are required to achieve IPv4 service connectivity. Current implementations normally use a separate instance for each mechanism,, and additional policies need to be applied when running multiple mechanisms in one device. Some have a limitation on the number of policies which can be configured in one device, while some have restrictions regarding the resource occupation (e.g. one transition instance will occupy a static amount of memory). The major challenges of IPv6 deployment mainly lie in two aspects: Sun, et al. Expires April 24, 2014 [Page 4] Internet-Draft Openv6 Problem Statement October 2013 The need to implement different IPv6 transition technologies in the same hardware and the need to support this by upgrading network devices as little as possible. The need to hop over legacy infrastructures which are not IPv6 enabled, costly or impossible to upgrade. The issues are: 1. How to support multiple transition mechanisms in a cost- efficient and flexible way ? 2. How to easily identify the transition type of different subscribers ? 3.3. Scattered Address Pool Management When operators are facing with address shortage problem, the remaining IPv4 address pools are usually quite scattered. It is quite complicated for an operator to manage scattered address pools in many transition devices. The situation will become even worse when multiple transition mechanisms in the same device need to be configured with different address pools. Besides, since the occupation of the address pools may vary during different transition periods, (e.g. when there is not many IPv6-enabled services and IPv6-enabled devices, IPv4 traffic will still occupy a great portion of the total traffic, while in the later stage of IPv6 transition, IPv4 traffic will decrease and the amount of IPv4 address pools will decrease accordingly. The ideal way is to manage the address pools centrally. Different transition mechanisms can require the address pools on-demand. For example, when one transition mechanism is running out of the current address pools,it may request a additional address pool. It can also release the address pools that it is not using anymore. In this way, operators do not need to configure the address pools one by one manually and it also helps using the address pools more efficiently. The issues are: 1. How to configure the address pools for different mechanisms ? 2. How to collect the current status of address pool usage ? 3.4. Extensibility In migration from IPv4 to IPv6, different scenarios usually need different solutions. Although IETF has already invented some Sun, et al. Expires April 24, 2014 [Page 5] Internet-Draft Openv6 Problem Statement October 2013 mechanisms including DS-Lite[RFC6333], XLate[RFC6146], BIH[RFC6535], NAT64[RFC6146], etc., However, the current solutions have solved the following scenarios only in a limited way: *IPv4 client communicates to IPv6 server *IPv4 client communicates to IPv6 peer It is possible that new technologies will be invented in the future. In addition, some mechanism are still evolving from a session-based solution (e.g. DS-Lite) to a more scalable way (e.g. lw4over6, MAP). It might be possible that operators who have already deployed one solution may upgrade to a better one in the future. Besides, IPv6 transition can also be regarded as a virtualized network function which can be offered to a third-party. Therefore, it is required to offer an open and programmable way to easily add new features without modifying existing device hardware. The issues are : 1. How to add a new module to the transition data plane ? 2. How to offer the capability for the possible future technologies? 4. Coexistence of IPv6 Transition Technologies The different network environments (architecture, scale, services deployed, varying IP traffic) cause a variety of IPv6 transition technologies for different operators. This section analyzes the current and future coexistence of IPv6 transition technologies situation as well as the issues behind it. Since IPv6 was proposed, there have been a couple of RFCs and on- going documents in IETF, as listed in the table below. +----------+---------+----------------------------------------------+ | status | number | documents | +----------+---------+----------------------------------------------+ | RFC | 8 or | [RFC5571], [RFC6333], [RFC6674], [RFC5969], | | | more | [RFC6219], [RFC6535], [RFC6654], [RFC6145], | | | | ... | | WG draft | 6 or | [I-D.ietf-softwire-4rd], [I-D.ietf-softwire- | | | more | map], [I-D.ietf-softwire-map-t], [I-D.ietf- | | | | softwire-public-4over6], [I-D.ietf-softwire- | | | | lw4over6], [I-D.ietf-v6ops-464xlat], ... | | Active | several | ... | | draft | | | Sun, et al. Expires April 24, 2014 [Page 6] Internet-Draft Openv6 Problem Statement October 2013 +----------+---------+----------------------------------------------+ Table 1: A Table of IPv6 Transition Technologies @ IETF The situation described above depicts the difficulty of selecting appropriate IPv6 transition technologies for the carriers. Moreover, according to [SD-NAT], there are multiple stages during the whole IPv6 transition period, and a variety of technologies and equipments are used during different IPv6 transition stages. To protect the user experience and the early investment, an operator will not upgrade its network directly to the final stage of IPv6 transition. During different IPv6 transition stages, an operator needs different technologies in different stages. Thus, a method that is able to implement different IPv6 transition technologies in the same hardware is crucial, to avoid repeated investments. 5. Security Considerations 6. Acknowledgements N/A. 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 7.2. Informative References [I-D.ietf-softwire-4rd] Despres, R., Jiang, S., Penno, R., Lee, Y., Chen, G., and M. Chen, "IPv4 Residual Deployment via IPv6 - a Stateless Solution (4rd)", draft-ietf-softwire-4rd-07 (work in progress), October 2013. [I-D.ietf-softwire-lw4over6] Cui, Y., Qiong, Q., Boucadair, M., Tsou, T., Lee, Y., and I. Farrer, "Lightweight 4over6: An Extension to the DS- Lite Architecture", draft-ietf-softwire-lw4over6-01 (work in progress), July 2013. [I-D.ietf-softwire-map-t] Li, X., Bao, C., Dec, W., Troan, O., Matsushima, S., and T. Murakami, "Mapping of Address and Port using Translation (MAP-T)", draft-ietf-softwire-map-t-04 (work in progress), September 2013. Sun, et al. Expires April 24, 2014 [Page 7] Internet-Draft Openv6 Problem Statement October 2013 [I-D.ietf-softwire-map] Troan, O., Dec, W., Li, X., Bao, C., Matsushima, S., Murakami, T., and T. Taylor, "Mapping of Address and Port with Encapsulation (MAP)", draft-ietf-softwire-map-08 (work in progress), August 2013. [I-D.ietf-softwire-public-4over6] Cui, Y., Wu, J., Wu, P., Vautrin, O., and Y. Lee, "Public IPv4 over IPv6 Access Network", draft-ietf-softwire- public-4over6-10 (work in progress), July 2013. [I-D.ietf-v6ops-464xlat] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: Combination of Stateful and Stateless Translation", draft- ietf-v6ops-464xlat-10 (work in progress), February 2013. [One-vision-for-IPv6] Mark Townsley, "One vision for IPv6", . [RFC5571] Storer, B., Pignataro, C., Dos Santos, M., Stevant, B., Toutain, L., and J. Tremblay, "Softwire Hub and Spoke Deployment Framework with Layer Two Tunneling Protocol Version 2 (L2TPv2)", RFC 5571, June 2009. [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification", RFC 5969, August 2010. [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation Algorithm", RFC 6145, April 2011. [RFC6219] Li, X., Bao, C., Chen, M., Zhang, H., and J. Wu, "The China Education and Research Network (CERNET) IVI Translation Design and Deployment for the IPv4/IPv6 Coexistence and Transition", RFC 6219, May 2011. [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- Stack Lite Broadband Deployments Following IPv4 Exhaustion", RFC 6333, August 2011. [RFC6535] Huang, B., Deng, H., and T. Savolainen, "Dual-Stack Hosts Using "Bump-in-the-Host" (BIH)", RFC 6535, February 2012. [RFC6654] Tsou, T., Zhou, C., Taylor, T., and Q. Chen, "Gateway- Initiated IPv6 Rapid Deployment on IPv4 Infrastructures (GI 6rd)", RFC 6654, July 2012. Sun, et al. Expires April 24, 2014 [Page 8] Internet-Draft Openv6 Problem Statement October 2013 [RFC6674] Brockners, F., Gundavelli, S., Speicher, S., and D. Ward, "Gateway-Initiated Dual-Stack Lite Deployment", RFC 6674, July 2012. [RFC6674] Brockners, F., Gundavelli, S., Speicher, S., and D. Ward, "Gateway-Initiated Dual-Stack Lite Deployment", RFC 6674, July 2012. [SD-NAT] Alain Durand, "SD-NAT", , . Authors' Addresses Qiong Sun China Telecom No.118 Xizhimennei street, Xicheng District Beijing 100035 P.R. China Email: sunqiong@ctbri.com.cn Will(Shucheng) Liu Huawei Technologies Bantian, Longgang District Shenzhen 518129 P.R. China Email: liushucheng@huawei.com Cathy Zhou Huawei Technologies Bantian, Longgang District Shenzhen 518129 P.R. China Email: cathy.zhou@huawei.com Sun, et al. Expires April 24, 2014 [Page 9]