Technical White Paper for Ipv6 Network End-To-End Evolution

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

Issue 1.0

Date 2011-11-30

HUAWEI TECHNOLOGIES CO., LTD.

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: [email protected]

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

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

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

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

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

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

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

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

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.

Summary Networks 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.

2 Impact of NAT on the Existing Network and Technical White Paper for IPv6 Network End-to-End Evolution Services

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.

2 Impact of NAT on the Existing Network and Technical White Paper for IPv6 Network End-to-End Evolution Services

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.

2 Impact of NAT on the Existing Network and Technical White Paper for IPv6 Network End-to-End Evolution Services

− 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.

2 Impact of NAT on the Existing Network and Technical White Paper for IPv6 Network End-to-End Evolution Services

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.

3 Impact of IPv6 on the Existing Network and Technical White Paper for IPv6 Network End-to-End Evolution Services

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 .

3 Impact of IPv6 on the Existing Network and Technical White Paper for IPv6 Network End-to-End Evolution Services

3.1 Impact on Network Devices

Figure 3-1 Impact of IPv6 deployment on network devices

Terminal Access Metro/Aggregation SPOP Core Services

TV UPE AGG BNG

OLT/DSLAM P CPE Server Farm PC IP/MPLS IPv4 PE PE Phone LSW UPE AGG CGN IPv6 P The CPE in bridging PPPoE packets are Tunnel services. Changes are not The BNG must Tunnel services. The Except the mode is not transparently required. be upgraded. dual stack or MPLS is Internet service, changed. transmitted on the Related adopted. Routers can self-operated PPPoE access network, no application support IPv6 perfectly. services such as The CPE in routing need to upgrade. systems such as the voice/TV are mode must be the AAA/DHCP difficult to be replaced or must be reconstructed. upgraded. updated and The deployment is re-integrated. not The CPE in bridging Upgrade must be Tunnel services. The IPv6 service recommended in mode is not performed to enable perception function can be the early phase. changed basically. the IPv6 service added to ensure the security. IPoE perception. The CPE in routing mode must be replaced or upgraded.

Without reconstruction or With reconstruction or upgrade which costs little With reconstruction or upgrade which costs upgrade. and is performed with little difficulty. much and is performed with much difficulty.

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.

3 Impact of IPv6 on the Existing Network and Technical White Paper for IPv6 Network End-to-End Evolution Services

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.

3 Impact of IPv6 on the Existing Network and Technical White Paper for IPv6 Network End-to-End Evolution Services

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

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

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

Table 4-1 Comparison of the three transition technologies

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

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

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

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

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

− 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

Table 4-3 Comparison of the two deployment modes Centralized NAT Distributed NAT

Construction cost Few devices yield low Construction costs for each user is construction costs for each higher. user.

Network routing Complex routing Limited impact on network deployment; unavoidable structure; routings are only traffic bypass; possible adjusted on SPOP points; no network adjustment are need changes on upper layers of SPOP . since NAT change the original traffic mode.

Maintenance and Each NAT covers a broad Each NAT covers a small activity troubleshooting activity range so faults have a range so faults are easily located. large effect and are difficult Multi-point deployment of the to locate. However, the small NAT may lead to complex number of NAT devices can maintenance. be centrally maintained and faults quickly rectified.

Performance High requirements on NAT Moderate requirements for NAT requirement forwarding performance , devices; NAT devices even can be session capacity, and session integrated into BNG. creation speed of NAT.

Logs Requires log servers with The NAT is integrated into the high performance capabilities BNG and the NAT log function and reliability. 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

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

4.4 BNG/CGN Convergence NAT resources can be managed and controlled for CGN. By incorporating a user-defined policy control mechanism, the carrier-grade operation and allocation of addresses and NAT resources can be implemented.

The architecture of traditional NAT management system implements policy control on user groups base on source address or domain, whereas the architecture of BNG's management system base on user accounts (single users) or control domains (user groups). Converging BNG and CGN enables the synergy of BNG and CGN, implements CGN user control policy (such as NAT port allocation policy/port segment range, NAT session number, and ALG policy) under the architecture of BNG's user management system with optimum compatibility.

BNG/CGN convergence architecture provides carrier-grade manageable NAT service:

Implement reasonable address resource allocation and management, optimize resource utilization rate.

No need for standalone log servers, lower maintenance cost.

Figure 4-2 Implement differentiated assignment of NAT resources and ALG ability based on user group. BNG/CGN convergence architecture

Radius Server PPPoEor DHCP user access authentication DNS Server IPv4 IPv4 Private Address L2 or L3 Tunnel + IPv4 Pr i vate IPv4 CPE BNG CGN

BNG User Profile from Radius CGN Profile Name CGN Profile Policy Control Template: CGN Profile local NAT port range allocation configuration CGN Profile Content NAT session number ALG capabilities Bind Lawful inspection BNG Subscriber CGN User Tunnel ID QoS/SLA ALG BNG User Group Bind CGN User Group Control Domain Instance

BNG/CGN convergence device can support DS-Lite or L2 Aware NAT. In this scenario, CPE does not need to enable NAT, BNG/CGN convergence device performs NAT functions according source IP address and source port, plus L2 information (such as

Technical White Paper for IPv6 Network End-to-End Evolution 4 Key Technologies

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.

5 Suggestions for Network Evolution and Technical White Paper for IPv6 Network End-to-End Evolution Deployment

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..

5 Suggestions for Network Evolution and Technical White Paper for IPv6 Network End-to-End Evolution Deployment

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

Terminal Access Metro/Aggregation SPOP Core Services

TV UPE AGG BNG

OLT/DSLAM P CPE Server Farm PC IP/MPLS IPv4 PE PE Phone LSW UPE AGG CGN IPv6 P

Certain terminals are All devices are upgraded to upgraded to support the IPv6 support the IPv6

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:

5 Suggestions for Network Evolution and Technical White Paper for IPv6 Network End-to-End Evolution Deployment

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

Terminal Access Metro/Aggregation SPOP Core Services

TV UPE AGG

OLT/DSLAM P CPE Server Farm PC IP/MPLS IPv4 PE PE BNG/CGN Phone LSW UPE AGG IPv6 P

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..

5 Suggestions for Network Evolution and Technical White Paper for IPv6 Network End-to-End Evolution Deployment

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

Terminal Access Metro/Aggregation SPOP Core Services

TV UPE AGG P CGN CPE OLT/DSLAM PC Server Farm IP/MPLS BNG IPv4 PE PE Phone BNG LSW UPE AGG IPv6 P

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

5 Suggestions for Network Evolution and Technical White Paper for IPv6 Network End-to-End Evolution Deployment

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

Terminal Access Metro/Aggregation SPOP Core Services

TV UPE AGG P

OLT/DSLAM NAT64 CPE Server Farm PC IP/MPLS BNG IPv4 PE PE Phone BNG LSW UPE AGG IPv6 P

Technical White Paper for IPv6 Network End-to-End Evolution 6 IPv6 Evolution Solution Selection

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

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.

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

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

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

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

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