Internet Engineering Task Force CC. Huang, Ed.
Internet-Draft XY. Li
Intended status: Informational LM. Hu
Expires: April 1, 2011 China Telecom
September 28, 2010
Use Case For IPv6 Transition For a Large-Scale Broadband network
draft-huang-v6ops-v4v6tran-bb-usecase-00
Abstract
This document describes a use case for the migration from IPv4 to
IPv6 for one of the typical broadband networks.
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
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 1, 2011 [Page 1]
Internet-Draft Broadband Network Use Case September 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 in the IP Network . . . . . . . . . 6
2.3. Solution 3: Creating a IPv6-only Network . . . . . . . . . 6
3. Metro Network Migration . . . . . . . . . . . . . . . . . . . 6
3.1. Solution 1 . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Solution 2 . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3. Solution 3 . . . . . . . . . . . . . . . . . . . . . . . . 7
3.4. Solution 4 . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Access Network Migration . . . . . . . . . . . . . . . . . . . 7
4.1. Solution 1 . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Solution 2 . . . . . . . . . . . . . . . . . . . . . . . . 7
4.3. Solution 3 . . . . . . . . . . . . . . . . . . . . . . . . 8
5. User Access Migration . . . . . . . . . . . . . . . . . . . . 8
5.1. Solution 1: Dual Stack subscribers access Dual Stack
BRAS . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.2. Solution 2: Dual Stack subscribers access IPv6-only
BRAS . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.3. Solution 3: Dual Stack subscribers access IPv4-only
BRAS . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.4. Solution 4: IPv6-only subscribers access IPv6-only BRAS . 9
6. Internet Content Provider (ICP) Migration . . . . . . . . . . 10
6.1. Provide NAT64 device at the IDC edge . . . . . . . . . . . 10
7. Challenges Faced In Migrating To IPv6 . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
9. Security Considerations . . . . . . . . . . . . . . . . . . . 11
10. Informative References . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Huang, et al. Expires April 1, 2011 [Page 2]
Internet-Draft Broadband Network Use Case September 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 coutries are facing unprecedented pressure in business
aspect, with the Global IPv4 address exhaustion. Therefore
developing coutries's 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 coutries 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 1, 2011 [Page 3]
Internet-Draft Broadband Network Use Case September 2010
+-------------------------------------+ +-------------------+
| ISP backbone | | External backbone|
| +-----------+ +-------------+ | | +-----------+ |
| |IP backbone| |MPLS backbone| | | | IPv6 | |
| | | | | | | | Internet | |
| +-----------+ +-------------+ | | +-----------+ |
+-------------------------------------+ +-------------------+
+------------------------------------------------------------+
| Metro Area Network |
|+---------------------------------------------------------+ |
|| Core Router | |
|| +-----------------------------+ |
|| | +---------------------------+ |
|| | | Aggregation Router | |
|+---------------------------+ +---------------------------+ |
|+-----------------------------------+ +-------------------+ |
|| BRAS | | Service Router | |
|+-----------------------------------+ +-------------------+ |
+------------------------------------------------------------+
+------------------------------------------------------------+
| Access Netrwork |
| +--------------------------------------------------------+ |
| | Aggregation Switch | |
| +--------------------------------------------------------+ |
| +--------------------------+ +---------------------------+ |
| | OLT | | DSLAM | |
| +--------------------------+ +---------------------------+ |
| +--------------------------+ +---------------------------+ |
| | ONT | | ONU | |
| +--------------------------+ +---------------------------+ |
+------------------------------------------------------------+
+------------------------------------------------------------+
| Customer Premises Network |
| +--------------------------+ +---------------------------+ |
| | Routed Mode CPE | | Bridged Mode CPE | |
| +--------------------------+ +---------------------------+ |
| +--------------------------------------------------------+ |
| | User End | |
| +--------------------------------------------------------+ |
+------------------------------------------------------------+
Figure 1: Architecture of the typical broadband Network
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
leased line services for the enterprise customers.
Huang, et al. Expires April 1, 2011 [Page 4]
Internet-Draft Broadband Network Use Case September 2010
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 1, 2011 [Page 5]
Internet-Draft Broadband Network Use Case September 2010
1.1. Requirements Language
This document is descriptive, and therefore contains no requirements
language.
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.
2.2. Solution 2: Dual Stack in the IP Network
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.
2.3. Solution 3: Creating a IPv6-only Network
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.
3. Metro Network Migration
The metro network here covers the network from BRAS to metro egress
router. Generally speaking, there are 4 mainstream programs.
3.1. Solution 1
The network is updated based on existing network. In this solution,
the Core Routers in the original metro network should be upgraded to
Huang, et al. Expires April 1, 2011 [Page 6]
Internet-Draft Broadband Network Use Case September 2010
dual stack. Old BRASs that can be upgraded to dual stack are also
upgraded; BRASs that cannot be upgraded remain as IPv4. Newly added
BRASs provide dual stack.
3.2. Solution 2
The network is updated based on existing network as well. The
approach is the same as solution 1 for existing equipments. The
difference from solution 1 is that newly added BRASs support IPv6
only.
3.3. Solution 3
Creat a dual stack network. The new Core Routers and BRASs are dual
stack and provide a dual stack with no changes to the existing
network.
3.4. Solution 4
Create an IPv6 network. The new Core Routers and BRASs are IPv6 only
with no changes to the existing network. The IPv6 traffic flows over
the new built network while the IPv4 traffic traverses the old one.
4. Access Network Migration
The access network covers the network from the user terminal to BRAS,
usually including DSLAM, aggregation switch and so on. The access
network is usually a layer 2 network in this typical network, and can
transmit IPv6 traffic transparently. As mentioned above, the access
network cannot carry IPv6 traffic directly due to some security
considerations, but the user can acquire an IP address by PPPoE
dial-up [RFC2516] which avoids the above problem. Generally, there
are 3 solutions for access network migration.
4.1. Solution 1
Modify the existing network and add new IPv6 aware access devices
without changing the old devices.
4.2. Solution 2
Solution 2 is modifying the existing network and adding new IPv6
aware access devices with upgrade or change to the old devices.
Huang, et al. Expires April 1, 2011 [Page 7]
Internet-Draft Broadband Network Use Case September 2010
4.3. Solution 3
Create a new access network supporting IPv6. The old network remains
the same. For the subscribers who have the requirement of IPv6, it
is needed to cut them over to the new access network.
5. User Access Migration
The broadband subscribers acquire IP addresses from the BRAS through
PPPoE to visit the Internet. The possible approaches to address
acquisition can be categorized as follows.
5.1. Solution 1: Dual Stack subscribers access Dual Stack BRAS
The subscribers acquire dual stack addresses from the BRAS in the
following scenarios:
1. Scenario 1 of metro network migration
2. Old upgradable BRAS in scenario 2 of metro network migration
3. Scenario 3 of metro network migration.
When not enough public IPv4 addresses are available, the BRAS
allocates a private IPv4 address to the user, thus requiring a NAT44
carrier grade NAT (CGN)device in the metro network. The NAT44 CGN
can be deployed at two locations based on the routing plan of metro
network: centralized (collocated with the Core Router), or
distributed (collocated with the BRAS).
5.2. Solution 2: Dual Stack subscribers access IPv6-only BRAS
The subscribers acquire dual stack addresses from an IPv6-only BRAS
in the following scenarios:
1. Scenario 2 of metro network migration
In this case, there are two methods to acquire IP addresses. One
is to create a L2TP tunnel from the IPv6-only BRAS to a dual
stack BRAS which can allocate dual stack addresses for the user.
Another way is to deploy a DS-Lite device in the metro network
and CPE devices which can support DS-Lite
[ID_softwire-dual-stack-lite].
2. Scenario 4 of metro network migration
Deploy DS-Lite in the edge of metro network and provide DS-Lite
Huang, et al. Expires April 1, 2011 [Page 8]
Internet-Draft Broadband Network Use Case September 2010
supported CPE to the user because the new Core Router and BRAS
are both IPv6 only.
In these two scenarios, NAT44 CGN device needs to be deployed in the
metro network because the IPv4 addresses the user acquires are IPv4
private addresses.
5.3. Solution 3: Dual Stack subscribers access IPv4-only BRAS
The subscribers acquire dual stack addresses from an IPv4-only BRAS
in the following scenarios:
1. Scenario 1 and 2 of metro network migration
Create a L2TP tunnel from the old BRAS (which could not be
upgraded to dual stack) to the dual stack BRAS to acquire dual
stack addresses, as above. Another method is to deploy 6RD
[RFC5969] gateway in the network and supply 6RD home gateway to
the subscribers.
2. Scenario 3 and 4 of metro network migration
Deploy 6RD in the old metro network and provide 6RD-supporting
CPE to users served by the old BRAS to acquire dual stack
address, since the old BRAS maintains IPv4 only.
5.4. Solution 4: IPv6-only subscribers access IPv6-only BRAS
The subscribers acquire an IPv6 address from an IPv6-only BRAS in the
following scenarios:
1. Scenario 2 of metro network migration
The user acquires an IPv6 address from the IPv6-only BRAS. There
are two ways to access the IPv4 Internet and communicate with
IPv4 users. We can deploy a protocol translation gateway in the
old metro network.
2. Scenario 4 of metro network migration
The user acquires IPv6 address from the IPv6 only BRAS. We can
deploy a protocol translation gateway in the new IPv6 only metro
network and at the edge of the old metro network
Huang, et al. Expires April 1, 2011 [Page 9]
Internet-Draft Broadband Network Use Case September 2010
6. Internet Content Provider (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.
6.1. Provide NAT64 device at the IDC edge
This solution requires a 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:
1. 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].
2. 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.
3. 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.
4. 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.
7. Challenges Faced In Migrating To IPv6
There is a long list of challenges during the transition from IPv4 to
IPv6:
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
Huang, et al. Expires April 1, 2011 [Page 10]
Internet-Draft Broadband Network Use Case September 2010
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.
8. IANA Considerations
This memo includes no request to IANA.
9. 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.
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.
Huang, et al. Expires April 1, 2011 [Page 11]
Internet-Draft Broadband Network Use Case September 2010
10. Informative References
[ID_behave-v6v4-xlate-stateful]
Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers(Work in progress)", July 2010.
[ID_softwire-dual-stack-lite]
Durand, A., droms, R., Woodyat, J., and Y. Lee, "Dual-
Stack Lite Broadband Deployments Following IPv4
Exhaustion(Work in progress)", August 2010.
[ID_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(work in progress)",
January 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.
[RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm
(SIIT)", RFC 2765, February 2000.
[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.
[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
Tiahne District, Guangzhou 510630
P.R. China
Phone:
Email: huangcc@gsta.com
Huang, et al. Expires April 1, 2011 [Page 12]
Internet-Draft Broadband Network Use Case September 2010
XiaoYang Li
China Telecom
109,Zhongshan Ave. west
Tiahne District, Guangzhou 510630
P.R. China
Phone:
Email: hz_lxy@gsta.com
LeMing Hu
China Telecom
109,Zhongshan Ave. west
Tiahne District, Guangzhou 510630
P.R. China
Phone:
Email: hulm@gsta.com
Huang, et al. Expires April 1, 2011 [Page 13]