Technical White Paper for IPv6 CGN Solution

Technical White Paper for IPv6

CGN Solution

Issue 1.0

Date 2011-11-30

HUAWEI TECHNOLOGIES CO., LTD.

Issue 1.0 (2011-11-30) Huawei Proprietary and Confidential

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

Technical White Paper for IPv6 CGN Solution Contents



ii

Contents

1 Introduction to the CGN ......................................................................................................................... 2

2 CGN Solution .......................................................................................................................................... 4

2.1 CGN Principles ........................................................................................................................... 4

2.2 CGN Packet Processing Procedure .............................................................................................. 5

2.3 CGN Technological Requirements............................................................................................... 6

2.4 CGN Application Scenarios ......................................................................................................... 7

2.5 Impact of the CGN on the Network ............................................................................................. 8

3 Key Technologies for Deploying the CGN .............................................................................................10

3.1 Classification of CGN Forms .....................................................................................................10

3.2 Classification of CGN Access..................................................................................................... 11

3.2.1 Mode 1: Access Through the L3 Tunnel ............................................................................. 11

3.2.2 Mode 2: Access Through the L2 Tunnel (NAT444) ............................................................12

3.2.3 Mode 3: Access Through the L2 Tunnel (NAT44 and Access with Any Address) ................12

3.2.4 Mode 4: Access Through the L2 Tunnel (NAT44 and Address Management and Allocation)

..................................................................................................................................................14

3.3 Controlling the NAT User Policy with BNG/CGN Convergence .................................................14

3.4 Management of Ordering Port Pre-Allocation .............................................................................17

3.5 NAT Traversal ............................................................................................................................18

3.6 High Reliability..........................................................................................................................20

4 Conclusion ..............................................................................................................................................23

A References ..............................................................................................................................................24

B Acronyms and Abbreviations ................................................................................................................25

Technical White Paper for IPv6 CGN Solution Figures



iii

Figures

Figure 2-1 Basic principle and packet processing flow of the NAPT mode........................................ 4

Figure 2-2 CGN packet processing procedure. .................................................................................. 6

Figure 3-1 CGN access mode by through the L3 tunnel ...................................................................12

Figure 3-2 CGN access mode through the L2 tunnel (NAT444) .......................................................12

Figure 3-3 CGN access mode through the L2 tunnel (NAT44 and access with any address) .............13

Figure 3-4 CGN access mode through the L2 tunnel (NAT44 and address management and allocation)

........................................................................................................................................................14

Figure 3-5 User policy control when the BNG and CGN are converged ...........................................15

Figure 3-6 Management of ordering port pre-allocation ...................................................................18

Figure 3-7 Large-scale deployment of CGN services to support NAT traversal ................................19

Figure 3-8 Backup mechanism between CGN devices .....................................................................21

Technical White Paper for IPv6 CGN Solution Tables



iv

Tables

Table 3-1 Comparison of the stand-alone CGN and integrated CGN ................................................10

Table 3-2 Comparison of the centralized CGN and distributed CGN ................................................ 11

Technical White Paper for IPv6 CGN Solution



1

Technical White Paper for IPv6 CGN Solution

Keywords

NAT, CGN, IPv6, transition technology, BNG, carrier grade NAT, source tracing, hot

backup

Summary

CGN refers to the carrier grade NAT. The CGN (number of concurrent users,

performance, and source tracing) must be greatly improved to enable large-scale

commercial deployment. The CGN can be used in multiple scenarios such as the NAT444

and DS-Lite. This document describes the NAT principles, NAT packet processing flow,

CGN tunnel mode, and CGN deployment solutions.

Technical White Paper for IPv6 CGN Solution 1 Introduction to the CGN



2

1 Introduction to the CGN

IPv4 address exhaustion represents a complex barrier that blocks carriers as they seek to

aggressively deploy mobile Internet, increase subscribers, and drive the convergence of

the Triple Play. As of February 3, 2011, all IANA IPv4 addresses across the globe had

been allocated, plunging global carriers into the crisis of IP address exhaustion. At present,

two major solutions can solve this problem:

� Deploying IPv6: This solution can resolve the above problem once and for all.

However, as most contents and applications are based on IPv4, current services may

not be inherited if networks running IPv4 are forcibly evolved to IPv6.

