Technical White Paper for IPv6 Network End-to-End Evolution ...

painlosososSoftware and s/w Development

Jun 30, 2012 (5 years and 1 month ago)

483 views







Technical White Paper for IPv6
Network End-to-End Evolution


Issue 1.0
Date 2011-11-30
HUAWEI TECHNOLOGIES CO., LTD.

Issue 1.0 (2011-11-30) Huawei Proprietary and Confi dential
Copyright © Huawei Technologies Co., Ltd.
i

Copyright © Huawei Technologies Co., Ltd. 2011. All rights reserved.
No part of this document may be reproduced or transmitted in any form or by any means without prior written
consent of Huawei Technologies Co., Ltd.
Trademarks and Permissions
and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd.
All other trademarks and trade names mentioned in this document are the property of their respective holders.

Notice
The purchased products, services and features are stipulated by the contract made between Huawei and the customer.
All or part of the products, services and features described in this document may not be within the purchase scope or
the usage scope. Unless otherwise specified in the contract, all statements, information, and recommendations in this
document are provided "AS IS" without warranties, guarantees or representations of any kind, either express or
implied.
The information in this document is subject to change without notice. Every effort has been made in the preparation
of this document to ensure accuracy of the contents, but all statements, information, and recommendations in this
document do not constitute a warranty of any kind, express or implied.

Huawei Technologies Co., Ltd.
Address: Huawei Industrial Base
Bantian, Longgang
Shenzhen 518129
People's Republic of China
Website:
http://www.huawei.com

Email:
support@huawei.com



Technical White Paper for IPv6 Network End-to-End Evolution

Contents

Issue 1.0 (2011-11-30) Huawei Proprietary and Confi dential
Copyright © Huawei Technologies Co., Ltd.
ii

Contents
1 Preface ..................................................................................................................................................... 2
1.1 Two Problems Existing on the IP Network................................................................................... 2
1.2 What Solution can Solve the Problems? .................................................................................... 3
2 Impact of NAT on the Existing Network and Services........................................................................... 5
2.1 Impact on Network Devices ........................................................................................................ 5
2.2 Impact on Network Performance ................................................................................................. 5
2.3 Impact on Network Maintenance ................................................................................................. 6
2.4 Impact on Services and Applications ........................................................................................... 6
3 Impact of IPv6 on the Existing Network and Services ........................................................................... 9
3.1 Impact on Network Devices .......................................................................................................10
3.2 Impact on Network Performance ................................................................................................ 11
3.3 Impact on Network Maintenance ................................................................................................12
3.4 Impact on Services and Applications ..........................................................................................12
4 Key Technologies ....................................................................................................................................13
4.1 Overview of Transition Technologies .........................................................................................13
4.2 Dual Stack .................................................................................................................................15
4.3 NAT ...........................................................................................................................................18
4.3.1 CGN Technological Requirements .....................................................................................19
4.3.2 NAT64 ...............................................................................................................................22
4.4 BNG/CGN Convergence ............................................................................................................23
4.5 DS-Lite ......................................................................................................................................24
5 Suggestions for Network Evolution Deployment ..................................................................................25
Technical White Paper for IPv6 Network End-to-End Evolution

Contents

Issue 1.0 (2011-11-30) Huawei Proprietary and Confi dential
Copyright © Huawei Technologies Co., Ltd.
iii

5.1 Deploying the Dual Stack ...........................................................................................................25
5.2 Deploying the CGN ...................................................................................................................26
5.3 Evolving to the IPv6 Only Network ............................................................................................28
6 IPv6 Evolution Solution Selection .........................................................................................................30
7 Conclusion ..............................................................................................................................................31
A References ..............................................................................................................................................32
B Acronyms and Abbreviations ................................................................................................................34
Technical White Paper for IPv6 Network End-to-End Evolution

Figures

Issue 1.0 (2011-11-30) Huawei Proprietary and Confi dential
Copyright © Huawei Technologies Co., Ltd.
iv

Figures
Figure 3-1 Impact of IPv6 deployment on network devices ..............................................................10
Figure 4-2 Implement differentiated assignment of NAT resources and ALG ability based on user
group. BNG/CGN convergence architecture .....................................................................................23
Figure 5-3 Upgrading backbone network and reconstructing SPOP and CPE in the early deployment
phase ...............................................................................................................................................26
Figure 5-4 Deploying BNG and CGN to resolve address exhaustion issue .......................................27
Figure 5-5 Deploying centralized NAT devices to resolve address exhaustion ..................................28
Figure 5-6 Upgrading the access network and deploying the NAT64 and IPv6-only network ...........29

Technical White Paper for IPv6 Network End-to-End Evolution

Tables

Issue 1.0 (2011-11-30) Huawei Proprietary and Confi dential
Copyright © Huawei Technologies Co., Ltd.
v

Tables
Table 4-1 Comparison of the three transition technologies ...............................................................15
Table 4-2 Comparison of the native dual stack and MPLS 6PE/6vPE ...............................................16
Table 4-3 Comparison of the two deployment modes .......................................................................21

Technical White Paper for IPv6 Network End-to-End Evolution

1 Preface

Issue 1.0 (2011-11-30) Huawei Proprietary and Confi dential
Copyright © Huawei Technologies Co., Ltd.
1

Technical White Paper for IPv6 Network End-to-End
Evolution
Keywords
IPv6, Dual stack, CGN, NAT, NAT444, NAT44, NAT64, DS-Lite, BNG/CGN
convergence
Summary
As the IPv4 address exhaustion issue turned to reality, evolution towards to IPv6 already
becomes the emphasis of carriers’ work. Although IPv6 is the ultimate solution for
resolving the address exhaustion issue, the fact is that IPv4 and IPv6 will coexist over the
long-term. NAT deployment is inevitable during the IPv6 transition, and directly results
in a complex network in which private IPv4 addresses, public IPv4 addresses, and IPv6
addresses coexist.
This document analyzes the root cause of the complexity; describes the key technologies
involved in network IPv6 evolution, and provides suggestions for deploying IPv6
network at early stage and solving IPv4 address exhaustion issue, smoothly migrating to
IPv6. The document also analyzes the mainstream operator’s choice for IPv6 migration
technology and the key factors they considered.
Technical White Paper for IPv6 Network End-to-End Evolution

1 Preface

Issue 1.0 (2011-11-30) Huawei Proprietary and Confi dential
Copyright © Huawei Technologies Co., Ltd.
2

