One document matched: draft-yang-v6ops-v4v6tran-bb-transition-guide-00.txt
Internet Engineering Task Force G. Yang, Ed.
Internet-Draft L. Hu
Intended status: Informational J. Lin
Expires: April 1, 2011 China Telecom
September 28, 2010
IPv6 Transition Guide For A Large-scale Broadband Network
draft-yang-v6ops-v4v6tran-bb-transition-guide-00
Abstract
This document discusses about different IPv6 migrating solutions for
each part of the Large-scale broadband infrastructure with layer 2
access network. They are based on the requirements of providing
existing broadband services in v4v6-coexisting or IPv6-only
situations. 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 1, 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 1, 2011 [Page 1]
Internet-Draft Broadband Network Transition September 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 . . . . . . . . . . . . . . . . . . 6
2. Overview of Solutions . . . . . . . . . . . . . . . . . . . . 6
2.1. Transition For the Backbone Network . . . . . . . . . . . 7
2.1.1. Transition to Dual-stack on existing IP Backbone . . . 7
2.1.2. Building A New Native IPv6-Only Backbone Network . . . 8
2.1.3. Deploy 6PE On Existing MPLS Backbone . . . . . . . . . 8
2.2. Transition of Metro IP Network . . . . . . . . . . . . . . 9
2.2.1. Solution 1 . . . . . . . . . . . . . . . . . . . . . . 10
2.2.2. Solution 2 . . . . . . . . . . . . . . . . . . . . . . 11
2.2.3. Solution 3 . . . . . . . . . . . . . . . . . . . . . . 12
2.2.4. Solution 4 . . . . . . . . . . . . . . . . . . . . . . 13
2.3. Transition Of Layer 2 Access network . . . . . . . . . . . 14
2.3.1. Solution 1 . . . . . . . . . . . . . . . . . . . . . . 14
2.3.2. Solution 2 . . . . . . . . . . . . . . . . . . . . . . 15
2.3.3. Solution 3 . . . . . . . . . . . . . . . . . . . . . . 15
3. Subscriber Access Mode in IPv6 Transition . . . . . . . . . . 16
3.1. Solution 1 . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2. Solution 2 . . . . . . . . . . . . . . . . . . . . . . . . 17
3.3. Solution 3 . . . . . . . . . . . . . . . . . . . . . . . . 18
3.4. Solution 4 . . . . . . . . . . . . . . . . . . . . . . . . 19
4. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 20
5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 20
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
8. Security Considerations . . . . . . . . . . . . . . . . . . . 20
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
9.1. Normative References . . . . . . . . . . . . . . . . . . . 20
9.2. Informative References . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
Yang, et al. Expires April 1, 2011 [Page 2]
Internet-Draft Broadband Network Transition September 2010
1. Introduction
As we known, the broadband subscriber is one of the largest parts of
the Internet participant. It is a significant issue 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 infrastructure with Layer 2 access network. And it will
focus on the cases that the network infrastructure is large and
widely covered, and the new subscriber!_s number 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 the development of broadband services.
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 provided are few and far between on Internet. In
addition, most of the broadband terminals, including PCs and CPEs,
will still be IPv4-only. Even if most PC Operating System declared
that they already supported IPv6, there is still a very serious
problem on supporting PPPoE with IPv6. Until now, PPPoE is the most
widely used access method in layer 2 access network, though some
access the broadband network via IPoE. Most users dial-up via PPPoE
on PC, but some deployed a Home Gateway by themselves and set up an
automatically dial-up from it. Not only the most widely used PC
operating system, Windows(TM) XP, but also nearly all CPEs in the
market, does not support PPPoE in IPv6 environment, which will be a
significant bottleneck of the development of IPv6 broadband with this
kind of network architecture.
During the IPv6 transition, large-scale broadband network basically
would like to be taken a smooth transition of the existing network
infrastructure and Internet content services because of the inactive
IPv6 industrial chain. For example, the first rule to the IPv6
transition 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.
During the network and service transition to IPv6, the technologies
and solutions should be compatible with the existing access mode
(PPPoE) and broadband service provisioning method (not providing
Yang, et al. Expires April 1, 2011 [Page 3]
Internet-Draft Broadband Network Transition September 2010
CPE).
It is difficult to find a suitable completely solution for the
transition of large-scale broadband network considering its specific
features. The combination of one or more existing transition
technologies could be the best practices to guarantee the smooth
transition and good performance corresponding to different scenarios.
How to figure out the appropriate technologies combination to fit
each network scenario is the focus of this document.
In general, IP backbone and MPLS backbone are two major types of
backbone network in the large scale broadband network.
Yang, et al. Expires April 1, 2011 [Page 4]
Internet-Draft Broadband Network Transition September 2010
+============================================================+
| +----------------+ +---------------------------+ |
| Internet | IPv4 Internet | | IPv6 Internet | |
| +----------------+ +---------------------------+ |
+============================================================+
+============================================================+
| ISP's Network |
| +--------------------------+ +---------------------------+ |
| | IP backbone | | MPLS backbone | |
| +--------------------------+ +---------------------------+ |
+------------------------------------------------------------+
+------------------------------------------------------------+
| Regional Broadband Network |
| +--------------------------------------------------------+ |
| | Metro Core Router | |
| | +-----------------------------+ |
| | | +---------------------------+ |
| | | | Aggregation Router | |
| +--------------------------+ +---------------------------+ |
| +----------------------------------+ +-------------------+ |
| | BRAS | | Service Router | |
| +----------------------------------+ +-------------------+ |
+============================================================+
+============================================================+
| Access Netrwork (Layer 2) |
| +--------------------------------------------------------+ |
| | Aggregation Switch | |
| +--------------------------------------------------------+ |
| +--------------------------+ +---------------------------+ |
| | OLT | | DSLAM | |
| +--------------------------+ +---------------------------+ |
+============================================================+
+============================================================+
| Customer Premises Network |
| +--------------------------+ +---------------------------+ |
| | Routing Mode CPE | | Bridging Mode CPE | |
| +--------------------------+ +---------------------------+ |
| +--------------------------------------------------------+ |
| | User End | |
| +--------------------------------------------------------+ |
+============================================================+
Figure 1: Typical Large-scale Broadband Network Architecture
The network architecture of a large-scale broadband network with L2
access network is shown in Figure 1. In the ISP!_s backbone, Metro
Core Router (CR) is connected to both IP backbone and MPLS backbones.
Yang, et al. Expires April 1, 2011 [Page 5]
Internet-Draft Broadband Network Transition September 2010
BRAS (Broadband Remote Access Server) acts as the aggregation point
for the subscriber traffic. It provides aggregation capabilities
between the L2 Access Network and the ISP!_s Backbone. Beyond
aggregation, it is also the injection point for access
authentication, policy management and IP QoS.
In most situations, 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. CR, SR and BRAS need to be sensitive to IP
protocols. Between BRAS and the edge of customer premises network,
the L2 Access Network, is not sensitive to IP protocols in theory.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
2. Overview of Solutions
In this section, it is described the overview of solutions for IPv6
Migration mentioned in the Use Case for Large-Scale Broadband
Network. [I-D.huang-v6ops-v4v6tran-bb-usecase] 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;
o Large number of network devices and their different capabilities
of supporting IPv6;
o Various types of the Internet services with different IPv6
capabilities and they will not migrated to IPv6 synchronized.
During the IPv6 transition, the user experience should be guaranteed.
It is important to take the terminals!_ problems into consideration.
Moreover, in order to migrate both of network infrastructures and
Internet services smoothly, it is significant to select the proper
technologies at each point of time on the IPv6 roadmap according to
different network environment.
This section analyzes related transition technologies and transition
roadmap regarding the network scenarios in the use case from the
following aspects:
Yang, et al. Expires April 1, 2011 [Page 6]
Internet-Draft Broadband Network Transition September 2010
o Compatible with existing services (access mode and existing
Internet service).
o Keep the high growth rate of the number of broadband subscribers.
o Guarantee the user experience in the transition procedure.
o Guarantee the existing network investment and avoid the duplicated
implementation.
2.1. Transition For the Backbone Network
Basically, there are three main ways for the transition of backbone
network: dual-stack on existing IP backbone, 6PE on MPLS backbone and
new IPv6-only IP backbone.
2.1.1. Transition to Dual-stack on existing IP Backbone
This approach requires enable IPv6 capability on the existing IP
Backbone routers in order to support both IPv4 and IPv6 related
protocols. Until now, the routers that supported dual-stack will
usually route IPv4 and IPv6 traffic separately based on the IPv4
routing table and the IPv6 one respectively.
Pros: Compatible with existing IPv4 traffic and new IPv6 traffic.
o The existing network devices have high capability to this. To
support IPv6, it only needs to make some configurations or, in
some cases, to upgrade the software version to support a better
performance. The cost of such kind of upgrades is low compared to
other approaches.
o It is helpful for the smooth transition.
Cons: Because the high volume of network traffic on the backbone and
each router has various capabilities, there is still a high risk to
upgrade all the routers to dual-stack without careful considerations.
o Impact to existing services: When dual-stack is enabled on the
routers, any problem may have considerable impact to the existing
services due to the large IP network traffic. And these impacts
could be difficult to be predicted and avoided.
o Impact to existing network: The existing network devices usually
have capability to dual-stack. But it is still a challenge for
the performance and stability, for example, the size of routing
table, routing lookup/forwarding capability and routing
convergence capability due to the sharing of resources.
Yang, et al. Expires April 1, 2011 [Page 7]
Internet-Draft Broadband Network Transition September 2010
o The reengineering of network takes much more workload than the 6PE
approach, which will be introduced below, because it is not only
make changes to edge devices, but also all of the core devices.
Applicable scenarios: Dual stack backbone network is applicable to
the phase when IPv6 traffic is relatively large. And the dual stack
capability, performance, and stability of the network device are
reasonable high enough in dual-stack backbone network.
2.1.2. Building A New Native IPv6-Only Backbone Network
The routers in a new backbone enables IPv6 protocol stack only.
There is only IPv6 routing in the router which does not carry IPv4
traffic.
Pros: In line with the future network transition and enables IPv6
protocol stack only:
o Nearly with no impact to the existing network and services
o Easy to maintain a single IPv6-only network separated from the
existing one.
Cons:
o The cost of rebuilding a new backbone network is considerable high
and the engineering cycle could be very long.
o It is difficult to support the network by the small number of
IPv6-only services and subscribers, because there is small
business driven at the IPv6 initial stage.
o The lifecycle of the Return over Investment (ROI) could also be
very long. Such kind of considerations cannot be avoidable for
any kind of commercial services, no matter for network providers,
content providers or devices vendors.
Applicable scenarios: In the last phase of IPv6 transition, most of
the CP/SP services are IPv6. Native IPv6 backbone network can be
upgraded from a dual-stack already backbone, or by creating a new
IPv6 backbone.
2.1.3. Deploy 6PE On Existing MPLS Backbone
The IPv6 routing information is marked with MPLS labels through IBGP
and is distributed into IPv4/MPLS backbone network. The
communication of IPv6 is achieved by the LSP among PEs. Implementing
both of IPv4 and IPv6 at the PE router connecting to IPv6 networks,
Yang, et al. Expires April 1, 2011 [Page 8]
Internet-Draft Broadband Network Transition September 2010
the original IPv4/MPLS network in the backbone network could be
adopted to provide access capability for the distributed IPv6-only
user.
Pros: Only the PE routers connecting to IPv6 networks need to be
implemented dual-stack and make some corresponding configurations.
The existing IPv4 MPLS network is highly utilized to carry IPv6
traffic. The reengineering cost and risk of this kind of changes is
comparable low.
o Little impact on the existing network: Quick deployment and small
modification to the network. There is no need to make changes on
core routers, and only PE routers to be modified as needed.
o Little impact to the existing services: There is little impact to
the existing services in the initial stage of IPv6 deployment.
o Supporting incremental deployment, the time for implementation is
short.
Cons:
o This approach changes the original purpose of the MPLS network.
MPLS network is normally used to carry VPN traffic and the network
is light load. 6PE is enabled to carry public traffic. When the
public traffic grows, there may be impact to the existing
services.
o Unable to deploy QoS policy for IPv6 traffic.
o Change the networking principle.
Applicable scenarios: It could be applicable in IPv6 initial stage
while the most traffic is still IPv4 in the backbone. The backbone
network could provide IPv6 traffic carrying with less deployment
time.
2.2. Transition of Metro IP Network
According to Figure 1, the typical Metro Network in the broadband
architecture is comprised of three kinds of elements:
o CR: The Core Router is usually the egress router of the metro
network and connected to BRASs or SRs for both users!_ and CPs!_
access.
o BRAS: BRAS is the aggregation point for the subscriber traffic.
It provides aggregation capabilities between the Access Network
Yang, et al. Expires April 1, 2011 [Page 9]
Internet-Draft Broadband Network Transition September 2010
and the Metro Network. Beyond aggregation, it is also the
injection point for access authentication, policy management and
IP QoS.
o SR: Service Router is basically the access nodes for different
services.
o AR: A small portion of the BRASs in some large metro networks may
connect to a Aggregation Router. And the AR is usually connected
to the CRs.
The network is transition to dual-stack from the existing network.
2.2.1. Solution 1
In this solution, CRs and ARs will be transition to dual-stack while
the new BRAS will implement dual-stack. Besides, the existing BRASs
could be upraded with the solution as follows:
o The existing BRAS will upgrade to dual-stack if it is able to do
so.
o For the BRAS that is unable to upgrade to dual-stack, it can
redirect the dual-stack subscribers to another dual-stack BRAS,
and the PPP links of the dual-stack subscribers will be terminated
on that dual-stack BRAS.GBP"e.g. L2TPGBP(C)
After the IPv4 addresses exhaustion, new BRASs could allocate private
IPv4 addresses for broadband subscribers, and a NAT44 CGN will be
deployed to provide IPv4 NAT services for subscribers who use private
IPv4 addresses.
The IPv6 services can be provided by this approach while providing
IPv4 services with private IPv4 addresses.
Pros:
o It is easy for incremental deployment. And the cost for this
solution is comparable low. Besides, the network operation and
management will also be simple.
o IPv6 could be introduced as soon as possible.
o The technology of NAT44 is relatively mature. The major existing
applications, such as MSN, Skype and QQ, are already supporting
NAT traverse very well.
Yang, et al. Expires April 1, 2011 [Page 10]
Internet-Draft Broadband Network Transition September 2010
o The existing access method does not need to be changed, so it is
no need to replace the CPEs for subscribers.
o The point of time when the IPv6 related industrial chain being
active could be later than that of the IPv6 transition of the
network infrastructures. Under such situation, the users
experience with this solution could be better. The reason may be
the immature NAT64 technologies.
o When the IPv4 traffic disappears in the future, the network could
be migrated to native IPv6 network gradually.
Cons:
o Some existing applications which do not consider NAT44 traverse
may have some problems after the deployment of NAT44 CGN. For
example, after the deployment of NAT44 CGN, the service of PPTP
VPN has malfunction. Parts of P2P users may have worse
experience.
Applicable scenarios: After IPv6 is introduced and before the traffic
of IPv4 disappears.
2.2.2. Solution 2
The existing network is upgraded to dual-stack, and the new BRASs
support IPv6-only, not the dual-stack.
In this solution, CR will be updated to dual-stack, and some AR which
may be deployed in large scale metro network will be updated to dual
stack, too. The update solution for BRASs is as followed:
o The existing BRASs which support to be transition to dual-stack
will be transition to dual-stack.
o For the BRAS that is unable to upgrade to dual-stack, it can
redirect the dual-stack subscribers to another dual-stack BRAS,
and the PPP links of the dual-stack subscribers will be terminated
on that dual-stack BRAS.GBP"e.g. L2TPGBP(C)
o The newly added BRASs will implement IPv6 only. The users who
connect to an IPv6 only BRAS will adopt DS-Lite mechanism to get
IPv4 access.
o As time goes, those BRASs which could not be upgraded to dual-
stack will be eliminated from the network gradually.
Pros:
Yang, et al. Expires April 1, 2011 [Page 11]
Internet-Draft Broadband Network Transition September 2010
o The technology of NAT44 is relatively mature. The major existing
applications, such as MSN, Skype and QQ, are already supporting
NAT traverse very well.
o The access method for existing subscribers does not need to be
changed, so providers does not need to provide home gateway to
existing users.
o The point of time when the IPv6 related industrial chain being
active could be later than that of the IPv6 transition of the
network infrastructures. Under such situation, the users
experience with this solution could be better. The reason may be
the immature NAT64 technologies.
o When the IPv4 traffic disappears in the future, the network could
be migrated to native IPv6 network gradually.
Cons:
o Some existing applications which do not consider NAT44 traverse
may have some problems after the deployment of NAT44 CGN. For
example, after the deployment of NAT44 CGN, the service of PPTP
VPN has malfunction. Parts of P2P users may have worse
experience.
o Home gateway could be needed to provide to users when DS-Lite is
deployed. It will draw a great amount of operational cost for the
devices replacement based on the great number of subscribers.
o In the case of both BRAS and the user are IPv6-only, other
technology like NAT64 or IVI is needed to be implemented for the
transitioning problems.
Applicable scenarios: This solution could be suitable for the
intermediate stage of the IPv6 transition. After IPv6 is introduced
and before the traffic of IPv4 disappears.
2.2.3. Solution 3
This solution is to build a new completely dual-stack metro network.
The existing network does not need to be changed, while the new
network could be mainly providing IPv6 services for users.
Pros:
o The risk due to changes of the existing metro network is low.
Yang, et al. Expires April 1, 2011 [Page 12]
Internet-Draft Broadband Network Transition September 2010
o It is much easier to build up a completely new metro network than
to upgrade the existing one.
Cons:
o The cost is huge and the investment is duplicated with the
existing one.
o Cost/income ratio is considerable low when the quantity of new
users in new network is small.
o The IPv6 transition of existing subscribers requires a large
amount of switchovers from the old network to the new one.
Applicable scenarios: (1) The existing metro network is difficult to
be upgraded. (2)In the case of fast increasing rate of broadband
subscribers and traffic, the existing metro network could be
insufficient, which may lead to the network expanding. If the
traffic in the extension network is large enough, building up a new
metro network could be a better idea.
2.2.4. Solution 4
This solution is to build up a new native IPv6 network. The existing
network does not need to be changed, while the new network is used to
provide IPv6 services for subscribers.
Some components, such as NAT64 device or DS-Lite CGN, will be
deployed in the existing metro network, in order to provide IPv4
services for the users connected to new metro network.
Pros:
o This solution could avoid the risk and difficulty from the changes
of the existing metro network.
Cons:
o The cost is huge and the investment is duplicated with the
existing one.
o Cost/income ratio is considerable low when the quantity of new
users in new network is small.
o Some transition technologies may be deployed to solve the
intercommunication problem between IPv6 and IPv4 for the IPv6-only
subscribers.
Yang, et al. Expires April 1, 2011 [Page 13]
Internet-Draft Broadband Network Transition September 2010
Applicable scenarios: This solution may be suitable for the situation
that the IPv6 traffic is large enough.
2.3. Transition Of Layer 2 Access network
Most of the broadband access networks are layer 2 networks in this
use case. It is defined that the access network is from BRAS, the IP
network edge, to the CPE at the edge of Customer Premises Network.
Basically, a layer 2 network device is IP layer protocol unaware when
PPPoE is used for broadband access. However, the IPv6 capability is
compulsory due to some security policies implemented on the access
network devices (e.g. IP-Based ACLs). On the other hand, some
future services (e.g. IPTV or M2M) may access the network via IPoE.
Therefore, the layer 2 network for these kinds of services may also
need to support IPv6 aware.
2.3.1. Solution 1
This solution is transitioning based on the existing network. In the
access network, the new devices will be IPv6 aware while the existing
devices will keep unchanged. But according to their lifecycle,
historical devices will be gradually removed from the existing
network. Thereby the whole layer 2 network will be IPv6 aware
finally.
Pros:
o The network transition will be simple and cost-effective, only
required new devices in the access network to be IPv6 aware.
o The network maintenance and management will be comparable simple;
o In a short term, since the access method of the existing services
will not be changed, the layer 2 network won't be required to be
transition. Since new devices will be IPv6 aware and existing
devices which are IPv6 unaware will be removed from the network as
time goes by, a smooth evolution without investment increase will
be reached.
Cons:
o This solution cannot meet the short-term requirements for some
services (e.g. IPoE)that require a IPv6 aware layer 2 network.
Applicable scenarios: This solution is suitable for the initial stage
of the IPv6 transition.
Yang, et al. Expires April 1, 2011 [Page 14]
Internet-Draft Broadband Network Transition September 2010
2.3.2. Solution 2
This solution is transitioning based on the existing network. In the
access network, the new devices will be IPv6 aware while the existing
devices will also upgraded or replaced. Thereby the whole layer 2
network will be IPv6 aware.
Pros:
o This solution can meet both the current and the future
requirements. The network will not need to be reengineering again
to support new services that require IPv6 aware on access network.
Cons:
o The access network transition is difficult with great amount of
workload due to the subscribers scale. And the cost of the
reengineering of access network is also expensive.
Applicable scenarios: When new services or new service providing
manners that require the layer 2 network to be IPv6 aware are about
to emerge.
2.3.3. Solution 3
This solution will build up a new layer 2 access network which is
IPv6 aware. On the other hand, it keeps the existing access network
unchanged or upgrading or evolving gradually. IPv6 aware services
will be provided only to the subscribers who connect to the new layer
2 network.
Pros:
o This solution could avoide the risk and difficulty from the
changes of the existing metro network.
Cons:
o The cost is huge and the investment is duplicated with the
existing one.
o Cost/income ratio is considerable low when the quantity of new
users in new network is small.
Applicable scenarios: When services and service providing manners
keep unchanged in the existing layer 2 network and meanwhile new
services or new service providing manners that require the layer 2
network to be IPv6 aware are about to emerge.
Yang, et al. Expires April 1, 2011 [Page 15]
Internet-Draft Broadband Network Transition September 2010
3. Subscriber Access Mode in IPv6 Transition
In the network and service transition to IPv6, the technologies and
solutions selected have to be compatible with the existing access
mode (PPPoE) and broadband service provisioning method. The
following factors should be considered:
o As the most widely used broadband access method, users dial-up via
PPPoE and are authenticated at a centralized AAA System.
o The CPE, including two kinds of mode, is usually provided by
subscribers themselves.
o Many broadband users dial-up via PPPoE on PC which connected to a
bridged-mode CPE. However, some broadband users deployed a Home
Gateway (e.g. WLAN AP) at home and make an automatically dial-up
from it. And some other subscribers deployed a routing-mode CPE
to share the broadband service with different hosts.
3.1. Solution 1
In this solution, the host is accessed with dual-stack mode,
acquiring both IPv4 and IPv6 addresses from dual-stack BRAS.
There are thousands of BRAS all over the typical large scale
broadband network. So, it is very difficult to ensure the dual-stack
capability for all these BRASs. For this circumstance, L2TP could be
used to initial a tunnel from the IPv4-only BRAS to a dual-stack one.
And the PPP connection initialed by PC or CPE would be terminated at
the dual-stack BRAS.
Pros:
o There is no need to change the existing access mode, and the Home
Gateways do not need to be replaced.
o NAT64 can be avoided and the user experience can be guaranteed.
o After IPv4 address exhaust, most existing users are still using
public IPv4 addresses. The new users may have to use private IPv4
addresses for the IPv4 services. NAT44 is relatively mature, and
the mainstream services, e.g., MSN, Skype can support NAT44 well.
Therefore, the user experience could be guaranteed.
o After the IPv4 traffic disappears, the network can migrate to
Native IPv6 smoothly.
Cons:
Yang, et al. Expires April 1, 2011 [Page 16]
Internet-Draft Broadband Network Transition September 2010
o Some applications not considering NAT-traversal issue may have
problem when deploying a NAT44 CGN. For example, PPTP VPN may
have service failure after deploying NAT44 CGN; Some Peer-to-Peer
applications may have worse experience.
Applicable scenarios: corresponds to the dual-stack metro network
scenario.
3.2. Solution 2
In this solution, the user-end host with dual-stack enabled connected
to an IPv6-only BRAS. The host will be allocated an IPv4 address and
an IPv6 address by a remote dual-stack BRAS. A L2TP tunnel is used
from the IPv6-only BRAS to the remote dual-stack BRAS.
Alternatively, DS-Lite CGNs and DS-Lite CPEs could be deployed to
provide dual-stack services with a native IPv6 access network for
subscribers.
Pros:
o BRAS is IPv6-only, which will benefit the IPv6 development.
o NAT44 is relatively mature, and the mainstream services, e.g.,
MSN, Skype can support NAT44 well. Therefore, the user experience
could be guaranteed.
Cons:
o The replacement of all the CPEs for great amount of subscribers
seems to be an impossible mission for a large scale broadband
network, not only because the distribution of subscribers is
scattered over a large area but also as the high costs for this
solution is unacceptable.
o DS-Lite has not been deployed and verified in any large scale
commercial trail.
o After the private IPv4 address is used, all the IPv4 services with
private address have to go through the NAT44 device. Some
applications not considering NAT-traversal issue may have problem
when deploying a NAT44 CGN.
o In the metro network with a large number of dual-stack
subscribers, a number of DS-Lite CGN devices with high performance
is needed. The reengineering cost for this solution may be very
high.
Yang, et al. Expires April 1, 2011 [Page 17]
Internet-Draft Broadband Network Transition September 2010
o Considering the scenarios introduced in the use case for large
scale broadband network[I-D.IETF-huang-v4v6tran-broadband-
usecase], CRs in metro network have to be upgraded to dual-stack
for providing dual-stack broadband service on existing metro
network, though the BRAS could be IPv6-only. Moreover, the metro
network could be more complexity due to the DS-Lite CGN!_s
deployment.
Applicable scenarios: This subscriber access mode is suitable for the
scenarios that the metro network is with dual-stack CRs and providing
IPv6-only BRASs for dual-stack users. Users!_ hosts can be dual-
stack or is accessing by DS-Lite CPEs.
3.3. Solution 3
In this solution, the user-end host with dual-stack enabled connected
to an IPv4-only BRAS. The IPv4 address is allocated from the IPv4-
only BRAS, while 6RD Gateway is deployed in the metro network for
IPv6 services. The 6RD CPE for subscribers is needed. The IPv6
packet is de-capsulated at the 6RD Gateway. NAT44 CGN could be also
deployed in the metro network if the IPv4 addressed which allocated
by BRAS is a private IPv4 address.
Pros:
o There is no need to upgrade the thousands of BRASs in a large
scale broadband network.
o NAT44 is relatively mature, and the mainstream services, e.g.,
MSN, Skype can support NAT44 well. Therefore, the user experience
could be guaranteed.
Cons:
o The compatible issue with the existing access mode need to be
solved. As the termination of the PPPoE link, the BRAS is also
need to be upgraded to support 6RD.
o Need to provide Home Gateway to the users (or the user is
unwilling to use IPv6 access due to the more investment on the
Home Gateway). The cost of implementation is high.
o The network should be reengineering and upgraded when the network
migrates to IPv6-only in the future which may lead to repeated
investment on the transition.
o When the IPv6 traffic is extremely high, each metro network may
need a number of 6RD Gateways to meet the IPv6 user requirement.
Yang, et al. Expires April 1, 2011 [Page 18]
Internet-Draft Broadband Network Transition September 2010
o After the private IPv4 address is used, all the IPv4 services with
private address have to go through the NAT44 device. Some
applications not considering NAT-traversal issue may have problem
when deploying a NAT44 CGN.
Applicable scenarios: This solution is suitable for the initial stage
of the IPv6 transition when the IPv4 traffic is still dominant in the
network.
3.4. Solution 4
In this solution, the user-end host with IPv6-only enabled is
connected to an IPv6-only BRAS. It is required that the BRASs are
upgraded to IPv6-only and the users!_ terminals are also upgraded to
support IPv6. Only IPv6 address is allocated to the users. For the
requirement of visiting IPv4 services, it is needed to deploy a NAT64
(stateful/IVI) device.
This solution can provide IPv6 services and also solve the problem of
IPv4 address shortage due to the high-speed growth of broadband
users.
Pros:
o It is no need to allocate IPv4 address for the users.
o 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 The point of time when the IPv6 related industrial chain being
active could be later than that of the IPv6 transition of the
network infrastructures. Under such situation, the users
experience with this solution could be worse. The reason may be
the immature NAT64 technologies.
o Stateful NAT64 and IVI/DIVI have not been deployed and verified in
large scale commercial trails. DNS64 accompanied with NAT64/IVI
has not been verified as well.
o The performance requirement of the NAT device deploying in a metro
network with large amount of subscribers is considerable high.
The situation could be much worse because the IPv4 traffic is
still the majority at the IPv6 initial stage.
Yang, et al. Expires April 1, 2011 [Page 19]
Internet-Draft Broadband Network Transition September 2010
Applicable scenarios: This solution is suitable in case of most ICPs
and terminals have been supporting IPv6 already. Besides, NAT64/IVI
technology is relatively mature and the IPv4 traffic is little. In
this case, IPv4 protocol stack of the dual-stack devices could be
disabled, and NAT64 devices could also be deployed at several sites
to meet the requirement of IPv6-only users who are visiting the
historical IPv4 services.
4. Backwards Compatibility
5. Conclusions
TBD...
6. Acknowledgements
7. IANA Considerations
This memo includes no request to IANA.
8. 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.
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
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Yang, et al. Expires April 1, 2011 [Page 20]
Internet-Draft Broadband Network Transition September 2010
Text on Security Considerations", BCP 72, RFC 3552,
July 2003.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
Authors' Addresses
GuoLiang Yang (editor)
China Telecom
109, Zhongshan Ave. Wast,
Guangzhou, Tianhe District 510630
P.R. China
Phone:
Email: yanggl@gsta.com
LeMing Hu
China Telecom
109, Zhongshan Ave. Wast,
Guangzhou, Tianhe District 510630
P.R. China
Phone:
Email: hulm@gsta.com
JinYan Lin
China Telecom
109, Zhongshan Ave. Wast,
Guangzhou, Tianhe District 510630
P.R. China
Phone:
Email: jasonlin.gz@gmail.com
Yang, et al. Expires April 1, 2011 [Page 21]
| PAFTECH AB 2003-2026 | 2026-04-24 01:16:45 |