� NAT: To inherit IPv4 services, the large-scale deployment of private network IPv4

addresses can implement statistical multiplexing on public network IPv4 addresses,

which resolves the problem of IPv4 address exhaustion for a long time.

Carriers must consider both solutions.

The NAT solution greatly reduces investment costs as the home gateway device does not

need to be replaced. Carrier investment is further protected if legacy devices are

reconstructed and reused. In the early phase, the mature commercial NAT444 solution can

resolve address exhaustion. Evolution from IPv4 to IPv6 is a relatively long process in

which the NAT444 is currently the best solution for exploring IPv4 address space and

smoothly developing IPv4 services based on user experience, technological maturity, and

deployment complexity.

Carrier Grade NAT (CGN) is also referred to as the Large Scale NAT (LSN). The CGN

greatly improves the features of the common NAT including concurrent user capacity,

performance, and source tracing. The CGN enables large-scale commercial deployment,

Technical White Paper for IPv6 CGN Solution 1 Introduction to the CGN



3

resolves IPv4 address exhaustion, and can be deployed in multiple scenarios such as

NAT444 and DS-Lite.

Deployment of the CGN, however, faces certain problems, such as packet transmission

delays caused by address translation, difficulties in user source tracing, and the NAT

traversal of certain applications. These, of course, must be resolved.

Technical White Paper for IPv6 CGN Solution 2 CGN Solution



4

2 CGN Solution

2.1 CGN Principles

Two address translation modes exist: NAT mode and Network Address and Port

Translation (NAPT) mode. NAT mode can be used to translate the IP address in an IP

packet but not the port number; NAPT mode enables the NAT device to translate both.

Therefore, NAPT mode is used in actual configuration as NAT mode wastes addresses

because each private network IP address requires a public network IP address.

Figure 2-1 Basic principle and packet processing flow of the NAPT mode

� The NAT device receives the packet for accessing the public network sent by the

private network user.




5

� If the private network user initiates another connection, the NAT device chooses an

idle public network IP address and a port number from the address pool to create the

NAT table items.

� Based on the source and destination IP addresses as well as source and destination

port numbers of the private network, the NAT device searches the NAPT table items,

translates the packet based on the search result, and sends the translated packet to the

public network.

� After receiving a response packet from the public network, the NAT device searches

the reverse NAPT table items based on the destination IP address and port number,

translates the packet based on the search result, and sends the translated packet to the

private network.

NAPT mode translates both the IP address and port number, which fully utilizes IP

address resources and enables multiple hosts on the internal network to

simultaneously access the Internet.

2.2 CGN Packet Processing Procedure

To process packets sent from the private network to the public network, the ACL is

enabled on the interface card for all streams. Currently, TCAM searches the ACL without

affecting forwarding performance. Line rate forwarding is available. Figure 2-2 shows the

CGN packet processing procedure.

1. On the incoming interface card, search for the ACL/UCL table.

If streams require translation, sends the streams to the NAT board.

2. On the NAT board, check the IPv4 forward session table based on the triplet (source IP

address, source port number, and protocol number) or quintuple elements (source and

destination IP addresses, source and destination port numbers, and protocol number).

The packet’s IP address and port number are translated on the NAT board. The system

checks the FIB and forwards the packet to the downlink of the interface card. The

mapping conditions of a quintuplet are stricter than those of a triplet. The quintuplet is

used when security is an issue.

3. On the outgoing interface card, forward the streams of translated packets.




6

For the return streams, the destination IP address of the packet is the public network IPv4

address on the NAT. The packet is routed to the NAT unit and reverse NAT processing is

performed.

Figure 2-2 CGN packet processing procedure.

2.3 CGN Technological Requirements

� Performance capacity: On carriers' networks, the NAT can support hundreds of

thousands of users, each of whom generates an average traffic flow of hundreds of

kilobits per second. Tests show that dozens of TCP connections are generated when a

Web2.0 page is clicked, while a P2P application generates over one hundred sessions.

Generally, a reservation of 1,000 ports per user meets common requirements. The

NAT device requires a forwarding capability of at least 100 Gbit/s and must be able

to establish millions of sessions per second and maintain tens of millions of active

sessions.

� Reliability: NAT network reliability can be improved by deploying redundant NAT

devices with board-level backup for automatic switchover if an active device fails.