1 Preface
1.1 Two Challenges Confronted by IP Network
The development of IP network is driven by services and applications. Each terminal
must be configured with a globally unique and usable IP address. However, obtaining
IPv4 addresses will become extremely difficult in the near future; IANA already allocated
its last five class-A IPv4 address segments in February 2011.
At present, the IP network is confronting two major challenges.
New Services Need More IP Addresses
Mobile terminals and mass terminals from the Internet of Things need huge numbers of
IP addresses. IPv4 could only provide 4.3 billion globally unique IPv4 addresses, of
which 3 billion are available - a clearly inadequate number in the context of the world's
population and the growth of the Internet. In addition, the distribution of IPv4 addresses
is uneven due to historical reasons, causing many carriers to suffer a shortage of IP
addresses and forcing them to use private addresses (RFC1918) during service
deployment.
The potentials for 50 billion connections have already been proposed. It is forecast that
about 2 billion residential broadband devices, 5 billion mobile devices, and 50 billion
M2M devices in 2020 will be connected to the Internet. The actual number of devices is
likely to be much larger than this, which of course the current IPv4 network cannot even
begin to hope to cope with.
IPv6 is Incompatible with IPv4
IPv6 has been developed to resolve the address exhaustion issue. The core protocol
standard of IPv6 has been stable since 2008,which already meet the requirements of IPv6
deployment, and the standards for fixed and mobile IPv6 applications are almost mature.
In fact, currently the biggest issue is the incompatibility between IPv6 and IPv4. Most
Technical White Paper for IPv6 Network End-to-End Evolution

1 Preface

Issue 1.0 (2011-11-30) Huawei Proprietary and Confi dential
Copyright © Huawei Technologies Co., Ltd.
3

existing application software cannot run on IPv6-only computers, because application
software must invoke the socket function during program initialization, however, the
parameters of socket function differ in IPv6 and IPv4, so if the programmers didn’t
consider the IPv6 factor , the program initialization will fail. To run current application
software on the IPv6 protocol, the source code must be modified, recompiled, and
reinstalled.
1.2 Solution to Address the Challenges
There are two ways of solving the address exhaustion issue: IPv6 and NAT. Each has its
own advantages and disadvantages.
NAT Solution
In the NAT solution, private IPv4 address and NAT (Network Address Translation)
technologies solve the address shortage problem by allowing multiple users to share a
public address. Although this solution is widely deployed in commercial networks (NAT
generally does not encounter application interconnection problems), the solution still only
support limited IP addresses (For example even with class-A addresses there is still only a
limited number before the addresses are exhausted). At present, the applications
supporting NAT normally adopt the client/server architecture in which the client initiates
the service connection; NAT goes well with this kind of applications (which have a
simple, undirectional service connection). However, NAT must support the corresponding
ALG (Application Layer Gateway) when the application has complex service connections.
P2P applications require cooperation between applications and NAT ( for example, the
home gateway supports UPnP); this type of cooperation cannot be supported in carriers'
NAT due to the security and performance issues.
Moreover, private addresses are still insufficient for a large-scale network. NAT mitigates
rather than eliminates the address exhaustion problem, the ultimate solution for IPv4
address issue is IPv6 migration.
IPv6 Solution
The huge number of IPv6 addresses in the IPv6 solution resolves the address exhaustion
issue completely. However, most IPv4-based applications cannot run in a whole new
Technical White Paper for IPv6 Network End-to-End Evolution

1 Preface

Issue 1.0 (2011-11-30) Huawei Proprietary and Confi dential
Copyright © Huawei Technologies Co., Ltd.
4

IPv6-only network, and interconnection between IPv6-based applications and IPv4-only
network is still quiet difficult now. Problems still exist in application deployment
scenarios which only NAT64 devices are used to perform network-layer translation
processing. An increasing number of IPv6 programs will adopt technologies such as
STUN (Session Traversal Utilities for NAT) and ICE (Interactive Connectivity
Establishment) to resolve the interconnection issue at the application layer. The
application is responsible for detecting NAT64 and obtaining the related address
translation information for interconnection processing.
An IPv6-only network is therefore not a feasible method for resolving the address
exhaustion issue in the current existing networks.
SummaryNetworks must support dual stack (both IPv4 protocol and IPv6 protocol) over
the long-term to enable the inevitable coexistence of IPv4 public networks, IPv6 networks,
and IPv4 private networks. A network that uses public IPv4 addresses, IPv6 addresses,
and private IPv4 addresses is considerably more complex than an IPv4-only network,
which naturally will impact construction and O&M of network.
Technical White Paper for IPv6 Network End-to-End Evolution

2 Impact of NAT on the Existing Network and
Services

Issue 1.0 (2011-11-30) Huawei Proprietary and Confi dential
Copyright © Huawei Technologies Co., Ltd.
5

2 Impact of NAT on the Existing Network and
Services
2.1 Impact on Network Devices
The basic IPv4 protocol remains the same during NAT deployment, meaning that existing
network devices do not require adjustments, although some application systems need to
change the configurations for private addresses.
The address translation function needs to be added to the network through either
independent NAT devices or adding NAT modules on existing devices.
2.2 Impact on Network Performance
NAT increases processing delays and the complexity of networks and routes. As NAT is a
traffic convergence point, it is difficult to back up all NAT sessions on carriers' networks,
users may have to operate to re-establish NAT sessions when a fault occurs, which
reduces network reliability.
NAT's defects impact network security as follows:
￿
Certain applications such as the IPSec and DNSsec cannot traverse NAT.
￿
NAT's stateful feature makes it vulnerable to DOS attacks.ALG integrated into the
NAT is also a weak point in NAT security.
These flaws reduce network security and service provisioning capability.
Technical White Paper for IPv6 Network End-to-End Evolution

2 Impact of NAT on the Existing Network and
Services

Issue 1.0 (2011-11-30) Huawei Proprietary and Confi dential
Copyright © Huawei Technologies Co., Ltd.
6

2.3 Impact on Network Maintenance
The effects of NAT deployment on network maintenance are as follows:
￿
Difficult fault location
Locating faults on the IP network is not easy. After NAT is introduced,
Ping/Traceroute is unavailable in NAT scenarios, which complicate fault location
and increase service interruption durations.
Certain services possibly cannot operate correctly in NAT environment. When a user
is switched from a public IPv4 address to a private IPv4 address, some existing
applications may not work correctly.
￿
Compliance with rules
Most countries implement rules for Internet source address tracing. During NAT
deployment, log servers need to be configured to store users' network visit records.
However, if all NAT sessions for each user are recorded, log traffic on each NAT
device may reach tens of megabits per second, requiring high-performance log
servers with enormous storage capacities, and log records may also be lost due to the
performance problems.
The increased number of NAT devices, more difficult fault location, possible user
complaints, and source address tracing issue dramatically increase network maintenance
difficulties and workload.
2.4 Impact on Services and Applications
NAT technology affects services and applications as follows:
￿
Reduces user service experience
− The increased processing delay reduces application performance.
− Additional signaling interaction is required for service flows to traverse NAT,
which cause slower application response speeds.
− Certain applications consider the access of multiple terminals using a shared IP
address as an attack and require additional authentication strings which
complicate user operations.
Technical White Paper for IPv6 Network End-to-End Evolution

2 Impact of NAT on the Existing Network and
Services

Issue 1.0 (2011-11-30) Huawei Proprietary and Confi dential
Copyright © Huawei Technologies Co., Ltd.
7

