Internet Engineering Task Force G. Yang, Ed. Internet-Draft L. Hu Intended status: Informational J. Lin Expires: March 19, 2011 China Telecom September 15, 2010 IPv6 Transition Guide For A Large ISP Providing Broadband Access draft-yang-v4v6tran-ipv6-transition-guide-00 Abstract This document provides a transition guide for a large-scale provider of broadband access migrating its network from IPv4 to IPv6. 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. Yang, et al. Expires March 19, 2011 [Page 1] Internet-Draft Broadband Access Provider Transition September 2010 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 2. Overview of Solutions for IPv6 Migration Mentioned In the China Telecom Use Case Document . . . . . . . . . . . . . . . 5 2.1. Transition For the Backbone Network . . . . . . . . . . . 6 2.1.1. Upgrade to Dual stack on existing IP Backbone . . . . 6 2.1.2. Building New Native IPv6-Only Backbone Network . . . . 6 2.1.3. Enable 6PE On Existing MPLS Backbone . . . . . . . . . 7 2.2. Transition of Metro IP Network . . . . . . . . . . . . . . 8 2.2.1. Solution 1 . . . . . . . . . . . . . . . . . . . . . . 8 2.2.2. Solution 2 . . . . . . . . . . . . . . . . . . . . . . 9 2.2.3. Solution 3 . . . . . . . . . . . . . . . . . . . . . . 10 2.2.4. Solution 4 . . . . . . . . . . . . . . . . . . . . . . 11 2.3. Transition Of Access network . . . . . . . . . . . . . . . 12 2.3.1. Solution 1 . . . . . . . . . . . . . . . . . . . . . . 12 2.3.2. Solution 2 . . . . . . . . . . . . . . . . . . . . . . 12 2.3.3. Solution 3 . . . . . . . . . . . . . . . . . . . . . . 13 2.4. Transition of Subscriber Access Mode . . . . . . . . . . . 13 2.4.1. Solution 1 . . . . . . . . . . . . . . . . . . . . . . 13 2.4.2. Solution 2 . . . . . . . . . . . . . . . . . . . . . . 14 2.4.3. Solution 3 . . . . . . . . . . . . . . . . . . . . . . 15 2.4.4. Solution 4 . . . . . . . . . . . . . . . . . . . . . . 16 3. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 17 4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 17 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 8.1. Normative References . . . . . . . . . . . . . . . . . . . 17 8.2. Informative References . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Yang, et al. Expires March 19, 2011 [Page 2] Internet-Draft Broadband Access Provider Transition 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. After the IPv4 addresses allocated by IANA are exhausted, China Telecom's broadband users will keep increasing at high speed, which will bring unprecedented pressure to the development of China Telecom's broadband service. In order to solve the problem of IPv4 address shortage, the network and service will eventually migrate to IPv6. Until now there are no services and applications which must use IPv6. In addition, most of Chinese broadband users (including China Telecom and other Chinese ISPs) are basically IPv4 only users before the IPv4 address exhaustion. So the time the related industrial chain supporting IPv6 will be later than the time the IPv6 in introduced into the operator's network. In the process of IPv6 migration, China Telecom focuses on the smooth transition of the existing services because the support from the related IPv6 industrial chain is relatively slow. For example, it should be compatible with the existing internet services, maintain the high-speed increasing of the broadband users, guarantee user experience in the transition process, and protect existing network investments. At the same time, China Telecom should consider that the transition technology and strategy should be consistent with the transition direction of future services and network. China Telecom provides broadband access by PPPoE dial-up authentication. BRAS is the termination device of PPPoE, which allocates IP address for the user, provides the access authentication for broadband users, administration of users, IP edge function and etc. Most of the broadband users use PC to make PPPoE dial up authentication. Some broadband users who need to dial up from the Home Gateway, have to purchase the Home Gateway themselves because China Telecom does not provide the Home Gateway. In the network and service transition to IPv6, the technologies and solutions selected have to be compatible with the existing access mode (PPPoE) and broadband service provisioning method (not provide HGW). The existing single transition technology is not suitable for the transition of China Telecom considering the specific feature of China Telecom's network. Only the combination of multiple technologies can guarantee the smooth transition of China Telecom's network. How to select appropriate technology combination to fit the network scenarios in China Telecom is the focus of this document. Yang, et al. Expires March 19, 2011 [Page 3] Internet-Draft Broadband Access Provider Transition 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 network structure of China Telecom is shown in Figure 1. In the metro network of China Telecom, CR, as the exit router of the metro network, is connected to both ChinaNet and CN2 backbone networks. BRAS, as the IP edge device, provide the access authentication for Yang, et al. Expires March 19, 2011 [Page 4] Internet-Draft Broadband Access Provider Transition September 2010 the broadband users. In most metro networks, BRAS is connected to CR directly, while for a small portion of large sale metro networks, BRAS is connected to CR via SR. CR, SR and BRAS need to be sensitive to the IP protocols. Between BRAS and broadband users, it is the layer 2 network which is not sensitive to IP protocols. 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. Overview of Solutions for IPv6 Migration Mentioned In the China Telecom Use Case Document The following factors make the network and service transition to IPv6 complicated in China Telecom: o Large scale broadband subscribers and different capabilities of supporting IPv6 in terminals. o Large number of network devices and different capabilities of supporting IPv6 in these devices. o Various types of the Internet services and different capabilities and timing of supporting IPv6 in these services. o The widespread ratio of broadband subscribers in different metro networks varies, which makes the smooth service and network transition to IPv6 complicated. In the transition to IPv6, existing terminals and access modes should be considered to guarantee the user experience. Only by selecting proper technologies in different networks and in different transition phases, the network and service can be migrated to IPv6 smoothly. This section analyzes related transition technologies and transition roadmap regarding the network scenarios in the use case draft from the following aspects: o Compatible with existing services (terminals, access mode and existing Internet service). o Keep the high speed increasing of broadband subscribers. o Guarantee the user experience in the transition procedure. Yang, et al. Expires March 19, 2011 [Page 5] Internet-Draft Broadband Access Provider Transition September 2010 o Guarantee the existing network investment. 2.1. Transition For the Backbone Network There are three main technologies for the transition of backbone network: dual stack, 6PE and Native IPv6. 2.1.1. Upgrade to Dual stack on existing 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. Pros: Compatible with existing IPv4 service and new IPv6 service. o The existing network device capability is high. To support IPv6, it only needs to enable protocol stack, the cost of upgrade is low. o It is useful for the smooth transition. Cons: Due to the large network traffic and each routing device has various capabilities in IP backbone network, there is big risk to directly upgrade to dual stack. o Impact to existing service: When dual stack is enabled, any problem may have great impact to the existing services due to the large IP network traffic. o Impact to existing network: The requirement of the existing network device capability is high. It is a challenge for the routing table size, routing lookup/forwarding capability and routing convergence capability when the devices are upgraded to dual stack and IPv4/IPv6 share resources. o The engineering of network modification takes much more work than 6PE, not only modifying edge devices, but also the core devices. Application scenarios: Dual stack backbone network is applicable to the phase when IPv6 traffic is relatively large and the dual stack capability of the network device in dual stack backbone network is verified. 2.1.2. Building New Native IPv6-Only Backbone Network The device enables IPv6 protocol stack only. There is only IPv6 routing in the router which does not carry IPv4 traffic. Yang, et al. Expires March 19, 2011 [Page 6] Internet-Draft Broadband Access Provider Transition September 2010 Pros: In line with the future network transition and enables IPv6 protocol stack only: o No impact to existing network and service o Easy to maintain single network Cons: Cost is large and the period of the engineering is long; The network is difficult to maintain since there is no service driven at the initial stage, the money invested and management is little. Application scenario: In the last phase of IPv6 transition, most of the CP/SP services are IPv6. Native IPv6 backbone network can be upgraded from dual stack backbone network, or by creating a new backbone network. 2.1.3. Enable 6PE On Existing MPLS Backbone 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. Pros: Only the PE devices connecting to IPv6 network need to be upgraded to dual stack and make corresponding configuration. The existing IPv4 MPLS network is utilized thoroughly to achieve the IPv6 service carry in the backbone network. The cost and risk of modifying the network is small. o Little impact to the existing network carrying: quick deployment and small modification to the network. There is no need to change core routers, and only PE routers having requirements need to be modified. o Little impact to the existing service: in the initial stage of IPv6 deployment, there is no impact to the existing service o Incremental deployment period is short. Cons: o Change the service orientation of the original networks. MPLS network is normally used to carry VPN traffic and the network is light load. 6PE is enabled to carry public service which changes the network orientation. When the public traffic grows, there may Yang, et al. Expires March 19, 2011 [Page 7] Internet-Draft Broadband Access Provider Transition September 2010 be impact to the existing service. o No way to deploy QoS policy for IPv6 traffic. o Change the networking principle. Application scenarios: applicable in the starting point of supporting IPv6 but the main traffic is IPv4 in the operator's network. The backbone network provides IPv6 carrying capability quickly. That is, 6PE is suitable for the first phase of IPv6 transition. 2.2. Transition of Metro IP Network According to the chart in the introduction section, China Telecom's MAN is comprised of two parts: o IP network: this part of network is composed of 2 sets of CRs and BRAS. Some SR may be included in some large scale MANs. o Layer 2 access network: this part of network is the layer 2 network between BRAS and users' home gateway. This section introduces the transition of the IP network in metro networks. 2.2.1. Solution 1 The network is updated bases on existing network. The network is updated to dual stack, and the BRAS added in future should support dual stack, too. Solution: CR (core router) will be updated to dual stack, and some aggregation routers which may be deployed in large scale MAN will be updated to dual stack, too. The update solution for BRAS is as follows: o The existing BRASs which supports to be updated to dual stack will be updated to dual stack, and the BRAS added in future should support dual stack, too. o Some BRASs which can not be upgraded to support dual-stack can redirect the dual-stack subscribers to dual-stack BRASs, and the PPP links of the dual-stack subscribers will be terminated on the dual-stack BRASs. After the exhaustion of IPv4 addresses, new BRASs distribute IPv4 addresses for broadband subscribers, and NAT44 CGN is deployed to provide IPv4 services for subscribers who use private IPv4 addresses. IPv6 services are provided by this mechanism. In the same time, the problem that the quantity of broadband subscribers keeps increasing Yang, et al. Expires March 19, 2011 [Page 8] Internet-Draft Broadband Access Provider Transition September 2010 quickly while IPv4 addresses is insufficient is solved. Pros: o The change of network is simple. The cost of the network change is low. Both administration and maintenance of network are simple. o IPv6 could be imported quickly. o The technology of NAT44 is relatively mature. o Major and existing services, such as MSN, Skype and OICQ, could support NAT44 traverse better. o The existing access method does not need change, so China Telecom does not need to provide home gateway to users. o In the condition that the time when the around industrial chain could support IPv6 will be later than the time when the IPv6 migration of telecommunication network begins, users' experience could be guaranteed better. o When the flow of IPv4 disappears in the future, the network could be migrated to native IPv6 network successfully. Some existing applications which do not consider NAT44 traverse may have some problems after the deployment of NAT44 CGN. For example, after the deployment of NAT44 CGN, the service of PPTP VPN has malfunction. Parts of P2P users may have worse experience. Applicable scenarios:After Ipv6 is imported and before the flow of Ipv4 disappears. 2.2.2. Solution 2 The network is updated bases on existing network. The network is updated to dual stack, and the BRASs added newly support IPv6 only. CR (core router) will be updated to dual stack, and some aggregation routers which may be deployed in large scale MAN will be updated to dual stack, too. The update solution for BRAS is as followed: o The existing BRASs which support to be updated to dual stack will be updated to dual stack, and the BRAS added in future should support dual stack, too. o Some BRASs which can not be upgraded to support dual-stack can redirect the dual-stack subscribers to dual-stack BRASs, and the Yang, et al. Expires March 19, 2011 [Page 9] Internet-Draft Broadband Access Provider Transition September 2010 PPP links of the dual-stack subscribers will be terminated on the dual-stack BRASs. o the newly added BRAS support IPv6 only. The users who connect to an IPv6 only BRAS will adopt DS-Lite mechanism to get IPv4 access. As time goes, those BRASs which could not be updated to dual stack will quit gradually from the network. Pros: o The technology of NAT44 is relatively mature. o Major and existing services, such as MSN, Skype and OICQ, could support NAT44 traverse better. o The existing access method does not need change, so China Telecom does not need to provide home gateway to users. o In the condition that the time when the around industrial chain could support IPv6 will be later than the time when the IPv6 migration of telecommunication network begins, users' experience could be guaranteed better. o When the flow of IPv4 disappears in the future, the network could be migrated to native IPv6 network successfully. Cons: o Some existing applications which do not consider NAT44 traverse may have some problems after the deployment of NAT44 CGN. For example, after the deployment of NAT44 CGN, the service of PPTP VPN has malfunction. Part of P2P users may have bad experience. o Home gateway is needed to provide to users. o In the condition that both BRAS and the user are IPv6 only, other technology is needed to be imported to solve the transition problems. Applicable scenarios:After Ipv6 is imported and before the traffic of IPv4 disappears. 2.2.3. Solution 3 The solution is to build a new network with dual stacks, and all the equipments, such as CR/BRAS, adopt dual stacks. The existing network does not need change, while the new network is used to provide IPv6 Yang, et al. Expires March 19, 2011 [Page 10] Internet-Draft Broadband Access Provider Transition September 2010 service for users. Pros: To avoid risk and difficulty in the process that existing IPv4 MAN is updated to dual stacks. Cons: o The cost is huge because the investment is duplicated. o Input and output ratio is too lower when the quantity of new users in new network is small. o The IPv6 transition of existing subscribers requires a large amount of switch from the old network to the new network. Applicable scenarios:(1) The existing network is hard to be updated. (2) The carrying capacity of the old IPv4 MAN is insufficient when the quantity of broadband users increases quickly, so the old network should be enlarged, and the traffic in the enlarged part is the same with the traffic of the newly creating dual stacks MAN. 2.2.4. Solution 4 Building a new IPv6 only network. All the devices, such as CR/BRAS, will use IPv6-only. The existing network does not need to change, while the new network is used to provide IPv6 service for users. Some devices, such as NAT64 or DS-Lite CGN, will be added in the old MAN, in order to provide IPv4 service for the users connected to new MAN. Pros: To avoid risk and difficulty in the process that existing IPv4 MAN is updated to dual stacks. Cons: o The cost is huge because the investment is duplicated. o Input and output ratio is too lower when the quantity of new users in new network is small. o The users are IPv6 only, so other technologies are needed to solve the smooth transition problems. Applicable scenarios: IPv6 traffic is large enough. Yang, et al. Expires March 19, 2011 [Page 11] Internet-Draft Broadband Access Provider Transition September 2010 2.3. Transition Of Access network The layer 2 network of China Telecom's metro network is between the BRAS and the CPE. The layer 2 network is IP layer protocol unaware when PPPoE is used for broadband access. But given that new services (e.g. IPTV or others) may use IPoE for network access, the layer 2 network may also need to support IPv6 aware during the IPv6 transition. 2.3.1. Solution 1 Transform based on the existing network. New devices will be IPv6 aware. Existing devices will keep unchanged. But as time goes by, existing devices will be gradually removed from the network. Thereby the whole layer 2 network will be IPv6 aware. Pros:(1) The network transformation will be simple and cost-effective (required only new devices to be IPv6 aware), and the network maintenance and management will be simple; (2) In the short term, since the access manner of existing services will not be changed largely, the layer 2 network won't be required to be transformed. Since new devices will be IPv6 aware and existing devices which are IPv6 unaware will be removed from the network as time goes by, a smooth evolution without investment increase will be reached. Cons: This solution can not meet short-term requirements (e.g. IPoE) that require the layer 2 network to be IPv6 aware. Applicable scenarios: After IPv6 begins to be introduced. 2.3.2. Solution 2 Transform based on the existing network. New devices will be IPv6 aware and existing devices will be upgraded or replaced, thereby the whole layer 2 networks will be IPv6 aware. Pros:This solution can meet both the current and the future requirements. The network will not need to be transformed again to support new services that require the layer 2 networks to be IPv6 aware. Cons: The network transformation is difficult and the cost of the transformation is expensive. Applicable scenarios: When new services or new service providing manners that require the layer 2 network to be IPv6 aware are about to emerge. Yang, et al. Expires March 19, 2011 [Page 12] Internet-Draft Broadband Access Provider Transition September 2010 2.3.3. Solution 3 The existing network keeps unchanged or is upgraded or evolved gradually. A new layer 2 access network which is IPv6 aware will be built. IPv6 aware services will be provided only to the subscribers who connect to the new layer 2 network directly or indirectly. Pros:Avoid the difficulties and risks of the transformation based on the existing network. Cons: (1) Duplicate investment with expensive cost. (2) The input- output ratio will be low when the number of subscribers attached to the network is low. Applicable scenarios: When services and service providing manners keep unchanged in the existing layer 2 network and meanwhile new services or new service providing manners that require the layer 2 network to be IPv6 aware are about to emerge. 2.4. Transition of Subscriber Access Mode The transition of access mode should be compatible with the existing broadband access modes: o China Telecom provides broadband access service through PPPoE dial-in authentication. The user terminal initiates PPPoE dial-in authentication directly in China Telecom. o China Telecom doesn't provide Home Gateway to broadband users (The user will purchase the Home Gateway device if there is requirement). 2.4.1. Solution 1 The user is accessed in dual stack mode, acquiring IPv4/IPv6 addresses from dual stack BRAS. Some users are connected to the BRAS which can not be upgraded to dual stack (IPv4 only BRAS). In this case, a L2TP tunnel from such BRAS to dual stack BRAS is created to terminate the PPP link at the dual stack BRAS. Pros: o There is no need to change the existing access method, and China Telecom does not need to provide the Home Gateway to the users. o NAT is not needed and the user experience can be guaranteed. Yang, et al. Expires March 19, 2011 [Page 13] Internet-Draft Broadband Access Provider Transition September 2010 o After IPv4 address exhaust in the future, most users are still using public IPv4 addresses. For the users who use private IPv4 addresses, NAT44 is relatively mature and mainstream services, e.g., MSN, Skype can support NAT44 well, so the user experience can be guaranteed. o After the IPv4 traffic disappears, the network can migrate to Native IPv6 smoothly. Cons: Some applications not considering NAT44 may have problem when deploying NAT44 CGN. For example, PPTP VPN may have service failure after deploying NAT44 CGN; Some P2P applications may have bad experience. Application scenario: corresponds to the dual stack metro IP network scenario. 2.4.2. Solution 2 The user acquires dual stack IP address from IPv6-only BRAS. The user is accessed to IPv6-only BRAS which allocates IPv6 only for the user (if there is requirement, it can allocate IPv4 address as well). A L2TP tunnel from IPv6-only BRAS to dual stack BRAS is created to allocate dual stack address for the PC. Alternatively, DS-Lite Gateway is set and DS-Lite CE is provided to user to acquire the Internet access capability of dual stack. Pros: o BRAS is IPv6-only. o NAT44 is relatively mature and mainstream services, e.g., MSN, Skype can support NAT44 well, so the user experience can be guaranteed. Cons: o China Telecom needs to provide Home Gateway for the user which costs much. o DS-Lite has not been verified in large scale commercial sites. o All the IPv4 services have to make NAT44. Some applications which have not considered NAT44 may have problems after deploying NAT44 CGN. o In the metro network with large number of subscribers, more DS- Lite CGN devices, more requirements for the performance. The cost Yang, et al. Expires March 19, 2011 [Page 14] Internet-Draft Broadband Access Provider Transition September 2010 is high. o Considering the scenarios introduced in the China Telecom use case draft, CR has to be dual stack and only BRAS is simplified (not dual stack). But the complexity of DS-Lite CGN is higher. Application scenarios: Metro IP network is dual stack or IPv6 only. Some users can be dual stack and some can be DS-Lite. 2.4.3. Solution 3 The user acquires dual stack addresses from IPv4 only BRAS. The user is accessed to IPv4 only BRAS which allocates IPv4 address for the user. 6RD Gateway is deployed in the metro network and 6RD CPE is provided to the user. IPv6 packet is de-capsulated at the 6RD Gateway. NAT44 CGN can be deployed in the network to solve the problem of IPv4 address shortage. Pros: o There is no need to upgrade BRAS. o When deploying NAT44 CGN, the user experience can be guaranteed because NAT44 is relatively mature and mainstream services, e.g., MSN, Skype can support NAT44 well. Cons: o How to be compatible with the existing access modes? As the termination device of PPPoE, BRAS allocates IPv4 and IPv6 addresses for the user. BRAS needs to be upgraded to support 6RD. o Need to provide Home Gateway to the users (or the user is unwilling to use IPv6 access due to the more investment on the Home Gateway). The cost of modification is high. o The network should be modified and upgraded when the network migrates to Native IPv6 in the future which leads to repeating investment of network. o When the IP traffic grows larger, each metro network may need a great number of 6RD Gateways to meet the IPv6 user requirement. o Some applications which have not considered NAT44 may have problems after deploying NAT44 CGN. For example, PPTP VPN may have service failure after deploying NAT44 CGN; Some P2P applications may have bad experience. Yang, et al. Expires March 19, 2011 [Page 15] Internet-Draft Broadband Access Provider Transition September 2010 Application scenarios: IPv6 is just introduced into network and the IPv4 traffic is dominant in the network. 2.4.4. Solution 4 The user acquires IPv6-only address from the IPv6-only BRAS. BRAS is upgraded to IPv6 only and the user terminal is upgraded to support IPv6 only. Only IPv6 address is allocated to the user who visits IPv4 service through NAT64 or IVI. This solution can provide IPv6 service and can solve the problem of IPv4 address shortage due to high speed increasing numbers of broadband users. Pros: o The operator does not need to allocate IPv4 address for the users. o Push the ICP to transit to IPv6. Cons: o All the user terminals have to support IPv6 which is unpractical at the initial stage of IPv6. o The time supporting IPv6 for the related industry chain is later than the time IPv6 is introduced into the operator's network. Therefore, this solution may lead to the failure of some applications and Internet services after IPv6 is only introduced for a while.. o The timing supporting NAT64 for the related industry chain is much later which will also lead to the failure of some applications and Internet services after IPv6 is only introduced for a while. o NAT64 and IVI have not been verified in large scale commercial sites. DNS64 accompanied with NAT64/IVI has not been verified as well. o There is high requirement for the performance of the NAT device because a great amount of traffic has to make NAT translations duo to the major IPv4 traffic in the network after IPv6 is only introduced for a while. Application scenarios: Most ICP and terminals support IPv6. NAT64 is relatively mature and IPv4 traffic is little. In this case, the operators disable IPv4 protocol stack of the dual stack devices, deploying NAT64 device at several sites to meet the requirement of IPv6 users who would like to visit IPv4 services. Yang, et al. Expires March 19, 2011 [Page 16] Internet-Draft Broadband Access Provider Transition September 2010 3. Backwards Compatibility 4. Conclusions 5. Acknowledgements 6. IANA Considerations This memo includes no request to IANA. 7. Security Considerations All drafts are required to have a security considerations section. See RFC 3552 [RFC3552] for a guide. 8. References 8.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. 8.2. Informative References [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999. [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. Yang, et al. Expires March 19, 2011 [Page 17] Internet-Draft Broadband Access Provider Transition September 2010 Authors' Addresses GuoLiang Yang (editor) China Telecom 109 East Zhongshan Road, Tiahne District, Guangzhou 510600 P.R. China Phone: Email: iamyanggl@gmail.com LeMing Hu China Telecom 109 East Zhongshan Road, Tiahne District, Guangzhou 510600 P.R. China Phone: Email: JinYan Lin China Telecom 109 East Zhongshan Road, Tiahne District, Guangzhou 510600 P.R. China Phone: Email: jasonlin.gz@gmail.com Yang, et al. Expires March 19, 2011 [Page 18]