Unlike common services, NAT sessions are configured with states, and session

generation and aging are rapid. On the CGN, millions of sessions may change states

each second. Protocol interaction is required to back up sessions, so this is not

particularly reliable. As the time-to-live for most NAT sessions is short and backup is

not required, only sessions with a long time-to-live are currently backed up.

� User management: Port reservation management is necessary in the CGN

application scenario so that users with the same IP address can still access a network

normally if other users using that address abuse network resources. The CGN is also

manageable to guarantee various features such as unique external addresses and port

parity or to prevent special-purpose ports such as ports identified as viruses.




7

� Address source tracing: As a part of NAT deployment, source tracing requires the

support of the application layer. For example, the access log must record not only IP

addresses but also port information. Logs are recorded based on common

implementation and sessions. In the CGN environment, log traffic may reach tens of

megabytes per second, which necessitates high performance log-processing and

storage systems and also increases maintenance costs. The CGN can reserve

hundreds of ports for users at one time using port pre-allocation technology, which

reduces the NAT log size to at least 1/1000 of its original size.

� NAT traversal: For certain TCP/UDP applications such as end-to-end applications,

including multimedia sessions, file sharing, and games, IP address or port

information may exist in payloads. The application program fails to traverse NAT if

IP address or port information in the payloads is not processed. For details on

resolving this problem, see section 3.5 "NAT Traversal."

2.4 CGN Application Scenarios

The CGN is jointly used with other technologies in multiple scenarios, including the

NAT444, DS-Lite, and NAT64.

� NAT444: The NAT is performed twice in the NAT444 scenario: once on the CPE

and again on the CGN.

� DS-Lite: In this scenario, two NEs are introduced: B4 (basic bridging broadband

element) and AFTR (address family transition router). The B4 is identical to the CPE

and performs tunnel encapsulation and decapsulation. The AFTR is the DS-Lite

gateway and performs tunnel encapsulation, decapsulation, and address translation.

The single stack IPv6 network exists between the CPE and AFTR. The B4 allocates

the private network IPv4 address to the user to support IPv4 services. The uplink

IPv4 packets are encapsulated in the IPv6 channel by the B4. After the packet is

transmitted to the DS-Lite gateway, the external IPv6 packet header is removed and

the private network IPv4 address is translated to the public network IPv4 address.

The flow for processing the IPv4 packet sent from the public network is reversed.

The public network IPv4 address is translated into the private network IPv4 address,

and then the packet is transmitted through the IPv6 tunnel to the B4. The B4

decapsulates and then forwards the packet to the destination host.




8

� NAT64: In this scenario, both the network address and protocol are translated

between the IPv6 and IPv4 networks. The NAT64 generally enables only IPv6

network users to access IPv4 network resources. If the static mapping relationship is

configured manually, the NAT64 also enables IPv4 network users to access the IPv6

network. The NAT64 can translate the network address and protocol between the

IPv6 and IPv4 networks when the TCP, UDP, and ICMP are used. The DNS64 must

be jointly used with the NAT64. Record A (the IPv4 address) in the DNS query

information is synthesized to the record AAAA (the IPv6 address). The synthesized

record AAAA is then sent to the IPv6 user.

2.5 Impact of the CGN on the Network

� Impact on network equipment: Deploying the NAT adds the address translation

function to the network, which requires little adjustment on the live network.

However, certain application systems need to be modified based on the private

network address. The NAT increases processing delays and the complexity of

networks and routes. As the NAT is a traffic convergence point, it is difficult to back

up sessions on carriers' networks. When a fault occurs, sessions may need to be

re-established, which reduces network reliability.

� Impact on network maintenance: User source tracing requires the NAT log server

to store users' network access records. Log traffic of each NAT may reach tens of

megabits per second, which requires high-performance log servers with huge storage

capacities. Network maintenance complexity and workloads are increased due to

more and more NAT devices, fault location difficulties, user complaints, and source

tracing.

� Impact on services and applications: NAT-created processing delays and the

restricted NAT traversal affecting certain applications lower user experience and may

influence the launch of carrier services; for example, if the NAT is deployed between

a user and the DPI, the DPI function is unavailable. The NAT affects value added

services that obtain user information from IP addresses as an IP address is shared by

multiple users; for instance, VoIP applications require the addition of an

