IM Engineer Study Notes
← Back to list
Networking
#NAT#PAT#IPv4고갈#CGN#NAT64
Last updated · 2026-10-28

NAT (Network Address Translation)

1. Overview

A. Definition

NAT (Network Address Translation) is a technique that, as an IP packet traverses a boundary device such as a router or firewall, rewrites the source or destination IP address (and port) in the header to a different value, thereby connecting distinct address spaces (typically a private network and the public Internet). The translating device records the correspondence between the original and translated addresses in a NAT table, then restores the addresses of returning reply packets in reverse to mediate two-way communication.

NAT was originally devised to cope with the practical constraint of IPv4 address exhaustion, but today it has become a core means of internal-network concealment and perimeter security beyond mere address conservation. Because hundreds to thousands of private hosts can be hidden behind a single public IP, homes, enterprises, and carriers alike have reached a structure in which they effectively cannot reach the Internet without NAT. RFC 2663 and 3022 standardized its concepts and terminology, and in particular, as the scheme that also translates ports (NAPT/PAT) became universal, the constraint of "one public IP = one host" was broken.

B. Background and Necessity

The most direct reason NAT became necessary is the structural exhaustion of IPv4 addresses. IPv4 can represent only about 4.3 billion addresses (2³²), and as Internet-connected terminals exploded, exhaustion was already foreseen in the 1990s, with IANA's top-level address blocks depleted in 2011. NAT dramatically reduced public-address consumption by freely reusing internally the private ranges defined by RFC 1918 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) and translating to a small number of public IPs only when leaving for the outside.

The second reason is concealment of internal topology and perimeter control. When traffic passes through NAT, the outside cannot see the actual address structure of internal hosts and sees only the single public IP of the translating device, making it hard for an attacker to directly pinpoint and scan internal terminals. In a PAT environment in particular, inbound sessions from outside to inside are blocked unless explicitly opened, and this "block by default" property provides a first-line perimeter effect that complements the firewall.

The third reason is independence of the addressing scheme and ease of migration. Using private addresses lets an organization keep internal addresses unchanged regardless of external public-address changes when switching ISPs or merging two organizations, and conversely NAT can avoid address collisions when connecting two networks that use overlapping private ranges. In this way NAT simultaneously provides the three values of address conservation, security, and operational flexibility, and became a hidden foundation of Internet growth.

C. Goals and Scope

The goals of adopting NAT are, first, the conservation and sharing of public IPv4 addresses; second, reinforcement of perimeter security through concealment of internal structure; and third, securing operational independence based on private addresses. Its scope spans nearly every point where a private/public boundary exists—home routers, enterprise perimeter firewalls, outbound gateways of data centers and clouds, and the large-scale shared devices of carriers (CGN). However, NAT breaks end-to-end transparency and causes failures in P2P, VoIP, and some protocols, so it can be applied correctly only when one also understands its limits and traversal techniques.

2. Operating Principles and Components of NAT

A. Overall Structure

The overall structure of NAT is summarized as a flow in which packets from the private network are translated to public addresses at the boundary device and sent out to the Internet, and replies are restored to the original host via the NAT table. The translating device has an inside and an outside interface, and for each session registers a pair (inside IP·port ↔ public IP·port) in the table.

flowchart LR
    subgraph INSIDE["Private network (Inside, RFC 1918)"]
        H1["Host A(192.168.0.10)"]
        H2["Host B(192.168.0.11)"]
    end
    H1 --> NAT
    H2 --> NAT
    NAT["NAT device(boundary router/firewall)"]
    TBL[("Translation table(session mapping)")] -.->|"lookup·restore mapping"| NAT
    NAT -->|"replace source IP with public IP"| INET["Internet(Outside)"]
    INET -->|"reply packet"| NAT
    NAT -.->|"restore destination to original host"| H1

Placing the translation table (session mapping) at the center is the key point. As a stateful device, NAT must create a mapping upon seeing the first outgoing packet and be able to restore the reply, so the lifetime, size, and policy of this table govern NAT's performance and security.

B. Translation Lifecycle and Components

The lifecycle of a single session passing through NAT, shown as a sequence using PAT (port translation) as an example, is as follows. Even when internal hosts differ, assigning different ports so that a single public IP is shared is the essence of PAT.

sequenceDiagram
    participant A as Host A(192.168.0.10:3500)
    participant N as NAT/PAT device
    participant S as Web server(203.0.113.9:443)
    A->>N: "SYN source=192.168.0.10:3500"
    N->>N: "create mapping: inside 10:3500 -> public 1.1.1.1:40001"
    N->>S: "SYN source replaced with 1.1.1.1:40001"
    S-->>N: "SYN-ACK destination=1.1.1.1:40001"
    N->>N: "identify original host via table lookup"
    N-->>A: "SYN-ACK destination=192.168.0.10:3500 restored"
    Note over N: "mapping reclaimed on session close·timeout"