− All users sharing the same IP address will be blacklisted when even just one of
them do something wrong (such as sending malicious emails).
− Services using IP addresses for location identification are no longer available.
− P2P performance is reduced and certain functions are even unavailable.
￿
Degrades carriers' services
- If NAT is deployed between users and DPI devices, the DPI function is
unavailable.
- User information is obtained through IP addresses for certain value-added
services. NAT affects this kind of applications due to sharing a single address
by multiple users; an application-layer gateway must be deployed for VoIP
applications.
￿
Increases application-layer costs
The cost of developing, deploying, operating, and maintaining an application is
increased.
− NAT has multiple behavior modes, and the application need to detect and
process these modes accordingly. This in turn increases software development
complexity.
− Port information must additionally be recorded on the website.
− Many applications need specified intermediate servers to process the
interconnection between different private-address users.
￿
Blocks certain applications
Applications using IPSec and DNSsec cannot work properly in NAT environment.
In addition, different vendors implement NAT differently, the difference even exist in
different platforms of one single vendor. Therefore, certain applications can run on
certain NAT devices but not on others.
If the BNG allocates private IPv4 addresses for CPEs and then the CPE allocates
private IPv4 addresses for terminals, two address translations are performed for
services: one on the CPE and the other on the NAT, which may affect certain
applications too.
Technical White Paper for IPv6 Network End-to-End Evolution

2 Impact of NAT on the Existing Network and
Services

Issue 1.0 (2011-11-30) Huawei Proprietary and Confi dential
Copyright © Huawei Technologies Co., Ltd.
8

These disadvantages do not affect the widespread NAT deployment in commercial
networks because the widely address exhaustion issue and the facts that NAT is the
only technology which can protect existing IPv4 investment. Supporting NAT
already becomes one must-have feature for new applications; as NAT-related
standards are currently being improved, new applications can use those new
technologies to bypass the limitations of the network layer by increasing the
complexity of the application layer.
Technical White Paper for IPv6 Network End-to-End Evolution

3 Impact of IPv6 on the Existing Network and
Services

Issue 1.0 (2011-11-30) Huawei Proprietary and Confi dential
Copyright © Huawei Technologies Co., Ltd.
9

3 Impact of IPv6 on the Existing Network and
Services
In the current industry chain, routers, switches, and terminal operating systems support
almost all IPv6 features. However, CPEs, access equipments, SPOP devices, NMSs, and
application service systems may only support some features. At present, the IPv6
migration of some telecom services such as TV and Voice is still quiet complex (not only
involving the migration of bearer network ,but also including the possible replacement
of terminals and service systems), the migration cost and maturity still need to be
improved, , special cautious are still needed when it comes to large-scale commercial
deployment .
Technical White Paper for IPv6 Network End-to-End Evolution

3 Impact of IPv6 on the Existing Network and
Services

Issue 1.0 (2011-11-30) Huawei Proprietary and Confi dential
Copyright © Huawei Technologies Co., Ltd.
10

3.1 Impact on Network Devices
Figure 3-1 Impact of IPv6 deployment on network devices

IP Backbone and Metro Aggregation
The backbone network and metro aggregation network provide tunnels for carrying IPv6
services. Routers can effectively support IPv6 by upgrading software or simply enabling
IPv6.
The metro aggregation network and switches are used as tunnels for L2 transparent
transmission, which goes well for IPv6 services carried through PPPoE. However, when
it comes to native IPv6 services carried through IPoE, certain protocol packets are
processed as unknown multicast packets (which lead to security risks); some features
such as DHCPv6 snooping, MLD snooping, or ND snooping are required, network
upgrade may be required to support them.
SPOP
SPOP devices include BRASs, SRs, AAA servers, DHCP servers, and DNS servers, all of
which generally need upgrades. When IPvt is introduced, some new interfaces or
protocols are needed for accounting, online queries, and RADIUS, which need BRAS
vendors and accounting devices vendors to re-perform development and integrated tests.
Without reconstruction or
upgrade.
With reconstruction or upgrade which costs little
and is performed with little difficulty.
With reconstruction or upgrade which costs
much and is performed with much difficulty.
Technical White Paper for IPv6 Network End-to-End Evolution

3 Impact of IPv6 on the Existing Network and
Services

Issue 1.0 (2011-11-30) Huawei Proprietary and Confi dential
Copyright © Huawei Technologies Co., Ltd.
11

Access
DSLAMs, OLTs, ONUs, MxUs, and switches are used as tunnels for L2 transparent
transmission, the mass deployment of access-layer devices leads to more upgrade or
replacement costs.
CPE
While CPEs in bridging mode can support IPv6 transparent transmission, CPEs in routing
mode may need to be replaced to support IPv6.
Solutions used in different stage of IPv6 deployment may vary greatly; for example, 6RD
solution may be suitable to quickly deploy IPv6 in pilot phase, while dual stack are the
best choice in commercial deployment phase, and DS-Lite is also a choice for carriers
who face the address shortage issue. Therefore, CPEs need to support various technical
solutions through remote configurations or software upgrades.
The mass deployment of CPEs leads to more upgrade or replacement costs.
NMS and OSS
The NMS and OSS must be upgraded to process the IPv6 MIB and user management
interface, which generally needs software upgrades and integrated test.
Other Devices
The DNS system can be configured to support dual stack(some old DNS versions may
need software upgrades).
Firewalls, load balancing devices, and DPI devices (there devices are widely used in data
centers) from different vendors may have different supporting degree of IPv6, there are
few commercial available products nowadays.
3.2 Impact on Network Performance
Enable IPv6 on high-performance routers have limited impact on its performances.
However, the available resources of certain devices may be reduced (for example, the
number of online users on BRAS and the processing capability of the AAA system), an
assessment for them is necessary, especially when there are heavy traffic loads.
Technical White Paper for IPv6 Network End-to-End Evolution

3 Impact of IPv6 on the Existing Network and
Services

Issue 1.0 (2011-11-30) Huawei Proprietary and Confi dential
Copyright © Huawei Technologies Co., Ltd.
12

Normally IPv6 deployment does not affect the delay, jitter, and packet loss ratio of a
network, and route convergence performance is not greatly impacted by faults when just a
few IPv6 routes exist.
3.3 Impact on Network Maintenance
Although IPv6 demands greater maintenance work and skill requirements, the actual
impact on network maintenance is limited and engineers can transition fairly easily from
IPv4 to IPv6.
During the early deployment phase, all systems must be integrated, tested, and deployed;
other maintenance tasks of developing new services and service provisioning are
performed in the later phase, which follows the general process for introducing new
technologies.
3.4 Impact on Services and Applications
Normally IPv6 deployment on the IP network does not affect existing network services
and applications, and users can obtain the ability of accessing IPv6 resources. Service
systems such as DNS must be adjusted during deployment, the incorrect configurations or
defective software may degrade end user experience.
If IPv6 is enabled on a user's host without a reliable connection to the IPv6 Internet, QoS
may decrease because certain applications or operating systems use IPv6 by default; for
example, Windows Vista (version earlier than SP1) defaults to IPv6 if dual stack is
available. Specifically, Vista obtains the IPv4 and IPv6 addresses from the DNS server
and then initiates a service connection request using IPv6. If this fails, the IPv4
connection is adopted after a significant delay (tens of seconds). If a user enables dual
stack but cannot access the IPv6 Internet, web page display is noticeably slow.
Although the IPv6 is regarded as the best solution to replace IPv4, its development is
slow than expectation except in highly competitive areas or when powered by strong
governmental support. The root cause is because IPv6 is incompatible with IPv4, which
lead to higher costs and risks. However, as the only solution for IPv4 address issue, the
development of IPv6 is inevitable, though the market factor will affect the schedule.
Technical White Paper for IPv6 Network End-to-End Evolution