application-layer gateway.

These disadvantages do not affect widespread NAT deployment in commercial

networks because address exhaustion exists over a large range and only NAT




9

technology can protect existing IPv4 investment. New applications must support

NAT, and related standards are currently being improved. New applications can use

nascent technologies to bypass the limitations of the network layer by increasing the

complexity of the application layer.

Technical White Paper for IPv6 CGN Solution 3 Key Technologies for Deploying the CGN



10

3 Key Technologies for Deploying the CGN

3.1 Classification of CGN Forms

The CGN can be either a stand-alone or integrated device.

� The stand-alone CGN is an independent device that provides the CGN function.

� The integrated CGN is also called the plug-in CGN because the board that provides

the CGN function is inserted into another device; for example, the BNG, SR, or CR.

The stand-alone CGN is used only for address translation and does not affect BNG

services. However, the BNG forwarding port is occupied with transmitting streams

to the CGN.

The integrated CGN can be combined with the BNG user management function to

optimally utilize the CGN’s management capabilities. For details, see Table 3-1.

Table 3-1 Comparison of the stand-alone CGN and integrated CGN

Stand-Alone CGN Integrated CGN

Characteristics � Excellent performance with a

multi-core CPU for

processing. The overall system

is used for CGN processing.

� High capacity and

extensibility. Extensibility can

be realized through cascading

or cross-chassis.

� Easy to deploy.

� Requires a BNG forwarding

port for drainage.

� A stand-alone device is not required. The

integrated CGN saves space, consumes minimal

power, meets heat dissipation requirements, and

requires a small investment.

� The excellent coordination capabilities of the

network and application layers enable various

routing protocols, convergence access, and

CGN information management.

� Excellent extensibility. The CGN can be

deployed online and extended without

limitation.

� Occupies the BNG service slot.




11

The CGN can be deployed in either centralized or distributed mode:

� Centralized: Usually deployed on the CR on an upper-layer network, for example, P

router of the metropolitan area network (MAN) in China and P router of the

backbone network in other countries. The CGN can be either a stand-alone device

attached to the CR or integrated into the CR.

� Distributed: Deployed in a relatively low network position, usually with the BNG or

SR. The CGN can be stand-alone or integrated.

Table 3-2 Comparison of the centralized CGN and distributed CGN

Centralized CGN Distributed CGN

Characteristics � Applicable when CGN users are

scattered on the MAN.

� Easy to deploy with few extra nodes.

� Places high requirements on device

performance. Device fault scope is

large.

� Requires private network routes on the

uplink network of the SR/BNG on the

MAN.

� Poor sustainable evolution capability;

must evolve to distributed mode as users

increase.

� Reduces address pool fragments and

enhances address usage.

� Applicable when CGN users are

centralized.

� Scattered user scenarios require many

nodes.

� Device fault scope is small.

� Integrating the CGN and SR/BNG

provides the SR/BNG with both user and

CGN information. User-based

management more effectively solves

CGN-based problems such as source

tracing.

3.2 Classification of CGN Access

3.2.1 Mode 1: Access Through the L3 Tunnel

As shown in Figure 3-1, a terminal user can access the CGN through the IPv6 tunnel. The

CPE encapsulates the IPv4 packet and transmits it through the IPv6 tunnel to the CGN

gateway. The CGN removes the IPv6 packet header and translates the IPv4 address. The

CPE is used as the DHCP server of the IPv4 private network address and allocates IPv4

private network addresses to user terminals on the home network. The CPE forwards the

IPv4 addresses instead of translating them and DS-Lite is typically used in this scenario.




12

Figure 3-1 CGN access mode by through the L3 tunnel

3.2.2 Mode 2: Access Through the L2 Tunnel (NAT444)

As Figure 3-2 shows, the CPE functions as the DHCP server for the IPv4 private network

address and allocates IPv4 private network addresses to user terminals. The CPE provides

level-1 NAT processing and the CGN gateway provides level-2 NAT processing. The

CPE connects to the CGN through an L2 tunnel (VLAN/PPPoE) in which only one IP

session exists. The private network address can be a shared address for level-2 NAT.

Figure 3-2 CGN access mode through the L2 tunnel (NAT444)

3.2.3 Mode 3: Access Through the L2 Tunnel (NAT44 and Access with

Any Address)

