Internet Engineering Task Force C. Huang, Ed.
Internet-Draft X. Li
Intended status: Informational L. Hu
Expires: April 23, 2011 China Telecom
October 20, 2010
Use Case For IPv6 Transition For a Large-Scale Broadband network
draft-huang-v6ops-v4v6tran-bb-usecase-01
Abstract
This document describes a use case for the migration from IPv4 to
IPv6 for one of the typical broadband networks. The contant is
orgnized by various scenarios we can foresee during the migration.
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
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.
Huang, et al. Expires April 23, 2011 [Page 1]
Internet-Draft Broadband Network Use Case October 2010
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 6
2. Backbone Network Migration . . . . . . . . . . . . . . . . . . 6
2.1. Solution 1: 6PE in the MPLS Network . . . . . . . . . . . 6
2.2. Solution 2: Dual-stack IP Backbone . . . . . . . . . . . . 6
2.3. Solution 3: IPv6-Only Backbone . . . . . . . . . . . . . . 6
2.4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Regional IP Network migration . . . . . . . . . . . . . . . . 7
3.1. Solution1:Dual-Stack and L2TP . . . . . . . . . . . . . . 9
3.2. Solution2: Dual-Stack over IPv6 - DS-lite . . . . . . . . 11
3.2.1. The Location of AFTR . . . . . . . . . . . . . . . . . 13
3.3. Solution3: Dual-Stack over IPv4 - 6rd . . . . . . . . . . 15
3.3.1. The Location of 6rd Gateway . . . . . . . . . . . . . 16
3.4. Solution4: IPv6 and protocol translation . . . . . . . . . 17
4. Terminal migration . . . . . . . . . . . . . . . . . . . . . . 18
5. ICP migration . . . . . . . . . . . . . . . . . . . . . . . . 19
6. Challenges Faced In Migrating To IPv6 . . . . . . . . . . . . 19
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
8. Security Considerations . . . . . . . . . . . . . . . . . . . 20
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
9.1. Normative References . . . . . . . . . . . . . . . . . . . 21
9.2. Informative References . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
Huang, et al. Expires April 23, 2011 [Page 2]
Internet-Draft Broadband Network Use Case October 2010
1. Introduction
The situations of IPv6 transition for developing countries are
different from the developed countries. The developed
countries,which is the originate place of Internet, hold the majority
part of IPv4 address space. However, according to the considerably
high growth speed of the potential subscribers in the developing
countries due to the large base number of users and booming
economies, e.g. China, Brazil and India, the small IPv4 address
space do put these developing countries under great pressure.
Generally speaking, developing countries have a large number of
subscribers. Some of them with more than dozen millions of broadband
subscribers, increase at a rate of 20+ percent of subscribers
annually.
Developing countries are facing unprecedented pressure in business
aspect, with the Global IPv4 address exhaustion. Therefore
developing countries' network and services will migrate to IPv6
eventually. However, during the transition procedure, developing
coutries should seriously concerned about the transition of existing
services in order to support the v4v6 coexistent environment, along
with the researches and developments of new services and
applications. Developing countries broadband networks are so large
with various types of service that the transition to IPv6 is doomed
to be complicated and difficult.
One of the typical network structure is shown in Figure 1. As this
figure shows, the network comprises three segments: backbone network
which usually includes IP backbone and MPLS backbone, metro network
(MAN) which basically includes Core Router(CR),Aggregation
Router(AR)and Broadband Remote Access Server(BRAS), and access
network covers from BRAS to users' Customer Premises Equipment(CPE).
Huang, et al. Expires April 23, 2011 [Page 3]
Internet-Draft Broadband Network Use Case October 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 backbone network provides long distance transmission for the
broadband traffic, which includes an IP backbone and a MPLS one. The
former one provides Internet service for home users and SME (Small
and Medium Enterprise) users while the latter one provides VPN and
Huang, et al. Expires April 23, 2011 [Page 4]
Internet-Draft Broadband Network Use Case October 2010
leased line services for the enterprise customers.
The metro network is mainly composed of Core Routers, Aggregation
Routers, and BRASs. CR, as the egress router of the metro network,
is connected to both IP backbone and MPLS backbone. Most BRASs are
connected directly to Core Routers, but a small portion of the BRASs
in some large metro networks are connected to Core Routers via
Aggregation Routers.
The access network provides broadband access service for users. It
mainly includes layer 2 devices (e.g., DSLAM, Aggregation
Switch).Broadband access service is provided over ADSL, LAN, PON and
so on.In the access network, the IPv6 capability is limited due to
some security considerations (IP-Based ACLs or policies). The best
part of UE access the network using the PPPOE dial up method. So,
hosts can acquire IPv6 address through PPPoE to avoid the problem.
With respect to the terminals, the Windows(TM) OS dominates in the
market, the Windows Vista and Windows 7 is the minority while the
Windows XP is majority. The WindowsXP cannot support IPv6 PPPOE.
The situation of terminals in some developing countries, e.g. China
is somewhat different from the situation of terminals in Europe. CPE
can operates either in routed or in bridged mode. The major part of
existing Routed mode CPE cannot support IPv6 PPPOE dial up. The
bridged mode CPE allows the users to dial up from PCs. CPE Home
Gateways in some cases are purchased by the users themselves, which
are unmanageable by the service provider.
During the migration to IPv6, the transition strategies and
technologies selection becomes one of the most significant issues due
to the complexity of the network and the services, the large number
of scenarios and the multiple methods of terminals and user access.
However, there is no universally applicable solution or guideline for
the migration of network and services to native IPv6 in the industry
yet. Each operator is looking for the appropriate transition
strategy for itself.
To investigate the impact of various transition technologies on
network and services and select correct migration procedures. A lot
of experiments were conducted on its existing networks, covering the
backbone network, metro network, terminals, service platforms, and
the provisioning systems.
In this document, several possible migration scenarios applicable to
the typical network are introduced. Related solutions for these
scenarios are also introduced.
Huang, et al. Expires April 23, 2011 [Page 5]
Internet-Draft Broadband Network Use Case October 2010
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. Backbone Network Migration
As stated in Section 1, there are usually two types of backbones: IP
backbone and an MPLS backbone.The migration solutions could be
enabling 6PE in MPLS backbone, dual stack capability in IP backbone,
and building up a new IPv6-only backbone network.
2.1. Solution 1: 6PE in the MPLS Network
MPLS backbone provides VPN service for the large scale enterprise
customers.When the whole network deploys MPLS, 6PE [rfc4798] can be
used to provide IPv6 transmission.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.Using 6PE and implementing IPv4 and IPv6 protocol stack
at the PE device connecting to IPv6 network, the original IPv4/ MPLS
network in the backbone network could be adopted to provide access
capability for the distributed IPv6 only user.
Technology saying, there is no problem with 6PE. However, the effect
of large scale deployment of 6PE(over thousands nodes)should be
evaluated in the future. In addition, since the IPv6 packet is
encapsulated in IPv4 tunnel, it is not easy for trouble shooting.
2.2. Solution 2: Dual-stack IP Backbone
The device enables IPv4/IPv6 protocol stack at the same time.IPv4 and
IPv6 routing are both in the routers which forward IPv4/IPv6 packet
separately based on the IPv4/IPv6 routing tables.
At present, functionally, the new equipments has better support for
DS while the left old devices do not.
2.3. Solution 3: IPv6-Only Backbone
Newly establish a native IPv6 network according to the scale of
current backbone network. The device enables IPv6 protocol stack
only. There is IPv6 routing only in the router which does not carry
IPv4 traffic.
From technology aspect, the IPv6 is running well in various existing
Huang, et al. Expires April 23, 2011 [Page 6]
Internet-Draft Broadband Network Use Case October 2010
experimental network. But from the business aspect, according to
many large-scale ISP which have no commercial experiences and
examples to reference, establishing a pure IPv6 network has the risk
impacting existing services. Besides, the IPv6 information resource
is extremely limited in recent time. It means IPv4 traffic dominates
the backbone traffic and consequently cause waste for the pure IPv6
network.
2.4. Conclusion
In conclusion, for the migration of backbone network, the most
reliable method is enable IPv6 in all the new-added devices, since
"support IPv6" in the manual script is far from well running in
current network.
3. Regional IP Network migration
The metro network here covers the network from BRAS to metro egress
router. Generally speaking, there are 4 mainstream programs.
The Overview of the solutions in the Regional Broadband Network is
reduced to the following three types:
Upgrading the existing BRASs and CRs for existing users, and adding
new BRASs for new users;
Upgrading the existing BRASs and CRs for all users;
Building a completely new Regional Broadband Network for new users;
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
Figure 2: 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:
Huang, et al. Expires April 23, 2011 [Page 7]
Internet-Draft Broadband Network Use Case October 2010
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 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 as same as the above one.
In the following sections, the technical solutions based on the
scenarios in Figure 2 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 2 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 protocol translation
In this document, we consider that the CPE is basically purchased by
customers themselves. The access method of subscribers in each
technical solution will be also discussed in this section. In the
PPPoE dial-up cases, most users dial-up from PC, but there is some
deployed a Home Gateway (e.g. 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. Even if most PC operating
system (OS) declared that they already supported IPv6, there is still
Huang, et al. Expires April 23, 2011 [Page 8]
Internet-Draft Broadband Network Use Case October 2010
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 PPPoE in IPv6
environment. These problems will be a significant bottleneck of the
development of IPv6 broadband.
3.1. Solution1: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 PPPoE with IPv6.
In the Figure 3 below, there are three scenarios in this solution.
o Scenario 1: A Dual-stack, IPv4 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
o Scenario 3: An IPv4 terminal accessing to a legacy IPv4-only BRAS
+----------------------+
CR/AR | Upgrade to DS/new DS |
+----------------------+
+----------------------+ +----------------+
BRAS | Upgrade to DS/new DS | |Legacy IPv4-only|
+----------------------+ +----------------+
+-----------------------------------------+
CPE | Legacy bridged CPE/upgraded routed CPE |
+-----------------------------------------+
+-------------------+ +-------+ +------+
User End | DS/IPv4/IPv6 | |DS/IPv6| | IPv4 |
+-------------------+ +-------+ +------+
Scenario1 Scenario2 Scenario3
Figure 3: 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
support PPPoE with IPv6.
The Scenario 3 is as the same as the access method currently.
Huang, et al. Expires April 23, 2011 [Page 9]
Internet-Draft Broadband Network Use Case October 2010
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 2 Tunnel Protocol (L2TP) [RFC2661] [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 4]
+----------------------+
CR/AR | Upgrade to DS/new DS |
+----------------------+
+----------------------+ +----------------+
BRAS | Upgrade to DS/new DS | |Legacy IPv4-only|
+----------------------+ +----------------+
+-----------------------------------------+
CPE | Legacy bridged CPE/upgraded routed CPE |
+-----------------------------------------+
+-------------------+ +-------+ +------+
User End | DS/IPv4/IPv6 | |DS/IPv6| | IPv4 |
+-------------------+ +-------+ +------+
Scenario1 Scenario2 Scenario3
Figure 4: 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 [TR 187]. 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.
Huang, et al. Expires April 23, 2011 [Page 10]
Internet-Draft Broadband Network Use Case 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.
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.
In conclusion, for dual stack aspect, The newly-added equipments have
few problem with the dual stack while the old ones do not. In these
new devices, the aggregation routers have much more problems than the
core routers. The switches has poor support capacities of IPv6. The
BRASs have many problems, like no well-formed access protocols, no
specificated address allocation policies, too many uncertain factors
which may influence the network operation and maintenance. Moreover,
most metro network is formed through continually devices expansion.
So, there are mounts of equipments which are too old to be upgraded.
Moreover, with IPv6 information resource increasing, how to provide
IPv6 internet visiting for the existing IPv4 subscribers should be
put into consideration.
3.2. Solution2: 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. This section will discuss the dual-stack subscriber
accessing this network. [See Figure 5]
A Dual-stack, IPv4 or IPv6 terminal accessing to an IPv6-only BRAS.
Huang, et al. Expires April 23, 2011 [Page 11]
Internet-Draft Broadband Network Use Case October 2010
+----------------------+ +---------------+
CR/AR | Upgrade to DS/new DS | | new IPv6 |
+----------------------+ +---------------+
AFTR device somewhere
+----------------------------------------+
BRAS | new IPv6 |
+----------------------------------------+
+-------------------------+ +------------+
CPE | bridged/upgraded routed | | DS-Lite CPE|
+-------------------------+ +------------+
+---------------------+ +------------+
User End | IPv6 | |DS/IPv6/IPv4|
+---------------------+ +------------+
Scenario
Figure 5: The DS-Lite Solution in IPv6 Infrastructure
The Scenario for IPv6 subscriber 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 needs to support PPPoE with IPv6. 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.
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 discuss 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 AFTR.
Any locally unique IPv4 address could be configured on the IPv4-in-
IPv6 tunnel to represent the B4 element. IANA has defined a well-
known range, 192.0.0.0/29.
DS-Lite technology is designed for an IPv6 infrastructure with a
layer 3 (L3) access network. However,
[I-D.zhou-softwire-ds-lite-p2p] describes the Point-to-Point access
method scenario. For a layer 2 (L2) access network with PPPoE access
method, each CPE has a unique PPP link. The link information can be
used to identify the CPE and any IPv4 or IPv6 address does not need
Huang, et al. Expires April 23, 2011 [Page 12]
Internet-Draft Broadband Network Use Case October 2010
to be allocated to the CPE. However, the CPE can allocate an
internal IPv4 address to a host. It simply puts the packets to the
point-to-point link and forward to the BRAS. When BRAS receives the
packet, it maps the point-to-point identifier to the IPv6 Flow Label
[RFC3697] and send to the AFTR for NAT.
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.
No matter the L3 or L2 access network DS-Lite is deploying on, the
DS-Lite Address Family Translation Router (AFTR) needs to be deployed
somewhere in the regional broadband network.
In all, currently, DS-lite, which offers IPv4 internet visiting
ability to dual stack subscribers through pure IPv6 accessing
network, does not be well integrated into devices. At the same time,
technically, it can not assign IPv4 DNS to the subscribers in the
first version. Moreover, how to assign addresses to users,
considering PPPOE accessing methods, should also be thought about
carefully.
3.2.1. The Location of AFTR
There are mainly three locations can be deployed an AFTR:
o Deploying a centralized AFTR connecting to the IPv6 CR; Figure 6
o Deploying a centralized AFTR card at the Dual-stack CR;[Figure 7]
o Deploying distributed AFTRs connecting to IPv6 BRASs;[Figure 8]
Huang, et al. Expires April 23, 2011 [Page 13]
Internet-Draft Broadband Network Use Case October 2010
+--------------------+ +----------------+
| IPv6/DS Backbone | |IPv4/DS Backbone|
+-----*--------------+ +--.-------------+
+-----*--------------+ +--.------+
CR/AR | * new IPv6 ######. AFTR |
+-----*------------#-+ +---------+
+-----*-----------#--+
BRAS | *new IPv6 # | * IPv6 Traffic
+-----*---------#----+ . IPv4 Traffic
+-*--------#-----+ # IPv4-in-IPv6 Traffic
CPE | DS-Lite CPE |
+----------------+
+----------------+
User End | DS/IPv6/IPv4 |
+----------------+
Figure 6: Centralized AFTR connecting to the IPv6 CR
+--------------------+ +----------------+
| IPv6/DS Backbone | |IPv4/DS Backbone|
+-----*--------------+ +-.--------------+
+-----*------------------.-----+
CR/AR |Upgrade to DS/new DS with AFTR|
+-----*----------------#-------+
+-----*---------------#--------+
BRAS | * new IPv6 # |
+-----*-------------#----------+
+-*------------#-+
CPE | DS-Lite CPE | * IPv6 Traffic
+----------------+ . IPv4 Traffic
+----------------+ # IPv4-in-IPv6 Traffic
User End | DS/IPv6/IPv4 |
+----------------+
Figure 7: Centralized AFTR card at the Dual-stack CR
Huang, et al. Expires April 23, 2011 [Page 14]
Internet-Draft Broadband Network Use Case October 2010
+--------------------+ +----------------+
| IPv6/DS Backbone | |IPv4/DS Backbone|
+-----*--------------+ +--.-------------+
+-----*--------------------.---+
CR/AR | Upgrade to DS/new DS . |
+-----*-------------------.----+
+-----*-------------+ +--.-----+
BRAS | * new IPv6 #####. AFTR |
+-----*-----------#-+ +--------+
+-*----------#--+
CPE | DS-Lite CPE | * IPv6 Traffic
+---------------+ . IPv4 Traffic
+---------------+ # IPv4-in-IPv6 Traffic
User End | DS/IPv6/IPv4 |
+---------------+
Figure 8: Distributed AFTRs connecting to IPv6 BRASs
3.3. Solution3: Dual-Stack over IPv4 - 6rd
In this solution, the CRs in the regional broadband network are IPv4-
only, Dual-stack or IPv6-only 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. " An IPv6 or Dual-
stack terminal accessing to an IPv4-only BRAS.
+----------------------------------------+
CR/AR | Upgrade to DS/new DS/Legacy IPv4 |
+----------------------------------------+
6rd border router somewhere
+----------------------------------------+
BRAS | Legacy IPv4 |
+----------------------------------------+
+-------------------------+ +------------+
CPE | bridged/upgraded routed | | 6rd CPE |
+-------------------------+ +------------+
+---------------------+ +------------+
User End | Legacy IPv4 | | DS/IPv6 |
+---------------------+ +------------+
Figure 9: The 6rd Solution in an IPv4 infrastructure
A possible technical solution for this scenario is IPv6 Rapid
Huang, et al. Expires April 23, 2011 [Page 15]
Internet-Draft Broadband Network Use Case October 2010
Deployment (6rd) [RFC5969]. There are two components in this
solution. 6rd CPEs support Ipv4 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.
In all, currently, 6RD, which offer Ipv6 internet visiting ability to
dual stack subscribers through pure Ipv4 accessing network, does not
be well integrated into devices. At the same time, technically,
Moreover, how to assign addresses to users, considering PPPOE
accessing methods, should also be thought about carefully.
3.3.1. The Location of 6rd Gateway
There are mainly two locations can be deployed a 6rd gateway:
o Deploying a centralized 6rd gateway at the edge of IPv4 regional
broadband network;
o Deploying distributed 6rd gateways connecting to IPv4 BRASs;
+------------------+ +----------------+
| IPv6/DS backbone | |IPv4/DS backbone|
+-------------*----+ +-----.----------+
+--------------*---+ +-----.----------+
| 6rd gateway* | | .NAT44 |
+----------------#-+-+-----.----------+
CR/AR | # IPv4 . |
+-----------------#--------.----------+
+------------------#-------.----------+
BRAS | IPv4 . |
+------------------#-----.------------+
+-----#----.-+
CPE | 6rd CPE. | . IPv4 traffic
+-----*----.-+ # 6rd traffic
+-----*----.-+ * IPv6 traffic
User End | DS/IPv6 |
+------------+
Figure 10: 6rd gateway at the edge of IPv4 network
Huang, et al. Expires April 23, 2011 [Page 16]
Internet-Draft Broadband Network Use Case October 2010
+------------------+ +----------------+
| IPv6/DS backbone | |IPv4/DS backbone|
+-----------*------+ +-----.----------+
+------------*-----+-+-----.----------+
CR/AR | Upgrade to DS/new DS . |
+-------------*----+-------.----------+
| 6rd gateway | NAT44 LSN |
+---------------#--+-------.----------+
BRAS | # IPv4 . |
+-----------------#------.------------+
+-----#----.-+
CPE | 6rd CPE. | . IPv4 traffic
+-----*----.-+ # 6rd traffic
+-----*----.-+ * IPv6 traffic
User End | DS/IPv6 |
+------------+
Figure 11: Distributed 6rd gateways connecting to IPv4 BRASs
3.4. Solution4: IPv6 and protocol translation
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 of IPv4 services, it is needed to deploy a NAT64
(stateful/IVI) [I D.ietf behave v6v4 xlate stateful] [I D.xli behave
ivi] device to solve the intercommunication problem between IPv6 and
IPv4 for the IPv6-only subscribers.
+-----------------+ +--------------------+
|IPv6/DS Backbone | | IPv4/DS Backbone |
+-----------*-----+ +----------.---------+
+-----------*-----++------++---.----------+
CR/AR | new IPv6 ***** NAT64 .... IPv4/DS |
+-----------------++------+|Regional Broad|
+-----------------+ |-band Network |
BRAS | new IPv6 | +--------------+
+-----------------+ Legacy/Upgraded network
+-------------+
User End | IPv6 | * IPv6 Traffic
+-------------+ . IPv4 Traffic
Scenario 1
Figure 12: The NAT64 Solution in an IPv6 infrastructure - Scenario 1
Huang, et al. Expires April 23, 2011 [Page 17]
Internet-Draft Broadband Network Use Case October 2010
+------++----------+ +------+
Backbone| IPv4 ||Dual-stack| | IPv6 |
+.-----++.------*--+ +--*---+
+--.-------.--+ * * * IPv6 Traffic
| . NAT64 . | * * . IPv4 Traffic
+--*-------*--+---*-------*--+
CR/AR | * new IPv6 * |
+----------------------------+
+----------------------------+
BRAS | new IPv6 |
+----------------------------+
+------------------------+
User End | IPv6 |
+------------------------+
Scenario 2
Figure 13: The NAT64 Solution in an IPv6 infrastructure - Scenario 2
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.
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.
In conclusion, protocol translation, just like NAT64, IVI,etc, is
widely agreed to be used in mobile network. But due to the vast
types of application in the internet accessed through fixed network,
protocol translation technologies can not deal with all the
applications. As far as we know, conclude from the experimental
data, only mail and http service protocol can be well translated.
4. Terminal migration
From the terminal aspect, there are two types of CPE: Routed CPE and
switched CPE. The switched CPE, which can transparently switch the
Ipv6 traffic from user PC to the network access device, does not
block the Ipv6 PPPOE dial up .
But the routed one, which always automatically initiates a PPPOE ,
cumbers the normal Ipv6 accessing since almost most part of the
routed CPE do not support Ipv6 PPPOE dial up. For the ISP, who can
provide CPE to the subscribers and manage them, can offer Ipv6
accessing service by upgrading the CPE. But for the ISPs in this
Huang, et al. Expires April 23, 2011 [Page 18]
Internet-Draft Broadband Network Use Case October 2010
case, who have large mount of users and have to allow the users to
purchase the CPE by themselves, it is nearly impossible for them to
replace all the CPE for the cost sake.
From OS aspect, there are some problem with windows XP operation
system, which dominate the over 80% market, to support the Ipv6 PPPOE
dial up.
5. ICP migration
Internet Content Provider (ICP) migration to IPv6 is the most
important step to break the deadlock in the IPv6 industry chain. The
ICPs can migrate by themselves, or can be assisted by others. For
the transition of ICP itself, some ICPs have modified their
proprietary web service.
This solution requires a protocol translation technology, like NAT64
[ID_behave-v6v4-xlate-stateful] device deployed at the edge of
IDC(Internet Data Center), but not requires to deploy a DNS64. The
solution could include the following steps:
o Configure AAAA records with IPv6 addresses for the ICP's sites on
its Authoritative DNS Server. These IPv6 addresses are
constituted by combining the ICP's IPv4 public address and an
specific prefix according to the Prefix+v4 address style described
in SIIT [RFC2765] or in IVI [ID_xli-behave-ivi].
o When user initials an http request to the website, the host will
query the corresponding IP address from DNS cache server which is
usually located in Metro Network.
o The DNS cache server replies with the ICP's IPv6 address in an
AAAA record which is from the ICP's Authoritative DNS Server. In
some circumstances, these records could be configured in a
centralized DNS server of the IDC.
o The user will access the IPv4 services using the IPv6 address.The
BRAS will route it to the NAT64 device located at the IDC edge,
and remove the prefix, then translating the IPv6 client address by
installing mappings in the normal NAT manner.
6. Challenges Faced In Migrating To IPv6
There is a long list of challenges during the transition from IPv4 to
IPv6:
Huang, et al. Expires April 23, 2011 [Page 19]
Internet-Draft Broadband Network Use Case October 2010
o The remaining stock of IPv4 addresses cannot support the
development of existing services. Future service's development is
not the only thing which is concerned about, but the transition of
existing services to IPv6 is also considered.
o Due to the long transition period, it will be highly possible that
one thing taken into consideration while the other be neglected
when the different parts of end-to-end network are migrated. A
balanced strategy is needed to guide the transition.
o Lack of IPv6 Internet resources. ICP seldom deploy IPv6 and
almost no Content Provider/Service Provider (CP/SP) considers IPv6
when developing proprietary services due to the large volume of
recoding. The applications of ICPs are of various types and so
complex that they cannot all support IPv6 in a short time. In
addition, many business websites are always linking to each other,
creating a complex topology which will lead to many problems when
one website migrates to IPv6 only. Another reason ICP migration
lacks motivation is that the CP/SP does not realize how urgent it
is to migrate to IPv6.
o From the perspective of terminals, some specific terminals
(e.g.,set top boxes) do not support IPv6 even if the main
operating systems can do so. Some operation systems for mobile
terminals officially claimed they don't support IPv6.
o No accumulated experience with IPv6 transition. Large scale
network and large number of subscribers are the two key
problems.IPv6 transition should be seriously considered. With
large scale network and various service platforms, the transition
involves multiple levels and broad scope, so the cost of
modification will be huge and the return on investment will not be
so evident. The selection of transition technology and network
modification solution is not clear for the transition roadmap of
the whole network.
7. IANA Considerations
This memo includes no request to IANA.
8. Security Considerations
The IETF is specifying security considerations for the tools that it
is providing for IPv6 migration.However, it is possible that
additional considerations arise due to the interaction of these
tools, and the fact that the network is in a transitional state.
Huang, et al. Expires April 23, 2011 [Page 20]
Internet-Draft Broadband Network Use Case October 2010
Security considerations should be incentive concerned about because
of the potential loss, which is caused by the IPv6 security issues,
e.g., dual-stack routing security, network expandability, device
reliability, network anti-attack, user tracing, government
supervision and etc.
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.baker-behave-ivi]
Li, X., Bao, C., Baker, F., and K. Yin, "IVI Update to
SIIT and NAT-PT", draft-baker-behave-ivi-01 (work in
progress), September 2008.
[I-D.durand-softwire-dual-stack-lite]
Durand, A., Droms, R., Haberman, B., and J. Woodyatt,
"Dual-stack lite broadband deployments post IPv4
exhaustion", draft-durand-softwire-dual-stack-lite-01
(work in progress), November 2008.
[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-gateway-init-ds-lite]
Brockners, F., Gundavelli, S., Speicher, S., and D. Ward,
"Gateway Initiated Dual-Stack Lite Deployment",
draft-ietf-softwire-gateway-init-ds-lite-01 (work in
progress), October 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.
Huang, et al. Expires April 23, 2011 [Page 21]
Internet-Draft Broadband Network Use Case October 2010
[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.
[RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm
(SIIT)", RFC 2765, February 2000.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552,
July 2003.
[RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling
Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.
[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.
Authors' Addresses
CanCan Huang (editor)
China Telecom
109, Zhongshan Ave. West,
Guangzhou, Tianhe District 510630
P.R. China
Phone:
Email: huangcc@gsta.com
Huang, et al. Expires April 23, 2011 [Page 22]
Internet-Draft Broadband Network Use Case October 2010
XiaoYang Li
China Telecom
109, Zhongshan Ave. West,
Guangzhou, Tianhe District 510630
P.R. China
Phone:
Email: hz_lxy@gsta.com
LeMing Hu
China Telecom
109, Zhongshan Ave. West,
Guangzhou, Tianhe District 510630
P.R. China
Phone:
Email: hulm@gsta.com
Huang, et al. Expires April 23, 2011 [Page 23]