4 Key Technologies

Issue 1.0 (2011-11-30) Huawei Proprietary and Confi dential
Copyright © Huawei Technologies Co., Ltd.
13

4 Key Technologies
4.1 Overview of Transition Technologies
Technologies that can smoothly evolve, allow the coexistence of IPv4 public networks,
IPv4 private networks, and IPv6-only networks, are very vital, such as NAT which
supports the coexistence of IPv4 private networks and IPv4 public networks. For
migration from IPv4 to IPv6, among the mass of transition technologies, dual stack,
DS-Lite, and NAT64 (a late phase technology) are believed to be the best choices for
carriers to deploy. Although 6RD technology was a previous contender, it is not viable for
large-scale commercial deployment:
￿
Lack support from industry chain.
￿
Depend on existing IPv4 network. Secondary network reconstruction is required to
evolve to an IPv6-only network.
￿ IPv6 packets are encapsulated on an IPv4 tunnel while independent 6RD gateways
are used for decapsulation. Consequently, it is impossible to manage users and
services or implement QoS and traffic management, making overall network
management unfeasible.
￿ For CPEs in bridging mode, specific drivers must be installed on PCs or terminals,
which in turn inhibit the wide deployment of low-cost bridging CPEs. For CPEs in
routing mode, there is no cost advantage in supporting 6RD compared with
implementing other solutions.
The dual stack solution is the same as the DS-Lite solution in the following contents:
￿
The dual stack is adopted.
Technical White Paper for IPv6 Network End-to-End Evolution

4 Key Technologies

Issue 1.0 (2011-11-30) Huawei Proprietary and Confi dential
Copyright © Huawei Technologies Co., Ltd.
14

￿ The communication must happen between terminals running same kind of IP
protocol (IPv4 to IPv4, IPv6 to IPv6).
The difference between the dual stack solution and DS-Lite solution is that DS-Lite
allows carriers to deploy IPv6-only networks.
Only NAT64 supports accessing IPv4 services for IPv6 terminals. Table 4-1 compares the
three mainstream transition technologies.
Technical White Paper for IPv6 Network End-to-End Evolution

4 Key Technologies

Issue 1.0 (2011-11-30) Huawei Proprietary and Confi dential
Copyright © Huawei Technologies Co., Ltd.
15

Table 4-1 Comparison of the three transition technologies

Dual Stack
DS-Lite
NAT64
Terminal/Host IPv4-only or IPv6-
only or dual stack
IPv4-only or IPv6-only or
dual stack.
IPv6 only
CPE Supports CPEs in
bridging mode;
requires upgrades
for CPEs in routing
mode. CPEs in
routing mode will be
mainstream.
Supports only CPEs in
routing mode.
CPEs must support the
DS-Lite function.
N/A
Access network Does not affect for
PPPoE access. The
access network must
support IPv6
features for IPoE.
Does not affect for PPPoE
access.
The access network must
support IPv6 features for
IPoE.
N/A
SPOP Dual stack. IPv6-only if the standalone
DS-Lite gateway (AFTR) is
deployed.
AFTR can be integrated
into BRAS.
N/A
Backbone
network
Dual stack. Dual stack or IPv6-only. N/A
Special-purpose
gateway
devices
None. AFTR ( Standalone AFTR
may reduce network
manageability)
NAT64
gateway.
Industry
maturity
Good. Moderate.
There is no requirement on
the application layer.
Poor.
Few
applications
support
NAT64.

4.2 Dual Stack
The coexistence of IPv4 and IPv6 networks make dual stack as the foundation for IPv6
evolution. Dual Stack is a necessity for the IP backbone network and terminals; inn most
scenarios, the BNG must also support dual stack. BNG and CPE are seen to be the key
aspects of IPv6 evolution.
Technical White Paper for IPv6 Network End-to-End Evolution

4 Key Technologies

Issue 1.0 (2011-11-30) Huawei Proprietary and Confi dential
Copyright © Huawei Technologies Co., Ltd.
16

IP Backbone Network
The IP backbone network supports two technical forms of dual stack: native dual stack
and MPLS 6PE/6vPE.
￿
Native dual stack means to enable the IPv6 function and routing protocols that
support IPv6 based on the existing IPv4 routers and links. IPv6 packets are
encapsulated and forwarded at the link layer much in the same way as IPv4 packets.
￿
MPLS 6PE/6vPE means to only enable IPv6 on the PE router; 6PE/6vPE can
encapsulate IPv6 packets into the MPLS tunnel for forwarding when the existing
MPLS network remains unchanged.
Both modes are widely used in commercial networks nowadays.
Table 4-2 Comparison of the native dual stack and MPLS 6PE/6vPE

Native Dual Stack
MPLS 6PE/6vPE
Implementation
cost
IPv6 is enabled on all devices.
Implementation cost is high.
IPv6 is enabled only on PE routers.
Implementation cost is low.
Protocol
deployment
IPv6 IGP/BGP operates on all
routers.
The P router in the MPLS network
remains unchanged. The MP-BGP
is deployed between PE routers.
Scalability Unlimited. Unlimited.
Maintenance
cost
Must maintain the
Newly-introduced IPv6
protocol and IPv6 routing in
all nodes.
As a new service of the MPLS,
IPv6 has little impact on existing
maintenance loads. Only the PEs
must be maintained.
Service support Unicast services/Multicast
services.
Multicast services are not yet
mature. VPN application is
supported.

While some believe that the dual stack is unsuitable due to the high performance
requirements on device resources and high maintenance loads. However, the router itself
is the high-performance device, plus the rapid development of chip technologies for
forwarding and lookup will avoid bottlenecks in the future. Additionally, the history of
network development also shows that maintenance capabilities and resources should
catch up with new services and technologies.
Technical White Paper for IPv6 Network End-to-End Evolution

4 Key Technologies

Issue 1.0 (2011-11-30) Huawei Proprietary and Confi dential
Copyright © Huawei Technologies Co., Ltd.
17