As shown in Figure 3-3, a terminal user can access the CGN through the L2 tunnel

(VLAN/PPPoE). The IPv4 packet sent by the user is transmitted through the L2 tunnel to

the CGN gateway for NAT processing. The CPE functions as the DHCP server of the

IPv4 private network address and allocates IPv4 private network addresses to user

terminals. The CPE does not provide the NAT function, and all packets containing a

private network address on the terminal network are transmitted at L2. Multiple IP

sessions exist in the L2 tunnel. Terminal network users are differentiated by L2 tunnel

information such as the PPP session ID or VLAN.

IPv6 L3 DS-LITE Tunnel

L3 CPE

IPv4 privateIPv4 DHCP server

IPv6CGN&BNG

Private IPv4

L2 Tunnel (PPPoE/VLAN)

CGN&BNGL3 CPE

IPv4 DHCPserverIPv4 NATIPv4 private

Private IPv4

IPv4 private




13

Figure 3-3 CGN access mode through the L2 tunnel (NAT44 and access with any address)

Private IPv4

L3 CPE

IPv4 DHCP server

CGN&BNG

L2 Tunnel (VLAN)

IPv4 private

IPv4 private




14

3.2.4 Mode 4: Access Through the L2 Tunnel (NAT44 and Address

Management and Allocation)

As shown in Figure 3-4, a terminal user can access the CGN through the L2 tunnel

(VLAN/PPPoE). The IPv4 packet sent by the user is transmitted through the L2 tunnel to

the CGN gateway for NAT processing. The CPE cannot allocate addresses. The BNG

functions as the DHCP server of the IPv4 private network address and allocates IPv4

private network addresses to user terminals. The CPE does not provide the NAT function,

and all packets containing a private network address on the terminal network are

transmitted at L2. Multiple IP sessions exist in the L2 tunnel. Terminal network users are

differentiated by L2 tunnel information such as the PPP session ID or VLAN.

Figure 3-4 CGN access mode through the L2 tunnel (NAT44 and address management and

allocation)

3.3 Controlling the NAT User Policy with BNG/CGN

Convergence

NAT resources can be managed and controlled for the CGN by incorporating user-based

defined policy control, which enables the carrier-class operation and allocation of

addresses and NAT resources. The CGN’s management system architecture implements

policy control on a user group based on the source address network segment or CGN

instance. The BNG management system architecture performs management based on user

accounts (single users) or control domains (user groups). The BNG and CGN are

converged to implement consistent control system architectures. The BNG network

system architecture implements the user CGN control policy with optimum compatibility.

IPv4 DHCP server

Private IPv4

L2 CPECGN&BNG

L2 Tunnel (VLAN)

IPv4 private

IPv4 private




15

As shown in Figure 3-5, the CGN control policy includes the NAT port allocation

policy/port segment range, number of NAT sessions, legal interception policy, ALG,

QoS/SLA service quality, and the ACL. Management of the CGN control policy is

performed through the control policy instances contained in the profile, and the control

policy’s profile content can be configured on the device locally or delivered by the policy

server or the RADIUS authentication system. Figure 3-5 shows the user policy control

when the BNG and CGN are converged.

Figure 3-5 User policy control when the BNG and CGN are converged

� Single users: The CGN can identify a user based on the unique user identifier and

the user can be bound to the user identifier during BNG access authentication. The

CGN control policy acts on the access user through the user account policy. Each

user must maintain the user management control table item to bind the user access

identifier and control policy. The CGN policy can be obtained during BNG/CGN

user access by using authority authentication or it can be delivered to the BNG/CGN

device by the RADIUS or policy server. Control policy delivery can directly deliver

policy content to the device or deliver the policy profile name. If the policy profile

name is delivered, policy content can be obtained in the local profile instances on the

device.

� User groups: The CGN correlates the CGN instances with the BNG control domains,

and users with a specific BNG user property belong to the same control domain. The

control domain binds to the corresponding CGN instance to implement the binding

relationship between the user group and control policy. During BNG/CGN user

CGNBNG

+

CPE

IPv4 IPv4 Private

Address

IPv4

Radius Server

CGN Profile Name

PPPoE or IPoE user access authentication

CGN Profile local

configuration

BNG User P rofile from Radius

