Internet Engineering Task Force H. Tian Internet-Draft CC. Huang, Ed. Intended status: Informational XY. Li Expires: March 19, 2011 China Telecom September 15, 2010 Use Case For IPv6 Transition For a Large-Scale Broadband Service Provider draft-tian-v4v6tran-broadband-sp-usecase-00 Abstract This document describes an use case for migration from IPv4 to IPv6 for China Telecom, a major operator serving both fixed and mobile subscribers. 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 19, 2011. Copyright Notice Copyright (c) 2010 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. Tian, et al. Expires March 19, 2011 [Page 1] Internet-Draft Broadband Service Provider Use Case September 2010 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 6 2. Experiments in Backbone Network Migration . . . . . . . . . . 6 2.1. Solution 1: 6PE in the MPLS Network . . . . . . . . . . . 6 2.2. Solution 2: Dual Stack in the IP Network . . . . . . . . . 6 2.3. Solution 3: Creating a New IPv6-only Network . . . . . . . 6 3. Experiments in Metro Network Migration . . . . . . . . . . . . 6 3.1. Solution 1 . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Solution 2 . . . . . . . . . . . . . . . . . . . . . . . . 7 3.3. Solution 3 . . . . . . . . . . . . . . . . . . . . . . . . 7 3.4. Solution 4 . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Experiments in Access Network Migration . . . . . . . . . . . 7 4.1. Solution 1 . . . . . . . . . . . . . . . . . . . . . . . . 7 4.2. Solution 2 . . . . . . . . . . . . . . . . . . . . . . . . 8 4.3. Solution 3 . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Experiments in UE Access Migration . . . . . . . . . . . . . . 8 5.1. Solution 1: Acquire Dual Stack Address From Dual Stack BRAS . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.2. Solution 2: Acquire Dual Stack Address Via IPv6-Only BRAS . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.3. Solution 3: Acquire Dual Stack Addresses Via IPv4-Only BRAS . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.4. Solution 4: Acquire IPv6 Address From IPv6-Only BRAS . . 10 6. Experiments in Internet Content Provider (ICP) Migration . . . 11 6.1. Provide Protocol Translation at the ICP . . . . . . . . . 11 7. Challenges Faced In Migrating To IPv6 . . . . . . . . . . . . 12 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 10. Informative References . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Tian, et al. Expires March 19, 2011 [Page 2] Internet-Draft Broadband Service Provider Use Case September 2010 1. Introduction China Telecom is one of the largest operators in the world, with more than 60 million broadband subscribers, increasing at a rate of 10 million subscribers annually. China Telecom is facing unprecedented pressure in business aspect, with the Global IPv4 address exhaustion. Therefore CT's network and services will migrate to IPv6 eventually. However, during the transition procedure, China Telecom seriously concerned about the transition of existing services in order to support the v4v6 coexistent environment, along with the researches and developments of new services and applications. CT's network is so large with various types of service that the transition to IPv6 is doomed to be complicated and difficult. The network structure of China Telecom is shown in Figure 1. As this figure shows, the network in China Telecom comprises three segments: backbone network, metro network(MAN) which includs Core Router(CR), Aggregation Router(AR) and Broadband Remote Access Server(BRAS), and access network that from BRAS to users' Customer Premises Equipment(CPE). Tian, et al. Expires March 19, 2011 [Page 3] Internet-Draft Broadband Service Provider Use Case September 2010 +-------------------------------------+ +-------------------+ | CT's backbone | | External backbone| | +-----------+ +-------------+ | | +-----------+ | | |IP backbone| |MPLS backbone| | | | IPv6 | | | |(Chinanet) | | (CN2) | | | | Internet | | | +-----------+ +-------------+ | | +-----------+ | +-------------------------------------+ +-------------------+ +------------------------------------------------------------+ | CT's Metro Area Network | |+---------------------------------------------------------+ | || Core Router | | || +-----------------------------+ | || | +---------------------------+ | || | | Aggregation Router | | |+---------------------------+ +---------------------------+ | |+-----------------------------------+ +-------------------+ | || BRAS | | Service Router | | |+-----------------------------------+ +-------------------+ | +------------------------------------------------------------+ +------------------------------------------------------------+ | CT's Access Netrwork | | +--------------------------------------------------------+ | | | Aggregation Switch | | | +--------------------------------------------------------+ | | +--------------------------+ +---------------------------+ | | | OLT | | DSLAM | | | +--------------------------+ +---------------------------+ | | +--------------------------+ +---------------------------+ | | | ONT | | ONU | | | +--------------------------+ +---------------------------+ | +------------------------------------------------------------+ +------------------------------------------------------------+ | Customer Premises Network | | +--------------------------+ +---------------------------+ | | | Routed Mode CPE | | Bridged Mode CPE | | | +--------------------------+ +---------------------------+ | | +--------------------------------------------------------+ | | | User End | | | +--------------------------------------------------------+ | +------------------------------------------------------------+ Figure 1: Structure of the China Telecom Network The backbone network provides long distance transmission for the broadbandtraffic, which includes an IP backbone (ChinaNet) and a MPLS one (CN2). The former one provides Internet service for home users and SME (Small and Medium Enterprise) users (named as public users in CT) while the latter one provides VPN and leased line services for Tian, et al. Expires March 19, 2011 [Page 4] Internet-Draft Broadband Service Provider Use Case September 2010 the enterprise customers. Considering the IPv6 capability, MPLS backbone supports 6PE already, and the network devices in IP backbone supports IPv6 basic protocol though 90 percent of the software needs to be updated. The metro network is mainly composed of Core Routers, Aggregation Routers, and BRASs. CR, as the egress router of the metro network, is connected to both IP backbone and MPLS backbone. Most BRASs are connected directly to Core Routers, but a small portion of the BRASs in some large metro networks are connected to Core Routers via Aggregation Routers. China Telecom operates over 300 metro networks. The access network provides broadband access service for the users. It mainly includes layer 2 devices (e.g., DSLAM, Aggregation Switch). Broadband access service is provided over ADSL, LAN, PON and so on. In China Telecom's access network, the IPv6 capability is limitated due to some security considerations (IP-Based ACLs or policies). However, hosts can acquire IPv6 address through PPPoE to avoid the problem. With respect to the terminals, the Windows(TM) OS dominates in the China market, 92% of which is Windows XP. The PPPoE dial terminal can not support IPv6, and the CPE Home Gateway is purchased by the users themselves. The CPE can operate either in routing or in bridged mode, which is unmanageable by China Telecom. Although most CPE is in bridging mode designed for PPPoE dial-up from hosts, many users deployed a Wireless AP at home which can dial-up automatically. All these APs cannot support gathering IPv6 address via PPPoE., . On the other hand, the costs of CPE replacement, with the number of more than 60 million subscribers are unacceptable by China Telecom. During the migration to IPv6, the transition strategies and technologies selection becomes one of the most significantissues for China Telecom due to the complexity of both the network and the services, the large number of scenarios and the multiple methods of terminal and user access. However, there is no universally applicable solution or guideline for the migration of network and services to native IPv6 in the industry yet. Each operator is looking for the appropriate transition strategy for itself. To investigate the impact of various transition technologies on network and services and select correct migration procedures, China Telecom has planned a number of IPv6 experiments, e.g., to support the world university summer games in Shenzhen in 2011, and to test UE access and multimedia IPv6 services for Shanghai EXPO, 2010. China Telecom has also made a lot of experiments on its existing networks, covering the backbone network, metro network, packet area, terminals, service platforms, and the provisioning systems. The most Tian, et al. Expires March 19, 2011 [Page 5] Internet-Draft Broadband Service Provider Use Case September 2010 appropriate and operational end-to-end solutions will be worked out from the results of these experiments to guide the migration of network and services. In this document, several possible migration scenarios applicable to China Telecom are introduced. Related testing solutions and problems are also introduced. Note that all the scenarios have corresponding deployment solutions, but not all the solutions have been tested due to lack of device capability. 1.1. Requirements Language This document is descriptive, and therefore contains no requirements language. 2. Experiments in Backbone Network Migration As stated in Section 1, the backbone network is composed of an IP backbone (ChinaNet) and an MPLS backbone (CN2). The migration solutions considered by China Telecom include 6PE in CN2, dual stack capability in ChinaNet, and building up a new IPv6-only backbone network. 2.1. Solution 1: 6PE in the MPLS Network CN2 provides VPN service for the large scale enterprise customers. When the whole network deploys MPLS, 6PE [rfc4798] can be used to provide IPv6 transmission. 6PE is enabled in four nodes of the backbone network to carry IPv6 traffic. There is no problem for 6PE to carry IPv6 traffic in the experiment. 2.2. Solution 2: Dual Stack in the IP Network This is still in trial, not finished yet. 2.3. Solution 3: Creating a New IPv6-only Network The new IPv6-only network covers seven POP nodes with no problem to support the basic IPv6 protocol. The problem is that there is no enough traffic and no successive maintenance support. 3. Experiments in Metro Network Migration The metro network here means the network from BRAS to metro exit router, including the network from BRAS to core router which is also the egress router to the backbone. Tian, et al. Expires March 19, 2011 [Page 6] Internet-Draft Broadband Service Provider Use Case September 2010 3.1. Solution 1 This solution requires modification of the existing network. In this solution, the Core Routers in the original metro network should be upgraded to dual stack. Old BRASs that can be upgraded to dual stack are also upgraded; BRASs that cannot be upgraded remain as IPv4. Newly added BRASs support dual stack. Dual stack technology itself has no problem. But not all the devices can be upgraded at the same time. 3.2. Solution 2 This also involves modification of the existing network. The approach is the same for existing equipment as for solution 1. The difference from solution 1 is that newly added BRASs support IPv6 only. Testing of this solution is planned for later. 3.3. Solution 3 Creation of a new dual stack network. The new Core Routers and BRASs are dual stack and provide a dual stack overlay with no change to the existing network. Testing of this solution is planned for later. 3.4. Solution 4 Creation of a new IPv6 network. The new Core Routers and BRASs are IPv6 only and provide an IPv6 overlay with no change to the existing network. Testing of this solution is planned for later. 4. Experiments in Access Network Migration The access network includes the network from the user terminal to BRAS, including DSLAM, aggregation switch and so on. The access network is layer 2 in China Telecom, and can transmit IPv6 traffic transparently. As mentioned above, the access network cannot carry IPv6 traffic directly due to some security aspects, but the user can acquire an IP address by PPPoE dial-up [RFC2516] which avoids the above problem. 4.1. Solution 1 Modify the existing network, and add new IPv6 aware access devices without changing the old devices. Not tested yet. Tian, et al. Expires March 19, 2011 [Page 7] Internet-Draft Broadband Service Provider Use Case September 2010 4.2. Solution 2 Modify the existing network and add new IPv6 aware access devices with upgrade or change of the old devices. Not tested yet. 4.3. Solution 3 Create a new access network. Not tested yet. 5. Experiments in UE Access Migration The subscribers of China Telecom acquire IP addresses from the BRAS through PPPoE to visit the Internet. The possible approaches to address acquisition can be categorized as follows. 5.1. Solution 1: Acquire Dual Stack Address From Dual Stack BRAS The user acquires dual stack addresses from the BRAS in the following scenarios: 1. Scenario 1 of metro network migration 2. Old upgradable BRAS in scenario 2 of metro network migration 3. Scenario 3 of metro network migration. When not enough public IPv4 addresses are available, the BRAS allocates a private IPv4 address to the user, thus requiring a NAT44 CGN device in the metro network. The NAT44 CGN can be deployed at two locations based on the routing plan of metro network: centralized (collocated with the Core Router), or distributed (collocated with the BRAS). In the solution verification, some problems with NAT444 became apparent: o Single-Sign-On (SSO) of the website: * The user's IPv4 private address is allocated by the BRAS after the AAA process, so only the user's private IPv4 address is mapped with the user account in the AAA system. In some cases, a website may carry out SSO authentication with the user's IP address via carrier's AAA server. * The user accesses the Internet website with a public address, while the address in the carrier's AAA Server is a private address. So the user cannot be authorized. Tian, et al. Expires March 19, 2011 [Page 8] Internet-Draft Broadband Service Provider Use Case September 2010 o VPN authentication: * In L2TP [RFC3931] and NAT444 environments with the user creating the VPN itself, if the user wants to access the enterprise internal network via VPN, some authentication protocols such as EAP, may not be supported in these two environments. o Flow Analysis System and Behavior Analysis System: * The carrier's existing flow analysis and behavior analysis systems are centralized and deployed in the backbone. In the NAT444 environment, they both need to be placed before the NAT device, in order to collect users' data and analyse their behavior accurately according to their IPv4 addresses. o Internet users initiating access to private network users. Currently two access methods are considered in the metropolitan area network: * Communication between private IP hosts. The traffic will not go through a NAT444 device. * Communication between private IP host and public one. The traffic will go through a NAT444 device. If the user wants to visit a website which is provided by a private address host, it is not accessible. o NAT444 doesn't support the current PPTP VPN. 5.2. Solution 2: Acquire Dual Stack Address Via IPv6-Only BRAS The user has to acquire dual stack addresses from an IPv6-only BRAS in the following scenarios: 1. Scenario 2 of metro network migration In this case, there are two methods to acquire IP addresses. One is to create a L2TP tunnel from the IPv6-only BRAS to a dual stack BRAS which can allocate dual stack addresses for the user. Another way is to deploy a DS-Lite device in the metro network and CPE devices which can support DS-Lite [ID_softwire-dual-stack-lite]. 2. Scenario 4 of metro network migration Tian, et al. Expires March 19, 2011 [Page 9] Internet-Draft Broadband Service Provider Use Case September 2010 Deploy DS-Lite in the edge of metro network and provide DS-Lite supported CPE to the user because the new Core Router and BRAS are both IPv6 only. In these two scenarios, NAT44 CGN device needs to be deployed in the metro network because the IPv4 addresses the user acquires are IPv4 private addresses. DS-Lite is not tested due to lack of DS-Lite- capable devices. 5.3. Solution 3: Acquire Dual Stack Addresses Via IPv4-Only BRAS The user has to acquire dual stack addresses from an IPv4-only BRAS in the following scenarios: 1. Scenario 1 of metro network migration Create a L2TP tunnel from the old BRAS (which could not be upgraded to dual stack) to the dual stack BRAS to acquire dual stack addresses. 2. Scenario 2 of metro network migration Create a L2TP tunnel from the old BRAS (which could not be upgraded to dual stack) to the dual stack BRAS to acquire dual stack addresses, as above. 3. Scenario 3 of metro network migration Deploy 6RD in the old metro network and provide 6RD-supporting CPE to users served by the old BRAS to acquire dual stack address, since the old BRAS maintains IPv4 only. 4. Scenario 4 of metro network migration Same as the previous scenario. 5.4. Solution 4: Acquire IPv6 Address From IPv6-Only BRAS The user acquires an IPv6 address from an IPv6-only BRAS in the following scenarios: 1. Scenario 2 of metro network migration The user acquires an IPv6 address from the IPv6-only BRAS. There are two ways to access the IPv4 Internet and communicate with IPv4 users. One is to deploya protocol translation gateway in the old metro network and another one is to deploy DS-Lite and provide DS-Lite supported CPE to achieve IPv4/IPv6 communication. Tian, et al. Expires March 19, 2011 [Page 10] Internet-Draft Broadband Service Provider Use Case September 2010 2. Scenario 4 of metro network migration The user acquires IPv6 address from the IPv6 only BRAS. There are three ways to access IPv4 Internet and communicate with IPv4 users. One is to deploy a protocol translation gateway in the new IPv6 only metro network and at the edge of the old metro network. Another one is to deploy a protocol translation gateway in the old metro network. A third one is to deploy DS-Lite and provide DS-Lite supported CPE to achieve IPv4/IPv6 communication. 6. Experiments in Internet Content Provider (ICP) Migration Internet Content Provider (ICP) migration to IPv6 is the most important step to break the deadlock in the IPv6 industry chain. The ICP can migrate itself, or can be supported by the operatorthat provides typical Internet applications (e.g., web and email) to it. For the migration of ICP itself, China Telecom has modified its proprietary web mail 189.cn. In addition, the solutions to provide protocol translation to assist ICP's migration include the following: 6.1. Provide Protocol Translation at the ICP The operator can provide protocol translation service for the ICP inside the IDC [Internet Data Center] by deploying a protocol translation device at the IDC exit. We make some improvements to the existing NAT-PT devices since NAT-PT technology has been terminated and there is no mature commercial NAT64 device yet. The AAAA record of the ICP's IPv6 address is stored in the ICP DNS authorization Server to substitute the DNS64 function. This IPv6 address is constituted by combining the ICP's IPv4 public address and the operator's prefix. The procedure is as below: 1. The user queries the corresponding IP address of the ICP domain name from DNS. 2. The DNS cache server replies with the ICP's IPv6 address. (This address is updated regularly by the ICP authorization server.) 3. The user will use this IPv6 address to visit the IPv4 applications. The BRAS will direct it to the IDC protocol translation server which will then drop the prefix to acquire the original IPv4 address of the ICP and forward the packet to the IPv4 server of the ICP. Tian, et al. Expires March 19, 2011 [Page 11] Internet-Draft Broadband Service Provider Use Case September 2010 7. Challenges Faced In Migrating To IPv6 When upgrading from IPv4 to IPv6, China Telecom, like other carriers, faces a long list of challenges: o The remaining stock of IPv4 addresses cannot support the development of existing services. China Telecom not only cares about future service development, but also the transition of existing services to IPv6. o Not enough sites are running IPv6. ICP has deployed little IPv6, and almost no Content Provider/Service Provider (CP/SP) considers IPv6 when developing proprietary services because of the large code change. The applications of ICPs are of various types and so complex that they cannot all support IPv6 in a short time. In addition, many business websites are always linking to each other, creating a complex topology which will lead to many problems when one website migrates to IPv6 only. Another reason ICP migration lacks motivation is that the CP/SP does not realize how urgent it is to migrate to IPv6. o From the perspective of terminals, some specific terminals (e.g., set top boxes) do not support IPv6 even if the main operating systems can do so. Most mobile terminals (CDMA) do not currently support IPv6, although this is a temporary situation. o No accumulated experience with IPv6 transition.Large scale network and large number of subscribers are the two key problems China Telecom has to face in IPv6 transition. With large scale network and various service platforms, the transition involves multiple levels and broad scope, so the cost of modification will be huge and the return on investment will not be so evident. The selection of transition technology and network modification solution is not clear for the transition roadmap of the whole network. 8. IANA Considerations This memo includes no request to IANA. 9. Security Considerations The IETF is specifying security considerations for the tools that it is providing for IPv6 migration. However, it is possible that additional considerations arise due to the interaction of these tools, and the fact that the network is in a transitional state. Tian, et al. Expires March 19, 2011 [Page 12] Internet-Draft Broadband Service Provider Use Case September 2010 China Telecom has a particular incentive to discern and take account of any such considerations, because as a result of its scale, the potential losses due to loss of security can be very large. 10. Informative References [ID_softwire-dual-stack-lite] Durand, A., droms, R., Woodyat, J., and Y. Lee, "Dual- Stack Lite Broadband Deployments Following IPv4 Exhaustion (Work in progress)", August 2010. [RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D., and R. Wheeler, "A Method for Transmitting PPP Over Ethernet (PPPoE)", RFC 2516, February 1999. [RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005. Authors' Addresses Hong Tian China Telecom No.31, Jinrong Ave,Xicheng District,100032 Beijing, 100032 P.R. China Phone: Email: Cancan Huang (editor) China Telecom 109 East Zhongshan Road, Tiahne District, Guangzhou 510600 P.R. China Phone: Email: cancanhuang110@gmail.com Tian, et al. Expires March 19, 2011 [Page 13] Internet-Draft Broadband Service Provider Use Case September 2010 XiaoYang Li China Telecom 109 East Zhongshan Road, Tiahne District, Guangzhou 510600 P.R. China Phone: Email: Tian, et al. Expires March 19, 2011 [Page 14]