Carrier-Grade Network Address Translation Overview

Dynamic NAT automatically maps internal private addresses and ports to available public addresses and ports selected from a predefined pool. When a session ends, the resources are returned to the pool.

To dramatically reduce the massive logging overhead required for legal prosecution and compliance, CGNAT does not typically log every single translation. Instead, it utilizes Port Block Allocation. Ports are assigned to a subscriber in predefined blocks (e.g., 128, 256, up to 2048 ports), which can be extended by chaining multiple blocks as a user’s session requires them.

Unlike Dynamic NAT, Static NAT creates a fixed, manually configured 1:1 mapping between a specific internal private IP (and optionally, a port) and a public IP. Because the private device is consistently associated with the exact same public footprint, this configuration is primarily used when external internet devices require reliable, inbound access to internal resources like web or email servers.

To deliver true carrier-grade scalability, the RBFS CGNAT solution executes IPv4 address translation directly at the forwarding plane (hardware level). By offloading packet processing from the CPU to dedicated hardware, the system achieves massive throughput and ultra-fast translation rates. This hardware-accelerated implementation ensures optimal performance, allowing service providers to manage millions of concurrent IP and port mappings with zero impact on overall network latency or CPU load.

A key feature of the RBFS solution is its use of Endpoint-Independent NAT (historically classified as Full Cone NAT, 1:1 NAT, or NAT 1). In this operational mode, once a subscriber’s internal private IPv4 address and port are mapped to a public IPv4 address and port, that mapping remains open. Any external host on the internet can successfully send packets to the internal device by targeting the mapped public IP and port, regardless of whether the internal device previously initiated communication with that specific external host. This ensures high compatibility with peer-to-peer (P2P) applications, online gaming, and VoIP protocols.

While standard NAPT generates logs for every single session, the RBFS solution significantly reduces logging overhead by using Port Block Allocation. Instead of logging individual connections, the system assigns a predefined block of ports to a subscriber at once. Logs are generated only when a port block is allocated or released, dramatically reducing the storage and processing burden on the logging server.

RBFS supports a deterministic NAT mode, which provides a highly consistent, static mapping between a subscriber’s private IPv4 address and a specific public IPv4 address. In this mode, a given private IPv4 address is always translated to the exact same public IP address for the duration of the subscriber’s session.

This stability is achieved by ensuring that whenever a subscriber requires additional ports, all of their port blocks are allocated from the same assigned public IPv4 address, rather than being scattered randomly across the entire public IP pool.

Many security-sensitive applications—such as online banking, gaming, and secure enterprise portals—monitor source IPs to validate session integrity. If a single subscriber’s traffic were to arrive from multiple different public IPv4 addresses simultaneously, these applications might falsely flag the behavior as a session hijacking attempt or a coordinated attack, leading to dropped connections. Deterministic NAT prevents this by presenting a single, unified public IP for all of a user’s connections.

A NAT pool consists of a defined range of publicly routable IPv4 addresses. Service providers can create multiple pools and assign them to specific NAT services. To ensure continuous service availability and prevent allocation failures, the system supports Pool Chaining. This method allows administrators to link pools sequentially. By defining a "next pool name", the system will automatically seamlessly transition to the designated next pool if the active pool’s IPv4 addresses become fully exhausted.

Ageing refers to the duration a translation entry remains active in the address translation table after its last recorded packet is received. To optimize hardware resources and prevent table exhaustion, RBFS implements robust session timeout mechanisms that enforce a finite lifespan for all active entries.

When a host initiates an outbound connection, CGNAT maps the private IP and port to a public IP and port, recording this state in the translation table. For every subsequent inbound or outbound packet, the software queries this table to verify the active session and process the translation. If a mapped session remains idle without any packet exchange for a specified duration, the system reclaims the resources by removing the stale entry. This efficiently frees up table capacity for new traffic flows.

TCP Ageing: For connection-oriented protocols like TCP, the system actively monitors connection states. Flows are typically marked for rapid removal upon the receipt of TCP teardown packets (such as FIN-ACK or RST), indicating that both sides have successfully terminated the connection. If no teardown packets are received, the session is removed only after a configurable idle aging timer expires.

UDP Ageing: Because UDP is a connectionless protocol without explicit teardown signals, the system relies exclusively on tracking traffic activity. Idle UDP flows are cleared strictly when their respective aging timers expire. To manage resource consumption effectively under heavy traffic, the UDP aging mechanism scales dynamically. As the volume of active UDP flows increases, the system polling mechanism adjusts to ensure idle flows are identified and removed proportionally faster, preventing table overflows.

The NAT-enabled RBFS devices can perform network address translation for ICMP echo request and reply messages. Subscribers can use the ping command (ICMP Echo Request, Echo Reply) to check internet connectivity to external internet addresses when NAT is enabled. This feature is enabled by default.

The RBFS CGNAT provides support for Traceroute and critical ICMP error handling on the Edgecore AGR420, UfiSpace S9600-72XC, and UfiSpace S9600-102XC platforms. This feature ensures that diagnostic tools can function correctly across NAT boundaries by accurately translating and forwarding "TTL Exceeded" and "Fragmentation Needed" messages.

RBFS with NAT supports address translation for TCP control messages using ACLs. It includes the TCP control messages such as FIN, FIN-ACK, RST, RST-ACK, SYN, and SYN-ACK. This feature is enabled by default.

RBFS supports a mechanism to handle NAT-miss packets at control plane. A NAT-miss occurs when a downstream packet arrives at a device configured for address translation, but no matching NAT rule exists for that flow. A new ACL rule is issued to detect such packets based on NAT-miss status and destination prefix match. These packets are redirected to the control plane, which performs network address translation in software and forwards them.

Path MTU Discovery works in NAT environments for PPPoE and IPoE subscribers. RBFS with CGNAT-enabled can send ICMP "Fragmentation Needed" messages to the source when packet fragmentation is required, allowing the source to adjust the packet size accordingly. It allows for dynamic MTU adjustment and prevents packet drops and fragmentation-related issues.

Limitations:

In an N:1 VLAN architecture (where multiple subscribers share a single VLAN), enabling NAT for a single subscriber automatically subjects all traffic within that VLAN to NAT processing.

If your deployment requires a mixed environment—where some subscribers in the shared VLAN use CGNAT while others are directly assigned public IPv4 addresses, you must explicitly configure an Access Control List (ACL) to bypass NAT for the public-IP subscribers. Because subscribers with public IPs will generate traffic originating from those public ranges, this bypass is most efficiently achieved by deploying a single static ACL that matches and exempts all traffic sourced from your public IPv4 address blocks. Alternatively, this can be managed using dynamic subscriber filters.

For detailed configuration steps, refer to the Selective NAT Bypass for Subscribers Using ACLs section.