Pr ivate IPv4Pr ivate IPv4Pr ivate IPv4Pr ivate IPv4L2 or L3 Tunnel

DNS Server

CGN Profile Content

CGN User Tunnel IDBNG Subscriber

CGN User Group

Instance

BNG User Group

Control Domain

CGN Profile Policy Control Template:�NAT port range allocation�NAT session number�ALG capabilities�Lawful inspection�QoS/SLA�ALG

Bind

Bind




16

access, the related control policy can be obtained by using authority authentication or

by finding the bound CGN instance based on the homing relationship of the control

domain.

Convergence of the CGN policy architecture and BNG user policy architecture

provides operable control capabilities on the NAT management policy and

implements the ordering management and allocation of user addresses and port

resources. This maximizes resource usage and implements the central management

of differentiated NAT services and policies, which reduces O&M costs and achieves

carrier grade NAT operation capabilities.




17

3.4 Management of Ordering Port Pre-Allocation

Statistical multiplexing of IP addresses is implemented by multiple users sharing the same

IP address to maximize the usage of limited public network address resources. The

conventional NAT mechanism causes multiple management problems as addresses are

allocated by requirement. For example, as user port resources are not effectively

controlled, a few users can occupy a large number of public network ports. After all ports

are allocated, IP addresses must be changed, which causes service access problems. In

addition, ports are not allocated in succession and user source tracing is difficult. In this

case, the system load increases and a large number of logs are required to record user port

allocation.

The ordering port pre-allocation mechanism effectively increases port usage and

improves operation and management efficiency. When the user accesses the network, the

public IP address is allocated based on the control policy bound to the user, and the public

network address and port range are specified. All information is recorded in the user

management control table.

As shown in Figure 3-6, the two HGWs are allocated with the private network IPv4

addresses of 192.168.1.1 and 192.168.1.2. The two HGWs share the same public network

IPv4 address of 211.1.10.88. HGW packets are differentiated based on the TCP/UDP port

segment. The public network IP address 211.1.10.88 and port segments 3001-4000 and

6001-7000 map the private network address 192.168.1.1. The public network IP address

211.1.10.88 and port segments 4001-5000 and 7001-8000 map the private network

address 192.168.1.2. Figure 3-6 shows the management of ordering port pre-allocation.




18

Figure 3-6 Management of ordering port pre-allocation

When a user accesses services using a private network address, the NAT is performed

based on the public network address and port segment allocated for the user, who is

identified by the unique user access channel. The terminals belonging to that user share

the allocated address and port resources, and limitations are specified by the user’s CGN

control policy.

External ports with the public network IPv4 address are allocated to users or user groups

in sequence based on the port segment. If all ports in a certain port segment are allocated,

extra ports can be increased for allocation.

Port segment allocation implements the ordering allocation management of IP addresses

and port resources. Abuse of both by a few users is prevented and user source tracing

management is simplified. CGN session logs are greatly reduced and system loads are

lowered.

3.5 NAT Traversal

Though the NAT effectively resolves the IP address resource issues, address translation

problems arise. The NAT can translate IP layer addresses and UDP/TCP ports, but the

address information is carried in the TCP/UDP payloads for certain applications and the

standard NAT device does not modify information in the TCP/UDP payloads. After the

NAT is performed, the IP layer address in the packet is inconsistent with the address

information carried in the UDP/TCP payloads, causing the application program to be

faulty. This problem occurs in scenarios with protocols such as the FTP, RTSP, SIP, and

DNS.

P rivate IPv4

HGW

IPv4IPv4 Private

Address

IPv4

HGW

IPv4IPv4 Private

Address

IPv4

IPv4 Public

Address

Radius DNS

CGN&BNG

BRAS, Radius and CGN inter-working

P rivate IPv4

User Identify Private IPv4 Prof ile Public IPv4 Start port 1 End port 1 Start port 2 End port 2 …

Tunnel ID 1 192.168.1.1 Prof ile 1 211.1.10.88 3001 4000 6001 7000 …

Tunnel ID 2 192.168.1.2 Prof ile 2 211.1.10.88 4001 5000 7001 8000 …

Address

211.1.10.88

Port 3001-4000

Port 4001-5000

…




19

Two solutions are provided to resolve the problem.

Solution one: The introduction of the application layer gateway (ALG) enables the NAT

