Internet Engineering Task Force G. Yang, Ed.
Internet-Draft L. Hu
Intended status: Informational J. Lin
Expires: April 23, 2011 China Telecom
October 20, 2010
IPv6 Transition Guide For A Large-scale Broadband Network
draft-yang-v6ops-v4v6tran-bb-transition-guide-01
Abstract
This document discusses about different IPv6 migrating solutions for
each part of the Large-scale broadband network with layer 2 access
infrastructure. They are based on the requirements of providing
existing broadband services in v4v6-coexisting or IPv6-only
scenarios. The document provides analysis of different solutions and
also describes the suitable scenarios that each solution may be
deployed in.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 23, 2011.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Yang, et al. Expires April 23, 2011 [Page 1]
Internet-Draft Broadband Network Transition October 2010
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 . . . . . . . . . . . . . . . . . . . . . . . . 4
3. High Level Architecture . . . . . . . . . . . . . . . . . . . 5
4. Overview of Solutions . . . . . . . . . . . . . . . . . . . . 7
5. Transition For the Backbone Network . . . . . . . . . . . . . 8
5.1. Dual-stack IP Backbone . . . . . . . . . . . . . . . . . . 9
5.2. IPv6-Only Backbone . . . . . . . . . . . . . . . . . . . . 10
5.3. 6PE on MPLS Backbone . . . . . . . . . . . . . . . . . . . 11
5.4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . 13
6. Transition of Regional IP Network . . . . . . . . . . . . . . 13
6.1. Dual-Stack and L2TP . . . . . . . . . . . . . . . . . . . 15
6.2. Dual-Stack over IPv6 - DS-lite . . . . . . . . . . . . . . 18
6.3. Dual-Stack over IPv4 - 6rd . . . . . . . . . . . . . . . . 20
6.4. IPv6 and NAT64 . . . . . . . . . . . . . . . . . . . . . . 22
7. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 24
8. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 24
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
11. Security Considerations . . . . . . . . . . . . . . . . . . . 24
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
12.1. Normative References . . . . . . . . . . . . . . . . . . . 24
12.2. Informative References . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
Yang, et al. Expires April 23, 2011 [Page 2]
Internet-Draft Broadband Network Transition October 2010
1. Introduction
As we known, broadband subscriber is one of the largest parts of the
Internet participants. It is significant to migrate them to IPv6,
which will seem as an important step on IPv6 development. This
document describes an IPv6 transition guide for a large-scale
broadband network with Layer 2 accessing. And it will focus on the
cases that the network infrastructure is large and widely covered,
and the new subscriber's number is very large and is still increasing
very fast.
In some cases, the broadband network is serving several dozen
millions of subscribers with more than 20% annual increases in next
few years. It is predicted that after the IPv4 addresses allocated
by IANA are exhausted, the broadband users in these cases will still
keep a high increasing rate, which will bring unprecedented pressure
to not only the development of broadband services, but also the
development of Internet.
Due to IPv4 addresses shortage, the network infrastructure and
Internet services will no doubt to migrate to IPv6 eventually. And
it is also our final goal. However, IPv6-based new services and
applications are few and far between.
During the IPv6 transition, large-scale broadband network basically
should take a smooth transition strategy because of the inactive IPv6
industrial chain. The first rule could be customer-oriented which
means any changes to the network infrastructure should guarantee the
users' experience. At the same time, the transition technology and
strategy should be consistent with the future direction in order to
protect the investments and maintain the network stability. And the
technologies and solutions should be compatible with the existing
broadband service access method and provisioning method.
This document is aimed to identify the pros and cons of all possible
solutions in every part of the broadband network with considering its
features. And it also provides the applicable scenarios for each
solution.
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].
Yang, et al. Expires April 23, 2011 [Page 3]
Internet-Draft Broadband Network Transition October 2010
2. Terminologies
Backbone network: Backbone network interconnects various regional
broadband networks, providing a path for the exchange of
information between different networks.
Regional Broadband Network: Regional broadband network interconnects
the central offices in a geographical area.
L2 Access Network: L2 Access Network is the broadband access
infrastructure which is a Layer 2 network.
Customer Premises Network: Customer Premises Network will contain
one or more terminal equipment devices possibly
interconnected by a customer premises network.
POP: Internet point of presence, POP, is the access point to
the backbone network for regional broadband network.
MPLS PE routers: Provider edge router in a MPLS backbone network.
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 Network. Beyond aggregation, it is also the
injection point for access authentication, policy
management and IP QoS.
CR: Core Router in a regional broadband network is the egress
router of the regional broadband network and connecting
to a POP of the backbone in upstream and connecting to
BRASs for downstream.
SR: Service Router, SR, is the access nodes for different
services providers (e.g. Internet Contents Provider).
AR: Aggregation Router is connected to CRs and provide
traffic aggregation for BRASs in a large-scale regional
broadband network.
DSLAM: Digital Subscriber Line Access Multiplexer, DSLAM, is the
access node for Digital Subscriber Lines (DSL)
subscribers.
OLT: An optical line termination (OLT) is a device which
serves as the endpoint of a passive optical network
(PON).
Yang, et al. Expires April 23, 2011 [Page 4]
Internet-Draft Broadband Network Transition October 2010
CPE: Customer Premises Equipment, CPE, is the edge of Customer
Premises Network. In this document, there are two types
of CPEs, Routing mode CPE and Bridging mode CPE.
User End: In this document, we consider the user end is a PC with a
popular operating system like Windows, MAC OS, or Linux.
3. High Level Architecture
In this section, a High Level Broadband Architecture with layer 2
(L2) access network is shown in Figure 1. There are basically five
parts in this architecture, Customer Premises Network, Layer 2 Access
Network, Regional Broadband Network, Backbone and the Internet. We
don't discuss the physical layer infrastructures in this document.
(e.g.Main Distribution Frame (MDF), and Optical Network Terminal
(ONT)).
Yang, et al. Expires April 23, 2011 [Page 5]
Internet-Draft Broadband Network Transition October 2010
+============================================================+
| +----------------+ +---------------------------+ |
| Internet | IPv4 Internet | | IPv6 Internet | |
| +----------------+ +---------------------------+ |
+============================================================+
+============================================================+
| Backbone |
| +--------------------------+ +---------------------------+ |
| | IP backbone | | MPLS backbone | |
| +--------------------------+ +---------------------------+ |
+============================================================+
+============================================================+
| Regional Broadband Network |
| +--------------------------------------------------------+ |
| | Metro Core Router | |
| | | |
| | ..............................| |
| | . Aggregation Router | |
| +--------------------------------------------------------+ |
| +------------------------------------------------------+ |
+==| BRAS |==+
+==| |==+
| +------------------------------------------------------+ |
| Access Netrwork (Layer 2) |
| +--------------------------------------------------------+ |
| | Aggregation Switch | |
| +--------------------------------------------------------+ |
| +--------------------------+ +---------------------------+ |
| | OLT | | DSLAM | |
| +--------------------------+ +---------------------------+ |
+============================================================+
+============================================================+
| Customer Premises Network |
| +--------------------------+ +---------------------------+ |
| | Routing Mode CPE | | Bridging Mode CPE | |
| +--------------------------+ +---------------------------+ |
| +--------------------------------------------------------+ |
| | User End | |
| +--------------------------------------------------------+ |
+============================================================+
Figure 1: High Level Broadband Architecture with L2 Access network
In general, IP backbone and MPLS-enabled Layer 3 IP backbone (to
simplify discuss, we call it "MPLS backbone" in this document)
[RFC3031] are two major types of backbone for long distance
transmission in the large scale broadband network. We classified two
Yang, et al. Expires April 23, 2011 [Page 6]
Internet-Draft Broadband Network Transition October 2010
types of MPLS backbone here, the combined backbone forwarding both
the non-labeled packets by IP switching and the labeled packets by
label switching (MPLS+IP backbone), or a MPLS backbone with label
switching only.
In the Regional Broadband Network, Metro Core Router (CR) is
connected to IP backbone, MPLS+IP backbone or both IP backbone and
MPLS backbone. In most situations, Broadband Remote Access Server
(BRAS) is directly connected to CR, while in some cases, BRAS could
be connected to an Aggregation Router (AR) that connected to CR.
Service Router (SR) is basically the access nodes for different
services. As this document is focus on the IPv6 transition of
broadband service, it does not discuss about the transition of SR.
BRAS acts as the aggregation point for the subscriber traffic. It
provides aggregation capabilities between the L2 Access Network and
the Regional Broadband Network. Beyond aggregation, it is also the
injection point for access authentication, policy management and IP
QoS.
The access network in this architecture is a L2 network. It is from
the BRAS to the Customer Premises Equipment (CPE) located at the edge
of customer premises network. The most popular access method in this
architecture currently could be PPPoE [RFC2516]. In theory, the
devices in the access network have no needs to be IPvX protocol
aware.
Note that although the IPoE access method may be using the same L2
access network, the discussion of IPv6 transition with IPoE is out-
of-scope in this document. And it does not consider the transition
from a layer 2 access network to a layer 3 one as well.
This document will focus on the IPv6 transition of the Backbone
Network and the Regional Broadband Network in the architecture above
[Figure 1]. And it will also discuss how to provide IPv6 service for
broadband subscribers in such kind of architecture.
4. Overview of Solutions
This document describes the IPv6 transition solutions and related
technologies for the Use Case for Large-Scale Broadband Network.
[I-D.huang-v6ops-v4v6tran-bb-usecase] By analysing the features of
the case, The following factors make the networks' and services' IPv6
transition complicated and difficult:
o Large number of broadband subscribers and their terminals with
diverse IPv6 capabilities;
Yang, et al. Expires April 23, 2011 [Page 7]
Internet-Draft Broadband Network Transition October 2010
o Large number of network devices with diverse IPv6 capabilities;
o Various types of the Internet services and applications have
diverse IPv6 capabilities and they will not migrated to IPv6
synchronized.
During the IPv6 transition, the user experience should be guaranteed.
So, it is important to take the terminal into consideration besides
the networking issues.
Moreover, in order to migrate both of the network infrastructures and
the Internet services smoothly, it is significant to select the
proper technologies at each point of time on the IPv6 roadmap
according to different network scenarios.
Because the global IPv4 addresses is depleting, and most of the
Internet contents and applications are not ready yet, carrier graded
NAT44 technologies and Large Scale NAT devices (LSN) may be deployed
in the network during the initial stage of the IPv6 transition. So,
the issues that are brought from NAT44 technology itself and the
interoperating with other IPv6 transition technologies should be
considered.
5. Transition For the Backbone Network
According to the architecture in Figure 1 above, there are three
possible backbones in a large-scale broadband network:
o There is an IP backbone only;
o There is a MPLS+IP combined backbone;
o There is an IP backbone and a MPLS backbone.
The discussion on backbone will focus onthe scenario that there is an
IP backbone and a MPLS backbone separately. When there is an IP
backbone only, it can use the Dual-stack solution or the IPv6
solutions. And when there is a MPLS+IP combined backbone, the
solutions are similar. It can use the Dual-stack solution or the
IPv6 solutions with IP-based switching; alternatively, it use the 6PE
solution with labeled switching for the IPv6 traffic.
Basically, there are three main ways for the transition of backbone
network:
o Dual-stack IP Backbone
Yang, et al. Expires April 23, 2011 [Page 8]
Internet-Draft Broadband Network Transition October 2010
o IPv6-Only Backbone
o 6PE in MPLS Backbone
5.1. Dual-stack IP Backbone
The Dual-stack IP Backbone Solution includes two implementation
options, building a completely new Dual-Stack IP backbone or
upgrading the existing routers in the IP backbone to Dual-Stack by
enabling IPv6. Technically, the main idea is carrying both the IPv6
and IPv4 traffic on one backbone. Except the management issue and
engineering cost, there may be little difference on technical aspect.
The upgrade implementation could be incrementally to reduce the risk
on each Internet point of presence (POP), but it can not avoid the
risk on provider (P) routers. In the new-built implementation, the
new POPs and P routers are sperately with the existing backbone.
Therefore, the risk of upgrading the P routers, which is considerable
high, will be avoided. The upgrade implementation will be much more
complicated, and this section will focus on it.
Upgrading the existing backbone to a Dual-stack IP backbone requires
enable IPv6 on the all the routers and support both IPv4 and IPv6
routing protocols. In some cases, the routers may upgrade to a new
software and hardware version to support a better performance and
functionality. So, the changes will contains two parts, devices
upgrade and reconfiguration. Figure 2 presents the architecture
after the upgrade implementation.
+----------------+ +-------------------+
| IPv4 Internet | | IPv6 Internet |
+-------||-------+ +--------#----------+
+-------||------------------#----------+
| Dual-stack IP backbone |
| +--------------+ |
+---------|Dual-Stack POP|-------------+
+--/\-----/\---+
|| #
IPv4 IPv6
Traffic Traffic
Figure 2: Dual-stack IP Backbone
Generally, the pros and cons of this solution are:
Pros:
o According the the use CASE [I-D.huang-v6ops-v4v6tran-bb-usecase],
most of existing routers have IPv6 capability already (but not
Yang, et al. Expires April 23, 2011 [Page 9]
Internet-Draft Broadband Network Transition October 2010
enabled). To support IPv6, it only needs to make some
configurations or upgrade the software version. It does not need
the extra engineering cost for the new infrastructure. It is no
need to build or expand the existing facilities like power, air
conditioning and transmission infrastructures, which may take a
long engineering period.
o The existing IP backbone is usually covering a widely area
already. So, this solution is flexible and can conduct a rapid
deployment of IPv6 services anywhere it covered.
o The upgraded IP backbone is compatible with the existing IPv4
traffic and the new IPv6 traffic. There is no extra new backbone
which will lead a large amount of extra management cost.
o The upgraded dual-stack backbone can be upgraded to IPv6-only by
turning off the IPv4 after the IPv4 traffic is disappeared.
Cons:
o Until now, the routers in the IP backbone that supported Dual-
stack will usually route IPv4 and IPv6 traffic separately based on
the IPv4 routing table and the IPv6 one respectively. The router
may have challenges for the performance and stability after they
are upgraded to dual-stack, for example, the size of routing
table, routing lookup/forwarding capability and routing
convergence capability due to the sharing of resources.
o There is lack of technical and management experience of large-
scale changing in a high volume traffic backbone, even though the
change is very little.
o There is a high risk to upgrade the P router to dual-stack because
of its high volume traffic. Any fault (hardware or software) may
lead a significant impact to the existing services. And these
impacts is difficult to predict.
5.2. IPv6-Only Backbone
It seems impossible to upgrade the existing IPv4 backbone to a native
IPv6 backbone. This section will discuss a solution of building a
new IPv6-only backbone network and keeping the original IPv4
infrastructure unchanged. There is only IPv6 routing in the new
backbone, and the IPv4 traffic will be kept going through the legacy
IPv4 backbone. Figure 3 presents the architecture of co-existing of
IPv4 backbone and IPv6 backbone.
Yang, et al. Expires April 23, 2011 [Page 10]
Internet-Draft Broadband Network Transition October 2010
+----------------+ +-------------------------+
| IPv4 Internet | | IPv6 Internet |
+-------||-------+ +------------#------------+
+-------||-------+ +------------#------------+
| IPv4 backbone | | new IPv6 backbone |
+---[IPv4 POP]---+ +--------[IPv6 POP]-------+
/\ /\
|| IPv4 Traffic || IPv6 Traffic
Figure 3: New IPv6 Backbone
Pros:
o In line with the future network; It is a one-step solution and no
need the second step which will also brings the risks (e.g. dual-
stack backbone upgrade to IPv6 only);
o Nearly with no impact on the existing IPv4 backbone and the
services on it;
o Simple to maintain two physically separated infrastructures
compared with a complex dual-stack network with two logical
network.
Cons:
o The cost of building a new backbone is considerable high and the
engineering cycle could be very long.
o If the IPv6 services are still very few, the subscribers' IPv4
traffic will not be forwarded to the new IPv6 backbone. The
inefficiency of the new IPv6 backbone could be a waste. Moreover,
there may be a separate network operation and management cost for
the new backbone.
5.3. 6PE on MPLS Backbone
The Multiprotocol Label Switching (MPLS) [RFC3031] is a popular
networking technology that forwards packets by label switching
instead of by IP switching. In this solution, the provider edge (PE)
routers are dual-stack. The egress routers of the regional broadband
network are connected to the PE router via a normal interface. The
IPv6 routing distribution between two IPv6 enabled PE routers is done
via Multiprotocol iBGP (MP-iBGP). The iBGP sessions distribute the
IPv6 prefixes and the associated MPLS label. This is known as IPv6+
label and is encoded according to [RFC3107]. The communication of
IPv6 is achieved by the label switched path (LSP) among PE
Yang, et al. Expires April 23, 2011 [Page 11]
Internet-Draft Broadband Network Transition October 2010
routers.Figure 4 presents the architecture of 6PE solution over a
MPLS backbone.
+------------+
+------------+ / MPLS CORE \ +------------+
|6PE Router A|-->......LSP.......-->|6PE Router B|
+-----/\-----+ \ (IPv4) / +------/\----+
|| +------------+ ||
IPv6 Traffic IPv6 Traffic
& IPv4 Traffic & IPv4 Traffic
Figure 4: 6PE in MPLS backbone
Pros:
o 6PE technology [RFC4798] is relatively mature compared to other
tunnel technology in backbone.
o There is no need to make changes on P routers which the LSP goes
through. Only the PE router connecting to IPv6-enabled networks
needs to implement Dual-stack and make some corresponding
configurations for 6PE. The reengineering cost and risk of this
kind of changes is comparable low.
o Little impact to the existing services: There is little impact to
the existing services. It is similar to the existing MPLS network
is carrying a new service with a new label.
o According to the use case [I-D.huang-v6ops-v4v6tran-bb-usecase],
the MPLS backbone covers a widely area already which means it can
provide IPv6 servces with a rapid deployment when there is an IPv6
demand in some regional broadband networks. Therefore, this
solution is flexible and supporting incremental deployment.
Cons:
o This solution changes the original designed purpose of the MPLS
network which is normally used to carry VPN traffic and usually
light load. 6PE brings the public traffic in to the MPLS
infrastructure. When the this kind of traffic grows, there may be
significant to the existing services.
o Unable to deploy QoS policy for IPv6 traffic.
o It may bring some inconvenient for troubleshooting.
Yang, et al. Expires April 23, 2011 [Page 12]
Internet-Draft Broadband Network Transition October 2010
5.4. Conclusion
The 6PE solution may be applicable in the IPv6 initial stage while
the most traffic is still IPv4 in the backbone and there is a demand
for the rapid deployment of IPv6 service.
The Dual-stack solution may be applicable to the intermediate stage
when IPv6 traffic is relatively large. And for the network devices,
the Dual-stack capability, performance, and stability need to be
reasonable high enough to support two IP stacks.
The native IPv6 solution may be suitable to the latter phase of IPv6
transition with most of the services being IPv6 capable. It can also
be upgraded from the Dual-stack backbone by turning off the IPv4
after the IPv4 traffic is disappeared.
6. Transition of Regional IP Network
According to the use case [I-D.huang-v6ops-v4v6tran-bb-usecase], The
Overview of the solutions in the Regional Broadband Network can be
summarized into the following three types:
o Providing IPv6 service by Large-scale upgrading the existing
regional broadband network infrastructure;
o Providing IPv6 service by little changes on the existing regional
broadband network infrastructure;
o Providing IPv6 service by building a completely new IPv6 regional
broadband network infrastructure;
Large-scale | Little | unchange
Upgrade | changes | +New Net
+--------------------+ | +---------+ | +------+
CR | Dual-Stack | | | DS/IPV4 | | | IPv6 |
+--------------------+ | +---------+ | +------+
+----+ +----+ +------+ | +---------+ | +------+
BRAS |IPv6| | DS | | IPv4 | | | IPv4 | | | IPv6 |
+----+ +----+ +------+ | +---------+ | +------+
| | | | | | |
DS-Lite/ DS 6rd 6rd NAT64/
L2TP+DS /L2TP+DS DS-Lite
Note: "DS" stands for "Dual-Stack".
Yang, et al. Expires April 23, 2011 [Page 13]
Internet-Draft Broadband Network Transition October 2010
Figure 5: Overview of Solutions in Regional Broadband Network
In each transition solution of regional broadband network, it can
connect to one of the following backbone described in section 3.1??:
o Connect to the Dual-stack IP backbone;
o Connect to the IPv6-only backbone for IPv6 traffic and to the
existing IP backbone for IPv4 traffic if it has;
o Connect to the 6PE on the MPLS backbone for IPv6 traffic and to
the existing IP backbone for IPv4 traffic if it has.
Some less possible transition solutions haven't been listed above:
o Upgrade the existing regional broadband network to IPv6-only; It
will lead to a huge influence to existing network and services.
o Create a new regional broadband network with native IPv6 CRs and
Dual-Stack BRASs; It has very low possibilities because if we
create a new regional broadband network to provide dual-stack
service with new dual-stack BRAS, the simplest solution will be
let the new CRs to be dual-stack too. If the new CRs are IPv6-
only, they need other transition technologies working together
which seem to be more complicated.
o Create a new regional broadband network with Dual-stack CRs and
native IPv6 BRASs; It also has very low possibilities and the
reason is same as the above one.
In the following sections, the technical solutions based on the
scenarios in Figure 5 are discussed. Although there may be many
technical options in each scenario, the discussion will focus on one
of them.
The possible solutions referred to Figure 5 that we will discuss:
o Solution 1: Dual-Stack and L2TP
o Solution 2: Dual-Stack over IPv6 - DS-lite
o Solution 3: Dual-Stack over IPv4 - 6rd
o Solution 4: IPv6 and NAT64
In this document, it is considering that the CPE is basically
purchased by customers. In the PPPoE dial-up cases, most users
dial-up from PC, but there is some deployed a Home Gateway (e.g.
Yang, et al. Expires April 23, 2011 [Page 14]
Internet-Draft Broadband Network Transition October 2010
WLAN AP) by themselves and set up an automatically dial-up from it.
Until now, most terminals, including PCs and CPEs, will still be
IPv4-only. Although most PC operating system (OS) declared that they
already supported IPv6, there is still a problem on supporting PPPoE
with IPv6. Not only the most widely used OS, Windows(TM) XP, doesn't
support PPPoE with IPv6, but also nearly all CPEs in the market does
not support this function. This problem will be a significant
bottleneck of the development of IPv6 broadband with PPPoE access
method.
6.1. Dual-Stack and L2TP
In this solution, both the CRs and BRASs will be transition to Dual-
stack by upgrading or replacing the existing devices. However, there
are so many different BRASs with diverse IPv6 capability in a large-
scale broadband network. So there is a possibility that some BRASs
cannot upgrade to Dual-stack and support PPPoE with IPv6.
In the Figure 6 below, there are two scenarios in this solution.
o Scenario 1: A Dual-stack or IPv6 terminal accessing to a Dual-
stack BRAS.
o Scenario 2: A Dual-stack or IPv6 terminal accessing to a legacy
IPv4-only BRAS.
+-----------------------------------------+
CR/AR | Dual-Stack |
+-----------------------------------------+
+----------------------+ +----------------+
BRAS | Dual-Stack | | IPv4-only |
+----------------------+ +----------------+
+-----------------------------------------+
CPE | Legacy bridged CPE/upgraded routed CPE |
+-----------------------------------------+
+-------------------+ +----------------+
User End | Dual-Stack/IPv6 | | Dual-Stack/IPv6|
+-------------------+ +----------------+
Scenario1 Scenario2
Figure 6: Dual-stack Transition Solution
The Scenario 1 is very simple. But the routing CPE at the edge of
customer premises network need to be upgraded to support IPv6 and
PPPoE with IPv6. And the PC operation system (OS) also need to
Yang, et al. Expires April 23, 2011 [Page 15]
Internet-Draft Broadband Network Transition October 2010
support PPPoE with IPv6.
The Scenario 2 is a little bit complicated. The BRAS which the
subscriber is connecting to is not support IPv6 and PPPoE with IPv6.
So, one possible solution could be terminating the point-to-point
protocol (PPP) [RFC1661] link at a remote Dual-stack BRAS. A tunnel
technology like Layer Two Tunneling Protocol (L2TP) [RFC2661] can be
used in this scenario. Other technologies could be an alternative.
But considering the device capabilities and the maturity of the
technology, the following discussion will focus on the solution that
Dual-stack network with L2TP to provide Dual-stack services.
[SeeFigure 7]
+----------------------+
CR/AR | Dual-Stack |
+----------------------+
+------------+_________+----------------+
BRAS | Dual-Stack |___L2TP__| IPv4-only |
+------------+ +----------------+
+---------------------------------------+
CPE |Legacy bridged CPE/upgraded routed CPE |
+---------------------------------------+
+----------------+
User End | Dual-Stack/IPv6|
+----------------+
Figure 7: The L2TP Solution in partly Dual-Stack network
Although tunnel technologies can solve this problem, it is considered
as a temporary solution. The legacy IPv4-only BRASs will be replaced
eventually.
For the Dual-stack service, IPv4 address is still need to allocate to
terminal. After the IPv4 addresses exhaustion, Dual-stack BRASs
could allocate private IPv4 addresses for broadband subscribers, and
a NAT44 Large Scale NAT (LSN) [I-D.kuarsingh-lsn-deployment] device
will be deployed to provide IPv4 NAT services for subscribers who are
using private IPv4 addresses.
The operating system (OS) of the new subscriber is recommended to
support PPPoE with IPv6. Third-party dial-up software could be
provided if the OS is not support PPPoE with IPv6.
The routing mode CPE of new subscriber is required to support PPPoE
with IPv6. Otherwise, they are required to turn off the auto-dialup
function, and initial the PPPoE dial-up session from the host that
supports PPPoE with IPv6.
Yang, et al. Expires April 23, 2011 [Page 16]
Internet-Draft Broadband Network Transition October 2010
The legacy subscribers are recommended to upgrade their OSs and CPEs,
but not required. They can still access by IPv4-only. Third-party
dial-up software could also be provided to support PPPoE with IPv6.
The benefits and drawbacks for this solution could be:
Pros:
o L2TP can be a temporary solution to provide Dual-stack services
with fast and incremental deployment. The BRASs that are unable
to upgraded to Dual-stack can be replaced at the end of its
lifecycle.
o When the IPv4 traffic disappears in the future, the network could
be migrated to native IPv6 network gradually.
o There is no need to change the existing access method. Although
many existing routing mode CPEs are not supporting auto-dialup via
PPPoE with IPv6, they can be replaced by existing subscribers
smoothly or waiting for new technologies because the network still
providing IPv4 service. When the IPv6 contents are abundant
enough, legacy subscribers would like to replace or upgrade their
CPEs and OSs to gain more services.
o Although NAT44 technology is needed after the IPv4 address
exhaustion, NAT[RFC3022] is relatively mature compared with IPv4/
IPv6 Translation (e.g. stateful NAT64
[I-D.ietf-behave-v6v4-xlate-stateful], or stateless NAT64
[I-D.xli-behave-ivi]. The major existing applications, such as
Instant Messengers, E-mail Terminals and P2P downloaders are
already supporting NAT traverse. Transitioning with providing
Dual-stack service is much smoother than providing IPv6-only
service, especially at the initial stage of the IPv6 transition.
o There is no extra cost on the network operation and management.
There is still only one physical network in each regional area and
the operation and management team can use the original one, though
some compulsory training is needed.
Cons:
o The requirment is that there is at least one Dual-Stack BRAS in
the network. And if the BRASs that cannnot support Dual-stack is
the majority, when the Dual-stack/IPv6 subscribers grows there
could be many L2TP tunnels across the network and the traffic load
among BRASs is not balanced which may impact the customer
experience. Incremental replacement of the old BRAS should be
considered.
Yang, et al. Expires April 23, 2011 [Page 17]
Internet-Draft Broadband Network Transition October 2010
o Although it is the same issue for any protocol translation
technology, some existing applications which do not consider NAT44
traverse may have some problems after the deployment of NAT44 LSN.
For example, after the deployment of NAT44 LSN, the service of
PPTP VPN has malfunction. Parts of P2P users have worse
experience.
Applicable scenarios: This solution could be suitable for the initial
stage or the intermediate stage of the IPv6 transition when the IPv4
traffic is still very large in the network. And the broadband
network is going to provide Dual-stack services with incremental
deployment. It is also suitable when the number of subscribers is
increasing very fast, and there is a large amount of CPEs and OSs
that do not support PPPoE with IPv6.
6.2. Dual-Stack over IPv6 - DS-lite
In this solution, the CRs in the regional broadband network are Dual-
stack or IPv6-only and the BRASs are IPv6-only. This network is
providing a Dual-stack service or an IPv6-only service for
subscribers. [See Figure 8]
o A Dual-stack or IPv6 terminal accessing to an IPv6-only BRAS.
+----------------------+ +---------------+
CR/AR | Dual-Stack | | new IPv6 |
+----------------------+ +---------------+
AFTR device somewhere
+----------------------------------------+
BRAS | IPv6 |
+----------------------------------------+
+-------------------------+ +------------+
CPE | bridged/upgraded routed | | DS-Lite CPE|
+-------------------------+ +------------+
+---------------------+ +------------+
User End | IPv6 | | DS/IPv6 |
+---------------------+ +------------+
Scenario
Figure 8: The DS-Lite Solution in IPv6 Infrastructure
The Scenario for IPv6-only subscriber accessing a IPv6 BRAS is very
simple. But the routed CPE at the edge of customer premises network
needs upgrade to support IPv6 and PPPoE with IPv6. And the PC
operation system (OS) also needs to support PPPoE with IPv6 with a
Yang, et al. Expires April 23, 2011 [Page 18]
Internet-Draft Broadband Network Transition October 2010
bridged CPE. This scenario will exist when the IPv6 traffic is
already dominant in the network. The little IPv4 traffic will be
translated by a NAT64 device located at the edge of IPv6 Ocean. This
situation is similar to the solution in Section 6.4
The Scenario for Dual-stack subscriber is a little bit complicated.
It provides Dual-stack service over an IPv6-only infrastructure. The
technologies like DS-Lite [I-D.ietf-softwire-dual-stack-lite] can be
deployed in this scenario. This section will focus on this
technology.
DS-Lite is a tunnel technology with a point-to-multipoint IPv4-in-
IPv6 tunnel between B4 element and AFTR. According to the definition
in [I-D.ietf-softwire-dual-stack-lite], the B4 element is a function
implemented on a dual-stack capable node, either a directly connected
device or a CPE, which creates a tunnel to an DS-Lite Address Family
Translation Router (AFTR) deployed somewhere in the regional
broadband network.
The operating system (OS) of the new subscriber is recommended to
support PPPoE with IPv6. Third-party dial-up software could be
provided if the OS is not support PPPoE with IPv6. Subscribers need
to replace the existing CPEs for DS-Lite services.
The pros and cons of the DS-Lite solution will be:
Pros:
o We are assuming a completely IPv6 scenario, it is a one-step
solution of IPv6 transition. The network infrastructure does not
need to upgrade to native IPv6 network in the future.
o AFTR is performing a NAT [RFC3022] behavior, which is relatively
mature compared with IPv4/IPv6 Translation. The major existing
applications, such as Instant Messengers, E-mail Terminals and P2P
downloaders are already supporting NAT traverse. Transitioning
with providing Dual-stack service is much smoother than providing
IPv6-only service, especially at the initial stage of the IPv6
transition.
o The IPv4 address used in DS-lite does not need to planned. It is
easy for operation and management.
Cons:
o DS-Lite solution seems not suitable for the transition of the
existing network that contains thousands of IPv4-only BRASs.
Because the first step should be upgrade the existing BRAS to at
Yang, et al. Expires April 23, 2011 [Page 19]
Internet-Draft Broadband Network Transition October 2010
least Dual-stack. if the BRASs is upgraded to Dual-stack, DS-Lite
does not need any more. Moreover, if the CRs are Dual-stack, and
it is planned to add new BRASs to provide Dual-stack service, the
simplist solution is let the new BRASs to be Dual-stack. So, DS-
Lite solution is only suitable for the new build IPv6 network
scenario.
o DS-lite CPEs are needed to provide to subscribers, and there is no
mature product until now. It may change the original access
method and service provisioning method. And the extra installment
cost is unacceptable when the number of subscribers is huge.
o DS-Lite has not been deployed and verified in any large-scale
commercial trail. In the regional broadband network with a large
number of dual-stack subscribers, a number of DS-Lite AFTR devices
with high performance are needed. The reengineering cost for this
solution may be very high.
Applicable scenarios: This solution is suitable for the scenarios
that providing dual-stack services over an IPv6-only network
infrastructure when IPv6 traffic is already dominant in the network.
It is also suitable when the broadband subscribers are increasing
slowly and the CPEs are provided by operators. Some IPv6-only BRASs
could be added for these new subscribers. It is also suitable for
the new services which may using IPv6-only, for example, IPTV and
Machine-to-machine (M2M) services.
6.3. Dual-Stack over IPv4 - 6rd
In this solution, the CRs in the regional broadband network are IPv4-
only or Dual-stack and the BRASs are IPv4-only. It provides a Dual-
stack service or an IPv6-only service with a completely/partly IPv4
infrastructure for subscribers.
The discussion will focus on scenario in Figure 9.
o An IPv6 or Dual-stack terminal accessing to an IPv4-only BRAS.
Yang, et al. Expires April 23, 2011 [Page 20]
Internet-Draft Broadband Network Transition October 2010
+----------------------------------------+
CR/AR | Dual-Stack/IPv4 |
+----------------------------------------+
6rd border router somewhere
+----------------------------------------+
BRAS | IPv4 |
+----------------------------------------+
+-------------------------+ +------------+
CPE | bridged/upgraded routed | | 6rd CPE |
+-------------------------+ +------------+
+------------+
User End | DS/IPv6 |
+------------+
Figure 9: The 6rd Solution in an IPv4 infrastructure
A possible technical solution for this scenario is IPv6 Rapid
Deployment (6rd) [RFC5969]. There are two components in this
solution. 6rd CPEs support IPv6 on their customer premise side and
support 6rd on the provider side. 6rd gateway (a.k.a 6rd border
router or 6rd relay) is operated at the border between IPv4
infrastructure and the IPv6 Internet. The 6rd mechanism operates
statelessly, which ensures simplicity and scalability. The IPv4
address in the IPv4 infrastructure could be a private address, 6rd
mechanism can support the private IPv4 address.
The pros and cons of the 6rd solution will be:
Pros:
o 6rd solution does not need to upgrade the IPv4 infrastructure. It
can deploy incrementally by adding some 6rd gateways in the
network. Therefore the engineering complexity and cost is low
compared with other solutions.
o Although NAT44 technology is needed after the IPv4 address
exhaustion, NAT[RFC3022] is relatively mature compared with IPv4/
IPv6 Translation. The major existing applications, such as
Instant Messengers, E-mail Terminals and P2P downloaders are
already supporting NAT traverse. Transitioning with providing
Dual-stack service is much smoother than providing IPv6-only
service, especially at the initial stage of the IPv6 transition.
o There is no extra cost on the network operation and management.
There is still only one physical network in each regional area and
the operation and management team can use the original one, though
some compulsory training is needed.
Yang, et al. Expires April 23, 2011 [Page 21]
Internet-Draft Broadband Network Transition October 2010
Cons:
o When the network infrastructure is transitioning to IPv6 in the
future, the access method may need to be changed again. 6rd is not
applicable when the infrastructure is IPv6-only in the future.
When the BRASs are removed by nature, the new BRASs for
replacement will enable IPv6 and the 6rd may be useless.
o 6rd CPE need to be provided to subscribers, which will lead to a
huge amount of devices cost and installment cost. And when the
IPv6 traffic is extremely high, each regional broadband network
may need a number of 6RD border routers to ensure the performance.
Applicable scenarios: This solution may be suitable for the initial
stage of the IPv6 transition, providing IPv6 services with rapid
deployment.
6.4. IPv6 and NAT64
This solution is for the IPv6-only subscribers that are accessing to
the new built IPv6-only regional broadband network. Basically, only
IPv6 address is allocated to the subscribers. And for the
requirement ofaccessing IPv4 applications and contents, it needs to
deploy a IPv6/IPv4 Translation device to solve the intercommunication
problem between IPv6 and IPv4 for the IPv6-only subscribers.
+------++----------+ +------+
Backbone| IPv4 ||Dual-stack| | IPv6 |
+.-----++.------*--+ +--*---+
+--.-------.--+ * * * IPv6 Traffic
| . NAT64 . | * * . IPv4 Traffic
+--*-------*--+---*-------*--+
CR/AR | * IPv6 * |
+----------------------------+
+----------------------------+
BRAS | IPv6 |
+----------------------------+
+------------------------+
User End | IPv6 |
+------------------------+
Figure 10: The NAT64 Solution in an IPv6 infrastructure - Scenario 1
The operating system (OS) is required to support PPPoE with IPv6.
Third-party dial-up software could be provided if the OS of the new
hosts is unable to support PPPoE with IPv6.
Yang, et al. Expires April 23, 2011 [Page 22]
Internet-Draft Broadband Network Transition October 2010
The routing mode CPE that is purchased by subscribers is also
required to support PPPoE with IPv6 as well, or to turn off the auto-
dialup function, and initial the PPPoE with IPv6 dial-up session from
the host.
Pros:
o This solution is usually building a new IPv6 network which could
avoid the risk from changing the existing regional broadband
network.
o Building a completely new network is much easier than upgrade from
the existing one. That is because there is no subscriber with no
traffic on the new network.
o It is no need to allocate IPv4 address for subscribers.
o It is benefit the development of IPv6 and push the IPv6 transition
of ICPs.
Cons:
o All the user terminals including CPEs have to support IPv6 which
is unpractical at the initial stage of IPv6.
o NAT64 mechanisms have not been deployed and verified in large
scale commercial trails. And the NAT64 technologies are still
immature, the users experience with this solution could be worse.
o The requirement of NAT64 device performance is very high,
especially when there is a large amount of subscribers. The
situation could be much worse because the IPv4 traffic is still
the majority at the IPv6 initial stage.
o The cost is huge and the investment is duplicated with the
existing one. The existing network infrastructure is usually kept
up-to-date. Building a new network may lead to an early end of
the lifecycle of the existing network infrastructure, which will
lead to investment loss.
o Building a completely new regional broadband network is usually
along with building a new transmission infrastructure. And the
engineering period will be very long.
o After the new network is built, there are two networks in the same
area, which will lead an extra operational cost.
Applicable scenarios: This solution is suitable for the last-step of
Yang, et al. Expires April 23, 2011 [Page 23]
Internet-Draft Broadband Network Transition October 2010
the IPv6 transition. The IPv6 contents and services are already very
popular and abundant. Besides, IPv6/IPv4 Translation technology is
relatively mature and the IPv4 traffic is little. In this case, we
can disable the IPv4 protocol stack of the Dual-stack devices, and
NAT64 devices can also be deployed at several sites to meet the
requirement of IPv6-only users who are visiting the historical IPv4
services.
7. Backwards Compatibility
8. Conclusions
TBD...
9. Acknowledgements
The authors would like to acknowledge the discussions on this topic
with Dave Thaler, Denis Alexeitsev, Jari Arkko, R"|mi Despr"|s, Tina
TSOU, Tom Taylor and Tony Li.
10. IANA Considerations
This memo includes no request to IANA.
11. Security Considerations
The IETF is specifying security considerations for the solutions that
it is providing for IPv6 migration. However, it is possible that
additional considerations arise due to the interoperation of these
solutions, and the fact that the network is in a transitional state.
12. References
12.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.
Yang, et al. Expires April 23, 2011 [Page 24]
Internet-Draft Broadband Network Transition October 2010
12.2. Informative References
[I-D.huang-v6ops-v4v6tran-bb-usecase]
Huang, C., Li, X., and L. Hu, "Use Case For IPv6
Transition For a Large-Scale Broadband network",
draft-huang-v6ops-v4v6tran-bb-usecase-00 (work in
progress), September 2010.
[I-D.ietf-behave-v6v4-xlate-stateful]
Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful
NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers",
draft-ietf-behave-v6v4-xlate-stateful-12 (work in
progress), July 2010.
[I-D.ietf-softwire-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-06 (work
in progress), August 2010.
[I-D.kuarsingh-lsn-deployment]
Kuarsingh, V. and J. Cianfarani, "NAT44/LSN Deployment
Options and Experiences",
draft-kuarsingh-lsn-deployment-00 (work in progress),
July 2010.
[I-D.xli-behave-ivi]
Li, X., Bao, C., Chen, M., Zhang, H., and J. Wu, "The
CERNET IVI Translation Design and Deployment for the IPv4/
IPv6 Coexistence and Transition", draft-xli-behave-ivi-07
(work in progress), January 2010.
[I-D.zhou-softwire-ds-lite-p2p]
Zhou, C., ZOU), T., Lee, Y., and G. Yang, "Deployment DS-
lite in Point-to-Point Access Network",
draft-zhou-softwire-ds-lite-p2p-02 (work in progress),
July 2010.
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
RFC 1661, July 1994.
[RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D.,
and R. Wheeler, "A Method for Transmitting PPP Over
Ethernet (PPPoE)", RFC 2516, February 1999.
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999.
Yang, et al. Expires April 23, 2011 [Page 25]
Internet-Draft Broadband Network Transition October 2010
[RFC2637] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little,
W., and G. Zorn, "Point-to-Point Tunneling Protocol",
RFC 2637, July 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.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001.
[RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in
BGP-4", RFC 3107, May 2001.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version
3", RFC 3376, October 2002.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552,
July 2003.
[RFC3697] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering,
"IPv6 Flow Label Specification", RFC 3697, March 2004.
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC4798] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur,
"Connecting IPv6 Islands over IPv4 MPLS Using IPv6
Provider Edge Routers (6PE)", RFC 4798, February 2007.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4
Infrastructures (6rd) -- Protocol Specification",
RFC 5969, August 2010.
Yang, et al. Expires April 23, 2011 [Page 26]
Internet-Draft Broadband Network Transition October 2010
Authors' Addresses
GuoLiang Yang (editor)
China Telecom
109, Zhongshan Ave. West,
Guangzhou, Tianhe District 510630
P.R. China
Phone:
Email: yanggl@gsta.com
LeMing Hu
China Telecom
109, Zhongshan Ave. West,
Guangzhou, Tianhe District 510630
P.R. China
Phone:
Email: hulm@gsta.com
JinYan Lin
China Telecom
109, Zhongshan Ave. West,
Guangzhou, Tianhe District 510630
P.R. China
Phone:
Email: jasonlin.gz@gmail.com
Yang, et al. Expires April 23, 2011 [Page 27]