Therefore, the evolutionary roadmap of the backbone network is destined to be dual stack until
IPv4 becomes obsolete. BNG
IP edge nodes are called BNG( Broadband Network Gateway), which controls users
access, services authorization and address assignment; both BRAS and SR is one device
form of BNG.
When one BNG supports dual stack, , besides the ability of IPv4 and IPv6 address
assignment, the BNG also need to be modified in other fields ( such as session state
management,, accounting, QoS, and security) to adapt IPv6 services. While interfaces
between the BNG and service systems (such as the NMS, AAA server, DHCP server, and
Policy server) exist, cooperation with the peripheral systems is required for the BNG to
support dual stack. Therefore, detailed integrated test must be carefully performed before
IPv6 is deployed.
The allocation mode for IPv6 is quite different from that for IPv4. With the abundant IPv6
address space, a suitable network prefix should be allocated for each user (see RFC3633
for details); this is reason why CPEs in routing mode will be mainstream devices.
Considering the management and maintenance, the recommendation is allocating an
independent /128 host address for the CPE WAN interface.
CPE
CPEs are vital during network evolution. Dual-stack CPEs in routing mode will become
the mainstream devices over the long term (no matter PPPoE or IPoE).
CPEs use the DHCPv6 Prefix Delegation to obtain an IPv6 prefix from the BNG through
the WAN interface, divide the IPv6 prefix into multi subnet prefix, and then allocate the
subnet prefix to the LAN interface. On the LAN side, user terminals can obtain addresses
using DHCPv6 or SLAAC (CPEs must support both modes since the capabilities of user
terminals vary). CPEs should have the ability to be upgraded to support IPv6 multicast
services. As the IPv6 multicast architecture for home networks is not yet perfect, CPEs
must be in the hardware-ready state to ensure that IPv6 multicast services can be
supported after software upgrades. In the future, HD TVs and internet videos will
consume increasingly bandwidth; therefore CPEs must support high-speed forwarding
capabilities to carry any conceivable ratio of IPv4 and IPv6 services.
Technical White Paper for IPv6 Network End-to-End Evolution

4 Key Technologies

Issue 1.0 (2011-11-30) Huawei Proprietary and Confi dential
Copyright © Huawei Technologies Co., Ltd.
18

CPEs must also retain the original functions of IPv4 such as DHCP, NAT, port mapping,
and UPnP. Following the evolution of NAT technology, CPE should also have the ability
to be upgraded to support new protocols.
CPEs should support various IPv6 service deployment solutions by remote software
upgrade or configuration modification. For example, in the early phase 6RD or dual stack
is deployed, in the later phase DS-Lite may be introduced to solve the address issue. In
this case, the solution migration can be implemented without entering users' homes,
therefore saving the deployment cost.
4.3 NAT
During network evolution, the NAT technology is omnipresent in multiple modes. In the
early phase of network evolution, NAT44 or NAT444 solutions are required to resolve the
IPv4 address exhaustion. During the mid and late phases, NAT64 is the key technology
for enabling IPv6 to access IPv4. Besides, many other technologies that avoid NAT444
translations have been proposed too.
When NAT technologies and their variations (such as the L2 Aware NAT, DS-Lite) are
deployed on carriers' networks, the following factors must be considered:
￿
Sufficient performance capacity to support the planned number of users.
￿
High reliability to guarantee good user experience.
￿ Manageability.
￿
Convenient source address tracing.
￿
Application-friendly NAT.
Carrier-grade NAT (CGN) and large scale NAT (LSN) are just different
terminologies for NAT in ISP scenario. As no standard to define whether the NAT
reaches carrier class, LSN has been proposed. (In this document, CGN is used as it is a
better known terminology.)
Technical White Paper for IPv6 Network End-to-End Evolution

4 Key Technologies

Issue 1.0 (2011-11-30) Huawei Proprietary and Confi dential
Copyright © Huawei Technologies Co., Ltd.
19

4.3.1 CGN Technology Requirements
CGN technology requirements are as follows:
￿
Performance and capacity: On carriers' networks, NAT can support hundreds of
thousands of users, each of whom generates an average traffic flow of hundreds of
kilobits per second; therefore NAT should have a forwarding capability of at least
100Gbit/s forwarding ability. Tests also show that dozens of TCP connections are
generated when a Web2.0 page is clicked, over one hundred sessions are generated
for a P2P application; generally, a quota of 1,000 ports per user meets common
requirements. Therefore NAT device must be able to establish millions of sessions
per second and maintain tens of millions of active sessions.
￿
Reliability: NAT reliability can be improved by deploying redundant NAT devices
and/or redundant NAT card-level backup for automatic switchover if an active
device or card fails. Unlike common services, NAT sessions are stateful, and session
generation and aging are rapid. On the CGN, millions of sessions may change states
each second. While protocol interaction is required to back up sessions, this method
is not actually reliable. Actually as the active duration for most NAT sessions is short
and backup is not required, the common view is only long lived sessions need
backup.
￿
User management: Port limit management is necessary in CGN deployment to
avoid abuse. The CGN is also need to be manageable, supporting various features:
guarantee unique external addresses, sustain port parity and avoid special-purpose
ports (for example, those identified as viruses).
￿
Source address tracing: Also a vital part of NAT deployment. Source address
tracing need support from application layer; For example, the access log must record
not only IP addresses but also port number. In the CGN environment, using the
common log model (logs are recorded based on sessions), log traffic may reach tens
of megabytes per second, therefore CGN need to support high log-processing
performance and storage systems which increase maintenance costs. By using
pre-allocation technology (CGN reserve hundreds of ports for users) , NAT log size
can be reduced to at least 1/1000 of its original size.
￿
Application-friendly NAT:
NAT has multiple operating modes based on how it is implemented:
− Full cone NAT
Technical White Paper for IPv6 Network End-to-End Evolution

4 Key Technologies

Issue 1.0 (2011-11-30) Huawei Proprietary and Confi dential
Copyright © Huawei Technologies Co., Ltd.
20

− Address-restricted cone NAT
− Port-restricted cone NAT
− Symmetric NAT
While the full cone NAT poses greater security risks, it is the most
application-friendly and boasts the fewest limitations. It is advisable to deploy full
cone NAT on carriers' networks for the following reasons:
− Users are responsible for their own security in the existing IP network. Too many
restrictions may increase complaints and fault reports, which increase operator’s
cost.
− Strict limitations also increase the difficulty of application development and
deployment /operating costs.
￿
On–demand Deployment
CGN supports NAT44, NAT64, and DS-Lite through configuration changes or
software upgrade. In different phases of network evolution, service requirements are
met by enabling different features. It is not necessary to replace hardware, thereby
protecting investment.
CGN Deployment on the Network
Based on the deployment location of NAT in the network, the CGN can be deployed in
either centralized or distributed mode:
￿
Centralized mode: NAT provides services for private address users across the entire
network. Either the NAT function modules are added to core routers or standalone
NAT devices are attached to the border gateway. However, adding NAT function
module on the CR does not comply with the network design principles of CR
(simple, stable, and reliable). Therefore, adding NAT function module on CRs is not
recommended.
￿
Distributed mode: NAT provides services for private network users in specific areas.
Either the NAT function module is added to BNG or NAT devices are attached to
BNG.
Table 4-3 describes the advantages and disadvantages of the two deployment modes.
Technical White Paper for IPv6 Network End-to-End Evolution

4 Key Technologies

Issue 1.0 (2011-11-30) Huawei Proprietary and Confi dential
Copyright © Huawei Technologies Co., Ltd.
21

Table 4-3 Comparison of the two deployment modes

