Internet DRAFT - draft-yang-v6ops-fast6-pppoe
draft-yang-v6ops-fast6-pppoe
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]
