Internet Engineering Task Force C. Huang, Ed. Internet-Draft X. Li Intended status: Informational L. Hu Expires: April 23, 2011 China Telecom October 20, 2010 Use Case For IPv6 Transition For a Large-Scale Broadband network draft-huang-v6ops-v4v6tran-bb-usecase-01 Abstract This document describes a use case for the migration from IPv4 to IPv6 for one of the typical broadband networks. The contant is orgnized by various scenarios we can foresee during the migration. 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 23, 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 23, 2011 [Page 1] Internet-Draft Broadband Network Use Case October 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 IP Backbone . . . . . . . . . . . . 6 2.3. Solution 3: IPv6-Only Backbone . . . . . . . . . . . . . . 6 2.4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Regional IP Network migration . . . . . . . . . . . . . . . . 7 3.1. Solution1:Dual-Stack and L2TP . . . . . . . . . . . . . . 9 3.2. Solution2: Dual-Stack over IPv6 - DS-lite . . . . . . . . 11 3.2.1. The Location of AFTR . . . . . . . . . . . . . . . . . 13 3.3. Solution3: Dual-Stack over IPv4 - 6rd . . . . . . . . . . 15 3.3.1. The Location of 6rd Gateway . . . . . . . . . . . . . 16 3.4. Solution4: IPv6 and protocol translation . . . . . . . . . 17 4. Terminal migration . . . . . . . . . . . . . . . . . . . . . . 18 5. ICP migration . . . . . . . . . . . . . . . . . . . . . . . . 19 6. Challenges Faced In Migrating To IPv6 . . . . . . . . . . . . 19 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 9.1. Normative References . . . . . . . . . . . . . . . . . . . 21 9.2. Informative References . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 Huang, et al. Expires April 23, 2011 [Page 2] Internet-Draft Broadband Network Use Case October 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 countries are facing unprecedented pressure in business aspect, with the Global IPv4 address exhaustion. Therefore developing countries' 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 countries 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 23, 2011 [Page 3] Internet-Draft Broadband Network Use Case October 2010 +============================================================+ | +----------------+ +---------------------------+ | | Internet | IPv4 Internet | | IPv6 Internet | | | +----------------+ +---------------------------+ | +============================================================+ +============================================================+ | ISP's Network | | +--------------------------+ +---------------------------+ | | | IP backbone | | MPLS backbone | | | +--------------------------+ +---------------------------+ | +------------------------------------------------------------+ +------------------------------------------------------------+ | Regional Broadband Network | | +--------------------------------------------------------+ | | | Metro Core Router | | | | +-----------------------------+ | | | | +---------------------------+ | | | | | Aggregation Router | | | +--------------------------+ +---------------------------+ | | +----------------------------------+ +-------------------+ | | | BRAS | | Service Router | | | +----------------------------------+ +-------------------+ | +============================================================+ +============================================================+ | Access Netrwork (Layer 2) | | +--------------------------------------------------------+ | | | Aggregation Switch | | | +--------------------------------------------------------+ | | +--------------------------+ +---------------------------+ | | | OLT | | DSLAM | | | +--------------------------+ +---------------------------+ | +============================================================+ +============================================================+ | Customer Premises Network | | +--------------------------+ +---------------------------+ | | | Routing Mode CPE | | Bridging Mode CPE | | | +--------------------------+ +---------------------------+ | | +--------------------------------------------------------+ | | | User End | | | +--------------------------------------------------------+ | +============================================================+ Figure 1: Typical Large-scale Broadband Network Architecture 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 Huang, et al. Expires April 23, 2011 [Page 4] Internet-Draft Broadband Network Use Case October 2010 leased line services for the enterprise customers. 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 23, 2011 [Page 5] Internet-Draft Broadband Network Use Case October 2010 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 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. Technology saying, there is no problem with 6PE. However, the effect of large scale deployment of 6PE(over thousands nodes)should be evaluated in the future. In addition, since the IPv6 packet is encapsulated in IPv4 tunnel, it is not easy for trouble shooting. 2.2. Solution 2: Dual-stack IP Backbone 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. At present, functionally, the new equipments has better support for DS while the left old devices do not. 2.3. Solution 3: IPv6-Only Backbone 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. From technology aspect, the IPv6 is running well in various existing Huang, et al. Expires April 23, 2011 [Page 6] Internet-Draft Broadband Network Use Case October 2010 experimental network. But from the business aspect, according to many large-scale ISP which have no commercial experiences and examples to reference, establishing a pure IPv6 network has the risk impacting existing services. Besides, the IPv6 information resource is extremely limited in recent time. It means IPv4 traffic dominates the backbone traffic and consequently cause waste for the pure IPv6 network. 2.4. Conclusion In conclusion, for the migration of backbone network, the most reliable method is enable IPv6 in all the new-added devices, since "support IPv6" in the manual script is far from well running in current network. 3. Regional IP Network migration The metro network here covers the network from BRAS to metro egress router. Generally speaking, there are 4 mainstream programs. The Overview of the solutions in the Regional Broadband Network is reduced to the following three types: Upgrading the existing BRASs and CRs for existing users, and adding new BRASs for new users; Upgrading the existing BRASs and CRs for all users; Building a completely new Regional Broadband Network for new users; Large-scale | Little | unchange Upgrade | changes | +New Net +--------------------+ | +---------+ | +------+ CR | Dual-Stack | | | DS/IPV4 | | | IPv6 | +--------------------+ | +---------+ | +------+ +----+ +----+ +------+ | +---------+ | +------+ BRAS |IPv6| | DS | | IPv4 | | | IPv4 | | | IPv6 | +----+ +----+ +------+ | +---------+ | +------+ | | | | | | | DS-Lite/ DS 6rd 6rd NAT64/ L2TP+DS /L2TP+DS DS-Lite Figure 2: Overview of Solutions in Regional Broadband Network In each transition solution of regional broadband network, it can connect to one of the following backbone described in section 3.1: Huang, et al. Expires April 23, 2011 [Page 7] Internet-Draft Broadband Network Use Case October 2010 o Connect to the Dual-stack IP backbone; o Connect to the IPv6-only backbone for IPv6 traffic and to the existing IP backbone for IPv4 traffic if it has;; o Connect to the MPLS backbone for IPv6 traffic and to the existing IP backbone for IPv4 traffic if it has. Some less possible transition solutions haven't been listed above: o Upgrade the existing regional broadband network to IPv6-only; It will lead to a huge influence to existing network and services. ; o Create a new regional broadband network with native IPv6 CRs and Dual-Stack BRASs; It has very low possibilities because if we create a new regional broadband network to provide dual-stack service with new dual-stack BRAS, the simplest solution will be let the new CRs to be dual-stack too. If the new CRs are IPv6- only, they need other transition technologies working together which seem to be more complicated. ; o Create a new regional broadband network with Dual-stack CRs and native IPv6 BRASs; It also has very low possibilities and the reason is as same as the above one. In the following sections, the technical solutions based on the scenarios in Figure 2 are discussed. Although there may be many technical options in each scenario, the discussion will focus on one of them. The possible solutions referred to Figure 2 that we will discuss: o Solution 1: Dual-Stack and L2TP ; o Solution 2: Dual-Stack over IPv6 - DS-lite; o Solution 3: Dual-Stack over IPv4 - 6rd o Solution 4: IPv6 and protocol translation In this document, we consider that the CPE is basically purchased by customers themselves. The access method of subscribers in each technical solution will be also discussed in this section. In the PPPoE dial-up cases, most users dial-up from PC, but there is some deployed a Home Gateway (e.g. WLAN AP) by themselves and set up an automatically dial-up from it. Until now, most terminals, including PCs and CPEs, will still be IPv4-only. Even if most PC operating system (OS) declared that they already supported IPv6, there is still Huang, et al. Expires April 23, 2011 [Page 8] Internet-Draft Broadband Network Use Case October 2010 a problem on supporting PPPoE with IPv6. Not only the most widely used OS, Windows(TM) XP, doesn't support PPPoE with IPv6, but also nearly all CPEs in the market does not support PPPoE in IPv6 environment. These problems will be a significant bottleneck of the development of IPv6 broadband. 3.1. Solution1:Dual-Stack and L2TP In this solution, both the CRs and BRASs will be transition to Dual- stack by upgrading or replacing the existing devices. However, there are so many different BRASs with diverse IPv6 capability in a large- scale broadband network. So there is a possibility that some BRASs cannot upgrade to Dual-stack and PPPoE with IPv6. In the Figure 3 below, there are three scenarios in this solution. o Scenario 1: A Dual-stack, IPv4 or IPv6 terminal accessing to a Dual-stack BRAS; o Scenario 2: A Dual-stack or IPv6 terminal accessing to a legacy IPv4-only BRAS o Scenario 3: An IPv4 terminal accessing to a legacy IPv4-only BRAS +----------------------+ CR/AR | Upgrade to DS/new DS | +----------------------+ +----------------------+ +----------------+ BRAS | Upgrade to DS/new DS | |Legacy IPv4-only| +----------------------+ +----------------+ +-----------------------------------------+ CPE | Legacy bridged CPE/upgraded routed CPE | +-----------------------------------------+ +-------------------+ +-------+ +------+ User End | DS/IPv4/IPv6 | |DS/IPv6| | IPv4 | +-------------------+ +-------+ +------+ Scenario1 Scenario2 Scenario3 Figure 3: Dual-stack Transition Solution The Scenario 1 is very simple. But the routing CPE at the edge of customer premises network need to be upgraded to support IPv6 and PPPoE with IPv6. And the PC operation system (OS) also need to support PPPoE with IPv6. The Scenario 3 is as the same as the access method currently. Huang, et al. Expires April 23, 2011 [Page 9] Internet-Draft Broadband Network Use Case October 2010 The Scenario 2 is a little bit complicated. The BRAS which the subscriber is connecting to is not support IPv6 and PPPoE with IPv6. So, one possible solution could be terminating the point-to-point protocol (PPP) [RFC1661] link at a remote Dual-stack BRAS. A tunnel technology like Layer 2 Tunnel Protocol (L2TP) [RFC2661] [RFC2661] can be used in this scenario. Other technologies could be an alternative. But considering the device capabilities and the maturity of the technology, the following discussion will focus on the solution that Dual-stack network with L2TP to provide Dual-stack services. [SeeFigure 4] +----------------------+ CR/AR | Upgrade to DS/new DS | +----------------------+ +----------------------+ +----------------+ BRAS | Upgrade to DS/new DS | |Legacy IPv4-only| +----------------------+ +----------------+ +-----------------------------------------+ CPE | Legacy bridged CPE/upgraded routed CPE | +-----------------------------------------+ +-------------------+ +-------+ +------+ User End | DS/IPv4/IPv6 | |DS/IPv6| | IPv4 | +-------------------+ +-------+ +------+ Scenario1 Scenario2 Scenario3 Figure 4: The L2TP Solution in partly Dual-Stack network Although tunnel technologies can solve this problem, it is considered as a temporary solution. The legacy IPv4-only BRASs will be replaced eventually. For the Dual-stack service, IPv4 address is still need to allocate to terminal. After the IPv4 addresses exhaustion, Dual-stack BRASs could allocate private IPv4 addresses for broadband subscribers, and a NAT44 Large Scale NAT (LSN) [I D.kuarsingh lsn deployment] device will be deployed to provide IPv4 NAT services for subscribers who are using private IPv4 addresses. The operating system (OS) of the new subscriber is recommended to support PPPoE with IPv6 [TR 187]. Third-party dial-up software could be provided if the OS is not support PPPoE with IPv6. The routing mode CPE of new subscriber is required to support PPPoE with IPv6. Otherwise, they are required to turn off the auto-dialup function, and initial the PPPoE dial-up session from the host that supports PPPoE with IPv6. Huang, et al. Expires April 23, 2011 [Page 10] Internet-Draft Broadband Network Use Case October 2010 The legacy subscribers are recommended to upgrade their OSs and CPEs, but not required. They can still access by IPv4-only. Third-party dial-up software could also be provided to support PPPoE with IPv6. Applicable scenarios: This solution could be suitable for the initial stage or the intermediate stage of the IPv6 transition when the IPv4 traffic is still very large in the network. And the broadband network is going to provide Dual-stack services with incremental deployment. It is also suitable when the number of subscribers is increasing very fast, and there is a large amount of CPEs and OSs that do not support PPPoE with IPv6. In conclusion, for dual stack aspect, The newly-added equipments have few problem with the dual stack while the old ones do not. In these new devices, the aggregation routers have much more problems than the core routers. The switches has poor support capacities of IPv6. The BRASs have many problems, like no well-formed access protocols, no specificated address allocation policies, too many uncertain factors which may influence the network operation and maintenance. Moreover, most metro network is formed through continually devices expansion. So, there are mounts of equipments which are too old to be upgraded. Moreover, with IPv6 information resource increasing, how to provide IPv6 internet visiting for the existing IPv4 subscribers should be put into consideration. 3.2. Solution2: Dual-Stack over IPv6 - DS-lite In this solution, the CRs in the regional broadband network are Dual- stack or IPv6-only and the BRASs are IPv6-only. This network is providing a Dual-stack service or an IPv6-only service for subscribers. This section will discuss the dual-stack subscriber accessing this network. [See Figure 5] A Dual-stack, IPv4 or IPv6 terminal accessing to an IPv6-only BRAS. Huang, et al. Expires April 23, 2011 [Page 11] Internet-Draft Broadband Network Use Case October 2010 +----------------------+ +---------------+ CR/AR | Upgrade to DS/new DS | | new IPv6 | +----------------------+ +---------------+ AFTR device somewhere +----------------------------------------+ BRAS | new IPv6 | +----------------------------------------+ +-------------------------+ +------------+ CPE | bridged/upgraded routed | | DS-Lite CPE| +-------------------------+ +------------+ +---------------------+ +------------+ User End | IPv6 | |DS/IPv6/IPv4| +---------------------+ +------------+ Scenario Figure 5: The DS-Lite Solution in IPv6 Infrastructure The Scenario for IPv6 subscriber is very simple. But the routing CPE at the edge of customer premises network need to be upgraded to support IPv6 and PPPoE with IPv6. And the PC operation system (OS) also needs to support PPPoE with IPv6. This scenario will exist when the IPv6 traffic is already dominant in the network. The little IPv4 traffic will be translated by a NAT64 device located at the edge of IPv6 Ocean. The Scenario for Dual-stack subscriber is a little bit complicated. It provides Dual-stack service over an IPv6-only infrastructure. The technologies like DS-Lite [I D.ietf softwire dual stack lite] can be deployed in this scenario. This section will discuss focus on this technology. DS-Lite is a tunnel technology with a point-to-multipoint IPv4-in- IPv6 tunnel between B4 element and AFTR. According to the definition in [I D.ietf softwire dual stack lite], the B4 element is a function implemented on a dual-stack capable node, either a directly connected device or a CPE, which creates a tunnel to an AFTR. Any locally unique IPv4 address could be configured on the IPv4-in- IPv6 tunnel to represent the B4 element. IANA has defined a well- known range, 192.0.0.0/29. DS-Lite technology is designed for an IPv6 infrastructure with a layer 3 (L3) access network. However, [I-D.zhou-softwire-ds-lite-p2p] describes the Point-to-Point access method scenario. For a layer 2 (L2) access network with PPPoE access method, each CPE has a unique PPP link. The link information can be used to identify the CPE and any IPv4 or IPv6 address does not need Huang, et al. Expires April 23, 2011 [Page 12] Internet-Draft Broadband Network Use Case October 2010 to be allocated to the CPE. However, the CPE can allocate an internal IPv4 address to a host. It simply puts the packets to the point-to-point link and forward to the BRAS. When BRAS receives the packet, it maps the point-to-point identifier to the IPv6 Flow Label [RFC3697] and send to the AFTR for NAT. The operating system (OS) of the new subscriber is recommended to support PPPoE with IPv6. Third-party dial-up software could be provided if the OS is not support PPPoE with IPv6. Subscribers need to replace the existing CPEs for DS-Lite services. No matter the L3 or L2 access network DS-Lite is deploying on, the DS-Lite Address Family Translation Router (AFTR) needs to be deployed somewhere in the regional broadband network. In all, currently, DS-lite, which offers IPv4 internet visiting ability to dual stack subscribers through pure IPv6 accessing network, does not be well integrated into devices. At the same time, technically, it can not assign IPv4 DNS to the subscribers in the first version. Moreover, how to assign addresses to users, considering PPPOE accessing methods, should also be thought about carefully. 3.2.1. The Location of AFTR There are mainly three locations can be deployed an AFTR: o Deploying a centralized AFTR connecting to the IPv6 CR; Figure 6 o Deploying a centralized AFTR card at the Dual-stack CR;[Figure 7] o Deploying distributed AFTRs connecting to IPv6 BRASs;[Figure 8] Huang, et al. Expires April 23, 2011 [Page 13] Internet-Draft Broadband Network Use Case October 2010 +--------------------+ +----------------+ | IPv6/DS Backbone | |IPv4/DS Backbone| +-----*--------------+ +--.-------------+ +-----*--------------+ +--.------+ CR/AR | * new IPv6 ######. AFTR | +-----*------------#-+ +---------+ +-----*-----------#--+ BRAS | *new IPv6 # | * IPv6 Traffic +-----*---------#----+ . IPv4 Traffic +-*--------#-----+ # IPv4-in-IPv6 Traffic CPE | DS-Lite CPE | +----------------+ +----------------+ User End | DS/IPv6/IPv4 | +----------------+ Figure 6: Centralized AFTR connecting to the IPv6 CR +--------------------+ +----------------+ | IPv6/DS Backbone | |IPv4/DS Backbone| +-----*--------------+ +-.--------------+ +-----*------------------.-----+ CR/AR |Upgrade to DS/new DS with AFTR| +-----*----------------#-------+ +-----*---------------#--------+ BRAS | * new IPv6 # | +-----*-------------#----------+ +-*------------#-+ CPE | DS-Lite CPE | * IPv6 Traffic +----------------+ . IPv4 Traffic +----------------+ # IPv4-in-IPv6 Traffic User End | DS/IPv6/IPv4 | +----------------+ Figure 7: Centralized AFTR card at the Dual-stack CR Huang, et al. Expires April 23, 2011 [Page 14] Internet-Draft Broadband Network Use Case October 2010 +--------------------+ +----------------+ | IPv6/DS Backbone | |IPv4/DS Backbone| +-----*--------------+ +--.-------------+ +-----*--------------------.---+ CR/AR | Upgrade to DS/new DS . | +-----*-------------------.----+ +-----*-------------+ +--.-----+ BRAS | * new IPv6 #####. AFTR | +-----*-----------#-+ +--------+ +-*----------#--+ CPE | DS-Lite CPE | * IPv6 Traffic +---------------+ . IPv4 Traffic +---------------+ # IPv4-in-IPv6 Traffic User End | DS/IPv6/IPv4 | +---------------+ Figure 8: Distributed AFTRs connecting to IPv6 BRASs 3.3. Solution3: Dual-Stack over IPv4 - 6rd In this solution, the CRs in the regional broadband network are IPv4- only, Dual-stack or IPv6-only and the BRASs are IPv4-only. It provides a Dual-stack service or an IPv6-only service with a completely/partly IPv4 infrastructure for subscribers. The discussion will focus on scenario in Figure 9. " An IPv6 or Dual- stack terminal accessing to an IPv4-only BRAS. +----------------------------------------+ CR/AR | Upgrade to DS/new DS/Legacy IPv4 | +----------------------------------------+ 6rd border router somewhere +----------------------------------------+ BRAS | Legacy IPv4 | +----------------------------------------+ +-------------------------+ +------------+ CPE | bridged/upgraded routed | | 6rd CPE | +-------------------------+ +------------+ +---------------------+ +------------+ User End | Legacy IPv4 | | DS/IPv6 | +---------------------+ +------------+ Figure 9: The 6rd Solution in an IPv4 infrastructure A possible technical solution for this scenario is IPv6 Rapid Huang, et al. Expires April 23, 2011 [Page 15] Internet-Draft Broadband Network Use Case October 2010 Deployment (6rd) [RFC5969]. There are two components in this solution. 6rd CPEs support Ipv4 on their customer premise side and support 6rd on the provider side. 6rd gateway (a.k.a 6rd border router or 6rd relay) is operated at the border between IPv4 infrastructure and the IPv6 Internet. The 6rd mechanism operates statelessly, which ensures simplicity and scalability. The IPv4 address in the IPv4 infrastructure could be a private address, 6rd mechanism can support the private IPv4 address. In all, currently, 6RD, which offer Ipv6 internet visiting ability to dual stack subscribers through pure Ipv4 accessing network, does not be well integrated into devices. At the same time, technically, Moreover, how to assign addresses to users, considering PPPOE accessing methods, should also be thought about carefully. 3.3.1. The Location of 6rd Gateway There are mainly two locations can be deployed a 6rd gateway: o Deploying a centralized 6rd gateway at the edge of IPv4 regional broadband network; o Deploying distributed 6rd gateways connecting to IPv4 BRASs; +------------------+ +----------------+ | IPv6/DS backbone | |IPv4/DS backbone| +-------------*----+ +-----.----------+ +--------------*---+ +-----.----------+ | 6rd gateway* | | .NAT44 | +----------------#-+-+-----.----------+ CR/AR | # IPv4 . | +-----------------#--------.----------+ +------------------#-------.----------+ BRAS | IPv4 . | +------------------#-----.------------+ +-----#----.-+ CPE | 6rd CPE. | . IPv4 traffic +-----*----.-+ # 6rd traffic +-----*----.-+ * IPv6 traffic User End | DS/IPv6 | +------------+ Figure 10: 6rd gateway at the edge of IPv4 network Huang, et al. Expires April 23, 2011 [Page 16] Internet-Draft Broadband Network Use Case October 2010 +------------------+ +----------------+ | IPv6/DS backbone | |IPv4/DS backbone| +-----------*------+ +-----.----------+ +------------*-----+-+-----.----------+ CR/AR | Upgrade to DS/new DS . | +-------------*----+-------.----------+ | 6rd gateway | NAT44 LSN | +---------------#--+-------.----------+ BRAS | # IPv4 . | +-----------------#------.------------+ +-----#----.-+ CPE | 6rd CPE. | . IPv4 traffic +-----*----.-+ # 6rd traffic +-----*----.-+ * IPv6 traffic User End | DS/IPv6 | +------------+ Figure 11: Distributed 6rd gateways connecting to IPv4 BRASs 3.4. Solution4: IPv6 and protocol translation This solution is for the IPv6-only subscribers that are accessing to the new built IPv6-only regional broadband network. Basically, only IPv6 address is allocated to the subscribers. And for the requirement of IPv4 services, it is needed to deploy a NAT64 (stateful/IVI) [I D.ietf behave v6v4 xlate stateful] [I D.xli behave ivi] device to solve the intercommunication problem between IPv6 and IPv4 for the IPv6-only subscribers. +-----------------+ +--------------------+ |IPv6/DS Backbone | | IPv4/DS Backbone | +-----------*-----+ +----------.---------+ +-----------*-----++------++---.----------+ CR/AR | new IPv6 ***** NAT64 .... IPv4/DS | +-----------------++------+|Regional Broad| +-----------------+ |-band Network | BRAS | new IPv6 | +--------------+ +-----------------+ Legacy/Upgraded network +-------------+ User End | IPv6 | * IPv6 Traffic +-------------+ . IPv4 Traffic Scenario 1 Figure 12: The NAT64 Solution in an IPv6 infrastructure - Scenario 1 Huang, et al. Expires April 23, 2011 [Page 17] Internet-Draft Broadband Network Use Case October 2010 +------++----------+ +------+ Backbone| IPv4 ||Dual-stack| | IPv6 | +.-----++.------*--+ +--*---+ +--.-------.--+ * * * IPv6 Traffic | . NAT64 . | * * . IPv4 Traffic +--*-------*--+---*-------*--+ CR/AR | * new IPv6 * | +----------------------------+ +----------------------------+ BRAS | new IPv6 | +----------------------------+ +------------------------+ User End | IPv6 | +------------------------+ Scenario 2 Figure 13: The NAT64 Solution in an IPv6 infrastructure - Scenario 2 The operating system (OS) is required to support PPPoE with IPv6. Third-party dial-up software could be provided if the OS of the new hosts is unable to support PPPoE with IPv6. The routing mode CPE that is purchased by subscribers is also required to support PPPoE with IPv6 as well, or to turn off the auto- dialup function, and initial the PPPoE with IPv6 dial-up session from the host. In conclusion, protocol translation, just like NAT64, IVI,etc, is widely agreed to be used in mobile network. But due to the vast types of application in the internet accessed through fixed network, protocol translation technologies can not deal with all the applications. As far as we know, conclude from the experimental data, only mail and http service protocol can be well translated. 4. Terminal migration From the terminal aspect, there are two types of CPE: Routed CPE and switched CPE. The switched CPE, which can transparently switch the Ipv6 traffic from user PC to the network access device, does not block the Ipv6 PPPOE dial up . But the routed one, which always automatically initiates a PPPOE , cumbers the normal Ipv6 accessing since almost most part of the routed CPE do not support Ipv6 PPPOE dial up. For the ISP, who can provide CPE to the subscribers and manage them, can offer Ipv6 accessing service by upgrading the CPE. But for the ISPs in this Huang, et al. Expires April 23, 2011 [Page 18] Internet-Draft Broadband Network Use Case October 2010 case, who have large mount of users and have to allow the users to purchase the CPE by themselves, it is nearly impossible for them to replace all the CPE for the cost sake. From OS aspect, there are some problem with windows XP operation system, which dominate the over 80% market, to support the Ipv6 PPPOE dial up. 5. 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. This solution requires a protocol translation technology, like 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: o 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]. o 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. o 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. o 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. 6. Challenges Faced In Migrating To IPv6 There is a long list of challenges during the transition from IPv4 to IPv6: Huang, et al. Expires April 23, 2011 [Page 19] Internet-Draft Broadband Network Use Case October 2010 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 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. 7. IANA Considerations This memo includes no request to IANA. 8. 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. Huang, et al. Expires April 23, 2011 [Page 20] Internet-Draft Broadband Network Use Case October 2010 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. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [min_ref] authSurName, authInitials., "Minimal Reference", 2006. 9.2. Informative References [I-D.baker-behave-ivi] Li, X., Bao, C., Baker, F., and K. Yin, "IVI Update to SIIT and NAT-PT", draft-baker-behave-ivi-01 (work in progress), September 2008. [I-D.durand-softwire-dual-stack-lite] Durand, A., Droms, R., Haberman, B., and J. Woodyatt, "Dual-stack lite broadband deployments post IPv4 exhaustion", draft-durand-softwire-dual-stack-lite-01 (work in progress), November 2008. [I-D.ietf-behave-v6v4-xlate-stateful] Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", draft-ietf-behave-v6v4-xlate-stateful-12 (work in progress), July 2010. [I-D.ietf-softwire-gateway-init-ds-lite] Brockners, F., Gundavelli, S., Speicher, S., and D. Ward, "Gateway Initiated Dual-Stack Lite Deployment", draft-ietf-softwire-gateway-init-ds-lite-01 (work in progress), October 2010. [I-D.zhou-softwire-ds-lite-p2p] Zhou, C., ZOU), T., Lee, Y., and G. Yang, "Deployment DS- lite in Point-to-Point Access Network", draft-zhou-softwire-ds-lite-p2p-02 (work in progress), July 2010. Huang, et al. Expires April 23, 2011 [Page 21] Internet-Draft Broadband Network Use Case October 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. [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999. [RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)", RFC 2765, February 2000. [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003. [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. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [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, Guangzhou, Tianhe District 510630 P.R. China Phone: Email: huangcc@gsta.com Huang, et al. Expires April 23, 2011 [Page 22] Internet-Draft Broadband Network Use Case October 2010 XiaoYang Li China Telecom 109, Zhongshan Ave. West, Guangzhou, Tianhe District 510630 P.R. China Phone: Email: hz_lxy@gsta.com LeMing Hu China Telecom 109, Zhongshan Ave. West, Guangzhou, Tianhe District 510630 P.R. China Phone: Email: hulm@gsta.com Huang, et al. Expires April 23, 2011 [Page 23]