Centralized NAT
Distributed NAT
Construction cost Few devices yield low
construction costs for each
user.
Construction costs for each user is
higher.
Network routing Complex routing
deployment; unavoidable
traffic bypass; possible
network adjustment are need
since NAT change the
original traffic mode.
Limited impact on network
structure; routings are only
adjusted on SPOP points; no
changes on upper layers of SPOP .
Maintenance and
troubleshooting
Each NAT covers a broad
activity range so faults have a
large effect and are difficult
to locate. However, the small
number of NAT devices can
be centrally maintained and
faults quickly rectified.
Each NAT covers a small activity
range so faults are easily located.
Multi-point deployment of the
NAT may lead to complex
maintenance.
Performance
requirement
High requirements on NAT
forwarding performance ,
session capacity, and session
creation speed of NAT.
Moderate requirements for NAT
devices; NAT devices even can be
integrated into BNG.
Logs Requires log servers with
high performance capabilities
and reliability.
The NAT is integrated into the
BNG and the NAT log function
can be implemented by querying
the allocation record of the port
from the AAA server without
deploying independent log
servers.

Technical White Paper for IPv6 Network End-to-End Evolution

4 Key Technologies

Issue 1.0 (2011-11-30) Huawei Proprietary and Confi dential
Copyright © Huawei Technologies Co., Ltd.
22

4.3.2 NAT64
The NAT64 is an address translation technology that enables IPv6 terminals to access
IPv4 servers. The IETF doesn’t intend to develop standard for IPv4 terminals to access
IPv6 services.
In contrast with NAT44's compliance with the IPv4 source address and source port,
address translation by NAT64 complies with the IPv6 source addresses and source port
only. NAT64 must cooperate with DNS64, which can be integrated into existing DNS.
Additionally, NAT 64 replaces the original NAT-PT (Network Address
Translation—Protocol Translation, based on RFC2766 NAT-PT can enable IPv6 terminals
access to IPv4 servers). The obsolescence of NAT-PT is explained in RFC4966:
Implementation of NAT-PT need integrate DNS-ALG function; however, implementing
application-layer protocol such as DNS-ALG in operator environment is problematic:
￿ Difficult to control terminals choose NAT-PT device as DNS when it access IPv4
server.
￿
Poor load balancing and reliability.
￿
Vulnerability to application-layer attacks and degraded performance (CPUs and
memory resources of NAT devices are not as high as those of servers).
Similar to NAT44, NAT64 is suitable for applications in client/server mode, and data
packets do not contain address and port information. NAT64 is introduced to ensure the
simplicity of network through the deployment of E2E IPv6-only network; however, the
application layer is not ready for NAT64 yet now.
At present, the foundation for deploying IPv6-only applications on the broadband Internet
is not mature, meaning that NAT64 is not widely deployed on fixed networks. The
application of the NAT64 on the mobile Internet depends on the industry chain promoted
by carriers.
NAT64 may mainly be deployed in centralized mode as BNG will not retain the IPv4
protocol stack when IPv6 networks become mainstream, and distributed mode is cost
inefficient sinceIPv4 service traffics will drop down in that scenario.
Technical White Paper for IPv6 Network End-to-End Evolution

4 Key Technologies

Issue 1.0 (2011-11-30) Huawei Proprietary and Confi dential
Copyright © Huawei Technologies Co., Ltd.
24

PPPoE session ID or VLAN/QinQ) or L3 information (such as IPv6 address) from
CPE.Unlike NAT444 which implements two layers of NAT, BNG/CGN convergence
device implements only one layer of NAT, which is friendlier to application.
4.5 DS-Lite
DS-Lite is a lightweight dual stack, unlike dual stack, DS-Lite does not require the
entire network supporting dual stack. DS-Lite deploys an IPv4-in-IPv6 tunnel on the IPv6
network for transmitting IPv4 services, while IPv6 services are directly transmitted on
IPv6 network.
DS-Lite technology allows terminals/hosts adopting private, individually allocated IPv4
addresses so that carriers don’t need to manage end users' IPv4 addresses. Address
translation for a user's IPv4 services is performed on the AFTR (Address Family Transition
Router element) based on CPE’s IPv6 address, user’s private IPv4 address and IPv4 ports.
CPEs, also called B4 (Basic Bridging BroadBand) in DS-Lite, and AFTR perform
encapsulation and decapsulation functions. The DS-Lite is superior to dual stack solution
with private addresse in the following ways:
￿
Only one layer of NAT is needed.
￿ Don’t need to manage private IPv4 addresses on the user side.
￿
In principle, network only need to support IPv6, which is far simpler.
DS-Lite deployment can promote the development of IPv6 networks because it enables
the bearer network to be pure IPv6.
Separately deploying AFTR on network is similar with deploying a standalone 6RD
Gateway, the deployment experience from 6RD shows the management of network and
traffic is quite complex. Since User management and service processing are tightly
coupled on a carrier's network. In this scenario, BNG integrated with DS-Lite function is
a more reasonable deployment mode, another choice is adding interfaces between AFTR
and BNG, though this requires standardization.
Technical White Paper for IPv6 Network End-to-End Evolution

5 Suggestions for Network Evolution and
Deployment

Issue 1.0 (2011-11-30) Huawei Proprietary and Confi dential
Copyright © Huawei Technologies Co., Ltd.
25

5 Suggestions for Network Evolution and
Deployment
Operators need to adopt the evolutionary deployment solution according their own
situations (such as current network and services).
Operators which are forced to react to strong competitive pressures and government
policies for deploying IPv6 can select Dual Stack solution. Operators facing serious
address exhaustion can select NAT solution or Dual Stack + NAT solution. DS-Lite is
also a choice for entire new network while the related supporting system should also be
considered.
When mainstream applications and terminals all support IPv6, IPv4 can be gradually
disabled while NAT64 is deployed to meet the few last requirements for accessing
IPv4-only server.
5.1 Deploying Dual Stack for IPv6 Migration
IPv6 deployment must comply with the following deployment principle: Core network
first, then edge network. . First of all, the backbone network/IGW must support Dual
Stack; According existing network and maintenance requirement, native dual stack or
6PE/6vPE will be selected. 6PE/6vPE is more suitable for MPLS network, which only
need to upgrade. PE routers to support Dual Stack while no change need to be done on P
routers.
L3VPN leased line service may generate early Dual Stack deployment requirements f;
VPN customers’ requirements for supporting IPv6 can be met after PE routers are
upgraded to dual stack or new dual stack enabled routers are added..
Technical White Paper for IPv6 Network End-to-End Evolution

5 Suggestions for Network Evolution and
Deployment

Issue 1.0 (2011-11-30) Huawei Proprietary and Confi dential
Copyright © Huawei Technologies Co., Ltd.
26

