Network Working Group Q. Sun Internet-Draft China Telecom Intended status: Informational W. Liu Expires: August 17, 2014 C. Zhou Huawei Technologies G. Leclanche Viagenie February 13, 2014 Problem Statement for Openv6 Scheme draft-sun-openv6-problem-statement-01 Abstract This document assesses the variety and complexity of IPv6 deployments, and proposes a new space of study to simplify the enablement of new IPv6 applications on an existing network. The document evaluates the identified technical gaps as well. 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 August 17, 2014. Copyright Notice Copyright (c) 2014 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 Sun, et al. Expires August 17, 2014 [Page 1] Internet-Draft Openv6 Problem Statement February 2014 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. Problem Extent and Existing Work . . . . . . . . . . . . . . 3 3.1. Variety of IPv6 deployment technologies . . . . . . . . . 3 3.2. Complexity of IPv6 operation . . . . . . . . . . . . . . 5 3.2.1. End-to-End Network Management . . . . . . . . . . . . 5 3.2.2. Open Network Business Capabilities . . . . . . . . . 6 3.3. Existing evaluations of the IPv6 Transition Landscape . . 7 4. Alternative Approach to IPv6 applications enablement . . . . 8 5. Existing protocols and methods for the alternate approach . . 9 6. Missing protocols and methods for the alternate approach . . 9 6.1. Dynamic devices forwarding table configuration . . . . . 9 6.2. Address Management . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7.1. Source Address Validation and Traceback with Openv6 . . . 10 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 9. Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 11.1. Normative References . . . . . . . . . . . . . . . . . . 10 11.2. Informative References . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 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 activation requires costly end-to-end network upgrades and different network scenarios will co-exist during IPv6 transition. In addition, the technologies deployed for the transition are suppose to be obsoleted once the transition is completed. This document proposes a new approach to deploy and operate IPv6 applications on a network, whether related to transition technologies or purely native ones. Such a technology would allow to continue using the same equipments and operational practices for various deployment scenarios. Sun, et al. Expires August 17, 2014 [Page 2] Internet-Draft Openv6 Problem Statement February 2014 2. Terminology 3. Problem Extent and Existing Work 3.1. Variety of IPv6 deployment technologies The IPv6 transition period contains three stages for IP Networks: IPv4-only, dual-stack and IPv6-only. The networks should support both IPv4 services and IPv6 services during 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 the IPv6 transition period, which means the devices implementing the IPv6 transition technology should support the array of technologies, or there has to be as many devices as technologies used in a given network. The following scenarios below will happen during the IPv6 transition period : Scenario 1: An IPv6 host visits IPv6 servers via an IPv4 access network Scenario 2: An IPv4 host visits IPv4 servers via an IPv4 NAT Dual- stack network Scenario 3: An IPv6 host visits IPv6 servers via an IPv6 network Scenario 4: An IPv4 host visits IPv4 servers via an IPv6 access network Scenario 5: IPv4 host and IPv6 host interaction 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. An operator having a diverse customer base might have to deploy different transition technologies for a given scenario depending on the required user experience. This implies that it is useful to support multiple transition mechanisms in the same area, and preferably on the same transition devices. 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. Sun, et al. Expires August 17, 2014 [Page 3] Internet-Draft Openv6 Problem Statement February 2014 The 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 that can be configured in one device, while some have restrictions regarding the resource occupation (e.g. one transition instance will use a static amount of memory). The major challenges of IPv6 deployment mainly lie in two aspects: 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 ? A random operator will most likely not go through each scenario one by one. For example, some operators may start from scenario 1, and some may start directly from scenario 2 or scenario 4. However, since the target scenario is the IPv6-only access network, a single operator will be confronted to multiple scenarios on 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 difficult to guarantee that all the legacy devices can be upgraded at the same time. This is costly and operationally complicated. We call Transition Data Plane (TDP) the data forwarding plane of the operator network during the whole transition period. Issues that can be identified to improve the situation are: 1. How to manipulate Transition Data Plane with different modes? 2. How to identify the capabilities of different transition devices ? 3. How does the Transition Data Plane identify different modes in the unified platform ? Sun, et al. Expires August 17, 2014 [Page 4] Internet-Draft Openv6 Problem Statement February 2014 3.2. Complexity of IPv6 operation 3.2.1. End-to-End Network Management 3.2.1.1. Scattered Address Pool Management When operators are facing the IPv4 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, the occupation of the address pools may vary during different transition periods: when there is not many IPv6-enabled services and IPv6-enabled devices, IPv4 traffic will still represent a great portion of the total traffic, while in the later stage of IPv6 transition, IPv4 traffic will decrease and the amount of allocated IPv4 addresses may decrease as well, depending on customer requirements. A solution could be 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 any longer. 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. Fixing this problem implies solving those issues: 1. How to configure the address pools for different mechanisms ? 2. How to collect the current status of address pool usage ? 3.2.1.2. Source Address Validation and Traceback with Openv6 It has been long known the IPv4/IPv6 transition makes the tracking and validating of source IP address challenging. Whenever an IPvX packet is translated into an IPvY packet, a major change happens to the IP packet, which brings new issues: 1. How to track the origin of the IPvY packet which is actually in the IPvX world? 2. How to validate the IPvX packet at the edge of the IPvY world to prevent possible spoofing? 3. How to protect the IPvY address from being spoofed in the IPvY world? Sun, et al. Expires August 17, 2014 [Page 5] Internet-Draft Openv6 Problem Statement February 2014 SAVI[RFC7039] defines the source address validation solutions for both IPv4 and IPv6, but doesn't cover the scenario where an IPv4/IPv6 transition technology is used in the network. Currently designing a solution for the transition scenario is not an easy task. There are two main challenges: 1. the diversity of IPv4/IPv6 transition mechanisms. There have been a number of transition mechanism. Moreover, new transition mechanisms may be standardized in the future. It would be complex for a SAVI solution to understand each transition mechanism. An unified abstraction of the transition mechanisms (for example, an abstract Openv6 Transition Data Plan (TDP)) and a set of unified open interfaces should be provided by Openv6 to the SAVI solution for the transition scenario. Then the SAVI solution could know the correspondences between the two IP protocols without having to inspect each packet or keep heavy state locally. The SAVI solution can then generate filtering rules and process tracking. 2. the inflexibility of SAVI. Currently SAVI solutions are tightly associated with address assignment mechanisms. It should be noted that each IPv4/IPv6 transition mechanism actually introduce a new mechanism to assign valid IPv4/IPv6 addresses. Based on the current model of SAVI, the SAVI solution for the transition scenario should be able to track the address translation in all the transition mechanism. Such a SAVI solution is heavy and costly for switches. The SAVI solution should introduce flexibility in rule generation similarly as Openv6, which offloading the complexity from network devices to a controller. 3.2.2. Open Network Business Capabilities 3.2.2.1. Dynamic QoS guarantee in IPv6 transition period Traditionally, almost all bandwidth on the Internet is shared, or with a pre-configured QoS class. However, since the QoS requirements by different applications are not always the same, the subscribers should either waste money by paying for a higher bandwidth service, or can not get qualified service when needed. Therefore, currently, operators are tending to provide more dynamic QoS guarantee for subscribers so that they may apply for a higher bandwidth on-demand when they needed, or specific QoS guarantee can be applied for a certain amount of applications. In this case, the QoS adjustment platform is needed to pass the QoS adjustment request from subscribers or application servers dynamically. In IPv6 transition period, the situation will become more complicated. When CGNs are introduced in the network, ip address and port will change during the translation or tunnelling process. For Sun, et al. Expires August 17, 2014 [Page 6] Internet-Draft Openv6 Problem Statement February 2014 some solutions, e.g. NAT444, DS-Lite, etc., the mappings might be different for different sessions. In this case, the QoS adjustment platform should have the ability to pass and acquire QoS requirements for certain mappings in the CGNs. Therefore, more flexibility should be introduced in the network to load the dynamic QoS requests to the forwarding devices, no matter whether it is a tunnelling or translating mapping. 3.2.2.2. Coordinated NAT translation Traditionally, most peer-to-peer applications would deploy relays by their own to achieve NAT traversal. They may use different kinds of ways e.g. TURN, STUN, or use some private protocols for their own purpose. It would not only cost a lot for applications deploy multiple relays, but also introduces a lot of complexity for newly emerging applications. In addition, in IPv6 transition period, there would be more CGNs than before which might make it more difficult for applications to achieve NAT traversal. However, when operators have deployed some kinds of CGNs in their network, it is reasonable for operators to provide NAT traversal service for third-party applications so that the applications do not need to deploy the relays by their own. For example, the third-party application may require the CGN with the transport address, reflect address, etc., and then choose the one to use for the specific NAT situation. It can also be applied when IPv6 client communicates with iPv4 client with similar procedure. In this case, a centralized controller is needed to acquire the requests from third-party applications and form the specific mappings for them. 3.3. Existing evaluations of the IPv6 Transition Landscape This paragraph references work done at the IETF or to describe the complex landscape of 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 analyses 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. Sun, et al. Expires August 17, 2014 [Page 7] Internet-Draft Openv6 Problem Statement February 2014 +--------+---------+------------------------------------------------+ | status | number | documents | +--------+---------+------------------------------------------------+ | RFC | 8 or | [RFC5571], [RFC6333], [RFC6674], [RFC5969], | | | more | [RFC6219], [RFC6535], [RFC6654], [RFC6145], | | | | ... | | WG | 6 or | [I-D.ietf-softwire-4rd], | | draft | more | [I-D.ietf-softwire-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 | | | +--------+---------+------------------------------------------------+ 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. 4. Alternative Approach to IPv6 applications enablement Finally an IP Network is simply an interconnection of various IPv4- and IPv6-aware devices over some transport. From a payload point of view, there is no need to wonder how the packet got to the destination (security aspects are reserved). Removing the complexity of the transport from the IP-aware devices, by simply considering it as a hop-by-hop "encapsulation" would simplify some situations and bring more flexibility for new applications. The alternative approach proposed here is to put the IPv6 forwarding rules into the devices by a dynamic configuration protocol like Netconf, depending on the application requirements. Those forwarding rules could for example require a change of encapsulation (e.g. from IPv6oEthernet to IPv6oIPv4oEthernet), or an IP protocol change (e.g. apply a NAT64 translation). A central management server would be able to coordinate this configuration and push it adequately on the forwarding devices. Sun, et al. Expires August 17, 2014 [Page 8] Internet-Draft Openv6 Problem Statement February 2014 Today, the configuration of these encapsulation or translations is done manually and is not controlled in a coordinated and standard way. The goal of the application-based approach is to allow the operator to have both the flexibility and full control on what technologies have to be used and when to help with its IPv6 transition process. 5. Existing protocols and methods for the alternate approach The proposed approach would have impact on layer 3, and maybe 4. Hence there is no need to change anything to Layer 1-2 protocols and techniques. Higher layer applications are not impacted either as the network forwarding is transparent to them. The proposed approach requires a dynamic configuration protocol for network devices, to update the forwarding table accordingly. Protocols like Netconf (add ref) or Openflow (add ref) are already existing to achieve this goal. Thanks to their openness, they can easily be extended to support it. 6. Missing protocols and methods for the alternate approach The authors have identified some missing pieces to be able to use the technology in a fully standard way. 6.1. Dynamic devices forwarding table configuration The IETF standard for devices configuration is [RFC6241], the NETCONF Protocol. So it may be suitable for the forwarding table configuration of the openv6 devices and the address management in [section 6.2], with some modifications of the code. However, Netconf is not able to support the packet report from the device to the controller/applications, which may need extensions of the protocol. 6.2. Address Management Having a centralized way to manage addresses requires an efficient protocol to request and allocate them. Among the possible solutions, Netconf or Radius could be extended. 7. Security Considerations Sun, et al. Expires August 17, 2014 [Page 9] Internet-Draft Openv6 Problem Statement February 2014 7.1. Source Address Validation and Traceback with Openv6 A easy-to-use solution for Source Address Validation would increase the safety of networks. If operators have an efficient and low cost unified solution for this problem for both IPv4 and IPv6 and the transition itself, they would be more incline to implement it and therefore the security of networks as a whole would improve. 8. IANA Considerations This document has no actions for IANA. 9. Authors Credits and Thanks 10. Acknowledgements Reference previous work. 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 11.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-06 (work in progress), February 2014. [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-05 (work in progress), February 2014. Sun, et al. Expires August 17, 2014 [Page 10] Internet-Draft Openv6 Problem Statement February 2014 [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-10 (work in progress), January 2014. [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 August 17, 2014 [Page 11] Internet-Draft Openv6 Problem Statement February 2014 [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. [RFC7039] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, "Source Address Validation Improvement (SAVI) Framework", RFC 7039, October 2013. [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 August 17, 2014 [Page 12] Internet-Draft Openv6 Problem Statement February 2014 Guillaume Leclanche Viagenie 246 Aberdeen Quebec, QC G1R 2E1 Canada Phone: +1 418 656 9254 Email: guillaume.leclanche@viagenie.ca Sun, et al. Expires August 17, 2014 [Page 13]