There are four core components. The inside/outside interfaces are the boundary that serves as the reference for translation, and the address pool (NAT pool) is the set of public addresses used for translation. The translation table is the state store that holds per-session mappings and timers, and the ALG (Application Layer Gateway) is an auxiliary module that also rewrites the body for protocols such as FTP and SIP that carry IPs and ports inside the payload.

C. Detailed Operation of Address·Port Translation

The fields NAT changes include not only the addresses in the IP header but also the checksum, which must be recomputed accordingly, and, in the case of PAT, the port number in the TCP/UDP header. Because the IP checksum and the TCP/UDP checksum are computed including addresses and ports, the NAT device must recompute (or incrementally update) them after translation, or the packet is discarded. Port assignment is usually chosen from available ports above 1024, and a single public IP can theoretically distinguish as many concurrent sessions as its roughly 60,000-odd ports, though in practice fewer because of timers, collisions, and reserved ports.

Protocols with no ports, such as ICMP, use the Query ID as an identifier in place of a port for mapping, which is why ping and traceroute also work correctly in a PAT environment. Meanwhile, each mapping has an idle timeout and is reclaimed when there is no traffic for a certain time; if this value is too short idle sessions drop, and if too long the table saturates, so tuning it appropriately per TCP/UDP is the crux of operation.

3. Types of NAT

A. Static NAT and Dynamic NAT

NAT is broadly divided by mapping scheme into static, dynamic, and PAT. Static NAT fixes one internal IP to one public IP in a permanent 1:1 correspondence, used when the outside must always reach an internal server at the same public address (publishing a web or mail server). It does not conserve addresses, but because the mapping is fixed and inbound is predictable, it is the standard way to publish DMZ servers.

Dynamic NAT keeps a pool of public addresses and temporarily borrows one 1:1 from the pool each time an internal host goes outside. It needs only as many public addresses as the number of hosts going out concurrently, so it is more efficient than static, but once the pool is exhausted no more can connect, and because the mapping differs each time, the outside cannot reach a specific internal host.

B. PAT (NAPT) and Sharing Among Many Hosts

PAT (Port Address Translation, NAPT) is the most prevalent scheme today, mapping many internal hosts simultaneously by assigning different ports on a single public IP. A home router connecting dozens of terminals to the Internet via the single public IP given by the ISP is exactly PAT, also called "IP overloading." Its address-conservation effect is the greatest, but since inbound sessions from outside to inside are blocked by default, publishing a server requires separately configuring port forwarding (static mapping).

flowchart TB
    START["receive outgoing packet"] --> Q1{"destination is an internal published server?"}
    Q1 -->|"yes(inbound·static)"| STATIC["apply static mapping/port forwarding"]
    Q1 -->|"no(outbound)"| Q2{"translation scheme?"}
    Q2 -->|"1:1 fixed"| SNAT["static NAT mapping"]
    Q2 -->|"1:1 temporary from pool"| DNAT["dynamic NAT allocation"]
    Q2 -->|"1 IP + many ports"| PAT["PAT port assignment"]
    SNAT --> WRITE["record in table·recompute checksum"]
    DNAT --> WRITE
    PAT --> WRITE
    STATIC --> WRITE
    WRITE --> OUT["send to public network"]

C. Comparison of NAT Subtypes

PAT behaves differently depending on how tightly it binds a mapping to the external address·port, and this difference governs the traversability of P2P and VoIP. The table below organizes the characteristics of each type from the perspectives of address conservation, inbound, and representative use.

Category Static NAT Dynamic NAT PAT (NAPT)
Mapping relation 1:1 fixed 1:1 temporary(pool) N:1(distinguished by port)
Address conservation none medium very large
Inbound access always possible only while mapped blocked by default(forwarding needed)
Representative use server publishing·DMZ intermittent external access home·enterprise sharing
Port translation none none yes

The key difference is that static NAT suits "servers that must be published" and PAT suits "many terminals to be sent out while hidden." Dynamic NAT is in between, but without port sharing it does not conserve as much as PAT, so in practice a configuration combining static for servers and PAT for the user network is common.

4. Limits of NAT and Traversal Techniques

Because NAT breaks end-to-end connectivity, it causes fundamental failures in applications where the outside first attempts to connect inward. In particular, for P2P file sharing, VoIP (SIP/RTP), online games, and video conferencing—where both sides must establish a session directly—if both are behind PAT, neither can learn the other's real address·port and the connection fails to form. The standard techniques to solve this are STUN, TURN, and ICE.

STUN (Session Traversal Utilities for NAT) lets an internal host query an external STUN server to learn "the public IP·port by which I am seen from outside," so it can tell that address to the peer and attempt a direct connection. However, in environments such as symmetric NAT that assign a different port per destination, the address learned via STUN is not used in the actual communication and fails; in that case a TURN (Traversal Using Relays around NAT) server relays the traffic to work around it. ICE (Interactive Connectivity Establishment) is a framework that collects all candidates—direct connection, STUN, and TURN—and automatically selects a workable path; WebRTC adopted it to enable real-time communication between browsers.