device to resolve specific application protocols. When address of an application program

is filled in the application payloads, the ALG module of the NAT can change the address

to the NAT external address. This ensures consistency between the packet IP header and

the address in the application payloads and enables the application program to run

normally.

Solution two: The application program pre-obtains the corresponding external NAT

address of the application address, and then fills the external NAT address in the payloads

so that the NAT is not required to modify payload content. If the STUN protocol is

configured, the application program can resolve the NAT traversal problem using the

second solution.

Figure 3-7 shows the large-scale deployment of CGN services to support NAT traversal.

Figure 3-7 Large-scale deployment of CGN services to support NAT traversal

Applications using the STUN protocol for traversal require the NAT device to support the

asymmetry NAT. However, the STUN protocol is not suitable for TCP mode.

Consequently, most current P2P stream media applications require the NAT device to be

able to open external address ports in UPNP/PMP mode during which control information

is sent to the NAT gateway to add port mapping. In this way, the NAT can be accessed

externally and NAT traversal is implemented.

•PMP

•UPNP

•PCP•WEB PORTAL

Port Open Request

Port Open

Request P rox y

HGW

IPv4IPv4 Private

Address

IPv4

Pre-allocated

port range

IPv4 Internet

IPv4 Public

Address

Radius

App request open external service ports

Portal Server

Terminal applications request CGN to

open outside service IP and port by

conic NAT model dynamically.

CGN&BNG

P rivate IPv4

Tunnel

DNS




20

To enable communication of two nodes on which the NAT is performed, certain

application software is required for NAT traversal based on port probation or speculation

given that both parties do not know the external service port of the peer device. However,

as efficiency is low and the success rate cannot be guaranteed, a relay server is required to

establish a connection for transferring both parties’ information. The NAT is generally

performed for both parties when deployed on a large scale, though relay server

performance is lowered and cannot be used to transfer information. However, external

port open protocols can dynamically open external ports. In this scenario, NAT server

with the asymmetry NAT is necessary to ensure security. Both parties can directly connect

to each other and information transfer by using the relay server is no longer required.

The CGN must support most applications to dynamically open ports. Applications must

support dynamic port mapping open modes such as PMP, UPNP, and PCP. When used

jointly with the STUN mode, service NAT traversal in the context of large-scale NAT

deployment is implemented. This combination enables P2P single-/multi-channel services

to support the NAT and can also be selected for application programs that do not support

ALG. PCP and Web Portal modes can also be used to coordinate and manage external

ports and meet the specific requirements of certain applications.

3.6 High Reliability

In the DS-Lite scenario, the CGN is the core of the network and as such must feature high

reliability and extensibility. High availability (HA) redundancy is necessary to achieve

carrier-class reliability for uninterrupted services. A single CGN device can use multiple

CGN service cards to implement inter-card load sharing and redundancy backup, and

enhance the processing performance and extensibility of the overall system. The

redundancy backup mechanism can be implemented between multiple devices to

implement redundancy backup and load sharing. Figure 3-8 shows the backup mechanism

between CGN devices.




21

Figure 3-8 Backup mechanism between CGN devices

The reliability backup mechanism of the CGN is based on the extended VRRP function,

and manages the active/standby status of the device. Patented by Huawei Technologies,

the extended VRRP is used for interface backup when multiple access interfaces exist

between devices/cards. Unlike the device-level backup provided by a conventional VRRP,

the extended VRRP provides interface-level backup and enables multiple interfaces on

the same device to be configured into the same backup group. Therefore, the backup

granularity of the extended VRRP is smaller than that of a conventional VRRP, and the

backup modes benefit from greater flexibility. The conventional VRRP is an L3 protocol

whereas the extended VRRP is an L2 protocol that can be used in L2 user access

scenarios without a virtual IP address for the access interface. The CGN uses the extended

VRRP to implement inter-device or inter-card backup. User services are switched to the

backup interface if faults occur in the active interface, on links connected to the active

interface, or on the board housing the active interface.

CGN user information must be synchronized in real time on the active and standby

devices or cards. User management control table items created on the active device or

card must be synchronized to the backup device or card. The active and standby VRRPs

are switched if the interface or interface link managed by the VRRP is faulty. Users

bound to this VRRP are immediately switched to the standby device to prevent service

interruptions and packet loss. The information backup mechanism between the devices

