Internet Engineering Task Force CC. Huang, Ed. Internet-Draft XY. Li Intended status: Informational LM. Hu Expires: April 1, 2011 China Telecom September 28, 2010 Use Case For IPv6 Transition For a Large-Scale Broadband network draft-huang-v6ops-v4v6tran-bb-usecase-00 Abstract This document describes a use case for the migration from IPv4 to IPv6 for one of the typical broadband networks. 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 1, 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. Huang, et al. Expires April 1, 2011 [Page 1] Internet-Draft Broadband Network Use Case September 2010 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 6 2. 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 IPv6-only Network . . . . . . . . . 6 3. Metro Network Migration . . . . . . . . . . . . . . . . . . . 6 3.1. Solution 1 . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Solution 2 . . . . . . . . . . . . . . . . . . . . . . . . 7 3.3. Solution 3 . . . . . . . . . . . . . . . . . . . . . . . . 7 3.4. Solution 4 . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Access Network Migration . . . . . . . . . . . . . . . . . . . 7 4.1. Solution 1 . . . . . . . . . . . . . . . . . . . . . . . . 7 4.2. Solution 2 . . . . . . . . . . . . . . . . . . . . . . . . 7 4.3. Solution 3 . . . . . . . . . . . . . . . . . . . . . . . . 8 5. User Access Migration . . . . . . . . . . . . . . . . . . . . 8 5.1. Solution 1: Dual Stack subscribers access Dual Stack BRAS . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.2. Solution 2: Dual Stack subscribers access IPv6-only BRAS . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.3. Solution 3: Dual Stack subscribers access IPv4-only BRAS . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.4. Solution 4: IPv6-only subscribers access IPv6-only BRAS . 9 6. Internet Content Provider (ICP) Migration . . . . . . . . . . 10 6.1. Provide NAT64 device at the IDC edge . . . . . . . . . . . 10 7. Challenges Faced In Migrating To IPv6 . . . . . . . . . . . . 10 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 10. Informative References . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Huang, et al. Expires April 1, 2011 [Page 2] Internet-Draft Broadband Network Use Case September 2010 1. Introduction The situations of IPv6 transition for developing countries are different from the developed countries. The developed countries, which is the originate place of Internet, hold the majority part of IPv4 address space. However, according to the considerably high growth speed of the potential subscribers in the developing countries due to the large base number of users and booming economies, e.g. China,Brazil and India, the small IPv4 address space do put these developing countries under great pressure. Generally speaking,developing countries have a large number of subscribers.Some of them with more than dozen millions of broadband subscribers, increase at a rate of 20+ percent of subscribers annually. Developing coutries are facing unprecedented pressure in business aspect, with the Global IPv4 address exhaustion. Therefore developing coutries's network and services will migrate to IPv6 eventually. However, during the transition procedure, developing coutries should 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. Developing coutries broadband networks are so large with various types of service that the transition to IPv6 is doomed to be complicated and difficult. One of the typical network structure is shown in Figure 1. As this figure shows, the network comprises three segments: backbone network which usually includes IP backbone and MPLS backbone, metro network (MAN) which basically includes Core Router(CR),Aggregation Router(AR) and Broadband Remote Access Server(BRAS), and access network covers from BRAS to users' Customer Premises Equipment(CPE). Huang, et al. Expires April 1, 2011 [Page 3] Internet-Draft Broadband Network Use Case September 2010 +-------------------------------------+ +-------------------+ | ISP backbone | | External backbone| | +-----------+ +-------------+ | | +-----------+ | | |IP backbone| |MPLS backbone| | | | IPv6 | | | | | | | | | | Internet | | | +-----------+ +-------------+ | | +-----------+ | +-------------------------------------+ +-------------------+ +------------------------------------------------------------+ | Metro Area Network | |+---------------------------------------------------------+ | || Core Router | | || +-----------------------------+ | || | +---------------------------+ | || | | Aggregation Router | | |+---------------------------+ +---------------------------+ | |+-----------------------------------+ +-------------------+ | || BRAS | | Service Router | | |+-----------------------------------+ +-------------------+ | +------------------------------------------------------------+ +------------------------------------------------------------+ | Access Netrwork | | +--------------------------------------------------------+ | | | Aggregation Switch | | | +--------------------------------------------------------+ | | +--------------------------+ +---------------------------+ | | | OLT | | DSLAM | | | +--------------------------+ +---------------------------+ | | +--------------------------+ +---------------------------+ | | | ONT | | ONU | | | +--------------------------+ +---------------------------+ | +------------------------------------------------------------+ +------------------------------------------------------------+ | Customer Premises Network | | +--------------------------+ +---------------------------+ | | | Routed Mode CPE | | Bridged Mode CPE | | | +--------------------------+ +---------------------------+ | | +--------------------------------------------------------+ | | | User End | | | +--------------------------------------------------------+ | +------------------------------------------------------------+ Figure 1: Architecture of the typical broadband Network The backbone network provides long distance transmission for the broadband traffic, which includes an IP backbone and a MPLS one. The former one provides Internet service for home users and SME (Small and Medium Enterprise) users while the latter one provides VPN and leased line services for the enterprise customers. Huang, et al. Expires April 1, 2011 [Page 4] Internet-Draft Broadband Network Use Case September 2010 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. The access network provides broadband access service for 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 the access network, the IPv6 capability is limited due to some security considerations (IP-Based ACLs or policies). The best part of UE access the network using the PPPOE dial up method. So, hosts can acquire IPv6 address through PPPoE to avoid the problem. With respect to the terminals, the Windows(TM) OS dominates in the market, the Windows Vista and Windows 7 is the minority while the Windows XP is majority. The WindowsXP cannot support IPv6 PPPOE. The situation of terminals in some developing countries, e.g. China is somewhat different from the situation of terminals in Europe. CPE can operates either in routed or in bridged mode. The major part of existing Routed mode CPE cannot support IPv6 PPPOE dial up. The bridged mode CPE allows the users to dial up from PCs. CPE Home Gateways in some cases are purchased by the users themselves, which are unmanageable by the service provider. During the migration to IPv6, the transition strategies and technologies selection becomes one of the most significant issues due to the complexity of the network and the services, the large number of scenarios and the multiple methods of terminals 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. A lot of experiments were conducted on its existing networks, covering the backbone network, metro network, terminals, service platforms, and the provisioning systems. In this document, several possible migration scenarios applicable to the typical network are introduced. Related solutions for these scenarios are also introduced. Huang, et al. Expires April 1, 2011 [Page 5] Internet-Draft Broadband Network Use Case September 2010 1.1. Requirements Language This document is descriptive, and therefore contains no requirements language. 2. Backbone Network Migration As stated in Section 1, there are usually two types of backbones: IP backbone and an MPLS backbone. The migration solutions could be enabling 6PE in MPLS backbone, dual stack capability in IP backbone, and building up a new IPv6-only backbone network. 2.1. Solution 1: 6PE in the MPLS Network MPLS backbone provides VPN service for the large scale enterprise customers. When the whole network deploys MPLS, 6PE [rfc4798] can be used to provide IPv6 transmission. The IPv6 routing information is marked with MPLS labels through IBGP and is distributed into IPv4/ MPLS backbone network. The communication of IPv6 is achieved by the LSP among PEs. Using 6PE and implementing IPv4 and IPv6 protocol stack at the PE device connecting to IPv6 network, the original IPv4/ MPLS network in the backbone network could be adopted to provide access capability for the distributed IPv6 only user. 2.2. Solution 2: Dual Stack in the IP Network The device enables IPv4/IPv6 protocol stack at the same time. IPv4 and IPv6 routing are both in the routers which forward IPv4/IPv6 packet separately based on the IPv4/IPv6 routing tables. 2.3. Solution 3: Creating a IPv6-only Network Newly establish a native IPv6 network according to the scale of current backbone network. The device enables IPv6 protocol stack only. There is IPv6 routing only in the router which does not carry IPv4 traffic. 3. Metro Network Migration The metro network here covers the network from BRAS to metro egress router. Generally speaking, there are 4 mainstream programs. 3.1. Solution 1 The network is updated based on existing network. In this solution, the Core Routers in the original metro network should be upgraded to Huang, et al. Expires April 1, 2011 [Page 6] Internet-Draft Broadband Network Use Case September 2010 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 provide dual stack. 3.2. Solution 2 The network is updated based on existing network as well. The approach is the same as solution 1 for existing equipments. The difference from solution 1 is that newly added BRASs support IPv6 only. 3.3. Solution 3 Creat a dual stack network. The new Core Routers and BRASs are dual stack and provide a dual stack with no changes to the existing network. 3.4. Solution 4 Create an IPv6 network. The new Core Routers and BRASs are IPv6 only with no changes to the existing network. The IPv6 traffic flows over the new built network while the IPv4 traffic traverses the old one. 4. Access Network Migration The access network covers the network from the user terminal to BRAS, usually including DSLAM, aggregation switch and so on. The access network is usually a layer 2 network in this typical network, and can transmit IPv6 traffic transparently. As mentioned above, the access network cannot carry IPv6 traffic directly due to some security considerations, but the user can acquire an IP address by PPPoE dial-up [RFC2516] which avoids the above problem. Generally, there are 3 solutions for access network migration. 4.1. Solution 1 Modify the existing network and add new IPv6 aware access devices without changing the old devices. 4.2. Solution 2 Solution 2 is modifying the existing network and adding new IPv6 aware access devices with upgrade or change to the old devices. Huang, et al. Expires April 1, 2011 [Page 7] Internet-Draft Broadband Network Use Case September 2010 4.3. Solution 3 Create a new access network supporting IPv6. The old network remains the same. For the subscribers who have the requirement of IPv6, it is needed to cut them over to the new access network. 5. User Access Migration The broadband subscribers 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: Dual Stack subscribers access Dual Stack BRAS The subscribers acquire 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 carrier grade NAT (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). 5.2. Solution 2: Dual Stack subscribers access IPv6-only BRAS The subscribers 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 Deploy DS-Lite in the edge of metro network and provide DS-Lite Huang, et al. Expires April 1, 2011 [Page 8] Internet-Draft Broadband Network Use Case September 2010 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. 5.3. Solution 3: Dual Stack subscribers access IPv4-only BRAS The subscribers acquire dual stack addresses from an IPv4-only BRAS in the following scenarios: 1. Scenario 1 and 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. Another method is to deploy 6RD [RFC5969] gateway in the network and supply 6RD home gateway to the subscribers. 2. Scenario 3 and 4 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. 5.4. Solution 4: IPv6-only subscribers access IPv6-only BRAS The subscribers acquire 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. We can deploy a protocol translation gateway in the old metro network. 2. Scenario 4 of metro network migration The user acquires IPv6 address from the IPv6 only BRAS. We can deploy a protocol translation gateway in the new IPv6 only metro network and at the edge of the old metro network Huang, et al. Expires April 1, 2011 [Page 9] Internet-Draft Broadband Network Use Case September 2010 6. 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 ICPs can migrate by themselves, or can be assisted by others. For the transition of ICP itself, some ICPs have modified their proprietary web service. 6.1. Provide NAT64 device at the IDC edge This solution requires a NAT64 [ID_behave-v6v4-xlate-stateful] device deployed at the edge of IDC(Internet Data Center), but not requires to deploy a DNS64. The solution could include the following steps: 1. Configure AAAA records with IPv6 addresses for the ICP's sites on its Authoritative DNS Server. These IPv6 addresses are constituted by combining the ICP's IPv4 public address and an specific prefix according to the Prefix+v4 address style described in SIIT [RFC2765] or in IVI [ID_xli-behave-ivi]. 2. When user initials an http request to the website, the host will query the corresponding IP address from DNS cache server which is usually located in Metro Network. 3. The DNS cache server replies with the ICP's IPv6 address in an AAAA record which is from the ICP's Authoritative DNS Server. In some circumstances, these records could be configured in a centralized DNS server of the IDC. 4. The user will access the IPv4 services using the IPv6 address. The BRAS will route it to the NAT64 device located at the IDC edge, and remove the prefix, then translating the IPv6 client address by installing mappings in the normal NAT manner. 7. Challenges Faced In Migrating To IPv6 There is a long list of challenges during the transition from IPv4 to IPv6: o The remaining stock of IPv4 addresses cannot support the development of existing services. Future service's development is not the only thing which is concerned about, but the transition of existing services to IPv6 is also considered. o Due to the long transition period, it will be highly possible that one thing taken into consideration while the other be neglected when the different parts of end-to-end network are migrated. A Huang, et al. Expires April 1, 2011 [Page 10] Internet-Draft Broadband Network Use Case September 2010 balanced strategy is needed to guide the transition. o Lack of IPv6 Internet resources. ICP seldom deploy IPv6 and almost no Content Provider/Service Provider (CP/SP) considers IPv6 when developing proprietary services due to the large volume of recoding. 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. Some operation systems for mobile terminals officially claimed they don't support IPv6. o No accumulated experience with IPv6 transition. Large scale network and large number of subscribers are the two key problems. IPv6 transition should be seriously considered. 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. Security considerations should be incentive concerned about because of the potential loss, which is caused by the IPv6 security issues, e.g., dual-stack routing security, network expandability, device reliability, network anti-attack, user tracing, government supervision and etc. Huang, et al. Expires April 1, 2011 [Page 11] Internet-Draft Broadband Network Use Case September 2010 10. Informative References [ID_behave-v6v4-xlate-stateful] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers(Work in progress)", July 2010. [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. [ID_xli-behave-ivi] Li, X., Bao, C., Chen, M., Zhang, H., and J. Wu, "The CERNET IVI Translation Design and Deployment for the IPv4/ IPv6 Coexistence and Transition(work in progress)", January 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. [RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)", RFC 2765, February 2000. [RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005. [RFC4798] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur, "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE)", RFC 4798, February 2007. [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification", RFC 5969, August 2010. Authors' Addresses CanCan Huang (editor) China Telecom 109,Zhongshan Ave. west Tiahne District, Guangzhou 510630 P.R. China Phone: Email: huangcc@gsta.com Huang, et al. Expires April 1, 2011 [Page 12] Internet-Draft Broadband Network Use Case September 2010 XiaoYang Li China Telecom 109,Zhongshan Ave. west Tiahne District, Guangzhou 510630 P.R. China Phone: Email: hz_lxy@gsta.com LeMing Hu China Telecom 109,Zhongshan Ave. west Tiahne District, Guangzhou 510630 P.R. China Phone: Email: hulm@gsta.com Huang, et al. Expires April 1, 2011 [Page 13]