Meanwhile, protocols that carry IPs·ports in the payload at the application layer, such as FTP (active mode) and SIP, require the ALG to rewrite the body as well to work, and home routers automate traversal with protocols such as UPnP IGD·NAT-PMP·PCP that let terminals request port forwarding themselves. Thus NAT traversal must be understood as a structure in which "the application and auxiliary protocols restore the transparency that NAT broke."

5. In Depth: Large-Scale NAT (CGN) and IPv6 Transition Trends

A. Carrier-Grade NAT (CGN)

As IPv4 exhaustion deepened and carriers could no longer give subscribers public IPs, they introduced CGN (or LSN, Large Scale NAT), placing a second NAT layer inside the ISP. It is a double NAT structure in which the ISP's CGN (second NAT) again translates traffic already translated by the subscriber home's router (first NAT), and here subscribers are given the 100.64.0.0/10 shared range that RFC 6598 allocated exclusively for this purpose. CGN lets tens of thousands of subscribers share a small number of public IPs, conserving addresses to the extreme, but it makes per-subscriber inbound impossible and, as many share one public IP, produces side effects in which tracing of abuse (logging) and IP-based blocking·reputation management become difficult. For this reason CGN requires port-block-unit allocation together with detailed logging, and RFC 6888 specifies these CGN requirements.

B. IPv6 Transition and NAT64/DNS64

NAT was a successful stopgap that extended the life of IPv4, but the fundamental solution is the transition to IPv6, whose address space is effectively unlimited (2¹²⁸). IPv6 can give a public address to every terminal, so NAT is in principle unnecessary, but during the transition a mixed situation arises in which IPv6-only terminals must communicate with IPv4-only servers. What mediates this is NAT64 (RFC 6146), which translates IPv6 packets to IPv4 and is usually used together with DNS64 (RFC 6147) to synthesize an IPv4 address into an IPv6 address and return it to the terminal. That said, since there is demand to use NAT even in IPv6 for the purpose of concealing internal structure, stateless prefix translation such as NPTv6 (RFC 6296) was defined, but the IETF recommends achieving security with firewalls rather than address translation in IPv6, so NAT is trending toward convergence as an IPv4 legacy technology.

C. Expected Exam Directions and Answer Strategy

From a professional engineer's perspective, NAT may appear as a conceptual explanation of "IPv4 exhaustion response and address-conservation mechanisms," or expand into an analytical question on "NAT type comparison and security·traversal design." An answer should not stop at a simple definition but unfold ① the mapping differences and application criteria of static·dynamic·PAT, ② detailed translation operations such as checksum·port·ALG, and ③ STUN·TURN·ICE traversal techniques and the transition context of CGN·NAT64, woven along the trade-off axis of address conservation–security–impairment of end-to-end transparency. Adding the outlook on IPv6 transition reveals an integrated perspective at the professional-engineer level.

6. Considerations and Implications

  • Do not overtrust the security effect: NAT's inbound block-by-default is only an incidental perimeter effect, not a designed security control. Once holes are opened via port forwarding·UPnP, hosts are exposed as is, so NAT must not be regarded as a substitute for a firewall and should be composed in multiple layers together with a stateful firewall·IPS. In particular, during IPv6 transition one must not fall into the misconception that "the absence of NAT is dangerous" but should explicitly design perimeter control with firewall policy.
  • Impairment of end-to-end transparency and application compatibility: NAT breaks protocols that presume direct end-to-end connection. When adopting VoIP·video conferencing·P2P, one must design together with whether STUN/TURN/ICE are supported and the bandwidth·cost of TURN relay servers, and also include in the checklist unexpected payload mangling caused by ALGs (cases that in fact cause failures).
  • Performance·scalability and state-table management: Because NAT is a stateful device, the number of concurrent sessions directly affects translation-table size and CPU. In large-scale environments table saturation·port exhaustion leads to service outages, so timeout tuning·session caps·redundancy (state synchronization between devices) must be reflected in the design, and CGN must balance logging volume and traceability through port-block allocation.
  • Traceability·legal response and the CGN dilemma: In CGN, where many subscribers share one public IP, identifying a specific subscriber at the time of an incident is difficult, creating common difficulties in investigation cooperation·abuse blocking·reputation management. An operational regime is needed that mandates port-range-unit logging and accurate time synchronization (NTP) to secure traceability.
  • Outlook — convergence into an IPv4 legacy technology: NAT extended IPv4's life by more than 20 years, but as IPv6 adoption rises, the long-term outlook is a transition, via NAT64·dual-stack, to a "NAT-free end-to-end Internet." Since IPv4/IPv6 coexistence is unavoidable for the time being, it is realistic for organizations to adopt dual-stack as the baseline and operate NAT only as a transitional relay·address-conservation means.

References

In one line: NAT is a technique that translates IP addresses·ports at a boundary device to join private and public networks; it conserves addresses in response to IPv4 exhaustion and conceals internal networks, but only when one also understands the mapping differences of static·dynamic·PAT, the transition context of CGN·NAT64, and the STUN·TURN·ICE traversal techniques that compensate for the impairment of end-to-end transparency can it be correctly designed and operated—a transitional core-infrastructure technology converging toward the IPv6 era.