Internet Engineering Task Force G. Yang Internet-Draft C. Huang Intended status: Informational Z. Peng Expires: July 14, 2012 China Telecom January 11, 2012 Fundamental Architecture of Services Provider's network Transitioning to IPv6 (FAST6) -- PPPoE Broadband Access draft-yang-v6ops-fast6-pppoe-02 Abstract Although there have already been some transition solutions and technologies, it is still lack of a complete solution for large scale broadband ISPs based on the network architecture considering service providers' requirements and constraints in the real world. This document proposes an IPv6 transitioning architecture, the FAST6, which is based on the common broadband network architecture and providing IPv6 transition solutions going through the whole transition period. 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 July 14, 2012. Copyright Notice Copyright (c) 2012 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 Yang, et al. Expires July 14, 2012 [Page 1] Internet-Draft FAST6-PPPoE January 2012 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Brief Description of ISP's Broadband Network . . . . . . . . . 5 3.1. Broadband Architecture . . . . . . . . . . . . . . . . . . 5 3.2. Network scale and model . . . . . . . . . . . . . . . . . 6 3.3. ISP Requirements For IPv6 Transition . . . . . . . . . . . 7 3.4. Weaknesses of current transition technology . . . . . . . 7 4. The FAST6 Architecture with L2 Access Network . . . . . . . . 7 4.1. Distributed CGN (DCGN) Architecture . . . . . . . . . . . 8 4.1.1. Architecture Description . . . . . . . . . . . . . . . 8 4.1.2. Scenario 1: Subscribers Access IPv4 BRAS . . . . . . . 10 4.1.3. Scenario 2: Subscribers Access Dual-Stack BRAS . . . . 11 4.1.4. Sharing Address between DCGNs . . . . . . . . . . . . 12 4.2. Centralized CGN Architecture . . . . . . . . . . . . . . 12 4.2.1. Architecture Description . . . . . . . . . . . . . . . 12 4.2.2. Scenario 1: Subscribers Access IPv4 BRAS . . . . . . . 14 4.2.3. Scenario 2: Subscribers Access Dual-Stack BRAS . . . . 15 4.2.4. BRAS-to-CCGN Tunnel for private IPv4 traffic . . . . . 15 4.3. Recommendations for PPPoE Access Broadband ISP . . . . . . 16 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 17 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 9.1. Normative References . . . . . . . . . . . . . . . . . . . 18 9.2. Informative References . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Yang, et al. Expires July 14, 2012 [Page 2] Internet-Draft FAST6-PPPoE January 2012 1. Introduction With witness the exhaustion of IANA's IPv4 address pool, more and more Internet Service Providers (ISPs) are considering their transition plans and solutions. However, there is not enough time for a large scale broadband network provider to migrate its entire network infrastructure, support systems and current services to an IPv6-only network. There are some transition solutions and technologies carried out by IETF based on Dual-Stack, Tunnel, and Translation models, including 6RD [RFC5969][RFC5569], DS-Lite [I-D.ietf-softwire-dual-stack-lite], NAT444 [I-D.shirasaki-nat444], Stateful NAT64 [RFC6146] and so on. Yet, it is still lack of a complete solution for large scale broadband ISPs based on widely deployed network architecture in the real world, with considering service providers' requirements and constraints from commercial and technical aspects. If the network were to run out of addresses, there would be no additional host, subscriber or server could be added to the network. ISPs need an IPv6 transition solution that can keep the continuity of the existing IPv4 services and can reduce the impacts to subscribers' experience as well. PPPoE as a broadband connecting method is widely used in large scale broadband ISPs. With this technology, the access network for broadband service is usually a L2 network. This document proposes a transitioning architecture, the FAST6, a fundamental architecture of service provider's broadband network with PPPoE access method that is transitioning to IPv6. The FAST6 is based on the real broadband network architecture and go through the whole transition period including how to solve the current address shortage problem, how to introduce IPv6 service, and how IPv4 eventually quit. 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. Terminologies The following definitions apply for the purposes of this document (some definitions are from [TR-059]): Yang, et al. Expires July 14, 2012 [Page 3] Internet-Draft FAST6-PPPoE January 2012 ISP's Backbone: ISP's Backbone interconnects ISP's metropolitan area networks (MANs), providing a path for long distance transmission between different MANs and connecting to the Internet. Metropolitan Area Network: Metropolitan Area Network, as known as MAN, interconnects one or more BRAS and associated Access Network in a geographical area to the national wide ISP's backbone. Its primary function is to provide end-to-end transport between the customer premises and the ISP's backbone. MAN may also provide higher layer functions such as QoS and content distribution. L2 Access Network: The Layer 2 Access Network is a layer 2 network that encompasses the elements of the DSL network from the Network Interface Device (NID) at the customer premises to the BRAS. Customer Premises Network: Customer Premises Network will contain one or more terminal equipment devices possibly interconnected by customer premises equipment (CPE). CR: Core Router (CR) in a metropolitan area network is the egress router of the MAN and connecting to the ISP's backbone in upstream and connecting to BRASs for downstream. BRAS: Broadband Remote Access Server, as known as BRAS, is the aggregation point for the subscriber traffic. It provides aggregation capabilities between the Access Network and the Metropolitan Area Network. Beyond aggregation, it is also the injection point for access authentication, policy management and QoS. DSLAM: Digital Subscriber Line Access Multiplexer, as known as DSLAM, can be used in a central office to aggregate traffic from multiple remote physical devices, and is considered logically to be a part of the Access Node for Digital Subscriber Lines (DSL) subscribers. CPE: Customer Premises Equipment (CPE) is the edge of Customer Premises Network. In this document, there are two types of CPEs, which are in Routed mode and in Bridged mode. Subscriber: The client that is purchasing the DSL circuit from the Service Provider and is receiving the billing. Yang, et al. Expires July 14, 2012 [Page 4] Internet-Draft FAST6-PPPoE January 2012 3. Brief Description of ISP's Broadband Network The IPv4 address exhaustion and IPv6 transition is an urgent issue for ISPs, especially for large scale broadband ISPs. Some of them are facing high increasing rate of new subscribers that needs a great amount of network addresses. The addresses shortage problem becomes a barrier of providing broadband service. Regardless IPv4 or IPv6, users or customers are only looking for a reliable broadband Internet access. At this point of time, IPv4 address has already been exhausted, and most of Internet contents or resources are still on IPv4. This section will start with a brief description of the broadband architecture with Layer 2 (L2) access network and try to summarize the business and technical requirements and the constraints of broadband service of ISPs. As mention in [I-D.yang-v6ops-fast6-tools-selection], current IPv6 transition technologies or solutions are not satisfying broadband ISPs' requirements completely. 3.1. Broadband Architecture With PPPoE [RFC2516] access technologyGBP[not]the Broadband Network Architecture with L2 access network is shown in Figure 1. In an ISP's Metropolitan Area Network (MAN), Core Routers (CRs) are the egress routers of the MAN, and all traffics to Internet are going through CRs towards to ISP's backbone which is connecting different MANs and the Internet. Broadband Remote Access Server (BRAS) is the PPP [RFC1661] session termination point at ISP edge. There could be hundreds of BRASs connecting to a few CRs in the MAN of a large scale broadband service provider. Basically, there are two home network models that allow users to connect hosts to the service provider's broadband network, which are Routed CPE model and Bridged CPE model. In Routed CPE model, the PPP session is established from the CPE, hosts in customer premises are connecting to the LAN/WLAN interfaces of CPE. In the Bridged CPE model, the PPP session is established from the host. This architecture describes a L2 access network which means the access network does not need to aware L3 header and forward based on the information in that layer. Yang, et al. Expires July 14, 2012 [Page 5] Internet-Draft FAST6-PPPoE January 2012 ISP Backbone --------------------------------------------------- ISP Metro Area Network --------- --------- / Core \ / Core \ | Router | | Router | \---------/ \---------/ +------+ +------+ | BRAS | ...... | BRAS | +------+ +------+ ---------------------------------------------------- Layer 2 Broadband Access Network +---------------+ | Agg. Switch | +---------------+ ------ ------- ------ ------- /DSLAM \ / DSLAM \ ... /DSLAM \ / DSLAM \ -------- --------- -------- --------- ---------------------------------------------------- Home Network +-------------+ +------------+ | Bridged CPE | OR | Routed CPE | +-------------+ +----------|-+ +------+ ------|-----+--- LAN | Host | +--+---+ +------+ | Host | +------+ Figure 1: The Network Architecture with L2 Access Network 3.2. Network scale and model In a large scale broadband network, there could be millions of subscribers with a high increasing rate accessing ISP's metropolitan area network. And there could be hundreds of BRASs connecting to a few CRs in a flat architecture metro area network. All traffics are going through the high performance CRs. In some cases, CPEs are not managed by broadband service providers, and they are mostly in bridged mode. Subscribers are accessing Internet via PPPoE [RFC2516] dial-up to establish a PPP session from host or routed CPE to BRAS. The routed CPE may perform a traditional NAT [RFC3022] for the hosts connected to the CPE. Yang, et al. Expires July 14, 2012 [Page 6] Internet-Draft FAST6-PPPoE January 2012 3.3. ISP Requirements For IPv6 Transition As a service provider, the most significant requirement for IPv6 transition is to keep the reliability of the network access service and ensure the Service Level Agreement (SLAs) with subscribers. The transition plan should adopt the subscribers' behaviors and current service providing model. Moreover, the investment and the technical risks are important aspects to any commercial organization. Commercially, ISPs should balance the investment and the technical risks by choosing a flexible, incremental and scalable transition model to lower the technical risks and safe the investment. Technically, ISP should evaluate how many risks to existing services are introduced accompany with the new technologies and the transition. This includes the risks of service reliability, the influence to network performance, the difficulties of operation and management and the difficulties and complexity of network maintenance. All these risks are tightly related to the scale of subscribers, the existing network architecture, and the traffic pattern at each stage of the transitioning. Last but not least, as a public network, the new network security system at personal level and public level should be finished the transition before providing the new service. 3.4. Weaknesses of current transition technology According to the [I-D.yang-v6ops-fast6-tools-selection], the current transition technologies and models still have some weaknesses. Although NAT444 transition model makes a balance between guaranteeing the subscribers' experience and introducing IPv6, it is still not a comprehensive and completely solution for a broadband network, especially for a L2 access network. The fundamental architecture of service provider's network transitioning to IPv6 (FAST6) with Layer 2 broadband access network is described in the following sections. The FAST6 is the architecture of the broadband service provider's network when it is transitioning to IPv6. 4. The FAST6 Architecture with L2 Access Network In this section, the FAST6 architecture is proposed. It absorbed the benefits of nat444 network model [I-D.shirasaki-nat444] and the deployment of CGN in [I-D.kuarsingh-lsn-deployment], and optimize for the existing broadband architecture with L2 access. It describes how Yang, et al. Expires July 14, 2012 [Page 7] Internet-Draft FAST6-PPPoE January 2012 an existing IPv4 broadband access service keeps growing when IPv4 address has been exhausted; how to introduce IPv6 broadband access service into current broadband architecture. It is a flexible, reliable IPv6 transition architecture to provide native dual-stack service with maximum guarantee the existing IPv4 broadband services. Large Scale NAT (LSN) or Carrier Grade NAT (CGN) device is the key component in the nat444 model. [I-D.shirasaki-nat444] specifies behaviors of CGN and [I-D.ietf-behave-lsn-requirements] defines the CGN device requirements. There are two options for the CGNs' location in FAST6: Distributed CGN Architecture and Centralized CGN Architecture. The influence of CGN's location has been discussed in [I-D.kuarsingh-lsn-deployment]. 4.1. Distributed CGN (DCGN) Architecture 4.1.1. Architecture Description As described above, there are many BRASs with different IPv6 capability in a broadband service provider's Metro Area Network (MAN). In the FAST6-DCGN Architecture, the ISP's MANs are upgrading to native dual-stack [I-D.arkko-ipv6-transition-guidelines], IPv4 and IPv6 traffic are separated. The MANs are connecting to ISP's backbone which should be capable of dual-stack accessing. Yang, et al. Expires July 14, 2012 [Page 8] Internet-Draft FAST6-PPPoE January 2012 ISP Dual-Stack Backbone --------------------------------------------------- ISP Dual-Stack MAN ----------- ----------- / Dual-Stack\ /Dual-Stack \ |Core Router| |Core Router| \-----------/ \-----------/ +---------+________+----------------## |IPv4 BRAS|__L2TP__| Dual-Stack BRAS## (Distributed | | | w/DCGN ## CGN) +---------+ +-----------------+ ---------------------------------------------------- L2 Broadband Access Network +---------------+ | Agg. Switch | +---------------+ ------ ------- ------ ------- /DSLAM \ / DSLAM \ ... /DSLAM \ / DSLAM \ -------- --------- -------- --------- ---------------------------------------------------- Home Network +-------------+ +------------## | Bridged CPE | OR | Routed CPE ## NAT +-------------+ | w/NAT ## +------------+ +---------+ +---------+ +----------+ +----------+ | v4 Host | | v4 Host | | DS Host | | DS Host | | w/Public| |w/Private| | w/Public | | w/Private| | Address | | Address | |v4 Address| |v4 Address| +---------+ +---------+ +----------+ +----------+ Figure 2: The FAST6-DCGN Architecture As shown above in Figure 2, CRs and BRASs in MANs are upgrading to dual-stack when they are able to do so. The supporting systems or public service systems like AAA, DNS, Network Management are upgrading to support the dual stack MANs and getting ready for the native dual-stack broadband service. There are usually only a few CRs in a MAN, which is high performance and up-to-dated. In a situation that all CRs cannot upgrade to dual- stack [RFC4213], adding new dual stack CRs or replacing the legacy CRs could be considered. This will not change the current architecture of the MAN. Yang, et al. Expires July 14, 2012 [Page 9] Internet-Draft FAST6-PPPoE January 2012 There are many BRASs, which have different levels of IPv6 capability, in a MAN. The L2TP [RFC2661] tunnel could be used if the legacy BRASs cannot update to dual stack. This scenario will describe in the below section. CGN is the component that performs network address transition between private IPv4 defined in [RFC1918] and the public IPv4 address when the IPv4 public addresses are exhausted. CGNs in the FAST6-DCGN Architecture are distributed deployed with the updated or new dual-stack BRASs. The L2 broadband access network is unaware of IPv4 or IPv6. DSLAMs are distributed throughout the whole metro area and act as the access nodes for broadband subscribers. DSLAMs are connecting to different Aggregation Switches according to their geography locations. In the FAST6-DCGN Architecture, CPE could be Bridged CPE or Routed CPE. That depends on subscribers. Most subscribers are using Bridged CPEs. So, most CPEs do not need to be upgraded or replaced. If the subscribers want to use legacy Routed CPEs to access IPv6 Internet, they should upgrade or replace their Routed CPEs to support IPv6. Otherwise, they need to initial another PPP session for IPv6 traffic separately from their hosts. In such case, CPE is bridged for this IPv6 PPP session. There are four types of hosts in this architecture: IPv4 host with public IPv4 address, IPv4 host with private IPv4 address, dual-stack host with public IPv4 address and dual-stack host with private IPv4 address. In the following sections, we discuss this architecture in two scenarios. 4.1.2. Scenario 1: Subscribers Access IPv4 BRAS The first scenario is subscribers are accessing a legacy IPv4 BRAS, and this BRAS cannot upgrade to dual-stack whereas some subscribers want to use dual-stack service. If it is practical, subscribers can be connected to the dual-stack BRAS, for example, when there is another available dual-stack BRAS for the same geography area. But in this case, the subscriber usually needs to be a new customer because it is impractical to switchover one or few subscribers from one BRAS to another. And we also noticed that, in a large scale broadband network, an IPv4 BRAS that cannot upgrade to dual-stack usually has been operating for years and will be replaced soon. If subscribers with IPv6 demand cannot connected to a dual-stack BRAS, L2TP tunnels from the IPv4 BRAS to dual-stack BRAS can be used Yang, et al. Expires July 14, 2012 [Page 10] Internet-Draft FAST6-PPPoE January 2012 to provide dual-stack service. The subscribers will get both IPv4 address and IPv6 address from the remote BRAS, and the address scheme will follow the rules on the remote dual-stack BRAS. Service provider can provide IPv4-only connectivity to subscribers unless they request for IPv6 service. These IPv4-only subscribers will be provided a public IPv4 address. CGN is not needed for this kind of BRAS. 4.1.3. Scenario 2: Subscribers Access Dual-Stack BRAS The second scenario is subscribers are accessing a dual stack BRAS. This BRAS could be an upgraded BRAS or newly implemented one. Distributed CGN (DCGN) could be deployed with this BRAS by plug-in CGN function card or standalone device aside it. There are two kinds of IPv4 address pools in a dual-stack BRAS, Public IPv4 Address pool and Private IPv4 address pool respectively. ISPs can assign different IPv4 address to their customers according to their marketing or management strategies. For example, Public IPv4 addresses can be assigned to the existing subscribers while private IPv4 addresses assigned to the new subscribers when the public address is exhausted. When a private IPv4 address is assigned to a subscriber, the traffic will go through the DCGN which perform the traditional NAT operation. The private IPv4 routes of subscribers will not distribute into ISP's Metropolitan Area Network. The IPv6/Dual-stack Service could be easily introduced by assigning IPv6 address in the same PPP session when the ISP's infrastructure is ready for dual-stack service. When to introduce the IPv6 connectivity also depends on ISP's strategies which are out of scope of this document. So, there will be two kinds of IPv4 hosts at the beginning of the IPv6 transitioning period, the host with private IPv4 address and the host with public IPv4 address. Also, there are two kinds of dual-stack hosts during the IPv6 transitioning period, the host with private IPv4 address and IPv6 address and the host with public IPv4 address and IPv6 address. When partly subscribers do not have demand for IPv4 any more, the dual-stack BRAS can allocate only one or more IPv6 addresses to those subscribers The dual-stack BRAS can transit to IPv6-only device by simply !oTurning off!+/- the IPv4 when there is no IPv4 subscriber connecting to that BRAS any more. Yang, et al. Expires July 14, 2012 [Page 11] Internet-Draft FAST6-PPPoE January 2012 4.1.4. Sharing Address between DCGNs In the FAST6-CCGN Architecture, the ISP's MANs are upgrading to native dual-stack, IPv4 and IPv6 traffic will be forwarded independently. The MANs are connecting to ISP's backbone which should be capable of dual-stack accessing. 4.2. Centralized CGN Architecture 4.2.1. Architecture Description In the FAST6-CCGN Architecture, the ISP's MANs are upgrading to native dual-stack [I-D.arkko-ipv6-transition-guidelines], IPv4 and IPv6 traffic will be forwarded independently. The MANs are connecting to ISP's backbone which should be capable of dual-stack accessing. Yang, et al. Expires July 14, 2012 [Page 12] Internet-Draft FAST6-PPPoE January 2012 ISP Dual-Stack Backbone --------------------------------------------------- ISP Dual-Stack MAN /-----------\ /-----------\ | Dual-Stack## |Dual-Stack ## |Core Router## Centralized |Core Router## | w/CCGN ## CGN | w/CCGN ## \-----------## \-----------## +---------+____________+-----------------+ | |___L2TP_____| | |IPv4 BRAS| | Dual-Stack BRAS | +---------+ +-----------------+ ---------------------------------------------------- Layer 2 Broadband Access Network +---------------+ | Agg. Switch | +---------------+ ------ ------- ------ ------- /DSLAM \ / DSLAM \ ... /DSLAM \ / DSLAM \ -------- --------- -------- --------- ---------------------------------------------------- Home Network +-------------+ +------------## | Bridged CPE | OR | Routed CPE ## NAT +-------------+ | w/NAT ## +------------+ +---------+ +---------+ +----------+ +----------+ | v4 Host | | v4 Host | | DS Host | | DS Host | | w/Public| |w/Private| | w/Public | | w/Private| | Address | | Address | |v4 Address| |v4 Address| +---------+ +---------+ +----------+ +----------+ Figure 3: The FAST6-CCGN Architecture As the same as the FAST6-DCGN Architecture, network devices and supporting systems in MANs are upgrading to dual-stack and getting ready for the native dual-stack broadband service. There are usually only a few CRs in a MAN, which is high performance and up-to-dated. In a situation that all CRs cannot upgrade to dual- stack, adding new dual stack CRs or replacing the legacy CRs could be considered. The Centralized-CGN is the component that performs network address transition between private IPv4 address defined in [RFC1918] and the Yang, et al. Expires July 14, 2012 [Page 13] Internet-Draft FAST6-PPPoE January 2012 public IPv4 address when the IPv4 public addresses are exhausted. And it is centralized deployed with CRs by plug-in CGN function card or standalone device aside it. L2TP [RFC2661] tunnel also could be used between IPv4 BRASs and dual- stack BRASs. The L2 broadband access network is also the same as in FAST6-DCGN architecture. CPE could be Bridged or Routed mode which depends on subscribers' preference. Currently, most subscribers accessing broadband network with L2 access network are using Bridged mode CPEs. And the bridged mode CPEs do not need to be upgraded or replaced, they can transparently support IPv6 over the PPPoE connection from host. If the subscribers are using Routed mode CPE, they should upgrade or replace their Routed CPEs. Otherwise, they need to initial another IPv6 PPP session separately from their hosts. The CPE is bridged for this IPv6 PPP session. There are also four types of hosts in this architecture: IPv4 host with public IPv4 address, IPv4 host with private IPv4 address, dual- stack host with public IPv4 address and dual-stack host with private IPv4 address. In the following sections, we discuss this architecture in two scenarios. 4.2.2. Scenario 1: Subscribers Access IPv4 BRAS This scenario is about subscribers connecting to an IPv4 BRAS. Some subscribers want to upgrade their services to dual-stack or IPv6. So, there are four types of hosts connecting to this BRAS according to the address allocated to them, which are public IPv4 address, private IPv4 address, dual-stack with public IPv4 address and dual- stack with private IPv4 address. For example, service provider could only provide IPv4 Service to existing subscribers unless they request for IPv6 or Dual-stack service. They will get a public IPv4 address. Service provider should try to avoid the subscribers with IPv6 demands connecting to an IPv4-only BRAS. Instead, they could connect to an upgraded or new dual-stack BRAS by connecting to a DSLAM attached to an aggregation switch that connects to a dual-stack BRAS. In the real environment, it is impractical to switch-over between BRASs for a specific subscriber or a small group of subscribers. That is because if we do so, the user management process would be much more complex. A more practical solution is using L2TP tunnels from the legacy BRAS to a dual-stack BRAS. The subscribers are Yang, et al. Expires July 14, 2012 [Page 14] Internet-Draft FAST6-PPPoE January 2012 getting IPv4 address and IPv6 address from the remote BRAS, and the address scheme will follow the rules on the remote dual-stack BRAS. The public IPv4 traffic is going through CRs, but CGNs at CRs are not translating such traffic. 4.2.3. Scenario 2: Subscribers Access Dual-Stack BRAS The second scenario is about subscribers connecting to a dual-stack BRAS, and this BRAS can be software upgraded from existing one or be a newly implemented. There are two kinds of IPv4 address pools in dual-stack BRAS. Public IPv4 Address pool and Private IPv4 address pool. ISPs can assign different kinds of IPv4 address to their customers according to their strategies. For example, Public IPv4 addresses can be assigned to the existing subscribers while private IPv4 addresses assigned to the new subscribers when the public address is exhausted. When a private IPv4 address is assigned to a subscriber, the traffic will go through the CGN at CR which perform the traditional NAT operation. The IPv6 or Dual-stack Service could be easily introduced by assigning IPv6 address to the host via the same PPP session when the ISP's infrastructure is ready for dual-stack service. When to introduce the IPv6 connectivity also depends on ISP's strategy which is out of scope of this document. So, there are two kinds of IPv4- only hosts, with private or public IPv4 address at the beginning of the IPv6 transitioning period; and there are two kinds of dual-stack hosts, with private or public IPv4 address and IPv6 address during the IPv6 transitioning period. When subscribers do not have demand for IPv4 any more, the dual-stack BRAS can allocate only IPv6 address to those subscribers. The dual-stack BRAS can transit to IPv6-only by simply !oTurning off!+/- IPv4 when there is no IPv4 subscriber connecting to that BRAS any more. An IPv4 subscriber with demands for IPv6 attached to an IPv4 BRAS can establish a PPP session from their hosts or CPEs to a remote dual- stack BRAS via a L2TP tunnel between these two BRAS. 4.2.4. BRAS-to-CCGN Tunnel for private IPv4 traffic The private IPv4 routes for subscribers may be distributed into ISP's Metropolitan Area Network. This may bring the address space conflict problem. So, a tunnel for private IPv4 traffic may be used to avoid Yang, et al. Expires July 14, 2012 [Page 15] Internet-Draft FAST6-PPPoE January 2012 the private IPv4 routes distribute into MAN. ISP Dual-Stack Backbone Dual-Stack Network --------------------------------------------------- ISP Dual-Stack MAN /------------\ /------------\ | Dual-Stack ## | Dual-Stack ## |Core Router ## Centralized |Core Router ## | w/CCGN ## CGN | w/CCGN ## \------------## \-+*+--------## |*|Tunnel for Private |*| IPv4 Traffic +---------+____________+--+*+------------+ | |___L2TP_____| | |IPv4 BRAS| | Dual-Stack BRAS | +---------+ +-----------------+ ---------------------------------------------------- Layer 2 Broadband Access Network Figure 4: BRAS-to-CCGN Tunnel for private IPv4 traffic As shown above, Dual-Stack BRAS can establish a tunnel with Dual- Stack CR, so CR can use tunnel ID to identify same range of IP address from different BRAS. For easy to maintain, we propose to use IPv4-in-IPv4 standard to establish tunnel and use it as tunnel ID. 4.3. Recommendations for PPPoE Access Broadband ISP For a L2 broadband access network, to provide IPv6/dual-stack accessing service, there is no immediately need to transit to an IPv6-capabile access network, especially when the subscribers establish PPP connections to BRASs directly. However, the L2 network devices like DSLAMs and aggregation switches could be replaced by fully IPv6 supported devices after their service lifecycle terminated. At the beginning of the IPv6 transition, most Internet Contents Providers (ICPs) are not ready for IPv6 access. Although broadband ISPs could provide IPv6 connectivity, the IPv4 traffic will still be very heavy and the majority. When we analyzed the broadband architecture and management behavior of broadband ISPs, we found that subscribers connecting to BRASs according to their geography location, which means there would be different type of subscribers connecting to the same BRAS. If the private IPv4 address is introduced, the IPv4-only/dual-stack subscribers with private IPv4 address will attach to different BRASs. Yang, et al. Expires July 14, 2012 [Page 16] Internet-Draft FAST6-PPPoE January 2012 If the number of new subscriber is not increasing very fast, FAST6- CCGN architecture maybe more appropriate. With the number of subscribers increasing, the Centralized CGN will become the bottleneck of the IPv4 traffic, which will affect user experience. So, the broadband network architecture should transform to the FAST6- DCGN architecture with Distributed CGNs at BRAS. The IPv4 traffic going through the DCGNs will not perform address translate action again at the CCGNs. 5. Conclusions With considering the weaknesses of NAT444 transitioning model, FAST6 is an architecture that based on the common broadband network architecture and providing transitioning solutions going through the whole IPv6 transition period. The two different network models, FAST6-DCGN and FAST6-CCGN, are introduced and discussed. Different scenarios within these two architectures are also described, with the considerations of the diverse IPv6 abilities of network devices. Suggestions and recommendations for broadband ISPs are also given. 6. Acknowledgements TBD... 7. IANA Considerations This memo includes no request to IANA. 8. Security Considerations This document has no impact on the security properties of specific IPv6 transition tools. When introducing IPv6, it is important to ensure that the necessary security capabilities exist on the network components even when dealing with IPv6 traffic. The security issues should be considered when deploying any transition technology. For instance, firewall and logging system for illegal activity tracing is still a challenge in IPv6 and NAT deployments. 9. References Yang, et al. Expires July 14, 2012 [Page 17] Internet-Draft FAST6-PPPoE January 2012 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", 2012. 9.2. Informative References [I-D.arkko-ipv6-transition-guidelines] Arkko, J. and F. Baker, "Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment", draft-arkko-ipv6-transition-guidelines-14 (work in progress), December 2010. [I-D.ietf-behave-lsn-requirements] Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., and H. Ashida, "Common requirements for Carrier Grade NATs (CGNs)", draft-ietf-behave-lsn-requirements-05 (work in progress), November 2011. [I-D.ietf-softwire-dual-stack-lite] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- Stack Lite Broadband Deployments Following IPv4 Exhaustion", draft-ietf-softwire-dual-stack-lite-10 (work in progress), May 2011. [I-D.kuarsingh-lsn-deployment] Kuarsingh, V. and J. Cianfarani, "NAT44/LSN Deployment Options and Experiences", draft-kuarsingh-lsn-deployment-01 (work in progress), January 2011. [I-D.shirasaki-nat444] Yamagata, I., Shirasaki, Y., Nakagawa, A., Yamaguchi, J., and H. Ashida, "NAT444", draft-shirasaki-nat444-03 (work in progress), January 2011. [I-D.shirasaki-nat444-isp-shared-addr] Shirasaki, Y., Miyakawa, S., Nakagawa, A., Yamaguchi, J., and H. Ashida, "NAT444 addressing models", draft-shirasaki-nat444-isp-shared-addr-05 (work in progress), January 2011. [I-D.yang-v6ops-fast6-tools-selection] Yang, G. and C. Huang, "The analysis of tools selection for broadband ISP", draft-yang-v6ops-fast6-tools-selection-00 (work in Yang, et al. Expires July 14, 2012 [Page 18] Internet-Draft FAST6-PPPoE January 2012 progress), May 2011. [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994. [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. [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. [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661, August 1999. [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001. [RFC4029] Lind, M., Ksinant, V., Park, S., Baudot, A., and P. Savola, "Scenarios and Analysis for Introducing IPv6 into ISP Networks", RFC 4029, March 2005. [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005. [RFC4241] Shirasaki, Y., Miyakawa, S., Yamasaki, T., and A. Takenouchi, "A Model of IPv6/IPv4 Dual Stack Internet Access Service", RFC 4241, December 2005. [RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)", RFC 5569, January 2010. [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification", RFC 5969, August 2010. [RFC6036] Carpenter, B. and S. Jiang, "Emerging Service Provider Scenarios for IPv6 Deployment", RFC 6036, October 2010. [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, April 2011. Yang, et al. Expires July 14, 2012 [Page 19] Internet-Draft FAST6-PPPoE January 2012 Authors' Addresses GuoLiang Yang China Telecom 109, Zhongshan Ave. West, Guangzhou, Tianhe District 510630 P.R. China Phone: Email: iamyanggl@gmail.com Cancan Huang China Telecom 109, Zhongshan Ave. West, Guangzhou, Tianhe District 510630 P.R. China Phone: Email: cancanhuang110@gmail.com Zhijing Peng China Telecom 109, Zhongshan Ave. West, Guangzhou, Tianhe District 510630 P.R. China Phone: Email: jonathan8304@gmail.com Yang, et al. Expires July 14, 2012 [Page 20]