Introduction
A home or office network typically has many hosts but one public IPv4 address. Inside, hosts use private addresses (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), which are not routed on the public Internet and may be reused by every organisation. A NAT router at the border rewrites addresses as packets cross it: outgoing packets get the public address as their source, and replies addressed to the public address are rewritten back to the right private host.
With one public address, the router must tell apart replies meant for different inside hosts. It does this by also rewriting the transport port, so each inside (address, port) pair is mapped to a distinct public port. This is NAPT (network address and port translation), the form almost all NAT boxes use. NAT saves public addresses and hides the inside network, but it breaks the end-to-end model: an outside host cannot start a connection to an inside host unless the router has been configured to forward it.
Prerequisites
- IPv4 Addressing and Header: private blocks, the source and destination address fields, the header checksum.
Core concepts
Basic NAT and NAPT
| Kind | What is translated | Public addresses needed |
|---|---|---|
| Basic NAT | IP address only | One per inside host that is active at a time |
| NAPT | IP address and TCP/UDP port (ICMP query identifier) | One can serve many inside hosts |
The translation table
Each NAPT entry binds an inside endpoint to an outside endpoint:
| Inside (private) | Outside (public) | Created by |
|---|---|---|
| private IP : private port | public IP : public port | The first outbound packet of a session |
- Outbound packet (inside to outside): find or create the entry for its source (private IP, private port); rewrite the source to (public IP, public port).
- Inbound packet (outside to inside): look up its destination (public IP, public port); rewrite the destination to (private IP, private port). If no entry exists, the packet is dropped, unless a static port-forwarding entry was configured.
- Unbinding. Entries are removed when the TCP session closes or after an idle timeout (UDP has no close).
What else must change
Rewriting addresses and ports requires these checksum updates:
- the IP header checksum (it covers the addresses);
- the TCP checksum, and any nonzero IPv4 UDP checksum, because they cover a pseudo-header containing both IP addresses, as well as the ports. Preserve an IPv4 UDP checksum field of zero: it indicates that no checksum was supplied. If the computed UDP checksum is zero, transmit FFFF instead.
A NAT box need not recompute them over the whole packet: RFC 1624 gives an incremental update. If a 16-bit word changes from to , the new checksum is
in one's complement arithmetic, applied once per changed word.
Payload addresses. Protocols that write IP addresses or ports inside their data (FTP's PORT command is the classic one) need an application-level gateway in the NAT box that edits the payload too, including any change in its length.
How it works: two hosts behind one address
Inside network 192.168.1.0/24; NAT router with public address 203.0.113.7; web server 198.51.100.20:80. Both inside hosts happen to choose source port 50000.
| Step | Packet as sent | Packet after NAT | Table entry |
|---|---|---|---|
| 1 | A 192.168.1.10:50000 to 198.51.100.20:80 | 203.0.113.7:6001 to 198.51.100.20:80 | 192.168.1.10:50000 = 203.0.113.7:6001 (new) |
| 2 | B 192.168.1.11:50000 to 198.51.100.20:80 | 203.0.113.7:6002 to 198.51.100.20:80 | 192.168.1.11:50000 = 203.0.113.7:6002 (new) |
| 3 | Server reply to 203.0.113.7:6002 | to 192.168.1.11:50000 | existing |
| 4 | Server reply to 203.0.113.7:6001 | to 192.168.1.10:50000 | existing |
| 5 | Outside host to 203.0.113.7:7000 | dropped | no entry |
The server sees two connections from 203.0.113.7, told apart only by the ports 6001 and 6002. The port numbers 6001 and 6002 are an arbitrary choice of this NAT box; any free ports would do.

Mathematical explanation: capacity
A public address with 16-bit ports can carry at most distinct port mappings per transport protocol at once (fewer in practice, since some ports are reserved or excluded). With inside hosts each holding concurrent sessions to arbitrary destinations, a single public address needs the available port count when each mapping uses a distinct public port. For example, 1000 hosts with 50 sessions each need 50,000 mappings: one address is enough by this count; 2000 hosts would need two.
Worked examples
Example 1: which fields change
An outbound UDP datagram from 192.168.1.10:5353 leaves as 203.0.113.7:6100. Changed by the NAT box: IP source address, UDP source port, IP header checksum, UDP checksum if nonzero (it covers the source address through the pseudo-header and the port directly; zero stays zero), and TTL (decremented as at any router, which also changes the IP checksum). Unchanged: destination address and port, identification, protocol, data.
Example 2: incremental checksum
A UDP checksum is 0x1C2B. NAT changes the source port word from 0x14E9 (5353) to 0x17D4 (6100). With one's complement addition (carry wrapped round):
so the new checksum is . The same update is applied for each changed address word.
Example 3: inbound without an entry
A server outside sends a TCP SYN to 203.0.113.7:22. Without a port-forwarding entry for port 22, the NAT box has no mapping and drops it: inside hosts are reachable only through sessions they started, or through configured forwarding.
Example 4: a host behind two NATs
A host in 10.0.0.0/8 behind a NAT whose outside address is 192.168.1.50, itself behind the home NAT with public address 203.0.113.7. Outbound packets are translated twice; the server sees 203.0.113.7 and the second NAT's port. Replies are translated back through both tables in reverse order.
Important properties and observations
- State in the network. The NAT box keeps per-session state; if it reboots, sessions break.
- Layer violation. A network-layer device reads and rewrites transport-layer ports.
- Not a firewall by design, though dropping unsolicited inbound packets has a similar effect.
- Private addresses repeat. Two organisations may both use
192.168.1.10; only their public addresses must differ. - Peer-to-peer and servers inside need port forwarding or traversal techniques, because outside hosts cannot initiate.
Common misconceptions.
- "NAT changes only the IP address." NAPT also changes ports, and the IP checksum and TCP/nonzero IPv4 UDP checksum need updating; an IPv4 UDP zero field stays zero.
- "The UDP or TCP checksum is unaffected because NAT is a network-layer function." The pseudo-header contains the IP addresses.
- "Inbound traffic is translated using the destination's private address." The inside address is not known outside; the lookup key is the public port.
- "One public address serves unlimited hosts." It serves as many concurrent mappings as there are usable ports.
GATE examination perspective
- Table tracing. Build the table from outbound packets in order; translate replies by public port; drop packets with no entry.
- Fields changed. Source address, source port, IP and TCP/nonzero IPv4 UDP checksums (outbound); destination address and port, corresponding checksums (inbound). Preserve an IPv4 UDP zero checksum; encode a computed UDP zero as FFFF.
- Capacity. Ports per public address, about .
- NAT and IP header semantics. NAT breaks end-to-end addressing; FTP needs a gateway because addresses appear in data.
Summary
Sources
- A. S. Tanenbaum, D. J. Wetherall, Computer Networks, 5th ed., Pearson, 2011: Section 5.6.2 (IP Addresses).
- J. F. Kurose, K. W. Ross, Computer Networking: A Top-Down Approach, 8th ed., Pearson, 2021: Section 4.3.3 (Network Address Translation (NAT)).
- B. A. Forouzan, Data Communications and Networking, 5th ed., McGraw-Hill, 2013: Chapter 18 (Introduction to Network Layer).
- P. Srisuresh, K. Egevang, RFC 3022, Traditional IP Network Address Translator (Traditional NAT), 2001, Sections 2.2 (Overview of NAPT), 3 (Translation phases), 4.1 (Header Manipulations), 4.2 (Checksum Adjustment) and 4.4 (FTP support), (consulted 2026-11-11).
- A. Rijsinghani (Ed.), RFC 1624, Computation of the Internet Checksum via Incremental Update, 1994, Section 3 (Eqn. 3), (consulted 2026-11-11).
- Y. Rekhter et al., RFC 1918, Address Allocation for Private Internets, 1996, Section 3, (consulted 2026-11-11).
- J. Postel, RFC 768, User Datagram Protocol, Fields: Checksum, (consulted 2026-11-11).