One document matched: draft-yang-v4v6tran-ipv6-transition-guide-00.txt
Internet Engineering Task Force G. Yang, Ed.
Internet-Draft L. Hu
Intended status: Informational J. Lin
Expires: March 19, 2011 China Telecom
September 15, 2010
IPv6 Transition Guide For A Large ISP Providing Broadband Access
draft-yang-v4v6tran-ipv6-transition-guide-00
Abstract
This document provides a transition guide for a large-scale provider
of broadband access migrating its network from IPv4 to IPv6.
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 March 19, 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.
Yang, et al. Expires March 19, 2011 [Page 1]
Internet-Draft Broadband Access Provider Transition September 2010
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. Overview of Solutions for IPv6 Migration Mentioned In the
China Telecom Use Case Document . . . . . . . . . . . . . . . 5
2.1. Transition For the Backbone Network . . . . . . . . . . . 6
2.1.1. Upgrade to Dual stack on existing IP Backbone . . . . 6
2.1.2. Building New Native IPv6-Only Backbone Network . . . . 6
2.1.3. Enable 6PE On Existing MPLS Backbone . . . . . . . . . 7
2.2. Transition of Metro IP Network . . . . . . . . . . . . . . 8
2.2.1. Solution 1 . . . . . . . . . . . . . . . . . . . . . . 8
2.2.2. Solution 2 . . . . . . . . . . . . . . . . . . . . . . 9
2.2.3. Solution 3 . . . . . . . . . . . . . . . . . . . . . . 10
2.2.4. Solution 4 . . . . . . . . . . . . . . . . . . . . . . 11
2.3. Transition Of Access network . . . . . . . . . . . . . . . 12
2.3.1. Solution 1 . . . . . . . . . . . . . . . . . . . . . . 12
2.3.2. Solution 2 . . . . . . . . . . . . . . . . . . . . . . 12
2.3.3. Solution 3 . . . . . . . . . . . . . . . . . . . . . . 13
2.4. Transition of Subscriber Access Mode . . . . . . . . . . . 13
2.4.1. Solution 1 . . . . . . . . . . . . . . . . . . . . . . 13
2.4.2. Solution 2 . . . . . . . . . . . . . . . . . . . . . . 14
2.4.3. Solution 3 . . . . . . . . . . . . . . . . . . . . . . 15
2.4.4. Solution 4 . . . . . . . . . . . . . . . . . . . . . . 16
3. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 17
4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 17
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.1. Normative References . . . . . . . . . . . . . . . . . . . 17
8.2. Informative References . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Yang, et al. Expires March 19, 2011 [Page 2]
Internet-Draft Broadband Access Provider Transition September 2010
1. Introduction
China Telecom is one of the largest operators in the world, with more
than 60 million broadband subscribers, increasing at a rate of 10
million subscribers annually. After the IPv4 addresses allocated by
IANA are exhausted, China Telecom's broadband users will keep
increasing at high speed, which will bring unprecedented pressure to
the development of China Telecom's broadband service.
In order to solve the problem of IPv4 address shortage, the network
and service will eventually migrate to IPv6. Until now there are no
services and applications which must use IPv6. In addition, most of
Chinese broadband users (including China Telecom and other Chinese
ISPs) are basically IPv4 only users before the IPv4 address
exhaustion. So the time the related industrial chain supporting IPv6
will be later than the time the IPv6 in introduced into the
operator's network.
In the process of IPv6 migration, China Telecom focuses on the smooth
transition of the existing services because the support from the
related IPv6 industrial chain is relatively slow. For example, it
should be compatible with the existing internet services, maintain
the high-speed increasing of the broadband users, guarantee user
experience in the transition process, and protect existing network
investments. At the same time, China Telecom should consider that
the transition technology and strategy should be consistent with the
transition direction of future services and network.
China Telecom provides broadband access by PPPoE dial-up
authentication. BRAS is the termination device of PPPoE, which
allocates IP address for the user, provides the access authentication
for broadband users, administration of users, IP edge function and
etc. Most of the broadband users use PC to make PPPoE dial up
authentication. Some broadband users who need to dial up from the
Home Gateway, have to purchase the Home Gateway themselves because
China Telecom does not provide the Home Gateway. 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 (not provide HGW).
The existing single transition technology is not suitable for the
transition of China Telecom considering the specific feature of China
Telecom's network. Only the combination of multiple technologies can
guarantee the smooth transition of China Telecom's network. How to
select appropriate technology combination to fit the network
scenarios in China Telecom is the focus of this document.
Yang, et al. Expires March 19, 2011 [Page 3]
Internet-Draft Broadband Access Provider Transition September 2010
+-------------------------------------+ +-------------------+
| CT's backbone | | External backbone|
| +-----------+ +-------------+ | | +-----------+ |
| |IP backbone| |MPLS backbone| | | | IPv6 | |
| |(Chinanet) | | (CN2) | | | | Internet | |
| +-----------+ +-------------+ | | +-----------+ |
+-------------------------------------+ +-------------------+
+------------------------------------------------------------+
| CT's Metro Area Network |
|+---------------------------------------------------------+ |
|| Core Router | |
|| +-----------------------------+ |
|| | +---------------------------+ |
|| | | Aggregation Router | |
|+---------------------------+ +---------------------------+ |
|+-----------------------------------+ +-------------------+ |
|| BRAS | | Service Router | |
|+-----------------------------------+ +-------------------+ |
+------------------------------------------------------------+
+------------------------------------------------------------+
| CT's Access Netrwork |
| +--------------------------------------------------------+ |
| | Aggregation Switch | |
| +--------------------------------------------------------+ |
| +--------------------------+ +---------------------------+ |
| | OLT | | DSLAM | |
| +--------------------------+ +---------------------------+ |
| +--------------------------+ +---------------------------+ |
| | ONT | | ONU | |
| +--------------------------+ +---------------------------+ |
+------------------------------------------------------------+
+------------------------------------------------------------+
| Customer Premises Network |
| +--------------------------+ +---------------------------+ |
| | Routed Mode CPE | | Bridged Mode CPE | |
| +--------------------------+ +---------------------------+ |
| +--------------------------------------------------------+ |
| | User End | |
| +--------------------------------------------------------+ |
+------------------------------------------------------------+
Figure 1: Structure of the China Telecom Network
The network structure of China Telecom is shown in Figure 1. In the
metro network of China Telecom, CR, as the exit router of the metro
network, is connected to both ChinaNet and CN2 backbone networks.
BRAS, as the IP edge device, provide the access authentication for
Yang, et al. Expires March 19, 2011 [Page 4]
Internet-Draft Broadband Access Provider Transition September 2010
the broadband users. In most metro networks, BRAS is connected to CR
directly, while for a small portion of large sale metro networks,
BRAS is connected to CR via SR. CR, SR and BRAS need to be sensitive
to the IP protocols. Between BRAS and broadband users, it is the
layer 2 network which is not sensitive to IP protocols.
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 for IPv6 Migration Mentioned In the China
Telecom Use Case Document
The following factors make the network and service transition to IPv6
complicated in China Telecom:
o Large scale broadband subscribers and different capabilities of
supporting IPv6 in terminals.
o Large number of network devices and different capabilities of
supporting IPv6 in these devices.
o Various types of the Internet services and different capabilities
and timing of supporting IPv6 in these services.
o The widespread ratio of broadband subscribers in different metro
networks varies, which makes the smooth service and network
transition to IPv6 complicated.
In the transition to IPv6, existing terminals and access modes should
be considered to guarantee the user experience. Only by selecting
proper technologies in different networks and in different transition
phases, the network and service can be migrated to IPv6 smoothly.
This section analyzes related transition technologies and transition
roadmap regarding the network scenarios in the use case draft from
the following aspects:
o Compatible with existing services (terminals, access mode and
existing Internet service).
o Keep the high speed increasing of broadband subscribers.
o Guarantee the user experience in the transition procedure.
Yang, et al. Expires March 19, 2011 [Page 5]
Internet-Draft Broadband Access Provider Transition September 2010
o Guarantee the existing network investment.
2.1. Transition For the Backbone Network
There are three main technologies for the transition of backbone
network: dual stack, 6PE and Native IPv6.
2.1.1. Upgrade to Dual stack on existing 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.
Pros: Compatible with existing IPv4 service and new IPv6 service.
o The existing network device capability is high. To support IPv6,
it only needs to enable protocol stack, the cost of upgrade is
low.
o It is useful for the smooth transition.
Cons: Due to the large network traffic and each routing device has
various capabilities in IP backbone network, there is big risk to
directly upgrade to dual stack.
o Impact to existing service: When dual stack is enabled, any
problem may have great impact to the existing services due to the
large IP network traffic.
o Impact to existing network: The requirement of the existing
network device capability is high. It is a challenge for the
routing table size, routing lookup/forwarding capability and
routing convergence capability when the devices are upgraded to
dual stack and IPv4/IPv6 share resources.
o The engineering of network modification takes much more work than
6PE, not only modifying edge devices, but also the core devices.
Application scenarios: Dual stack backbone network is applicable to
the phase when IPv6 traffic is relatively large and the dual stack
capability of the network device in dual stack backbone network is
verified.
2.1.2. Building New Native IPv6-Only Backbone Network
The device enables IPv6 protocol stack only. There is only IPv6
routing in the router which does not carry IPv4 traffic.
Yang, et al. Expires March 19, 2011 [Page 6]
Internet-Draft Broadband Access Provider Transition September 2010
Pros: In line with the future network transition and enables IPv6
protocol stack only:
o No impact to existing network and service
o Easy to maintain single network
Cons: Cost is large and the period of the engineering is long; The
network is difficult to maintain since there is no service driven at
the initial stage, the money invested and management is little.
Application scenario: In the last phase of IPv6 transition, most of
the CP/SP services are IPv6. Native IPv6 backbone network can be
upgraded from dual stack backbone network, or by creating a new
backbone network.
2.1.3. Enable 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. 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.
Pros: Only the PE devices connecting to IPv6 network need to be
upgraded to dual stack and make corresponding configuration. The
existing IPv4 MPLS network is utilized thoroughly to achieve the IPv6
service carry in the backbone network. The cost and risk of
modifying the network is small.
o Little impact to the existing network carrying: quick deployment
and small modification to the network. There is no need to change
core routers, and only PE routers having requirements need to be
modified.
o Little impact to the existing service: in the initial stage of
IPv6 deployment, there is no impact to the existing service
o Incremental deployment period is short.
Cons:
o Change the service orientation of the original networks. MPLS
network is normally used to carry VPN traffic and the network is
light load. 6PE is enabled to carry public service which changes
the network orientation. When the public traffic grows, there may
Yang, et al. Expires March 19, 2011 [Page 7]
Internet-Draft Broadband Access Provider Transition September 2010
be impact to the existing service.
o No way to deploy QoS policy for IPv6 traffic.
o Change the networking principle.
Application scenarios: applicable in the starting point of supporting
IPv6 but the main traffic is IPv4 in the operator's network. The
backbone network provides IPv6 carrying capability quickly. That is,
6PE is suitable for the first phase of IPv6 transition.
2.2. Transition of Metro IP Network
According to the chart in the introduction section, China Telecom's
MAN is comprised of two parts:
o IP network: this part of network is composed of 2 sets of CRs and
BRAS. Some SR may be included in some large scale MANs.
o Layer 2 access network: this part of network is the layer 2
network between BRAS and users' home gateway.
This section introduces the transition of the IP network in metro
networks.
2.2.1. Solution 1
The network is updated bases on existing network. The network is
updated to dual stack, and the BRAS added in future should support
dual stack, too. Solution: CR (core router) will be updated to dual
stack, and some aggregation routers which may be deployed in large
scale MAN will be updated to dual stack, too. The update solution
for BRAS is as follows:
o The existing BRASs which supports to be updated to dual stack will
be updated to dual stack, and the BRAS added in future should
support dual stack, too.
o Some BRASs which can not be upgraded to support dual-stack can
redirect the dual-stack subscribers to dual-stack BRASs, and the
PPP links of the dual-stack subscribers will be terminated on the
dual-stack BRASs.
After the exhaustion of IPv4 addresses, new BRASs distribute IPv4
addresses for broadband subscribers, and NAT44 CGN is deployed to
provide IPv4 services for subscribers who use private IPv4 addresses.
IPv6 services are provided by this mechanism. In the same time, the
problem that the quantity of broadband subscribers keeps increasing
Yang, et al. Expires March 19, 2011 [Page 8]
Internet-Draft Broadband Access Provider Transition September 2010
quickly while IPv4 addresses is insufficient is solved.
Pros:
o The change of network is simple. The cost of the network change
is low. Both administration and maintenance of network are
simple.
o IPv6 could be imported quickly.
o The technology of NAT44 is relatively mature.
o Major and existing services, such as MSN, Skype and OICQ, could
support NAT44 traverse better.
o The existing access method does not need change, so China Telecom
does not need to provide home gateway to users.
o In the condition that the time when the around industrial chain
could support IPv6 will be later than the time when the IPv6
migration of telecommunication network begins, users' experience
could be guaranteed better.
o When the flow of IPv4 disappears in the future, the network could
be migrated to native IPv6 network successfully.
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 imported and before the flow of
Ipv4 disappears.
2.2.2. Solution 2
The network is updated bases on existing network. The network is
updated to dual stack, and the BRASs added newly support IPv6 only.
CR (core router) will be updated to dual stack, and some aggregation
routers which may be deployed in large scale MAN will be updated to
dual stack, too. The update solution for BRAS is as followed:
o The existing BRASs which support to be updated to dual stack will
be updated to dual stack, and the BRAS added in future should
support dual stack, too.
o Some BRASs which can not be upgraded to support dual-stack can
redirect the dual-stack subscribers to dual-stack BRASs, and the
Yang, et al. Expires March 19, 2011 [Page 9]
Internet-Draft Broadband Access Provider Transition September 2010
PPP links of the dual-stack subscribers will be terminated on the
dual-stack BRASs.
o the newly added BRAS support IPv6 only. The users who connect to
an IPv6 only BRAS will adopt DS-Lite mechanism to get IPv4 access.
As time goes, those BRASs which could not be updated to dual stack
will quit gradually from the network.
Pros:
o The technology of NAT44 is relatively mature.
o Major and existing services, such as MSN, Skype and OICQ, could
support NAT44 traverse better.
o The existing access method does not need change, so China Telecom
does not need to provide home gateway to users.
o In the condition that the time when the around industrial chain
could support IPv6 will be later than the time when the IPv6
migration of telecommunication network begins, users' experience
could be guaranteed better.
o When the flow of IPv4 disappears in the future, the network could
be migrated to native IPv6 network successfully.
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. Part of P2P users may have bad experience.
o Home gateway is needed to provide to users.
o In the condition that both BRAS and the user are IPv6 only, other
technology is needed to be imported to solve the transition
problems.
Applicable scenarios:After Ipv6 is imported and before the traffic of
IPv4 disappears.
2.2.3. Solution 3
The solution is to build a new network with dual stacks, and all the
equipments, such as CR/BRAS, adopt dual stacks. The existing network
does not need change, while the new network is used to provide IPv6
Yang, et al. Expires March 19, 2011 [Page 10]
Internet-Draft Broadband Access Provider Transition September 2010
service for users.
Pros: To avoid risk and difficulty in the process that existing IPv4
MAN is updated to dual stacks.
Cons:
o The cost is huge because the investment is duplicated.
o Input and output ratio is too lower when the quantity of new users
in new network is small.
o The IPv6 transition of existing subscribers requires a large
amount of switch from the old network to the new network.
Applicable scenarios:(1) The existing network is hard to be updated.
(2) The carrying capacity of the old IPv4 MAN is insufficient when
the quantity of broadband users increases quickly, so the old network
should be enlarged, and the traffic in the enlarged part is the same
with the traffic of the newly creating dual stacks MAN.
2.2.4. Solution 4
Building a new IPv6 only network. All the devices, such as CR/BRAS,
will use IPv6-only. The existing network does not need to change,
while the new network is used to provide IPv6 service for users.
Some devices, such as NAT64 or DS-Lite CGN, will be added in the old
MAN, in order to provide IPv4 service for the users connected to new
MAN.
Pros: To avoid risk and difficulty in the process that existing IPv4
MAN is updated to dual stacks.
Cons:
o The cost is huge because the investment is duplicated.
o Input and output ratio is too lower when the quantity of new users
in new network is small.
o The users are IPv6 only, so other technologies are needed to solve
the smooth transition problems.
Applicable scenarios: IPv6 traffic is large enough.
Yang, et al. Expires March 19, 2011 [Page 11]
Internet-Draft Broadband Access Provider Transition September 2010
2.3. Transition Of Access network
The layer 2 network of China Telecom's metro network is between the
BRAS and the CPE. The layer 2 network is IP layer protocol unaware
when PPPoE is used for broadband access. But given that new services
(e.g. IPTV or others) may use IPoE for network access, the layer 2
network may also need to support IPv6 aware during the IPv6
transition.
2.3.1. Solution 1
Transform based on the existing network. New devices will be IPv6
aware. Existing devices will keep unchanged. But as time goes by,
existing devices will be gradually removed from the network. Thereby
the whole layer 2 network will be IPv6 aware.
Pros:(1) The network transformation will be simple and cost-effective
(required only new devices to be IPv6 aware), and the network
maintenance and management will be simple; (2) In the short term,
since the access manner of existing services will not be changed
largely, the layer 2 network won't be required to be transformed.
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: This solution can not meet short-term requirements (e.g. IPoE)
that require the layer 2 network to be IPv6 aware.
Applicable scenarios: After IPv6 begins to be introduced.
2.3.2. Solution 2
Transform based on the existing network. New devices will be IPv6
aware and existing devices will be upgraded or replaced, thereby the
whole layer 2 networks will be IPv6 aware.
Pros:This solution can meet both the current and the future
requirements. The network will not need to be transformed again to
support new services that require the layer 2 networks to be IPv6
aware.
Cons: The network transformation is difficult and the cost of the
transformation is 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.
Yang, et al. Expires March 19, 2011 [Page 12]
Internet-Draft Broadband Access Provider Transition September 2010
2.3.3. Solution 3
The existing network keeps unchanged or is upgraded or evolved
gradually. A new layer 2 access network which is IPv6 aware will be
built. IPv6 aware services will be provided only to the subscribers
who connect to the new layer 2 network directly or indirectly.
Pros:Avoid the difficulties and risks of the transformation based on
the existing network.
Cons: (1) Duplicate investment with expensive cost. (2) The input-
output ratio will be low when the number of subscribers attached to
the network is low.
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.
2.4. Transition of Subscriber Access Mode
The transition of access mode should be compatible with the existing
broadband access modes:
o China Telecom provides broadband access service through PPPoE
dial-in authentication. The user terminal initiates PPPoE dial-in
authentication directly in China Telecom.
o China Telecom doesn't provide Home Gateway to broadband users (The
user will purchase the Home Gateway device if there is
requirement).
2.4.1. Solution 1
The user is accessed in dual stack mode, acquiring IPv4/IPv6
addresses from dual stack BRAS. Some users are connected to the BRAS
which can not be upgraded to dual stack (IPv4 only BRAS). In this
case, a L2TP tunnel from such BRAS to dual stack BRAS is created to
terminate the PPP link at the dual stack BRAS.
Pros:
o There is no need to change the existing access method, and China
Telecom does not need to provide the Home Gateway to the users.
o NAT is not needed and the user experience can be guaranteed.
Yang, et al. Expires March 19, 2011 [Page 13]
Internet-Draft Broadband Access Provider Transition September 2010
o After IPv4 address exhaust in the future, most users are still
using public IPv4 addresses. For the users who use private IPv4
addresses, NAT44 is relatively mature and mainstream services,
e.g., MSN, Skype can support NAT44 well, so the user experience
can be guaranteed.
o After the IPv4 traffic disappears, the network can migrate to
Native IPv6 smoothly.
Cons: Some applications not considering NAT44 may have problem when
deploying NAT44 CGN. For example, PPTP VPN may have service failure
after deploying NAT44 CGN; Some P2P applications may have bad
experience.
Application scenario: corresponds to the dual stack metro IP network
scenario.
2.4.2. Solution 2
The user acquires dual stack IP address from IPv6-only BRAS. The
user is accessed to IPv6-only BRAS which allocates IPv6 only for the
user (if there is requirement, it can allocate IPv4 address as well).
A L2TP tunnel from IPv6-only BRAS to dual stack BRAS is created to
allocate dual stack address for the PC. Alternatively, DS-Lite
Gateway is set and DS-Lite CE is provided to user to acquire the
Internet access capability of dual stack.
Pros:
o BRAS is IPv6-only.
o NAT44 is relatively mature and mainstream services, e.g., MSN,
Skype can support NAT44 well, so the user experience can be
guaranteed.
Cons:
o China Telecom needs to provide Home Gateway for the user which
costs much.
o DS-Lite has not been verified in large scale commercial sites.
o All the IPv4 services have to make NAT44. Some applications which
have not considered NAT44 may have problems after deploying NAT44
CGN.
o In the metro network with large number of subscribers, more DS-
Lite CGN devices, more requirements for the performance. The cost
Yang, et al. Expires March 19, 2011 [Page 14]
Internet-Draft Broadband Access Provider Transition September 2010
is high.
o Considering the scenarios introduced in the China Telecom use case
draft, CR has to be dual stack and only BRAS is simplified (not
dual stack). But the complexity of DS-Lite CGN is higher.
Application scenarios: Metro IP network is dual stack or IPv6 only.
Some users can be dual stack and some can be DS-Lite.
2.4.3. Solution 3
The user acquires dual stack addresses from IPv4 only BRAS. The user
is accessed to IPv4 only BRAS which allocates IPv4 address for the
user. 6RD Gateway is deployed in the metro network and 6RD CPE is
provided to the user. IPv6 packet is de-capsulated at the 6RD
Gateway. NAT44 CGN can be deployed in the network to solve the
problem of IPv4 address shortage.
Pros:
o There is no need to upgrade BRAS.
o When deploying NAT44 CGN, the user experience can be guaranteed
because NAT44 is relatively mature and mainstream services, e.g.,
MSN, Skype can support NAT44 well.
Cons:
o How to be compatible with the existing access modes? As the
termination device of PPPoE, BRAS allocates IPv4 and IPv6
addresses for the user. BRAS needs 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 modification is high.
o The network should be modified and upgraded when the network
migrates to Native IPv6 in the future which leads to repeating
investment of network.
o When the IP traffic grows larger, each metro network may need a
great number of 6RD Gateways to meet the IPv6 user requirement.
o Some applications which have not considered NAT44 may have
problems after deploying NAT44 CGN. For example, PPTP VPN may
have service failure after deploying NAT44 CGN; Some P2P
applications may have bad experience.
Yang, et al. Expires March 19, 2011 [Page 15]
Internet-Draft Broadband Access Provider Transition September 2010
Application scenarios: IPv6 is just introduced into network and the
IPv4 traffic is dominant in the network.
2.4.4. Solution 4
The user acquires IPv6-only address from the IPv6-only BRAS. BRAS is
upgraded to IPv6 only and the user terminal is upgraded to support
IPv6 only. Only IPv6 address is allocated to the user who visits
IPv4 service through NAT64 or IVI. This solution can provide IPv6
service and can solve the problem of IPv4 address shortage due to
high speed increasing numbers of broadband users.
Pros:
o The operator does not need to allocate IPv4 address for the users.
o Push the ICP to transit to IPv6.
Cons:
o All the user terminals have to support IPv6 which is unpractical
at the initial stage of IPv6.
o The time supporting IPv6 for the related industry chain is later
than the time IPv6 is introduced into the operator's network.
Therefore, this solution may lead to the failure of some
applications and Internet services after IPv6 is only introduced
for a while..
o The timing supporting NAT64 for the related industry chain is much
later which will also lead to the failure of some applications and
Internet services after IPv6 is only introduced for a while.
o NAT64 and IVI have not been verified in large scale commercial
sites. DNS64 accompanied with NAT64/IVI has not been verified as
well.
o There is high requirement for the performance of the NAT device
because a great amount of traffic has to make NAT translations duo
to the major IPv4 traffic in the network after IPv6 is only
introduced for a while.
Application scenarios: Most ICP and terminals support IPv6. NAT64 is
relatively mature and IPv4 traffic is little. In this case, the
operators disable IPv4 protocol stack of the dual stack devices,
deploying NAT64 device at several sites to meet the requirement of
IPv6 users who would like to visit IPv4 services.
Yang, et al. Expires March 19, 2011 [Page 16]
Internet-Draft Broadband Access Provider Transition September 2010
3. Backwards Compatibility
4. Conclusions
5. Acknowledgements
6. IANA Considerations
This memo includes no request to IANA.
7. Security Considerations
All drafts are required to have a security considerations section.
See RFC 3552 [RFC3552] for a guide.
8. References
8.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.
8.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
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.
Yang, et al. Expires March 19, 2011 [Page 17]
Internet-Draft Broadband Access Provider Transition September 2010
Authors' Addresses
GuoLiang Yang (editor)
China Telecom
109 East Zhongshan Road,
Tiahne District, Guangzhou 510600
P.R. China
Phone:
Email: iamyanggl@gmail.com
LeMing Hu
China Telecom
109 East Zhongshan Road,
Tiahne District, Guangzhou 510600
P.R. China
Phone:
Email:
JinYan Lin
China Telecom
109 East Zhongshan Road,
Tiahne District, Guangzhou 510600
P.R. China
Phone:
Email: jasonlin.gz@gmail.com
Yang, et al. Expires March 19, 2011 [Page 18]
| PAFTECH AB 2003-2026 | 2026-04-24 01:31:39 |