uses the HRP protocol patented by Huawei Technologies to synchronize status

information in real time.

SPU/N

AT

SPU/N

AT

MPU

LPU

SPU/N

AT

MPU

LPUActiveActiveActiveActive BackupBackupBackupBackup

NAT instance

1

NAT instance

2

NAT instances

1+2

Loopback1.1.1.1

TCP1(RUI): ins 1 session//NAT table

TCP1（RUI）：ins 2 session/NAT table

Loopback2.2.2.1

Loopback1.1.1.2

CGN1

Active

CGN2

Backup

BFD

VRRP group1

HRP

VRRP group 2

User 1

Internet v4

User 2




22

The CGN uses VRRP-based BFD technology to manage the active/standby status

detection on the VRRP group and to implement carrier-class management of the device or

link faults. The BFD is applied between the active and standby VRRP entities to ensure

that the fault detection duration is less than 50 milliseconds. This achieves smooth

switching between the active and standby devices, and the user is unaware a fault has

occurred as services are not interrupted.

However, the number of VRRP groups is limited within the system. Therefore,

management granularity must be fractionized as much as possible to maximize operation

and management flexibility. The backup relationship of the VRRP groups can be

correlated to related user groups by correlating CGN instances or BNG control domains

to CGN instances. If the CGN user groups are bound to the VRRP groups, the correlated

CGN user group is switched to the standby device or card once active/standby switchover

is performed for the VRRP backup group. The standby device then takes over the

subsequent services.

Sessions of a CGN user are synchronized between the devices as hot backup, and fault

detection is performed in real time. The backup relationship supports 1:1 or N:1 mode to

meet the reliability and extensibility requirements of CGN services.

Technical White Paper for IPv6 CGN Solution 4 Conclusion



23

4 Conclusion

The CGN is the most mature and economical solution for resolving IPv4 address

exhaustion during the lengthy evolutionary process from IPv4 to IPv6.

The high-performance CGN device developed by Huawei supports a large number of

concurrent users, provides an effective user source tracing mechanism, and is suitable for

large-scale commercial deployment. With high deployment flexibility, the Huawei CGN

device can be deployed independently or integrated into the BRAS or CR in either

centralized or distributed mode. Its inter-device and inter-card hot backup ensures high

reliability and uninterrupted services, while CGN/ BNG convergence provides a range

flexible user control policies. The Huawei CGN solution ensures the smooth transition of

carriers' networks to IPv6 and the seamless continuity of IPv4 services.

Technical White Paper for IPv6 CGN Solution A References



24

A References

1. RFC2663: IP Network Address Translator (NAT) Terminology and Considerations

2. RFC2709: Security Model with Tunnel-mode IPsec for NAT Domains

3. RFC2993: Architectural Implications of NAT

4. RFC3022: Traditional IP Network Address Translator (Traditional NAT)

5. RFC3235: Network Address Translator (NAT)-Friendly Application Design

Guidelines

6. RFC3519: Mobile IP Traversal of Network Address Translation (NAT) Devices

7. RFC4008: Definitions of Managed Objects for Network Address Translators (NAT)

8. RFC4787: Network Address Translation (NAT) Behavioral Requirements for

Unicast UDP

9. RFC5135: IP Multicast Requirements for a Network Address Translator (NAT) and

a Network Address Port Translator (NAPT)

10. RFC5382: NAT Behavioral Requirements for TCP

11. RFC5508: NAT Behavioral Requirements for ICMP

12. RFC5597: Network Address Translation (NAT) Behavioral Requirements for the

Datagram Congestion Control Protocol

13. RFC6264: An Incremental Carrier Grade NAT (CGN) for IPv6 Transition

Technical White Paper for IPv6 CGN Solution B Acronyms and Abbreviations



25

B Acronyms and Abbreviations

Acronym and Abbreviation Full Name

CGN Carrier Grade NAT

CPE Customer Premises Equipment

DHCP Dynamic Host Configuration Protocol

DS-Lite Dual Stack Lite

NAT Network Address Translation

Native IPv6 Native IPv6

Radius Remote Authentication Dial-In User Service

VRRP Virtual Router Redundancy Protocol

Technical White Paper for IPv6 CGN Solution

Documents

Transcript of Technical White Paper for IPv6 CGN Solution