Internet Engineering Task Force G. Chen Internet-Draft H. Deng Intended status: Informational China Mobile Expires: November 14, 2011 May 13, 2011 Motivation Analysis for 4via6 Stateless Solutions draft-chen-softwire-4v6-motivation-00 Abstract The growth of Internet obliged to accelerate IPv6 deployment. IPv6- only network likely become prevalent due to low costs and higher efficiency for operators to employ. Meanwhile, a significant part of network will still stay in IPv4 for long time. Regarding IPv4 depletion, address sharing mode should be deployed in small segmented IPv4 networks. Operators expect 4via6 solution with low capital and operational expense by balancing tradeoff between simple core network and edge-distributed management. This memo discusses several motivations, and it recommends the 4via6 stateless solution should be specified for deployment models in the guideline document. 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 November 14, 2011. Copyright Notice Copyright (c) 2011 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 Chen & Deng Expires November 14, 2011 [Page 1] Internet-Draft 4via6-motivation May 2011 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. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Chen & Deng Expires November 14, 2011 [Page 2] Internet-Draft 4via6-motivation May 2011 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Operational Motivations Analysis . . . . . . . . . . . . . . . 5 3.1. NAT Logging Consideration . . . . . . . . . . . . . . . . . 5 3.2. Transition Costs Consideration . . . . . . . . . . . . . . 6 3.3. High Availability(HA) Consideration . . . . . . . . . . . . 7 3.4. Avoiding Centralized Traffic Bottleneck . . . . . . . . . . 7 3.5. Optimizing Encap/Decap and Translation . . . . . . . . . . 8 4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 9 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.1. Normative References . . . . . . . . . . . . . . . . . . . 9 7.2. Informative References . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Chen & Deng Expires November 14, 2011 [Page 3] Internet-Draft 4via6-motivation May 2011 1. Introduction With the fast development of global Internet, the demands for IP address are rapidly increasing currently. This year, IANA announced that the global free pool of IPv4 depleted on 3 February. IPv6 is the only real option on the table. Operators have to accelerate the process of deploying IPv6 networks in order to address IP address strains. IPv6 deployment normally involves a step-wise approach where parts of the network should properly updated gradually. As IPv6 deployment progresses it may be simpler for operators to employ a single-version network, since deploying both IPv4 and IPv6 in parallel would costs more than IPv6-only network. Operators have to maintain double management interfaces and operational support system for dual-stack network. Moreover, some additional efforts should be paid for troubleshooting. [RFC6180] also has described mitigation issues related to this model. Therefore switching to an IPv6-only network will become more prevalent. Meanwhile, a significant part of network will still stay in IPv4 for long time. There may not be enough public or private IPv4 addresses to support end-to-end network communication, without segmenting the network into small parts with sharing one IPv4 address space. Operators have to choose a IPv6 transition technology to bridge these IPv4 islands through IPv6 network. Furthermore, operators have to facilitate the continued growth of the deployment of Internet technology at relatively low capital and operational expense without destabilizing deployed services. Currently, DS-Lite[DS-Lite] could serve for hosts in IPv4 network to communicate servers located in IPv4 Internet via IPv6 network by encapsulating packages in IPv6 tunnel. In order to route inbound traffic to correct tunnel appropriately, AFTR needs to keep states for per-session. In such stateful solution, network should maintain user-session states relying on the dynamic NAT-state management function. Targeting to above objectives, operators may expect more lightweigh transition approach in terms of less expensive, easier scaling, more administrable and flexible. Lightening state-managment burden and reducing complexities in core network, operators desire high scalability and simplicity in core network. Accordingly, operators could balance the tradeoffs by pushing state-management to network edge on which CPE are located to achieve holistic optimization. It also could give operators high flexibilities to rapidly deploy IPv6 in operational network. Operators are always looking for an approach to minimize additional resources provision with accommodating more new customers during IPv6 transition. This memo will specifically state several operational Chen & Deng Expires November 14, 2011 [Page 4] Internet-Draft 4via6-motivation May 2011 considerations. It stands for seeking solution of which is not only stateful but also stateless. The goal here is to help operators make their decision for which solution should be adopted. 2. Terminology In this document, the following terms are used. 4via6: it supports residual IPv4 services, over an infrastructure geared for IPv6-only operations, and doing so in the context of IPv4 address depletion. Border GW (Gateway): it will serve for interconnects two networks that use different address families. The Border GW could be AFTR in DS-Lite [DS-Lite] , CGN or LSN [CGN]. On the carrier side, operators normally deploy several concentrated GWs for scalability reasons. 3. Operational Motivations Analysis 3.1. NAT Logging Consideration Today, Border GW devices are required to log events like creation and deletion of translations and information about the resources it is managing to provide traceability. The logs are required in many cases to identify an attacker or a host that was used to launch malicious attacks and/or for various other purposes of accounting. Some existing 4via6 solutions adopts statefull models. Users are identified by a dynamic address and port "NAT Log". During the operation, logging for every dynamic NAT mapping is created. The logging information on per-session will consume significant parts of physical resources, such as memory and processors resource. It can be observed that NAT logging enabling might degrade Border GW performances according to experimental results. In addition, operators have to made complicated data inspection to dig up desired information from inner tunnel header in case of valid IP package encapsulated by routable outer header. This would require an additional Deep Packet Inspection (DPI) equipment to perform such analysis. In order to make relief for resource consumption and analysis complexities issues, operators would prefer to directly identify IPv4 users by means of derivatization from IPv6 address. In this case, Border GW are not required to enable additional NAT logging or DPI functionalities. It will not only preclude risks of equipment performance degradation, but also simplify NAT logging analysis. Chen & Deng Expires November 14, 2011 [Page 5] Internet-Draft 4via6-motivation May 2011 3.2. Transition Costs Consideration Minimized resources costs for IPv6 transition is desirable for operators. CAPEX(e.g. investments of new added equipments) and OPEX (e.g. provisioning costs of network maintenance) should be reduced as much as possible so as to make forward progress on IPv6 deployment. Investments of Border GW occupy the significant part of 4via6 transition CAPEX. In stateful case, Border GW serving as a NAT concentrator needs to keep mapping states for each session, which will require large memory and processors with high performance in large scale network. A dedicated NAT board should be integrated into Router/FW platform to perform such processing. According to latest statistics, the investment of dedicated NAT board supporting 5,000,000 concurrent sessions is at hundreds of thousands price level and 500,000 concurrent sessions is at tens of thousands price level. It could be observed that the smaller the number of concurrent sessions required, the lower expenditures operators should spend on Border GW. Furthermore, high capacity of NAT broad would require high-end router platform. The capital expenditures become even more expensive. Besides, associated CPEs prices should also be taken account into total capital of 4via6 transition. As compared to that, operators could rely on the use of fully distributed NAT functionality located on CPE. The additional NAT functions doesn't increase CPE prices. Each CPE approximately is at hundred pricelevel. Yet, the Border GW investment will largely be decreased by eliminating dedicated NAT board integration, since Border GW doesn't need to keep any session states. OPEX is heavily depending on the provisioning for growing users. In a stateful "Hubs and Spokes model", a carrier must be able to scale the solution to millions of initiators by adding more Border GW (e.g., softwire concentrators). Since each Border GW maintains specific customers's states, new deployed GW likely requires significant manpower to carry out a new round of GW discovery planning and addressing layout. With growth of user number, OPEX would linearly be increased. It is painful for operators. In order to reduce operational costs, operators would require each Border GW decouple with specific users states. As a consequence, each Border GW can process the packets from all customers. Therefore, it could easy to save its maintenance costs. Total CAPEX and OPEX of a transition system determine the costs for IPv6 transition. According to above analysis, operators should take a lightweight approach to minimize stateful costs . Chen & Deng Expires November 14, 2011 [Page 6] Internet-Draft 4via6-motivation May 2011 3.3. High Availability(HA) Consideration HA is one of key features to facilitate the IPv6 transitions and incremental commercial deployment. It will guarantee the reliability of deploying IPv6, especially during the IPv6 transition period. Border GW is deployed within large-scale networks, where a large number of customers are located. These customers within a network which is served by a single Border GW device MAY experience service degradation due to the presence of the single point of failure. Therefore, load-balancing and/or redundancy capabilities of the Border GW devices are strongly desired in order to deliver highly available services to customers. The load-balancing could avoid Border GW falling into the overload situations. In stateful cases, the upstream and downstream traffics for the same user must go through the same gateway. Load-balancing could be achieved only if each Border GW synchronizes up all customers states. Several contribution are proposed to satisfy this demands[NAT-Redundancy][NAT64-Load-Balancing]. However, standardization progress is struggling to proceed. In order to facilitate load balance, it is also very important for network operators to adopt flexible load sharing mechanism, in which upstream and downstream traffics for the same user could go through the different gateway. Any requirements of states synchronization between Border GW should be avoid in such approach. And GW load- balance should be naturally supported when appropriate routing information has been set. Regarding Border GW redundancy, cold standby and host standby are proposed to address stateful GW redundancy issues. The solutions are at the cost of a complex election procedure or manual configuration, also of a considerable cost and a low reliability. Operators should break such tradeoff by eliminating mapping states storing in GW . In such case, the backup GW can be replicated automatically if the primary GW is out of service. The switching process is smooth since any GW doesn't worry about losing mapping information for serving users. 3.4. Avoiding Centralized Traffic Bottleneck Statefull takes "Hubs and Spokes model" where there are major CPEs connecting a relatively small number of Border GW. When a user behind CPE require communications with others behind another CPE, data packages have to go through GW to reach proper users. Border GW is at risk with traffic bottleneck due to increasing serving users. Moreover, it could also bring additional latency during traffic delivery. It would become worse when CPE has long distance with remote Border GW. Chen & Deng Expires November 14, 2011 [Page 7] Internet-Draft 4via6-motivation May 2011 Operators would consider an efficient data path by optimizing routing to avoid such risks. "Mesh model" would be adopted to optimize data path when there are communications required between CPEs. The data packages between different CPEs can be directly delivered bypassing remote GW. It would not only effectively minimize network latency, but also relieve traffic burden on centralized GW. 3.5. Optimizing Encap/Decap and Translation Regarding 4via6 transition architecture, a "tunnel" that is created to cross a segment of IPv6 when communicating from IPv4 to IPv4 [RFC4925]. Both encapsulation/decapsulation and translations methods for connecting IPv4 networks across IPv6-only networks could be applied. For encap/decap mode, double IP header is appended to allow IPv4 package transparently transmit through IPv6 network. As stated above, operator have to employ DPI to inspect desired information from inner package in some cases. This would further increase system complexities and economic costs. In addition to that, additional IP header would bring overhead on link usages, especially in wireless network (spectrum is a very valuable and scarce resource). Operators usually wish to eliminate unnecessary overhead in such environment. Compared to encap/decap mode, translation based solution using single IP header allows IPv4 interact with IPv6 by translating IPv4 header to IPv6 header. However, some elements are missing during translation since different IP header structures are existing between IPv4 and IPv6 package. Operators need to consider optimize data package processing in such "tunnel" architecture for both encap/decap and translation modes. The approach should not only minimize overhead introduced by double IP header, but also avoid infromation missing by IPv4-IPv6 translation. 4. Conclusions Operator should investigate an approach to minimize the costs spending on IPv6 transition because we believe the ultimate goal of the transition must be the long-term viability of the Internet and also the provision of our services. To ensure that, we should take all operations provisioning and network planning into account. The considerations yielded conclusion that 4via6 stateless with IP header compression might reduce IPv6 transition costs and benefit IPv6 network transition. It is recommended that IETF specified the stateless solution guidance for 4via6 transition. Chen & Deng Expires November 14, 2011 [Page 8] Internet-Draft 4via6-motivation May 2011 5. IANA Considerations TBD 6. Security Considerations TBD 7. References 7.1. Normative References [DS-Lite] Durand, A., "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion", draft-ietf-softwire-dual-stack-lite-07.txt (work in progress), March 2011. 7.2. Informative References [CGN] Perreault, S., "Common requirements for IP address sharing schemes", draft-ietf-behave-lsn-requirements-01.txt (work in progress), March 2011. [NAT-Redundancy] Xu, X., "Redundancy Requirements and Framework for Stateful Network Address Translators (NAT)", draft-xu-behave-stateful-nat-standby-06.txt (work in progress), October 2010. [NAT64-Load-Balancing] Zhang, D., "Considerations on NAT64 Load-Balancing", draft-zhang-behave-nat64-load-balancing-01.txt (work in progress), February 2011. [RFC4925] Li, X., Dawkins, S., Ward, D., and A. Durand, "Softwire Problem Statement", RFC 4925, July 2007. [RFC6180] Arkko, J., "Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment", April 2011. Chen & Deng Expires November 14, 2011 [Page 9] Internet-Draft 4via6-motivation May 2011 Authors' Addresses Gang Chen China Mobile 53A,Xibianmennei Ave., Xuanwu District, Beijing 100053 China Email: chengang@chinamobile.com Hui Deng China Mobile 53A,Xibianmennei Ave. Beijing 100053 P.R.China Phone: +86-13910750201 Email: denghui02@gmail.com Chen & Deng Expires November 14, 2011 [Page 10]