The SPOP is the key point for IPv6 migration of public broadband service. As access
network reconstruction is not required in PPPoE scenarios, it is advisable that early dual
stack deployment of HSI (High Speed Internet) service begins with PPPoE broadband
users. BRAS and AAA system need to be upgraded or added for dual stack user access;
CPEs in bridging mode don’t need to be changed while CPEs in routing mode must be
upgraded to support dual stack (CPEs should also support future evolution by software
upgrades). During the early stage of IPv6 introduction, to keep cost effective, operators
can only upgrade part BRAS or add a few new BRAS to support dual stack, PPPoE users
in other areas can use L2TP to access dual stack enabled BRAS.
The upgrade for value added service (VAS) system must be performed simultaneously to
increase IPv6 service traffic. SS
Figure 5-3 Upgrading backbone network and reconstructing SPOP and CPE in the early
deployment phase


5.2 Deploying CGN
At present, IPv4-based services are still the dominant services. However, NAT
deployment is necessary as most carriers are IPv4 address exhaustion issue. Introducing
NAT usually changes the network traffic model, which in turn complicates traffic
management and user service identification, even affects certain services.
In BNG/CGN convergence solution, only one layer NAT is required as BNG is integrated
with DS-Lite or L2 Aware NAT. Moreover, the distributed NAT reduces requirement for
equipment performance, and implement easier location and isolation of faults. . Carriers
do not have to manage terminals' IPv4 addresses or deploy NAT log server to improve
service sensation for users. The disadvantages are:
Technical White Paper for IPv6 Network End-to-End Evolution

5 Suggestions for Network Evolution and
Deployment

Issue 1.0 (2011-11-30) Huawei Proprietary and Confi dential
Copyright © Huawei Technologies Co., Ltd.
27

￿ The cost for replacing terminals is high as the existing CPEs must be replaced to
support IPv6.
￿
The implementation of this solution depends on the support of BRAS vendors.
￿ Systems whose user identification only rely on IP addresses (such as DPI, traffic
management) will not operate normally.
Figure 5-4 Deploying BNG and CGN to resolve address exhaustion issue

Centralized NAT, which already have widely deployment, means NAT device is deployed
by the border gateway in IP core network to redirect the services from private-address
users to NAT device for address translation. The advantages of stand-alone NAT
deployment are as follows:
￿
NAT devices are widely available in the market, and the cost is reasonable.
￿ The original networks and service systems can almost remain unchanged.
The disadvantages of stand-alone NAT deployment are as follows:
￿
Faults on devices in centralized mode involve a large area and faults are difficult to
locate.
￿
The source tracing system must be constructed.
￿
No promotion effect to IPv6 deployment.
Centralized NAT can also be a choice to resolve address exhaustion issue in Dual-Stack
network..
Technical White Paper for IPv6 Network End-to-End Evolution

5 Suggestions for Network Evolution and
Deployment

Issue 1.0 (2011-11-30) Huawei Proprietary and Confi dential
Copyright © Huawei Technologies Co., Ltd.
28

Figure 5-5 Deploying centralized NAT devices to resolve address exhaustion


The industry has reached the consensus that, while native Dual Stack is the best one,
DS-Lite is another good choice for solving address exhaustion issue and accelerating
IPv6 development. The corresponding standards are almost matured, and some leading
carriers have selected DS-Lite as their migration solution, and terminal and device
suppliers are commercializing products that support DS-Lite.
The native Dual Stack solution is compatible with DS-Lite solution. The native Dual
Stack solution can be used in the early phase with DS-Lite tests (the DS-Lite network
only uses IPv6 protocol). The native Dual Stack can be easily switched to the DS-Lite
when conditions permit.
5.3 Evolving to the IPv6-Only Network
The evolution to IPv6-only networks requires two additional actions, first is upgrading
the access network to support IPv6, and second is deploying NAT64.
The trend of replacing PPPoE with IPoE requires access network must support IPv6
service sensation. IPv6 protocol packets are generally specific multicast packets in IPoE
access scenarios, in order to support IPv6, additional developing is required for legacy
security features such as the DHCP option, DHCP snooping, IP/MAC binding, and
multicast snooping/proxy. IPv6 also bring the potential risk of ICMPv6 attacks at the
access layer, which make Neighbor Discovery Snooping the must-have function for
access-layer devices.
With the boosting of IPv6 deployment, the requirements (like to be simple, low-cost, low
power consumption and easy to deployment) naturally lead to a sharp increase of
IPv6-only terminals. As certain terminals may require access to IPv4 servers, NAT64
Technical White Paper for IPv6 Network End-to-End Evolution

5 Suggestions for Network Evolution and
Deployment

Issue 1.0 (2011-11-30) Huawei Proprietary and Confi dential
Copyright © Huawei Technologies Co., Ltd.
29

should be deployed to enable IPv6 terminals to access IPv4 servers in a manageable
mode.
Figure 5-6 Upgrading the access network and deploying the NAT64 and IPv6-only network


Technical White Paper for IPv6 Network End-to-End Evolution

6 IPv6 Evolution Solution Selection

Issue 1.0 (2011-11-30) Huawei Proprietary and Confi dential
Copyright © Huawei Technologies Co., Ltd.
30

6 IPv6 Evolution Solution Selection
Surveys show that most carriers tend to choose Dual Stack to introduce IPv6 and deploy
NAT to resolve address exhaustion issue. Some carriers want to choose DS-Lite as an
evolutionary solution however, no commercialized deployment cases currently exist.
Only a few carriers are using 6to4 or 6RD as early pilot deployment solutions.
Certain carriers choose Dual Stack + NAT for the following reasons:
￿
The agency needs to solve address exhaustion issue in the short-term.
￿
Existing network devices require minimal reconstruction with Dual Stack.
￿ The CPEs in bridging mode can be unchanged.
￿
Gradual migration can be implemented.
￿
The cost for the initial deployment is low, which suits the most investment-sensitive
carriers.
Carriers who promote DS-Lite normally already had lots of investment and research in
DS-Lite field, and hold related patents, they expect a simpler network architecture in
which IPv6-only seems to be more attractive, another feature is their CPE in existing
network can support DS-Lite after low-cost software upgrades or they will have lots of
new CPEs which will occupy the most percent.
Also, some carriers are planning to test both Dual Stack + NAT and DS-Lite to evaluate
and select the optimal evolutionary technology.
Technical White Paper for IPv6 Network End-to-End Evolution

7 Conclusion

Issue 1.0 (2011-11-30) Huawei Proprietary and Confi dential
Copyright © Huawei Technologies Co., Ltd.
31

7 Conclusion
This document describes the difficulty in converting the current IPv4 Internet to IPv6 and
analyzes address translation technologies. IPv6 migration will last for a long time, and
therefore the gradual evolution of network architecture is required. Dual Stack and
DS-Lite are seen as the mainstream technology for IPv6 migration, and today most
carriers are prefer to choose Dual Stack to deploy IPv6.
As a leader in the IPv6 industry, Huawei is putting efforts to improve the deployable
end-to-end IPv6 solution consisting of terminals, networks and services. The CGN based
on NE40E router platform supports multiple IPv6 evolution solutions such as NAT44,
DS-Lite, and NAT64. Additionally, innovative BNG/CGN convergence technology
provides simple and rapid NAT+IPv6 deployment solution for carriers.
This document analyzes the root cause of the complexity; describes the key technologies
involved in network IPv6 evolution, and provides suggestions for deploying IPv6
network at early stage and solving IPv4 address exhaustion issue, smoothly migrating to
IPv6. The document also analyzes the mainstream operator’s choice for IPv6 migration
technology and the key factors they considered.
Technical White Paper for IPv6 Network End-to-End Evolution

