- Released At: 18-04-2024
- Page Views:
- Downloads:
- Table of Contents
- Related Documents
-
CGN Technology White Paper
Copyright © 2024 New H3C Technologies Co., Ltd. All rights reserved.
No part of this manual may be reproduced or transmitted in any form or by any means without prior written consent of New H3C Technologies Co., Ltd.
Except for the trademarks of New H3C Technologies Co., Ltd., any trademarks that may be mentioned in this document are the property of their respective owners.
The content in this article consists of general technical information, and some information may not be applicable to the product you have purchased.
Contents
Centralized deployment of CGN method
Distributed deployment of CGN method
Centralized backup for distributed CGN
Inter-board backup for standalone CGN board
Dual-device CGN inter-frame backup
Centralized CGN backup of distributed CGN
Inter-board backup of standalone CGN card
Dual-device CGN inter-frame backup
Overview
Technical background
On February 3, 2011, ICANN announced that the last five groups of IP addresses have been fully allocated, and there are no more IPv4 addresses available for allocation.
Introducing IPv6 is the fundamental and direct solution to address IPv4 exhaustion, but it is challenging to migrate all IPv4 applications and services to IPv6 in a short term. During the IPv6 transition period, to avoid impacting the carrier's existing users and the growing number of new users accessing the Internet, carrier grade NAT (CGN) has emerged.
CGN, also known as large-scale NAT (LSN), is essentially NAT, a technology capable of multiplexing the limited public network IPv4 addresses, effectively enhancing their utilization rate, solving the issue of IPv4 address exhaustion for a significant period of time. CGN has various application scenarios, such as NAT444 and DS-Lite.
Benefits
Traditional NAT is mostly deployed on customer premises equipment (CPE), achieving address translation for a small number of users. Whereas, CGN is deployed within the carrier network, facilitating address translation for a large number of users, greatly enhancing support for concurrent users, performance, and traceability.
Compared to traditional NAT, CGN has the following advantages:
· Large Capacity: Deployment in carrier networks, providing address translation services for a large number of users.
· High availability (HA): Multiple CGN boards are used for backup within a single machine board, between dual machine frames, or in a centralized backup distributed format, to avoid network service unavailability caused by a fault in a single CGN board.
· Traceable: CGN provides user logs and stream logs, allowing administrators to query the private network user's IP address in the logs based on the public network address and port number of the business message, and then lockout specific users.
· CGN Resource Management: CGN resources include public network addresses and port blocks. It supports preventing individual users from occupying too many CGN resources by limiting the number of ports and restricting the number of private network users sharing a single public network IP.
CGN technology implementation
Basic concepts of CGN
The basic concept of CGN is as follows:
· CGN board: The board that carries CGN services is called the CGN board. Its product forms are divided into Core Router (CR) card type and Broadband Remote Access Server (BRAS) card type.
· Intra-device CGN backup: NAT service backup is performed between two CGN boards installed on the same device.
· Inter-device CGN backup: NAT service backup is performed between the CGN boards located on two separate devices.
CGN conversion methods
Static method
The static method of address translation refers to the address mapping relationship between the external network and the internal network, which is determined by the configuration. In other words, a public network IP address uniquely corresponds to an internal host. This method is suitable for network environment groups with fixed access requirements between internal and external networks. Static address translation supports bidirectional interactions: internal network users can initiate access to the external network, and external network users can similarly initiate access to the internal network.
Dynamic method
NO-PAT method
The NO-PAT method belongs to one-to-one address translation, in which only the IP address is translated while the port number of TCP/UDP protocol is not processed, and a public network IP address cannot be used by multiple users simultaneously.
As shown in Figure 1, the processing procedure for the NO-PAT method is as follows:
· The NAT device receives a message from the private network host, requesting access to the public network server.
· The NAT device selects an available public network IP address from the address pool, and establishes a NAT translation table entry with the source IP address on the private network side. Based on the result of looking up the NAT table entry, the device then transmits the converted data packet to the public network side.
· Upon receiving a response message from the public network side, the NAT device reverses the lookup of the NAT entry based on its destination IP address. According to the lookup result, it translates the message and transmits it to the private network side.
Figure 1 Conceptual Diagram of NO-PAT Method
PAT method
Since the NO-PAT method does not implement address multiplexing, it cannot solve the problem of public network address shortage. However, the Port Address Translation (PAT) method can solve this problem.
The PAT method performs many-to-one address translation. It performs the translation using the "IP address + port number", allowing multiple private network users to share a single public network IP address to access the Internet. This achieves the multiplexing of addresses and is, thus, the primary form of address translation implementation.
Currently, PAT only supports the translation of "IP address + port number" for messages with TCP, UDP, or ICMP as their transport layer protocol.
As shown in Figure 2, the processing process of the PAT method is as follows:
· The NAT device receives a message from the host on the private network side, which is sent to access the server on the public network side.
· The NAT device selects a pair of available "public network IP address + port number" from the address pool, establishes a PAT translation entry between the private network side message "source IP address + source port number", and sends the message to the public network side after converting it according to the result of looking up the PAT entry.
· Upon receiving a response message from the public network, the NAT device reverses lookup the PAT entry based on its "destination IP address + destination port number", and transmits the translated message to the private network side according to the lookup result.
Figure 2 Network diagram of the NAT method
Port block method
The port block method is a type of PAT dynamic address translation based on the port range, where a private network IP address exclusively occupies a certain port block of a public network IP address within a set period. For instance, suppose a private network IP address 10.1.1.1 uniquely occupies a port block 10001-10256 of the public network IP address 202.1.1.1. In such a case, all connections initiated by the private network IP address to the public network would be translated to the same public network IP address 202.1.1.1, and the source port would be translated to a port within the range of the port block 10001-10256.
The port block method includes two types: static mapping and dynamic mapping, mainly used in NAT444 and DS-Lite networks.
Static mapping of the port block
A static mapping of port blocks refers to a NAT gateway device automatically calculating static mappings from private network IP addresses to public network IP addresses and port blocks based on its configuration and creating static port block entries. When a private IP address from the private network members initiates a new connection to the public network, it matches the static port block entry according to the private IP address, obtains the corresponding public IP address and port block, and dynamically allocates a public port from the port block for address translation of the message.
When setting up static mapping for port blocks, you need to create a port block group. In the group, members of private network IP address, public network IP address, port range, and port block size are to be configured. Assume each public network IP address in the port block group has an available number of port blocks denoted as m (that is, port range divided by port block size), the algorithm for port block static mapping is as follows: All IP addresses in the private network IP address members are sorted in ascending order. The smallest m private IP addresses correspond to the smallest public IP address and its port blocks, with the port blocks allocated in ascending order of the port number; the same allocation applies to the next smallest m private IP addresses that correspond to the next smallest public network IP address and its port blocks, and so forth.
Port block is dynamically mapped
In the NAT and BRAS unification scenario, once the user successfully goes online, the device will traverse all address translation configurations on every interface. When the user's traffic matches the ACL rule within the address translation configuration of a certain interface, the device allocates public network address and port block to the user, and creates a dynamic port block entry. When the user goes offline, the device reclaims the allocated port block resources and deletes the corresponding dynamic port block entry.
In the non-linkage scenario, when an internal network user initiates a connection to the public network, the ACL rule in the dynamic address translation is first filtered to determine whether a source address translation is needed. For connections requiring source address translation, when it is the first connection for that user, obtain a public IP address from the NAT address group referenced by the matched dynamic address translation configuration, then dynamically allocate a port block from that public IP address, create a dynamic port block entry, and allocate a public port from the port block entry for address translation. For subsequent connections of that user, public ports are allocated from the generated dynamic port block entry. When all the connections of that user are disconnected, reclaim the allocated port block resources and delete the corresponding dynamic port block entry.
Dynamic mapping of the port blocks supports delta allocation of port blocks. When all ports in the allocated block for a specific private network IP address are used (i.e., resources in the block are depleted), no ports can be obtained from the block for address translation if a new connection to the public network is initiated by this IP. In this case, if a delta number of port blocks were pre-configured in the corresponding NAT address group, additional port blocks can be allocated for this private network IP address to execute address translation.
Server-based NAT method
For security reasons, most private network hosts usually do not want to be accessed by public network users. However, in some practical applications, it is necessary to provide public network users with an opportunity to access private network servers. In the NO-PAT or PAT mode, public network users cannot access private network hosts because NAT entries cannot be dynamically established by the visits initiated by public network users. The internal NAT server method can solve this problem - by statically configuring the mapping between "public IP address + port number" and "private IP address + port number", the NAT device can "reverse" translate the public address into a private address.
As shown in Figure 3, the processing procedure of the NAT Server mode is as follows:
· The NAT device receives the message sent by the host on the public network side, accessing the server on the private network side.
· The NAT device reverses the lookup of the static NAT entry based on the "destination IP address + destination port number" of the public network side message, and then transmits the message to the private network side after the translation based on the lookup result.
· When the NAT device receives a response message from the private network side, it searches for a static NAT entry based on its "source IP address + source port number", then transmits the message to the public network side after translating it according to the lookup result.
Figure 3 Conceptual Diagram of NAT Server Method
CGN deployment method
According to the deployment location of the CGN board, it can be divided into two methods: centralized CGN deployment and distributed CGN deployment.
Centralized deployment of CGN method
Centralized deployment refers to placing the device that provides CGN function near or at the core of the metropolitan area network. It is typically deployed on a core router (CR), as shown in figures Figure 4 and Figure 5. The device equipped with a CGN board can be attached to the CR, or the CGN board can be installed in the CR.
The features of the centralized deployment method for CGN are as follows:
· This is suitable for scenarios where both users and traffic are relatively low.
· The device fault has a wide impact.
· The number of CGN boards needed for deployment is small.
Figure 4 Deploy the CGN centrally (The device with a CGN board mounted next to CR)
Figure 5 Deploy CGN centrally by inserting the CGN board into the CR
Distributed deployment of CGN method
In comparison to centralized deployment, distributed deployment of network locations involves deploying devices with CGN functions close to or at the margin of a metropolitan area network, typically on BRAS devices, as shown in Figure 6.
The features of the distributed deployment CGN method are as follows:
· This is applicable for scenarios where there are a lot of users and traffic.
· The device fault has a small impact range.
· A large number of CGN boards need to be deployed.
Figure 6 Deploy distributed CGN (Carrier Grade NAT)
CGN backup
The CGN board is a core part of a carrier's network, tasked with handling many users' address translation. If the CGN board encounters a fault, a large number of users' network services will be unavailable. To enhance the reliability of CGN, several CGN boards must be used and a backup relationship must be established to prevent network service unavailability resulting from a single CGN board's fault. There are three backup methods available to select for CGN:
· Centralized backup for distributed CGN deployment
· Intra-device CGN backup
· Inter-device CGN backup
Centralized backup for distributed CGN
The term centralized backup distributed CGN refers to the existence of both distributed deployment CGN devices and centralized deployment CGN devices in the network, where the NAT business capacity of the distributed deployment CGN is backed up by the centrally deployed CGN.
Under normal circumstances, NAT operations are handled by the devices deployed by distributed CGN. When a failure occurs in the distributed CGN board, traffic switches over to the devices deployed by the centralized CGN for address translation. Once the board failure of the distributed CGN is resolved, the traffic switches back to the devices deployed by the distributed CGN for address translation.
As shown in Figure 7, when the CGN board on the BRAS device is working properly, traffic goes through address translation on the CGN board of the BRAS device. As indicated in Figure 8, when the CGN board on the BRAS device has a fault, the traffic switches over to the CGN board on the CR device for address translation.
Figure 7 Centralized Backup Distributed CGN Network Diagram (Normal CGN Board on BRAS)
Figure 8 Network diagram of centralized backup distributed CGN group (Fault on CGN board on BRAS)
Inter-board backup for standalone CGN board
Single-machine CGN board backup refers to the NAT business backup between two CGN boards installed on the same device.
The CGN board acting as both the main and backup node joins the same backup group for mutual backup. The backup group determines the active state of the main and backup nodes (CGN boards). Only nodes in an active state can process NAT business. As shown in Figure 9, the mechanism for intra-machine CGN board backup is as follows:
· When the primary node is functioning properly, it is in an active state, handling NAT business. At the same time, the primary node synchronizes the NAT entries with the backup node.
· When the main node experiences a fault, the standby node will become active, taking over the processing of NAT services from the main node.
Figure 9 Conceptual diagram of intra-board backup for standalone CGN
Dual-device CGN inter-frame backup
Dual-device CGN inter-frame backup refers to the NAT business synchronization between CGN boards located on two separate devices. Under this backup method:
· The CGN boards on two devices logically form the primary and backup nodes of the same group.
· Establish a backup channel on the Layer 3 direct link between two devices, and synchronize the NAT session entry and port block entry through this backup channel.
· A VRRP backup group needs to be created on the interface where the backup channel is located, and the backup groups on both devices should be bound to this VRRP backup group. The active state of the main and backup nodes in the backup group is determined by VRRP. In VRRP, the backup group node on the Master device is active, while the backup group node on the Backup device is inactive. Only nodes in the active state can process NAT business.
As shown in Figure 10, the mechanism for inter-frame backup of the dual-device CGN is as follows:
· In VRRP, the backup group node on the Master device processes NAT services and synchronizes the NAT session entries and port block entries to the backup group node on the Backup device via the backup channel.
· When a device failure occurs in the Master of VRRP, a new Master device is elected. The backup group node on the new Master device takes over the processing of NAT service.
Figure 10 Conceptual diagram of dual-device CGN frame backup
Typical applications
Centralized CGN backup of distributed CGN
As shown in Figure 11, BRAS A, BRAS B, BRAS C, and Device belong to the same autonomous system (AS), and their interconnection in the IP network is achieved through the IS-IS protocol. BRAS A, BRAS B, and BRAS C provide access services to hosts and offer address translation functions through the CGN board. Traffic switchover is achieved using routing, which means under normal conditions, address translation is performed on the CGN boards of BRAS A, BRAS B, and BRAS C. If a fault occurs on the CGN board of BRAS A, BRAS B, or BRAS C, traffic switches to the CGN board on the Device connected to the Core Router, improving the reliability of the CGN services.
Figure 11 Typical Application Group Network Diagram of Centralized Backup Distributed CGN
Inter-board backup of standalone CGN card
As shown in Figure 12, BRAS provides access services for the host while also offering address translation function through the CGN board, and supports 1:1 mode CGN board hot backup. During the switchover of the primary and standby CGN boards, the user's operations will not be affected, thereby improving the reliability of CGN services.
Figure 12 Typical Application Network Diagram of Standalone CGN Board Inter-Backup
Dual-device CGN inter-frame backup
As shown in Figure 13, BRAS A and BRAS B provide access services to users, and offer address translation function through the CGN board. Under normal conditions, BRAS A is the Master in the VRRP backup group, and the CGN board on BRAS A is the main node in the backup group. It processes the NAT business and backs up the business data to the CGN board on BRAS B device. If a fault occurs on the CGN board of BRAS A, BRAS B becomes the Master in the VRRP backup group. Its CGN board switches to the main node of the backup group. At this time, the CGN board on BRAS B processes the NAT business, ensuring the NAT business does not get disrupted.
Figure 13 Typical Network Diagram for Inter-rack Backup Applications of Dual CGN Devices
Related documentation
· RFC 1631: IP Network Address Translator (NAT)
· RFC 2663: IP Network Address Translator (NAT) Terminology and Considerations
· RFC 2993: Architectural Implications of NAT
· RFC 3022: Traditional IP Network Address Translator (Traditional NAT)
· RFC 3027: Protocol Complications with the IP Network Address Translator