One document matched: draft-yang-v6ops-fast6-pppoe-00.txt
Internet Engineering Task Force G. Yang
Internet-Draft J. Lin
Intended status: Informational J. Tan
Expires: November 24, 2011 China Telecom
May 23, 2011
Fundamental Architecture of Services Provider's network Transitioning to
IPv6 (FAST6)-PPPoE Broadband Access
draft-yang-v6ops-fast6-pppoe-00
Abstract
Although there have already been many transition solutions and
technologies, it is still lack of a complete solution for large scale
broadband ISPs based on the network architecture in the real world,
with considering service providers' requirements and constraints.
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. It is based on
common broadband network architecture and providing transitioning
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 November 24, 2011.
Copyright Notice
Copyright (c) 2011 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
Yang, et al. Expires November 24, 2011 [Page 1]
Internet-Draft FAST6-PPPoE May 2011
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.
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 LSN (DLSN) Architecture . . . . . . . . . . . 8
4.1.1. Architecture Description . . . . . . . . . . . . . . . 8
4.1.2. Scenario 1: Subscribers Access Legacy IPv4 BRAS . . . 10
4.1.3. Scenario 2: Subscribers Access Updated or New
Dual-Stack BRAS . . . . . . . . . . . . . . . . . . . 11
4.1.4. Sharing Address between DLSNs . . . . . . . . . . . . 12
4.2. Centralized LSN (CLSN) Architecture . . . . . . . . . . . 12
4.2.1. Architecture Description . . . . . . . . . . . . . . . 12
4.2.2. Scenario 1: Subscribers Access Legacy IPv4 BRAS . . . 14
4.2.3. Scenario 2: Subscribers Access Updated or New
Dual-Stack BRAS . . . . . . . . . . . . . . . . . . . 15
4.2.4. BRAS-to-CLSN 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1. Normative References . . . . . . . . . . . . . . . . . . . 17
9.2. Informative References . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
Yang, et al. Expires November 24, 2011 [Page 2]
Internet-Draft FAST6-PPPoE May 2011
1. Introduction
With witness the exhaustion of IANA's IPv4 address, many Internet
Service Providers (ISPs) are on their way with transition plans.
However, there is not enough time for a large scale broadband network
provider to migrate its entire network, supporting systems and
existing subscribers to a native IPv6 network. There are many
transition solutions and technologies were carried out by IETF and
engineers all over the world based on Dual-Stack, Tunnel, and
Translation basic 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 both business
and technical aspects.
If the network were to run out of addresses, no additional hosts,
subscribers or servers could be added to the network. ISPs need an
IPv6 transition solution that can keep the continuity of the existing
IPv4 services and reduce the impacts to subscribers' experience.
The PPPoE access technology is widely used in large scale broadband
ISPs. With this technology, the service provider's broadband network
is usually with a L2 access network.
This document proposes a transitioning architecture, the FAST6, which
is a Fundamental Architecture of Service provider's broadband network
Transitioning to IPv6 with a L2 access network. The FAST6 is based
on the broadband network architecture that is widely deployed 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 November 24, 2011 [Page 3]
Internet-Draft FAST6-PPPoE May 2011
ISP's Backbone: ISP's Backbone interconnects ISP's metro area
networks (MANs), providing a path for long distance
transmission between different MANs and connecting to the
Internet.
Metro Area Network: Metro Area Network 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. The Metro Area
Network 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 metro area network (MAN) 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, BRAS, is the aggregation
point for the subscriber traffic. It provides
aggregation capabilities between the Access Network and
the Metro Area Network. Beyond aggregation, it is also
the injection point for access authentication, policy
management and IP QoS.
DSLAM: Digital Subscriber Line Access Multiplexer, 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 November 24, 2011 [Page 4]
Internet-Draft FAST6-PPPoE May 2011
3. Brief Description of ISP's Broadband Network
The transition is an urgent issue for ISPs, especially for large
scale broadband ISPs. Some large scale broadband ISPs are facing
high increasing rate of new subscribers which needs a great amount of
addresses. The addresses shortage problem becomes a bottleneck of
the broadband service. There is only broadband user demand for
reliable Internet access regardless of whether IPv4 or IPv6. At this
point of time, IPv4 address is already exhausted, and most of the
Internet contents and resources are still providing IPv4-only access.
This section will start with a brief description of the broadband
architecture with Layer 2 (L2) access network; try to summarize the
business and technical requirements and constraints of broadband
service of ISP. As mention in [I-D.yang-v6ops-fast6-tools-
selection], the current IPv6 transition technologies or solutions are
not completely fitting broadband ISPs' requirements.
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 Metro Area Network (MAN), Core Routers (CRs) are the egress
routers, and all Internet traffics from broadband subscribers are
going through CRs toward to ISP's backbone that is connecting
different MANs and the Internet. Broadband Remote Access Server
(BRAS) is the PPP [RFC1661] session termination point at ISP-side.
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 WAN Port of 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.
Yang, et al. Expires November 24, 2011 [Page 5]
Internet-Draft FAST6-PPPoE May 2011
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 growing pace in an ISP's metro area network.
And there could be hundreds of BRASs connecting to a few CRs in a
flat metro area network. All traffics are going through the high
performance CRs. In many cases, CPE is not managed by broadband
service providers, and the users' CPEs 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 November 24, 2011 [Page 6]
Internet-Draft FAST6-PPPoE May 2011
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, a fundamental architecture of service provider's
network transitioning to IPv6 is proposed. It absorbed the benefits
of nat444 network model [I-D.shirasaki-nat444] and the deployment of
LSN in [I-D.kuarsingh-lsn-deployment], and optimize for the existing
Yang, et al. Expires November 24, 2011 [Page 7]
Internet-Draft FAST6-PPPoE May 2011
broadband architecture with L2 access. It describes how 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) device is the key component in the nat444 model.
[I-D.shirasaki-nat444] specifies the behaviors of LSN and
[I-D.ietf-behave-lsn-requirements] defines the LSN device
requirements. There are two options for the LSNs' location:
Distributed LSN Architecture and Centralized LSN Architecture. The
influence of LSN's location is discussed in
[I-D.kuarsingh-lsn-deployment].
4.1. Distributed LSN (DLSN) 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-DLSN 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 November 24, 2011 [Page 8]
Internet-Draft FAST6-PPPoE May 2011
ISP Dual-Stack Backbone
---------------------------------------------------
ISP Dual-Stack MAN
----------- -----------
/ Dual-Stack\ /Dual-Stack \
|Core Router| |Core Router|
\-----------/ \-----------/
+---------+________+----------------##
| Legacy |__L2TP__| Updated/New ## Distributed
|IPv4 BRAS| |Dual-Stack BRAS ## LSN
+---------+ | w/DLSN ##
+-----------------+
----------------------------------------------------
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-DLSN 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 November 24, 2011 [Page 9]
Internet-Draft FAST6-PPPoE May 2011
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. LSN 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.
LSNs in the FAST6-DLSN 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-DLSN 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 upgrade or replace. 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. 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 Legacy IPv4 BRAS
The first scenario is the subscribers are accessing a legacy IPv4
BRAS, and the BRAS cannot upgrade to dual-stack. Some of subscribers
want to upgrade their services to dual-stack.
The existing subscribers will continue IPv4-only access unless they
request for IPv6 service. These IPv4-only subscribers are still
provided a public IPv4 address. So, LSN is not needed for this kind
of BRAS.
The new subscribers with demands for IPv6 are tried not to connect to
a legacy IPv4 BRAS. Instead, they could connect to an upgraded or
new dual-stack BRAS by connecting to a DSLAM attaches to the
aggregation switch that connects to a dual-stack BRAS. In a large
scale broadband network, a legacy IPv4 BRAS that cannot upgrade to
dual-stack usually has been operating for years and will be replaced
Yang, et al. Expires November 24, 2011 [Page 10]
Internet-Draft FAST6-PPPoE May 2011
soon. The existing IPv4 subscribers with demands for IPv6 are
impractical to switch-over to a dual-stack BRAS because it will
increase the complexity of the users management for ISPs. The
practical solution is using L2TP tunnels from the legacy BRAS to a
dual-stack BRAS. The subscribers are getting IPv4 address and IPv6
address from the remote BRAS, and the address scheme will follow the
rules on the remote dual-stack BRAS.
4.1.3. Scenario 2: Subscribers Access Updated or New Dual-Stack BRAS
The second scenario is the subscribers are accessing a dual stack
BRAS, and this BRAS can upgrade from the existing BRAS or newly
implemented. And Distributed LSN (DLSN) is deployed with this kind
of BRAS by plug-in LSN function card or standalone device aside it.
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 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's host, the
traffic from it will go through the DLSN which perform the address
translation. The private IPv4 routes for subscribers will not
distribute into ISP's Metro 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 strategy which is out of scope of
this document. So, there are two kinds of IPv4-only hosts, with
private/public address at the beginning of the IPv6 transitioning
period; and there are two kinds of dual-stack hosts, with private/
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 distribute IPv6 address only 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.
The existing IPv4 subscribers with demands for IPv6 attaches to a
legacy 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.
Yang, et al. Expires November 24, 2011 [Page 11]
Internet-Draft FAST6-PPPoE May 2011
4.1.4. Sharing Address between DLSNs
The private IPv4 address [RFC1918] pool of the dual-stack BRASs
within the FAST6-DLSN Architecture can be the same address space.
The sharing address space may be the address block that is not from
private IPv4 address space, but the operation and management risks
should be carefully considered. Because this specific address space
is not familiar by operation engineers, it is easy to introduce
risks.
4.2. Centralized LSN (CLSN) Architecture
4.2.1. Architecture Description
In the FAST6-CLSN 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 November 24, 2011 [Page 12]
Internet-Draft FAST6-PPPoE May 2011
ISP Dual-Stack Backbone
---------------------------------------------------
ISP Dual-Stack MAN
/-----------\ /-----------\
| Dual-Stack## |Dual-Stack ##
|Core Router## Centralized |Core Router##
| w/CLSN ## LSN | w/CLSN ##
\-----------## \-----------##
+---------+____________+-----------------+
| Legacy |___L2TP_____| Updated/New |
|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-CLSN Architecture
As the same as the FAST6-DLSN 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-LSN is the component that performs network address
transition between private IPv4 defined in [RFC1918] and the public
Yang, et al. Expires November 24, 2011 [Page 13]
Internet-Draft FAST6-PPPoE May 2011
IPv4 address when the IPv4 public addresses are exhausted. And it is
centralized deployed with CRs by plug-in LSN function card or
standalone device aside it.
L2TP [RFC2661] tunnel also could be used in this architecture when
the legacy BRASs cannot upgrade to dual-stack. The L2 broadband
access network is also the same as in FAST6-DLSN architecture.
CPE could be Bridged CPE or Routed CPE which depends on subscribers.
Most subscribers accessing broadband network with L2 access network
are using Bridged CPEs. So, most CPEs do not need to upgrade or
replace. If the subscribers want to use their legacy Routed CPEs to
access IPv6 Internet, they should upgrade or replace their Routed
CPEs. Otherwise, they need to initial another IPv6 PPP session
separately from their hosts. 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 Legacy IPv4 BRAS
The first scenario is the subscribers are accessing a legacy IPv4
BRAS, and the BRAS cannot upgrade to dual-stack. Some of subscribers
want to upgrade their services to dual-stack.
The existing subscribers will continue IPv4-only access unless they
request for IPv6 service. These IPv4-only subscribers are still
provided a public IPv4 address. The new subscribers with demands for
IPv6 are tried not to connect to a legacy IPv4 BRAS. Instead, they
could connect to an upgraded or new dual-stack BRAS by connecting to
a DSLAM attaches to the aggregation switch that connects to a dual-
stack BRAS.
The existing IPv4 subscribers with demands for IPv6 are impractical
to switch-over to a dual-stack BRAS because it will increase the
complexity of the user management. The practical solution is using
L2TP tunnels from the legacy BRAS to a dual-stack BRAS. The
subscribers are 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 the CRs, but CLSNs are not
Yang, et al. Expires November 24, 2011 [Page 14]
Internet-Draft FAST6-PPPoE May 2011
translating such traffic.
4.2.3. Scenario 2: Subscribers Access Updated or New Dual-Stack BRAS
The second scenario is the subscribers are accessing a dual stack
BRAS, and this BRAS can upgrade from the existing BRAS or 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's host, the
traffic from it will go through the CLSN at CR which perform the
address translation.
The IPv6/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/public address at the beginning of the IPv6
transitioning period; and there are two kinds of dual-stack hosts,
with private/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 distribute IPv6 address only 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.
The existing IPv4 subscribers with demands for IPv6 attaches to a
legacy 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-CLSN Tunnel for private IPv4 traffic
The private IPv4 routes for subscribers may be distributed into ISP's
Metro Area Network. This may bring some address space conflict
problems. So, a tunnel for private IPv4 traffic may be used to avoid
the private IPv4 routes distribute into MAN.
Yang, et al. Expires November 24, 2011 [Page 15]
Internet-Draft FAST6-PPPoE May 2011
ISP Dual-Stack Backbone Dual-Stack Network
---------------------------------------------------
ISP Dual-Stack MAN
/------------\ /------------\
| Dual-Stack ## | Dual-Stack ##
|Core Router ## Centralized |Core Router ##
| w/CLSN ## LSN | w/CLSN ##
\------------## \-+*+--------##
|*|Tunnel for Private
|*| IPv4 Traffic
+---------+____________+-+*+-------------+
| Legacy |___L2TP_____| Updated/New |
|IPv4 BRAS| | Dual-Stack BRAS |
+---------+ +-----------------+
----------------------------------------------------
Layer 2 Broadband Access Network
Figure 4: BRAS-to-CLSN Tunnel for private IPv4 traffic
4.3. Recommendations for PPPoE Access Broadband ISP
For a L2 broadband Access network, there is no need to migrate the
large scale access network to IPv6-only to provide IPv6/dual-stack
accessing service, especially when the subscribers establish PPP
connections to BRASs directly. However, the L2 network devices like
DSLAMs and aggregation switches could be replaced by a fully IPv6
supported devices at the end of their service lifecycle.
At the beginning of the IPv6 transition, most Internet contents are
not ready for IPv6 access. Although broadband ISPs could provide
IPv6 connectivity, the IPv4 traffic will be still heavy and be the
majority. When we analyzed the broadband architecture and management
behavior of many broadband ISPs, we found that which BRAS a
subscriber would connect to is geography location based. If the
private IPv4 address is introduced, the IPv4-only/dual-stack
subscribers with private IPv4 address will distributed attach to
different BRASs. If the increasing rate of new subscribers is not
very high, FAST6-CLSN architecture maybe more appropriate at the
beginning of the transitioning period. With the subscribers with
private IPv4 address increase, the Centralized LSN will become the
bottleneck of the IPv4 traffic. So, the broadband network
architecture should transform to a FAST6-DLSN architecture with DLSNs
at the BRAS level. The IPv4 traffic going through the DLSNs will not
perform address translate action again at the CLSNs.
Yang, et al. Expires November 24, 2011 [Page 16]
Internet-Draft FAST6-PPPoE May 2011
5. Conclusions
With considering the weaknesses of other transitioning tools, the
FAST6, a fundamental architecture of service provider's broadband
network transitioning to IPv6 with layer 2 access network, is based
on common broadband network architecture and providing transitioning
solutions going through the whole transition period. The two
different network models, FAST6-DLSN and FAST6-CLSN, are introduced
and discussed. Different scenarios within these two architectures
are also described, with the considerations of the diverse IPv6
abilities of the 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 trace have
often been a challenge in IPv6 deployments.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[min_ref] authSurName, authInitials., "Minimal Reference", 2006.
9.2. Informative References
[I-D.arkko-ipv6-transition-guidelines]
Arkko, J. and F. Baker, "Guidelines for Using IPv6
Yang, et al. Expires November 24, 2011 [Page 17]
Internet-Draft FAST6-PPPoE May 2011
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 IP address sharing
schemes", draft-ietf-behave-lsn-requirements-01 (work in
progress), March 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.
[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.
Yang, et al. Expires November 24, 2011 [Page 18]
Internet-Draft FAST6-PPPoE May 2011
[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.
Authors' Addresses
GuoLiang Yang
China Telecom
109, Zhongshan Ave. West,
Guangzhou, Tianhe District 510630
P.R. China
Phone:
Email: yanggl@gsta.com
Yang, et al. Expires November 24, 2011 [Page 19]
Internet-Draft FAST6-PPPoE May 2011
Jinyan Lin
China Telecom
109, Zhongshan Ave. West,
Guangzhou, Tianhe District 510630
P.R. China
Phone:
Email: jasonlin.gz@gmail.com
Jinghua Tan
China Telecom
109, Zhongshan Ave. West,
Guangzhou, Tianhe District 510630
P.R. China
Phone:
Email: tanjh@gsta.com
Yang, et al. Expires November 24, 2011 [Page 20]
| PAFTECH AB 2003-2026 | 2026-04-24 01:16:30 |