A References

Issue 1.0 (2011-11-30) Huawei Proprietary and Confi dential
Copyright © Huawei Technologies Co., Ltd.
32

A References
1) Nordmark, E. and Gilligan, R., "Basic Transition Mechanisms for IPv6 Hosts and
Routers", RFC4213, Oct. 2005
2) Carpenter B, et al. Connection of IPv6 Domains via IPv4 Clouds[S]. RFC 3056.
3) Aoun, C. and E. Davies, "Reasons to Move the Network Address Translator -
Protocol Translator (NAT-PT) to Historic Status", RFC 4966, July 2007
4) Tsirtsis, G. and P. Srisuresh, "Network Address Translation - Protocol Translation
(NAT-PT)", RFC 2766, February 2000.
5) J Wu, et al, "4over6 Transit Solution Using IP Encapsulation and MP-BGP
Extensions", RFC5747, Mar 2010.
6) S. Jiang, D. Guo, and B. Carpenter, "An Incremental Carrier-Grade NAT (CGN) for
IPv6 Transition" draft-jiang-v6ops-incremental-cgn, work in progress, May 2009
7) A. Durand, R. Droms, B. Haberman, and J. Woodyatt, "Dual-stack lite broadband
deployments post IPv4 exhaustion", draft-ietf-softwire-dual-stack-lite-00, work in
progress, March 2009
8) X. Li, S. Dawkins, D. Ward, and A. Durand, "Softwire Problem Statement", RFC
4925, July 2007
9) Bagnulo, M., Matthews, P., and I. Beijnum, "NAT64: Network Address and Protocol
Translation from IPv6 Clients to IPv4 Servers", draft-bagnulo-behave-nat64-03
(work in progress), March 2009
10) Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum, "DNS64: DNS extensions
for Network Address Translation from IPv6 Clients to IPv4 Servers",
draft-ietf-behave-dns64-00 (work in progress), July 2009
Technical White Paper for IPv6 Network End-to-End Evolution

A References

Issue 1.0 (2011-11-30) Huawei Proprietary and Confi dential
Copyright © Huawei Technologies Co., Ltd.
33

11) Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)", RFC 2765,
February 2000.
12) Li, X., Bao, C., Chen, M., Zhang, H., and J. Wu, "The CERNET IVI Translation
Design and Deployment for the IPv4/IPv6 Coexistence and Transition",
draft-xli-behave-ivi, (work in progress), January 2010.
13) Templin F, Gleeson T, Thaler D. Intra-Site Automatic Tunnel Addressing Protocol
(ISATAP). RFC 5214 March 2008
14) Nordmark E. Stateless IP ICMP Translation Algorithm (SIIT) [S]. RFC2765,
February 2000.
15) J. De Clercq, et al, Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider
Edge Routers (6PE), RFC4798, Feb 2007
16) J. De Clercq, IPv6 Address Specific BGP Extended Community Attribute, RFC4659,
Sep 2006
17) D. Cheng, NAT44 with Pre-allocated Ports,
draft-cheng-behave-nat44-pre-allocated-ports, Mar 2011
18) P. Srisuresh et al, Traditional IP Network Address Translator (Traditional NAT),
RFC3022, Jan 2001
19) S. Asadullah et alISP IPv6 Deployment Scenarios in Broadband Access Networks,
RFC 4779, Jan 2007
20) D. Cheng, RADIUS Extensions for NAT Forwarding Port,
draft-cheng-behave-nat-fwd-port-radius-ext, Feb 2011
21) M. Boucadair, et al, Port Control Protocol (PCP) NAT-PMP Interworking Function,
draft-bpw-pcp-nat-pmp-interworking, Mar 2011
22) P. Srisuresh, etc., IP Network Address Translator (NAT) Terminology and
Considerations, RFC 2663, Aug 1999
23) T. Hain, Architectural Implications of NAT, RFC 2993, Nov 2000
Technical White Paper for IPv6 Network End-to-End Evolution

B Acronyms and Abbreviations

Issue 1.0 (2011-11-30) Huawei Proprietary and Confi dential
Copyright © Huawei Technologies Co., Ltd.
34

B Acronyms and Abbreviations
Acronym and Abbreviation
Full Name
6PE IPv6 Provider Edge Routers
6RD IPv6 Rapid Deployment
6vPE BGP-MPLS IP Virtual Private Network Extension for IPv6 VPN
AAA Authentication, Authorization and Accounting
AFTR DS-Lite Address Family Transition Router element
ALG Application Layer Gateway
B4 Base Bridging BroadBand element
BGP Border Gateway Protocol
BNG Broadband Network Gateway
BRAS Broadband Remote Access Server
CGN Carrier Grade NAT
CPE Customer Premises Equipment
DHCP Dynamic Host Configuration Protocol
DHCPv6 Dynamic Host Configuration Protocol for IPv6
DNS Domain Name System
DNSsec Domain Name System Security Extensions
DPI Deep Packet Inspection
DS Dual Stack
DSLAM Digital Subscriber Line Access Multiplexer
DS-Lite Dual Stack Lite
HGW Home Gateway
ICE Interactive Connectivity Establishment
Technical White Paper for IPv6 Network End-to-End Evolution

B Acronyms and Abbreviations

Issue 1.0 (2011-11-30) Huawei Proprietary and Confi dential
Copyright © Huawei Technologies Co., Ltd.
35

Acronym and Abbreviation
Full Name
ICMP Internet Control Message Protocol
ICMPv6 Internet Control Message Protocol version 6
IGMP Internet Group Management Protocol
IGP interior gateway protocol
IGW Internet Gateway
IP Internet Protocol
IPoE IP over Ethernet
IPSec Internet Protocol Security
IPv6 Internet Protocol Version 6
LSN Large Scale NAT
MIB Management information base
MLD Multicast Listener Discovery
MP-BGP Multiprotocol BGP
MPLS Multi-Protocol Label Switching
MxU Multiplexer Unit
NAT network address translation
NAT-PT Network Address Translation—Protocol Translation
ND Neighbor Discovery
OLT Optical Line Terminal
ONU Optical Network Unit
OSS Operations support system
P2P Peer to Peer
PPPoE Point-to-Point Protocol over Ethernet
QoS Quality of Service
RADIUS Remote Authentication Dial-In User Service
SLA Service Level Agreement
SLACC Stateless Address Autoconfiguration
SPOP Service Point of Presence
STUN Session Traversal Utilities for NAT
UPnP Universal Plug and Play
VAS Value Added Service
Technical White Paper for IPv6 Network End-to-End Evolution

B Acronyms and Abbreviations

Issue 1.0 (2011-11-30) Huawei Proprietary and Confi dential
Copyright © Huawei Technologies Co., Ltd.
36