Network address translation maps private local addresses to public routable numbers so packets can cross edge routers to the wider internet. Devices on a home or office local network use private IP addresses that cannot route across public backbones on their own. When a computer sends a packet outside its local subnet, a routing device swaps the private source address with an assigned public IP address before forwarding the traffic. The router records the details in a state table, which lets it return incoming replies to the right local machine [12]. This routing mechanism helped delay the exhaustion of 32-bit IPv4 addresses for decades while shaping how firewalls and client software manage packet flows.
Early History and IPv4 Shortages
Internet Protocol version 4 was built with 32-bit addresses, which yields roughly 4.3 billion unique identifiers for connected machines. During the early days of network expansion, developers expected that pool to last far longer than it did. By 1992, fast adoption made it obvious that unallocated IPv4 blocks would soon run out. In response, K. Egevang and P. Francis published RFC 1631 in May 1994, presenting address translation as a short-term patch to buy time while the internet community designed a next-generation protocol [12]. The shortage arrived by 1992, forcing network architects to rethink address allocation. Engineers realized that global tables would expand too swiftly if every client terminal demanded a unique routable number.
The first specification treated address translation as an interim patch rather than a permanent fixture of internet architecture. It addressed two immediate problems: the depletion of unique IPv4 addresses and the fast growth of routing tables in backbone routers. As researchers Bansal and Goel pointed out in a study on routing techniques, enlarging the address space remained the primary long-term remedy, but carving out private subnets offered relief right away [14]. Network operators adopted the concept much faster than expected because it allowed them to connect hundreds of office workstations without purchasing large public address blocks.
By 2004, address translation had spread into nearly every consumer router and boundary device. RFC 1918 reserved specific address ranges, including 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16, so organizations could assign local numbers freely without coordinating with global registries. Because these numbers never leave the local boundary, millions of independent homes can reuse the exact same 192.168.0.0/16 range without causing packet collisions on the public internet [12].
How Network Address Translation Maps Ports
Early implementations relied on basic NAT, which creates a simple one-to-one mapping between a private IP address and a public IP address. In this setup, the router modifies the IP header and recalculates the header checksum as packets pass through the interface, but it leaves transport layer details untouched. While basic NAT works well to connect two networks with incompatible addressing schemes, it does not solve address scarcity because each active inside host still needs its own public address while transmitting data [12]. Translators adjust IP headers without inspecting ports, so if ten hosts transmit at once, the pool must supply ten distinct public addresses.
To let entire networks share a single public address, engineers developed Port Address Translation, which RFC 2663 terms network address and port translation. Introduced around 1996, this method multiplexes transport identifiers from TCP and UDP headers into a single public IP address. In RFC 4787, Section 4.1 describes address and port mapping, while Section 4.2 outlines port assignment rules. The Internet Assigned Numbers Authority divides ports into Well Known Ports from 0 to 1023, Registered ports from 1024 to 49151, and Dynamic or Private ports from 49152 to 65535 [1]. Return packets carry the assigned public port, allowing the gateway to look up the matching private socket in its tracking table [12].
Engineers also call this method IP masquerading or NAT overload. It functions cleanly for web browsing and file downloads because client software initiates the session from behind the router. But it creates hurdles for incoming traffic because outside nodes cannot reach an inside workstation unless the router already has an open translation entry or a preconfigured port forwarding rule [1].
How Does Endpoint Mapping Direct Traffic?
Because different router makers built translation tables in different ways, early peer-to-peer software struggled to predict how routers would handle outgoing sessions. In 2003, RFC 3489 proposed the STUN protocol, which sorted routers into full-cone, restricted-cone, port-restricted cone, and symmetric categories. That terminology caused confusion because many commercial devices combined behaviors from multiple categories [1]. In 2008, RFC 5389 updated the standard under the title Session Traversal Utilities for NAT to establish clearer evaluation methods [12].
To resolve this problem, François Audet of Nortel Networks and Cullen Jennings of Cisco Systems authored RFC 4787 as BCP 127 in January 2007, establishing precise requirements for how devices should translate unicast UDP traffic. The RFC separated translation behavior into two independent concepts: mapping and filtering. Mapping describes how a router picks an outside address and port for an inside endpoint, while filtering describes what outside packets the router allows through to that endpoint. Under Endpoint-Independent Mapping, the router reuses the exact same outside port for all outbound packets sent from a specific inside port, regardless of the target server [1]. In contrast, address-dependent and port-dependent mappings generate new outside ports when an inside host connects to different outside targets.
Audet and Jennings established that routers must use Endpoint-Independent Mapping to ensure apps like online gaming and voice communication work consistently. When an inside app advertises its public mapping to a remote peer, that remote peer can send data back to the same mapped port without getting blocked by unexpected table shifts. The standard also requires support for hairpinning, which lets two inside devices communicate using each other’s public mapped addresses without leaving the local gateway [1]. Packets loop back at the edge router.
Resolving Overlapping IP Networks
Address translation also solves complex routing problems when separate networks use conflicting address spaces. When two companies merge, both corporate environments might already use the popular 10.0.0.0/8 or 171.68.200.0/24 subnet inside their facilities. Readdressing thousands of servers, printers, and workstation access control lists would take months and disrupt daily business operations [3]. Merging companies often encounter these duplicate network numbers.
Cisco Systems added support for this capability starting in Cisco IOS version 11.2. In an overlapping network configuration, the border router translates both the source address and the destination address of crossing packets. If an inside host with IP address 171.68.200.48 wants to reach an outside host that shares the exact same address, it cannot send packets straight to that number without confusing its own local routing table. To make communication possible, the inside host sends a DNS lookup for the remote domain name through nameserver 171.69.2.132 [3].
The border router intercepts the DNS reply, alters the answer in the packet payload, and presents a temporary virtual address from an outside pool named test-dns with addresses like 172.16.47.177. When the inside device subsequently sends ICMP or TCP packets to that virtual address, the router rewrites the source to an inside pool named test-loop with addresses like 172.16.47.161 and restores the true destination address on the outside Serial1 interface [3]. By modifying both headers and payload records in transit, the router keeps both devices communicating without requiring either organization to renumber its private subnets.
Server Load Sharing With LSNAT
Beyond conserving IP addresses, translation technology can balance high traffic volumes across server clusters. In August 1998, P. Srisuresh of Lucent Technologies and D. Gan of Juniper Networks published RFC 2391 through the Internet Society, outlining Load Sharing using IP Network Address Translation, or LSNAT. At the time, popular web servers, mail servers, and remote login services frequently suffered performance slowdowns when inundated by simultaneous user sessions [4]. Distributing incoming sessions across multiple identical hosts prevented bottlenecks on busy web gateways.
Traditional load balancing schemes often relied on DNS zone transfers that shuffled resource record orders on a periodic schedule. But DNS shuffling adjusted slowly, taking minutes to reflect sudden traffic spikes, and it assumed every server in the pool possessed identical computing capacity. LSNAT solved this limitation by placing a translation router at the border of a server stub domain, where it intercepts client requests directed toward a single virtual service address. The router selects an individual backend server from the pool using real-time scheduling algorithms and rewrites the incoming packet destination [4].
Because LSNAT tracks connections at the session level, it directs all subsequent packets for an open TCP or UDP flow to the same host until that session terminates. Measuring load by session units ensures that an active download or transaction does not switch to a different server midstream, which would break the underlying connection state. The gateway identifies session startups by monitoring the TCP SYN flag, and it cleans up stale table entries after detecting FIN handshakes, reset flags, or configurable idle timeout periods [4].
Why NAT Behaves Differently in IPv6?
When the internet engineering community introduced IPv6 with its massive 128-bit address space, designers expected address translation to disappear. IPv6 provides enough unique addresses for every device on Earth, restoring the original end-to-end communication model where every node possesses a globally routable identifier. For years, IETF architectural guidelines in RFC 4864 actively discouraged IPv6 translation, pointing out that stateful address translation breaks end-to-end security and causes unnecessary protocol complexity [5].
Many network engineers also held the mistaken belief that address masquerading provides essential network security. But security comes from stateful firewall inspection that blocks unsolicited inbound traffic, not from the address translation step itself. Despite clear warnings from protocol purists, practical operational problems led some administrators to implement NAT on IPv6 networks. For example, budget hosting providers sometimes grant virtual server customers only a single /128 address rather than a full /64 subnet [5, 6].
Writing on the APNIC Blog in 2018, Marco Cilloni explained how a restrictive VPS allocation forced him to configure NAT66 on Linux using nftables to connect VPN clients. He assigned private Unique Local Addresses from the RFC 4193 fd00::/8 block to internal clients, pushed default routes, and translated outbound traffic through the single provider address. To make DNS work reliably, Cilloni had to adjust label precedence in the Glibc gai.conf file, because default resolver rules under RFC 3484 preferred IPv4 over local IPv6 subnets when testing connections to Google and Facebook servers [6].
Stateless Prefix Mapping in NPTv6
To help enterprises avoid provider lock-in without the drawbacks of stateful translation, Margaret Wasserman of Painless Security and Fred Baker of Cisco Systems developed IPv6-to-IPv6 Network Prefix Translation. Standardized as an experimental specification in June 2011 under RFC 6296, NPTv6 provides address independence at the network edge. If an organization changes its upstream internet service provider, administrators do not need to renumber thousands of local host addresses, firewall filters, or logging servers [10, 13]. Edge routers translate prefixes algorithmically without altering host identifiers.
Unlike IPv4 masquerading, NPTv6 operates statelessly on a one-to-one prefix basis. The translator replaces the high-order network prefix while preserving the low-order interface identifier of the machine. To prevent recalculating transport layer checksums for every crossing packet, the algorithm uses a checksum-neutral mathematical offset that adjusts specific bits in the address. Because the mapping maintains a direct bidirectional relationship without tracking open connection states, inbound connections can reach inside nodes straight away if outside firewall policies permit them [10].
Multiple hardware and software platforms now support prefix translation, including Juniper Junos, Cisco IOS-XE, VyOS, and Netgate pfSense firewalls. In pfSense software, the NPt feature translates an inside /64 prefix to a routed outside /64 prefix for multi-WAN redundancy. However, the Netgate documentation warns that its implementation operates statefully and differs from pure checksum-neutral RFC 6296 translation [11]. Vendor behaviors vary across implementations.
Carrier Grade Network Address Translation
As regional internet registries exhausted their remaining IPv4 pools, internet service providers could no longer give a dedicated public IPv4 address to every home and mobile subscriber. To keep expanding their subscriber networks, service providers deployed large-scale translation gateways known as Carrier Grade Network Address Translation, or CGNAT. In an academic analysis of migration strategies, researcher Chauhan noted that CGNAT allowed carriers to maintain business continuity and support millions of mobile subscribers while transitioning toward native IPv6 backbones [15].
Service providers frequently structure these deployments around a NAT444 architecture. Under NAT444, user traffic traverses three separate IPv4 addressing domains: the customer’s home subnet, the carrier’s private distribution network, and the public internet. This layered translation handles tens of millions of concurrent flows on high-performance routing hardware. To track connections for regulatory compliance and security reviews without overwhelming standard syslog servers, carrier platforms use High-Speed Logging to record every binding and session event, while Session Initiation Protocol traffic requires specialized application level gateways [2].
While address translation saved the IPv4 internet from collapsing under the weight of billions of devices, it also introduced latency, broke end-to-end encryption protocols like AH, and complicated peer-to-peer applications. Transition tools like NAT64 and Dual-Stack Lite bridges now help IPv6-only devices communicate with legacy IPv4 hosts. As global adoption of IPv6 continues to climb, native end-to-end routing remains the ultimate goal for network operators seeking to retire translation layers entirely [2, 12]. Eliminating translation simplifies routing boundaries and restores genuine peer-to-peer reachability.
- REPORT Audet, F., & Jennings, C. (2007). Network Address Translation (NAT) Behavioral Requirements for Unicast UDP (RFC 4787 / BCP 127). RFC Editor. [Article Link]
- WEBSITE Cisco Systems. (2000). What Is Network Address Translation (NAT)? Cisco Learning Network. [Article Link]
- WEBSITE Cisco Systems. (2005). Using NAT in Overlapping Networks (Document ID 13774). Cisco Technical Tips. [Article Link]
- REPORT Srisuresh, P., & Gan, D. (1998). Load Sharing using IP Network Address Translation (LSNAT) (RFC 2391). RFC Editor. [Article Link]
- WEBSITE Hogg, S. (2021). You Thought There Was No NAT for IPv6, But NAT Still Exists. Infoblox Blog. [Article Link]
- WEBSITE Cilloni, M. (2018). NAT66: The good, the bad, the ugly. APNIC Blog. [Article Link]
- REPORT Wasserman, M., & Baker, F. (2008). IPv6-to-IPv6 Network Address Translation (NAT66) (Internet-Draft draft-mrw-behave-nat66-02). IETF Datatracker. [Article Link]
- WEBSITE H3C. (2018). Configuring NAT66. H3C Technology Documentation. [Article Link]
- WEBSITE Guo, Y. (2023). What Is NAT66? Why Do We Need NAT66? Huawei Info-Finder Encyclopedia. [Article Link]
- REPORT Wasserman, M., & Baker, F. (2011). IPv6-to-IPv6 Network Prefix Translation (RFC 6296). RFC Editor. [Article Link]
- WEBSITE Netgate. (2025). IPv6 Network Prefix Translation (NPt). pfSense Documentation. [Article Link]
- WEBSITE Wikipedia Contributors. (2026). Network address translation. Wikipedia, The Free Encyclopedia. [Article Link]
- WEBSITE Wikipedia Contributors. (2026). IPv6-to-IPv6 Network Prefix Translation. Wikipedia, The Free Encyclopedia. [Article Link]
- ACADEMIC JOURNAL Bansal, A., & Goel, P. (2017). Simulation and Analysis of Network Address Translation (NAT) & Port Address Translation (PAT) Techniques. International Journal of Engineering Research and Applications, 07(07), 50-56. [Article Link]
- ACADEMIC JOURNAL Chauhan, D. (2023). IPv6 Migration Strategy Using Carrier Grade Network Address Translation. International Journal of Wireless and Microwave Technologies, 13(4), 11-17. [Article Link]
