Network Working Group C. Xie Internet-Draft Q. Sun Intended status: Informational China Telecom Expires: January 2, 2015 JF. Tremblay Viagenie July 1, 2014 Use case of IPv6 transition in APONF draft-sun-aponf-openv6-use-cases-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 software defined unifying approach would provide a unified way to deploy IPv6 in a cost-effective, flexible manner. This document describes use cases of IPv6 transition (Openv6) and also requirements in APONF architecture. 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 January 2, 2015. Xie, et al. Expires January 2, 2015 [Page 1] Internet-Draft Use case of IPv6 transition in aponf July 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 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. IPv6 transition 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 . . . . . . . . . . . . 4 3.4. Virtualized Computing Resource Management . . . . . . . . 5 3.5. Transition Function Openness to Third-party Applications 5 3.6. ISP Customers Opt-out for Transition Mechanisms . . . . . 6 3.6.1. Failure Modes for Transition Mechanisms . . . . . . . 6 3.6.2. Failure Modes for Native Deployments . . . . . . . . 6 3.6.3. Application-driven Opt-out Mechanism for ISPs . . . . 7 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 6.1. Normative References . . . . . . . . . . . . . . . . . . 7 6.2. Informative References . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 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. This document describes use cases of IPv6 transition (Openv6) and also requirements in APONF architecture. Xie, et al. Expires January 2, 2015 [Page 2] Internet-Draft Use case of IPv6 transition in aponf July 2014 2. Terminology 3. IPv6 transition 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.[Reference-Mark] 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, 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 requirements are: 1. The Transition Data Plane should be flexible to deal with different scenarios and different mechanisms. Xie, et al. Expires January 2, 2015 [Page 3] Internet-Draft Use case of IPv6 transition in aponf July 2014 2. The Transition Control Plane should be able to notify the Transition Data Plane with its desired scenario. It is also have the ability to collect the current status from the running Transition Devices. 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 issues. Operators will need to offer 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 (even in the same device). 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 requirements in multiple transition co-existence 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. 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 Xie, et al. Expires January 2, 2015 [Page 4] Internet-Draft Use case of IPv6 transition in aponf July 2014 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 major requirements are: The management plane should have the ability to configure the address pools for different mechanisms centralized. The management plane should be able to send the address pool information to the transition devices. 3.4. Virtualized Computing Resource Management Many IPv6 transition mechanisms (e.g. DS-Lite, CGN, etc.) would need to consume a lot of computing resources to maintain a large number of session tables. However, since the number of concurrent subscribers may vary during different periods of time, it will be more flexible to manage the computing resouces centrally. For example, we may add more computing resources when current resouces are not enough and release back to the resource pool if not necessary. The major reuiqrements are : The management plane is able to allocate and withdrawn the computing resource for certain v6transition traffic. The management plane is able to request more resources for certain v6transition traffic. 3.5. Transition Function Openness to Third-party Applications In migration from IPv4 to IPv6, some transition functionalities may be opened to Third-party ICPs. For example, the NAT traversal functionality may be opened to Content Providers as a value-added service. IPv4/IPv6 translation functionality can also be opened to Content Providers in order to support IPv6 client communicating with IPv4 peer. It is also possible that one day, OTT providers may rent Xie, et al. Expires January 2, 2015 [Page 5] Internet-Draft Use case of IPv6 transition in aponf July 2014 CGN functionality from operators to provide IPv6 access for end-host subscribers. Therefore, transition functions are required to have an interface for third-party applications. 3.6. ISP Customers Opt-out for Transition Mechanisms While deploying transition scenarios detailed in section 3.1, such as 6RD, DS-Lite, NAT444 or NAT64, ISPs may not be able to reach 100% end-user coverage for a specific mechanism. Some failure modes exist for diverse end-user equipment, mechanisms and applications, depending if the deployment is done over a very homogenous or diverse user base and device population. Failure modes may also exist for dual - stack deployments or native IPv6 without transition mechanisms. 3.6.1. Failure Modes for Transition Mechanisms Device-based failure may be caused by inexistent or partial implementations in user CPE devices (aka home routers). For example, some off-the-shelf home routers implement 6RD partially, sometimes with or without DHCPv4 option 212 support. In the former case, 6RD failure may result from wrong 6RD parameters entered manually by a user. In the latter case, failure may happen from partial implementations of the 6RD specifications [RFC5969] for example those without support for values of IPv4MaskLen larger than zero or when the IPv6 MTU is not reduced in IPv6 Router Advertisements (RA). For DS-Lite and NAT444, failure modes are usually application-related and are introduced through the presence of the additional IPv4 Network Address Translation (NAT) function in the provider network. These application may not support the interaction of with the ISP NAT device such as Port Control Protocol [RFC6887]. For NAT64 deployments, failure modes are also often application-based or destination-specific and therefore can't be detected at the time of provisioning. Such cases includes the presence of IPv4-only applications on the end-host (a mobile UE for example) without the presence of of a local CLAT/646XLAT implementation [RFC6877]. Other failure modes may be present if the DNS64 function shows difficulties for the synthesis of an IPv4-only server entry. 3.6.2. Failure Modes for Native Deployments Failure modes for native deployments include those for IPv6-only deployments and dual-stack deployments. Reasons for failures are various and include improper implementations of DHCPv6 and DHCPv6-PD Xie, et al. Expires January 2, 2015 [Page 6] Internet-Draft Use case of IPv6 transition in aponf July 2014 in customer-grade home routers, improper or absent handling of IPv6 DNS in Router Advertisement or local DHCPv6, absent or defective DHCPv6 server implementation on the LAN side, etc. For example, early DHCPv6-PD implementations did not support delegated prefixes shorter than a /64 and would show erratic behaviour (such as RAs with prefixes advertisements longer than /64 on the LAN) or failure to operate in IPv6. Such defective implementations exist now in customer-grade equipment that may not be updated by newer software versions during their lifetime, if a newer non-defective firmware exists at all. These defective implementation may lead to invalid IPv6 configurations on hosts, causing delays or application breakage, especially if Happy Eyeballs [RFC6555] type fallback is not implemented. 3.6.3. Application-driven Opt-out Mechanism for ISPs In the cases mentioned above, it may be optimal for the ISP to allow the user or the application to opt-out dynamically from the transition mechanism or request access to the original native version of the access provisioning (such as standard NAT44, native IPv6 or through dual-stack IPv6). Whether the access to such a feature is linked to the ISP billing scheme, such as a specific tier or paid add-on service, is out-of scope for the present document but could be considered by the ISP. For example, customers who host PC or console-based gaming servers and are affected by the deployment of mechanisms such as NAT444 or DS-Lite could choose to get a public address for their server based on a specific time-frame and other application-based requirements such as required latency, QoS and bandwidth. Other examples include real-time chat or video-conferencing applications that could signal their requirements to the network, which would then select an optimal transition mechanism based on them. 4. Security Considerations 5. Acknowledgements N/A. 6. References 6.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Xie, et al. Expires January 2, 2015 [Page 7] Internet-Draft Use case of IPv6 transition in aponf July 2014 6.2. Informative References [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. [RFC6674] Brockners, F., Gundavelli, S., Speicher, S., and D. Ward, "Gateway-Initiated Dual-Stack Lite Deployment", RFC 6674, July 2012. Authors' Addresses Chongfeng Xie China Telecom No.118 Xizhimennei street, Xicheng District Beijing 100035 P.R. China Email: xiechf@ctbri.com.cn Xie, et al. Expires January 2, 2015 [Page 8] Internet-Draft Use case of IPv6 transition in aponf July 2014 Qiong Sun China Telecom No.118 Xizhimennei street, Xicheng District Beijing 100035 P.R. China Email: sunqiong@ctbri.com.cn JF Tremblay Viagenie Email: jean-francois.tremblay@viagenie.ca Xie, et al. Expires January 2, 2015 [Page 9]