Network address translation, or NAT, changes IP addressing information as packets cross between networks. When the translator also changes port numbers, it can let several devices share one external address while still directing replies to the right device.

NAT includes several designs. A home router translating IPv4 traffic, an IPv6-to-IPv4 translator, and an IPv6 prefix translator do not all change the same fields or keep the same kind of state. Some translators keep records of active connections, while others translate addresses without those records.

Addresses, Ports, and Translation Rules

Basic NAT changes addresses without translating transport ports. Network address and port translation, called NAPT or PAT, includes ports in the mapping. Address sharing therefore does not mean that every device receives an identical local address; the translation happens as traffic passes through the translator.

Source translation changes where a packet appears to come from. Destination translation changes where the packet is being sent, such as redirecting traffic arriving at an external address to an internal server. These describe which fields change, rather than which IP version the translator uses.

A static mapping is configured in advance, such as a fixed translation for an internal server. A dynamic mapping can be created as traffic arrives or explicitly requested through a supported control protocol. Dynamic mappings have a limited lifetime; static mappings normally remain until an administrator removes them.

A Packet’s Trip through an IPv4 Translator

Consider this example using the Transmission Control Protocol (TCP). The external addresses below are reserved for examples and do not represent a tested connection. The chosen ports simply make the two sides of the mapping visible.

  1. A client at 192.168.50.23 sends from port 51000 to a server at 198.51.100.80, port 443.
  2. The translator changes the source to 203.0.113.9, port 62010, while retaining the server destination.
  3. The server replies to 203.0.113.9, port 62010.
  4. The translator uses the matching state to restore the destination to 192.168.50.23, port 51000, and forwards the reply.

A different mapped port can distinguish another client’s exchange through the same external address.

How Mappings and Filtering Affect Incoming Traffic

With address and port translation, a mapping associates an internal address and port with an external address and port. Filtering decides which incoming packets the translator will forward using that mapping. For User Datagram Protocol (UDP) traffic, endpoint-independent mapping means that the translator reuses the same external mapping for packets from the same internal address and port, even when those packets go to different destinations. Other mapping behaviors use a different external mapping when the destination address, or the destination address and port, changes.

Filtering can likewise accept traffic regardless of the external sender, restrict it to previously contacted addresses, or also require a matching remote port. The mapping behavior alone therefore does not tell you which incoming packets will be admitted. A label such as “NAT enabled” leaves these details unanswered.

A NAT device that tracks TCP connections may delete a connection record after no traffic has passed for a while. The two devices at either end may still consider the connection open. If the NAT device no longer has the mapping needed to forward packets, further traffic may fail.

This is why timeout behavior matters for long-lived, mostly idle connections. An application’s keepalive behavior and the translator’s actual policy must be compatible. A timeout stated for one implementation or transport should not be applied to every NAT device or every kind of traffic.

NAT44, NAT64, and Translation within IPv6

NAT44 replaces one set of IPv4 addresses with another. It includes both address-only translation and translation that also changes identifiers such as TCP or UDP port numbers. Packets remain IPv4 packets on both sides of the translator.

Stateful NAT64 converts packets between IPv6 and IPv4 and keeps mappings between the addresses and ports on each side. It lets an IPv6-only client initiate communication with an IPv4-only server. The translator uses the mapping to send the server’s replies back to the IPv6 client.

DNS64 can supply a synthesized IPv6 address for an IPv4 destination, helping an IPv6 client send traffic toward NAT64. DNS64 supplies the address information; NAT64 translates the packets. That distinction matters when diagnosing a failure, because resolving a name and translating the resulting traffic are separate operations.

NAT66 means translation from IPv6 addresses to other IPv6 addresses. Some implementations support port translation as well. For example, Cisco Firewall Threat Defense supports IPv6 interface PAT, allowing internal devices to share an outside IPv6 address by using different ports.

NPTv6 is a more specific design: stateless IPv6 prefix translation with a reversible, one-to-one address mapping and no port translation. It does not combine many internal addresses into one external address as PAT does. NPTv6 has an experimental specification, and IPv6 networks do not have to use address translation.

A stateless prefix translator does not need a separate dynamic record for each connection. Identically configured NPTv6 translators can therefore translate traffic without exchanging connection records. Applications can still have problems if they rely on an address that differs on the other side of the translator.

A Second Translator in the Provider’s Network

Carrier-grade NAT, or CGN, shares external IPv4 addresses among subscribers and is managed by the internet service provider. It may sit beyond a customer’s own router. Traffic can consequently pass through one translation at home and another within the provider’s network.

A forwarding rule on the home router controls only that router. It cannot, by itself, establish a matching inbound mapping at the provider’s translator. Before planning an externally reachable service, determine who controls each translation point and whether the provider offers a suitable inbound arrangement.

A public address in a server log can therefore be shared by several subscribers, as well as by several devices in one household. The address alone cannot identify a single device.

Why NAT Does Not Replace a Firewall

NAT does not replace a firewall because changing addresses does not define a policy for allowed traffic. A firewall applies that policy. A single router can perform both jobs, which makes the distinction easy to miss when they are configured through one administration screen.

A translator without a suitable mapping may be unable to deliver unsolicited inbound traffic to an internal client. That effect is not a complete security policy. A static translation exposing an internal server still leaves that server reachable unless filtering restricts access.

Address translation also does not encrypt application data or establish who is permitted to use a service. Authentication, transport encryption, host security, and traffic filtering retain their own roles. An IPv6 network can enforce a stateful firewall policy without translating its addresses.

NAT Traversal for Peer-to-Peer Applications

In a peer-to-peer application, each device may need to receive a new connection from another device. An incoming connection can fail if the receiving device’s NAT has no suitable mapping or its filtering rules block the traffic. Applications can try to establish a direct connection through the translators, a process called NAT traversal, or use a relay server that both devices can reach.

A relay carries traffic between the peers through their connections to the relay server. It can make communication possible when a direct path is unavailable, but it consumes relay resources and may add latency. A successful connection through a relay does not demonstrate that the peers could have connected directly.

When investigating a specific failure, record which operation failed: obtaining an external mapping, receiving a reply, accepting a new incoming connection, or maintaining an idle session. Then check the relevant translation and filtering behavior. “Behind NAT” describes the network arrangement; it does not establish which of those operations failed.