Hubbry Logo
Network address translationNetwork address translationMain
Open search
Network address translation
Community hub
Network address translation
logo
8 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
Network address translation
Network address translation
Network address translation
View on Wikipedia
from Wikipedia

Network address translation between a private network and the Internet

Network address translation (NAT) is a method of mapping an IP address space into another by modifying network address information in the IP header of packets while they are in transit across a traffic routing device.[1] The technique was initially used to bypass the need to assign a new address to every host when a network was moved, or when the upstream Internet service provider was replaced but could not route the network's address space. It is a popular and essential tool in conserving global address space in the face of IPv4 address exhaustion. One Internet-routable IP address of a NAT gateway can be used for an entire private network.[2]

As network address translation modifies the IP address information in packets, NAT implementations may vary in their specific behavior in various addressing cases and their effect on network traffic. Vendors of equipment containing NAT implementations do not commonly document the specifics of NAT behavior.[2]

History

[edit]

Internet Protocol version 4 (IPv4) uses 32-bit addresses, capable of uniquely addressing about 4.3 billion devices on the network. By 1992, it became evident that that would not be enough. The 1994 RFC 1631 describes NAT as a "short-term solution" to the two most compelling problems facing the Internet Protocol at that time: IP address depletion and scaling in routing. By 2004, NAT had become widespread.[3]

The technique also became known as IP masquerading. which suggests a technique that hides an entire IP address space, usually consisting of private IP addresses, behind a single IP address in another, usually public address space. Because of the popularity of this technique to conserve IPv4 address space, the term NAT became virtually synonymous with IP masquerading.

In 1996, port-address translation (PAT) was introduced,[4] which expanded the translation of addresses to include port numbers.

Basic NAT

[edit]

The simplest type of NAT provides a one-to-one translation of IP addresses (RFC 1631). RFC 2663 refers to this type of NAT as basic NAT, also called a one-to-one NAT. In this type of NAT, only the IP addresses, IP header checksum, and any higher-level checksums that include the IP address are changed. Basic NAT can be used to interconnect two IP networks with incompatible addresses.[2]

One-to-many NAT

[edit]
Network address mapping

Most network address translators map multiple private hosts to one publicly exposed IP address.

In a typical configuration, a local network uses one of the designated private IP address subnets (RFC 1918[5]). The network has a router having network interfaces on both the private and the public network. The public address is typically assigned by an Internet service provider. As traffic passes from the private network to the Internet, NAT translates the source address in each packet from a private address to the router's public address. The NAT facility tracks each active connection. When the router receives inbound traffic from the Internet, it uses the connection tracking data obtained during the outbound phase to determine to which private address it should forward the reply.[2]

Packets passing from the private network to the public network will have their source address modified, while packets passing from the public network back to the private network will have their destination address modified. To avoid ambiguity in how replies are translated, further modifications to the packets are required. The vast bulk of Internet traffic uses Transmission Control Protocol (TCP) or User Datagram Protocol (UDP). For these protocols, the port numbers are changed so that the combination of IP address (within the IP header) and port number (within the Transport Layer header) on the returned packet can be unambiguously mapped to the corresponding private network destination. RFC 2663 uses the term network address and port translation (NAPT) for this type of NAT.[5] Other names include port address translation (PAT), IP masquerading, NAT overload, and many-to-one NAT. This is the most common type of NAT and has become synonymous with the term NAT in common usage.

This method allows communication through the router only when the conversation originates in the private network, since the initial originating transmission establishes the required information in the translation tables. Thus, a web browser within the private network is able to browse websites that are outside the network, whereas web browsers outside the network are unable to browse a website hosted within.[a] Protocols not based on TCP and UDP require other translation techniques.

The primary benefit of one-to-many NAT is mitigation of IPv4 address exhaustion by allowing entire networks to be connected to the Internet using a single public IP address.

Methods of translation

[edit]

Network address and port translation may be implemented in several ways. Some applications that use IP address information may need to determine the external address of a network address translator. This is the address that its communication peers in the external network detect. Furthermore, it may be necessary to examine and categorize the type of mapping in use, for example when it is desired to set up a direct communication path between two clients both of which are behind separate NAT gateways.

For this purpose, RFC 3489 specified the protocol Simple Traversal of UDP over NATs (STUN) in 2003. It classified NAT implementations as full-cone NAT, (address) restricted-cone NAT, port-restricted cone NAT or symmetric NAT, and proposed a methodology for testing a device accordingly. However, these procedures have since been deprecated from standards status, as the methods are inadequate to correctly assess many devices. RFC 5389 standardized new methods in 2008 and the acronym STUN since represents the new title of the specification: Session Traversal Utilities for NAT.

NAT types
Endpoint-Independent NAT, Full Cone NAT, 1:1/one-to-one NAT, or NAT 1
  • Once an internal address (iAddr:iPort) is mapped to an external address (eAddr:ePort), any packets from iAddr:iPort are sent through eAddr:ePort.
  • Any external host can send packets to iAddr:iPort by sending packets to eAddr:ePort.
Address-Dependent NAT, Restricted Cone NAT, or NAT 2
  • Once an internal address (iAddr:iPort) is mapped to an external address (eAddr:ePort), any packets from iAddr:iPort are sent through eAddr:ePort.
  • An external host (hAddr:any) can send packets to iAddr:iPort by sending packets to eAddr:ePort only if iAddr:iPort has previously sent a packet to hAddr:any. Any means the port number doesn't matter.
Address- and Port-Dependent NAT, Port Restricted Cone NAT, or NAT 3
  • Once an internal address (iAddr:iPort) is mapped to an external address (eAddr:ePort), any packets from iAddr:iPort are sent through eAddr:ePort.
  • An external host (hAddr:hPort) can send packets to iAddr:iPort by sending packets to eAddr:ePort only if iAddr:iPort has previously sent a packet to hAddr:hPort.

It is similar to an address restricted cone NAT, but the restriction includes port numbers.

Address- and Port-Dependent NAT, Symmetric NAT, or NAT 4
  • The combination of one internal IP address and a destination IP address and port is mapped to a single unique external source IP address and port; if the same internal host sends a packet even with the same source address and port but to a different destination, a different mapping is used.
  • Only an external host that receives a packet from an internal host can send a packet back.

As many NAT implementations combine multiple types, it is better to refer to specific individual NAT behavior instead of using the Cone/Symmetric terminology. RFC 4787 attempts to alleviate confusion by introducing standardized terminology for observed behaviors. For the first bullet in each row of the above table, the RFC would characterize Full-Cone, Restricted-Cone, and Port-Restricted-Cone NATs as having an Endpoint-Independent Mapping, whereas it would characterize a Symmetric NAT as having an Address- and Port-Dependent Mapping. For the second bullet in each row of the above table, RFC 4787 would also label Full-Cone NAT as having an Endpoint-Independent Filtering, Restricted-Cone NAT as having an Address-Dependent Filtering, Port-Restricted Cone NAT as having an Address- and Port-Dependent Filtering, and Symmetric NAT as having either an Address-Dependent Filtering or Address- and Port-Dependent Filtering. Other classifications of NAT behavior mentioned in the RFC include whether they preserve ports, when and how mappings are refreshed, whether external mappings can be used by internal hosts (i.e., its hairpinning behavior), and the level of determinism NATs exhibit when applying all these rules.[2] Specifically, most NATs combine symmetric NAT for outgoing connections with static port mapping, where incoming packets addressed to the external address and port are redirected to a specific internal address and port.

NAT mapping vs NAT filtering

[edit]

RFC 4787 distinguishes between NAT mapping and NAT filtering.[2]

Section 4.1 of the RFC covers NAT mapping and specifies the translation of an external IP address and port number into an internal IP address and port number. It defines endpoint-independent mapping, address-dependent mapping and address- and port-dependent mapping, explains that these three possible choices do not relate to the security of the NAT as security is determined by the filtering behavior and then specifies "A NAT MUST have an 'Endpoint-Independent Mapping' behavior."

Section 5 of the RFC covers NAT filtering and describes the criteria used by the NAT to filter packets originating from specific external endpoints. The options are endpoint-independent filtering, address-dependent filtering and address- and port-dependent filtering. Endpoint-independent filtering is recommended where maximum application transparency is required while address-dependent filtering is recommended where more stringent filtering behavior is most important.

Some NAT devices are not compliant with RFC 4787 as they treat NAT mapping and filtering in the same way so that their configuration option for changing the NAT filtering method also changes the NAT mapping method (e.g. Netgate TNSR).

Type of NAT and NAT traversal, role of port preservation for TCP

[edit]

NAT traversal problems arise when peers behind different NATs try to communicate. One way to solve this problem is to use port forwarding. Another way is to use various NAT traversal techniques. The most popular technique for TCP NAT traversal is TCP hole punching.

TCP hole punching requires the NAT to follow the port preservation design for TCP. For a given outgoing TCP communication, the same port numbers are used on both sides of the NAT. NAT port preservation for outgoing TCP connections is crucial for TCP NAT traversal because, under TCP, one port can only be used for one communication at a time. Programs that bind distinct TCP sockets to ephemeral ports for each TCP communication, make NAT port prediction impossible for TCP.[2]

On the other hand, for UDP, NATs do not need port preservation. Indeed, multiple UDP communications (each with a distinct endpoint) can occur on the same source port, and applications usually reuse the same UDP socket to send packets to distinct hosts. This makes port prediction straightforward, as it is the same source port for each packet.

Furthermore, port preservation in NAT for TCP allows P2P protocols to offer less complexity and less latency because there is no need to use a third party (like STUN) to discover the NAT port since the application itself already knows the NAT port.[2][6]

However, if two internal hosts attempt to communicate with the same external host using the same port number, the NAT may attempt to use a different external IP address for the second connection or may need to forgo port preservation and remap the port.[2]: 9 As of 2006, roughly 70% of the clients in peer-to-peer (P2P) networks employed some form of NAT.[7]

Implementation

[edit]

Establishing two-way communication

[edit]
In bidirectional NAT the session can be established both from inside and outside realms.

Every TCP and UDP packet contains a source port number and a destination port number. Each of those packets is encapsulated in an IP packet, whose IP header contains a source IP address and a destination IP address. The IP address/protocol/port number triple defines an association with a network socket.

For publicly accessible services such as web and mail servers the port number is important. For example, port 443 connects through a socket to the web server software and port 465 to a mail server's SMTP daemon.[8] The IP address of a public server is also important, similar in global uniqueness to a postal address or telephone number. Both IP address and port number must be correctly known by all hosts wishing to successfully communicate.

Private IP addresses as described in RFC 1918 are usable only on private networks not directly connected to the internet. Ports are endpoints of communication unique to that host, so a connection through the NAT device is maintained by the combined mapping of port and IP address. A private address on the inside of the NAT is mapped to an external public address. Port address translation (PAT) resolves conflicts that arise when multiple hosts happen to use the same source port number to establish different external connections at the same time.

Translation process

[edit]

With NAT, all communications sent to external hosts actually contain the external IP address and port information of the NAT device instead of internal host IP addresses or port numbers. NAT only translates IP addresses and ports of its internal hosts, hiding the true endpoint of an internal host on a private network.

When a computer on the private (internal) network sends an IP packet to the external network, the NAT device replaces the internal source IP address in the packet header with the external IP address of the NAT device. PAT may then assign the connection a port number from a pool of available ports,[b] inserting this port number in the source port field. The packet is then forwarded to the external network. The NAT device then makes an entry in a translation table containing the internal IP address, original source port, and the translated source port. Subsequent packets from the same internal source IP address and port number are translated to the same external source IP address and port number. The computer receiving a packet that has undergone NAT establishes a connection to the port and IP address specified in the altered packet, oblivious to the fact that the supplied address is being translated.

Upon receiving a packet from the external network, the NAT device searches the translation table based on the destination port in the packet header. If a match is found, the destination IP address and port number is replaced with the values found in the table and the packet is forwarded to the inside network. Otherwise, if the destination port number of the incoming packet is not found in the translation table, the packet is dropped or rejected because the PAT device doesn't know where to send it.

Applications

[edit]
Routing
Network address translation can be used to mitigate IP address overlap.[9][10] Address overlap occurs when hosts in different networks with the same IP address space try to reach the same destination host. This is most often a misconfiguration and may result from the merger of two networks or subnets, especially when using RFC 1918 private network addressing. The destination host experiences traffic apparently arriving from the same network, and intermediate routers have no way to determine where reply traffic should be sent to. The solution is either renumbering to eliminate overlap or network address translation.
Load balancing
In client–server applications, load balancers forward client requests to a set of server computers to manage the workload of each server. Network address translation may be used to map a representative IP address of the server cluster to specific hosts that service the request.[11][12][13][14]
[edit]

IEEE Reverse Address and Port Translation (RAPT or RAT) allows a host whose real IP address changes from time to time to remain reachable as a server via a fixed home IP address.[15] Cisco's RAPT implementation is PAT or NAT overloading and maps multiple private IP addresses to a single public IP address. Multiple addresses can be mapped to a single address because each private address is tracked by a port number. PAT uses unique source port numbers on the inside global IP address to distinguish between translations.[c] PAT attempts to preserve the original source port. If this source port is already used, PAT assigns the first available port number starting from the beginning of the appropriate port group 0–511, 512–1023, or 1024–65535. When there are no more ports available and there is more than one external IP address configured, PAT moves to the next IP address to try to allocate the original source port again. This process continues until it runs out of available ports and external IP addresses.

Mapping of Address and Port is a Cisco proposal that combines Address plus Port translation with tunneling of the IPv4 packets over an ISP provider's internal IPv6 network. In effect, it is an (almost) stateless alternative to carrier-grade NAT and DS-Lite that pushes the IPv4 address/port translation function (and the maintenance of NAT state) entirely into the existing customer premises equipment NAT implementation. Thus avoiding the NAT444 and statefulness problems of carrier-grade NAT, and also provides a transition mechanism for the deployment of native IPv6 at the same time with very little added complexity.

Issues and limitations

[edit]

Hosts behind NAT-enabled routers do not have end-to-end connectivity and cannot participate in some internet protocols. Services that require the initiation of TCP connections from the outside network, or that use stateless protocols such as those using UDP, can be disrupted. Unless the NAT router makes a specific effort to support such protocols, incoming packets cannot reach their destination. Some protocols can accommodate one instance of NAT between participating hosts ("passive mode" FTP, for example), sometimes with the assistance of an application-level gateway (see § Applications affected by NAT), but fail when both systems are separated from the internet by NAT. The use of NAT also complicates tunneling protocols such as IPsec because NAT modifies values in the headers which interfere with the integrity checks done by IPsec and other tunneling protocols.

End-to-end connectivity has been a core principle of the Internet, supported, for example, by the Internet Architecture Board. Current Internet architectural documents observe that NAT is a violation of the end-to-end principle, but that NAT does have a valid role in careful design.[16] There is considerably more concern with the use of IPv6 NAT, and many IPv6 architects believe IPv6 was intended to remove the need for NAT.[17]

An implementation that only tracks ports can be quickly depleted by internal applications that use multiple simultaneous connections such as an HTTP request for a web page with many embedded objects. This problem can be mitigated by tracking the destination IP address in addition to the port thus sharing a single local port with many remote hosts. This additional tracking increases implementation complexity and computing resources at the translation device.

Because the internal addresses are all disguised behind one publicly accessible address, it is impossible for external hosts to directly initiate a connection to a particular internal host. Applications such as VOIP, videoconferencing, and other peer-to-peer applications must use NAT traversal techniques to function.

Fragmentation and checksums

[edit]

Pure NAT, operating on IP alone, may or may not correctly parse protocols with payloads containing information about IP, such as ICMP. This depends on whether the payload is interpreted by a host on the inside or outside of the translation. Basic protocols such as TCP and UDP cannot function properly unless NAT takes action beyond the network layer.

IP packets have a checksum in each packet header, which provides error detection only for the header. IP datagrams may become fragmented and it is necessary for a NAT to reassemble these fragments to allow correct recalculation of higher-level checksums and correct tracking of which packets belong to which connection.

TCP and UDP have a checksum that covers all the data they carry, as well as the TCP or UDP header, plus a pseudo-header that contains the source and destination IP addresses of the packet carrying the TCP or UDP header. For an originating NAT to pass TCP or UDP successfully, it must recompute the TCP or UDP header checksum based on the translated IP addresses, not the original ones, and put that checksum into the TCP or UDP header of the first packet of the fragmented set of packets.

Alternatively, the originating host may perform path MTU Discovery to determine the packet size that can be transmitted without fragmentation and then set the don't fragment (DF) bit in the appropriate packet header field. This is only a one-way solution, because the responding host can send packets of any size, which may be fragmented before reaching the NAT.

Variant terms

[edit]

DNAT

[edit]

Destination network address translation (DNAT) is a technique for transparently changing the destination IP address of a routed packet and performing the inverse function for any replies. Any router situated between two endpoints can perform this transformation of the packet.

DNAT is commonly used to publish a service located in a private network on a publicly accessible IP address. This use of DNAT is also called port forwarding, or DMZ when used on an entire server, which becomes exposed to the WAN, becoming analogous to an undefended military demilitarized zone (DMZ).

SNAT

[edit]

The meaning of the term SNAT varies by vendor:[18][19][20]

  • source NAT is a common expansion and is the counterpart of destination NAT (DNAT). This is used to describe one-to-many NAT; NAT for outgoing connections to public services.
  • stateful NAT is used by Cisco Systems[21]
  • static NAT is used by WatchGuard[22]
  • secure NAT is used by F5[23] and by Microsoft (in regard to the ISA Server)

Secure network address translation (SNAT) is part of Microsoft's Internet Security and Acceleration Server and is an extension to the NAT driver built into Microsoft Windows Server. It provides connection tracking and filtering for the additional network connections needed for the FTP, ICMP, H.323, and PPTP protocols as well as the ability to configure a transparent HTTP proxy server.

Dynamic network address translation

[edit]
How dynamic NAT works

Dynamic NAT, just like static NAT, is not common in smaller networks but is found within larger corporations with complex networks. Where static NAT provides a one-to-one internal to public static IP address mapping, dynamic NAT uses a group of public IP addresses.[24][25]

NAT hairpinning

[edit]

NAT hairpinning, also known as NAT loopback or NAT reflection,[26] is a feature in many consumer routers[27] where a machine on the LAN is able to access another machine on the LAN via the external IP address of the LAN/router (with port forwarding set up on the router to direct requests to the appropriate machine on the LAN). This notion is officially described in 2008, RFC 5128.

The following describes an example network:

  • Public address: 203.0.113.1. This is the address of the WAN interface on the router.
  • Internal address of router: 192.168.1.1
  • Address of the server: 192.168.1.2
  • Address of a local computer: 192.168.1.100

If a packet is sent to 203.0.113.1 by a computer at 192.168.1.100, the packet would normally be routed to the default gateway (the router)[d]. A router with the NAT loopback feature detects that 203.0.113.1 is the address of its WAN interface, and treats the packet as if coming from that interface. It determines the destination for that packet, based on DNAT (port forwarding) rules for the destination. If the data were sent to port 80 and a DNAT rule exists for port 80 directed to 192.168.1.2, then the host at that address receives the packet.

If no applicable DNAT rule is available, the router drops the packet. An ICMP Destination Unreachable reply may be sent. If any DNAT rules were present, address translation is still in effect; the router still rewrites the source IP address in the packet. The local computer (192.168.1.100) sends the packet as coming from 192.168.1.100, but the server (192.168.1.2) receives it as coming from 203.0.113.1. When the server replies, the process is identical to an external sender. Thus, two-way communication is possible between hosts inside the LAN network via the public IP address.

NAT in IPv6

[edit]

Network address translation is not commonly used in IPv6 because one of the design goals of IPv6 is to restore end-to-end network connectivity.[28] The large addressing space of IPv6 obviates the need to conserve addresses and every device can be given a unique globally routable address. Use of unique local addresses in combination with network prefix translation can achieve results similar to NAT.

The large addressing space of IPv6 can still be defeated depending on the actual prefix length given by the carrier. It is not uncommon to be handed a /64 prefix – the smallest recommended subnet – for an entire home network, requiring a variety of techniques to be used to manually subdivide the range for all devices to remain reachable.[29] Even actual IPv6-to-IPv6 NAT, NAT66, can turn out useful at times: the APNIC blog outlines a case where the author was only provided a single address (/128).[30]

Applications affected by NAT

[edit]

Some application layer protocols, such as File Transfer Protocol (FTP) and Session Initiation Protocol (SIP), send explicit network addresses within their application data. File Transfer Protocol in active mode, for example, uses separate connections for control traffic (commands) and for data traffic (file contents). When requesting a file transfer, the host making the request identifies the corresponding data connection by its network layer and transport layer addresses. If the host making the request lies behind a simple NAT firewall, the translation of the IP address or TCP port number makes the information received by the server invalid. SIP commonly controls voice over IP calls, and suffer the same problem. SIP and its accompanying Session Description Protocol may use multiple ports to set up a connection and transmit voice stream via Real-time Transport Protocol. IP addresses and port numbers are encoded in the payload data and must be known before the traversal of NATs. Without special techniques, such as STUN, NAT behavior is unpredictable and communications may fail. Application Layer Gateway (ALG) software or hardware may correct these problems. An ALG software module running on a NAT firewall device updates any payload data made invalid by address translation. ALGs need to understand the higher-layer protocol that they need to fix, and so each protocol with this problem requires a separate ALG. For example, on many Linux systems, there are kernel modules called connection trackers that serve to implement ALGs. However, ALG cannot work if the protocol data is encrypted.

Another possible solution to this problem is to use NAT traversal techniques using protocols such as STUN or Interactive Connectivity Establishment (ICE), or proprietary approaches in a session border controller. NAT traversal is possible in both TCP- and UDP-based applications, but the UDP-based technique is simpler, more widely understood, and more compatible with legacy NATs.[citation needed] In either case, the high-level protocol must be designed with NAT traversal in mind, and it does not work reliably across symmetric NATs or other poorly behaved legacy NATs.

Other possibilities are Port Control Protocol (PCP),[31] NAT Port Mapping Protocol (NAT-PMP), or Internet Gateway Device Protocol but these require the NAT device to implement that protocol.

Most client–server protocols (FTP being the main exception[e]), however, do not send layer 3 contact information and do not require any special treatment by NATs. In fact, avoiding NAT complications is practically a requirement when designing new higher-layer protocols today.

NATs can also cause problems where IPsec encryption is applied and in cases where multiple devices such as SIP phones are located behind a NAT. Phones that encrypt their signaling with IPsec encapsulate the port information within an encrypted packet, meaning that NAT devices cannot access and translate the port. In these cases, the NAT devices revert to simple NAT operations. This means that all traffic returning to the NAT is mapped onto one client, causing service to more than one client behind the NAT to fail. There are a couple of solutions to this problem: one is to use TLS, which operates at layer 4 and does not mask the port number; another is to encapsulate the IPsec within UDP – the latter being the solution chosen by TISPAN to achieve secure NAT traversal, or a NAT with "IPsec Passthru" support; another is to use a session border controller to help traverse the NAT.

Interactive Connectivity Establishment (ICE) is a NAT traversal technique that does not rely on ALG support.

The DNS protocol vulnerability announced by Dan Kaminsky on July 8, 2008,[32] is indirectly affected by NAT port mapping. To avoid DNS cache poisoning, it is highly desirable not to translate UDP source port numbers of outgoing DNS requests from a DNS server behind a firewall that implements NAT. The recommended workaround for the DNS vulnerability is to make all caching DNS servers use randomized UDP source ports. If the NAT function de-randomizes the UDP source ports, the DNS server becomes vulnerable.

Examples of NAT software

[edit]

See also

[edit]
Wikimedia Commons has media related to Network Address Translation.

Notes

[edit]

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Network address translation

View on Grokipedia
from Grokipedia
Network Address Translation (NAT) is a method used in computer networking to remap one IP address space into another by modifying network address information in the IP header of packets while they are in transit across a traffic routing device, thereby enabling multiple devices on a private network to share a single public IP address for internet access. Developed in the mid-1990s as a short-term solution to the rapid exhaustion of IPv4 addresses and scaling issues in IP routing, NAT originated from concepts of address reuse proposed by Van Jacobson and further elaborated in a 1993 paper by Paul Francis and Tony Eng, leading to its formal description in RFC 1631 published in May 1994 by the Internet Engineering Task Force (IETF). This standard introduced NAT as a border router function for stub domains, such as corporate networks, allowing transparent translation without modifications to end hosts or internal routers, and experimental implementations demonstrated its feasibility for protocols like Telnet and FTP. Subsequent updates, including RFC 3022 in 2001, extended the original specification by incorporating port translation (Network Address Port Translation or NAPT) to support even more efficient sharing of public addresses and corrected checksum algorithms, solidifying NAT as an informational standard for connecting private networks to the global internet. In modern internet infrastructure, NAT has evolved into a fundamental component of routers and firewalls, providing enhanced security by hiding internal IP addresses from external networks, conserving public IPv4 addresses amid ongoing shortages, and facilitating the transition to IPv6 through variants like NAT64. Key types include Basic NAT for one-to-one address mapping, Port Address Translation (PAT) for many-to-one sharing using ports, and Carrier-Grade NAT (CGN) for large-scale deployments by internet service providers, all of which operate at the network edge to enable seamless connectivity for devices in homes, offices, and data centers while supporting features like application-level gateways for protocol-specific handling. Despite its widespread adoption, NAT introduces challenges such as complications for peer-to-peer applications and end-to-end connectivity, though it remains essential for conserving address space until full IPv6 deployment.

Overview and Fundamentals

Definition and Purpose

Network Address Translation (NAT) is a networking technique that modifies the IP address information in the header of packets as they pass through a routing device, effectively remapping one IP address space into another to enable multiple devices on a private network to share a single public IP address. This process typically involves rewriting the source or destination IP addresses, allowing internal hosts to communicate with external networks without each requiring a unique public address. The primary purpose of NAT is to conserve IPv4 addresses amid their scarcity, a challenge that emerged in the mid-1990s due to the rapid growth of the internet, thereby extending the usability of the IPv4 protocol without an immediate need for widespread adoption of IPv6. It also facilitates seamless connectivity for private networks to the public internet, enabling organizations and home users to connect numerous devices efficiently using non-routable private addresses. Central to NAT's operation are the private IP address ranges defined in RFC 1918, which include 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16; these ranges are reserved for internal use and are not routable on the public internet, allowing NAT to bridge the gap between such private networks and the global public addressing space without assigning unique public IPs to every device. By translating these private addresses to a public one at the network boundary, NAT ensures that internal communications remain isolated while permitting outbound access, thus supporting scalable and secure internet usage.

Historical Development

Network Address Translation (NAT) originated as a response to the impending exhaustion of IPv4 addresses in the early 1990s. Concepts of address reuse were proposed by Van Jacobson and further elaborated in a 1993 paper by Paul Francis and Tony Eng published in Computer Communication Review. The concept was first formally specified in RFC 1631, published in May 1994 by Kjeld Egevang and Paul Francis, which introduced basic NAT as a short-term solution for conserving public IP addresses through one-to-one mapping, allowing private networks to reuse address space. This initial specification outlined the basic mechanism for remapping IP addresses at network borders, enabling stub domains to reuse address space without conflicting with the global Internet. In the late 1990s, NAT saw rapid integration into commercial routers and firewalls, driven by the explosive growth of the Internet during the dot-com boom, which amplified the demand for IP addresses. Vendors like Cisco began incorporating NAT functionality into their products, such as the PIX firewall series, facilitating its widespread adoption in enterprise and home networks to manage address scarcity efficiently. This period marked NAT's transition from a theoretical proposal to a core feature of internet infrastructure, with implementations becoming standard in broadband routers as consumer Internet access surged. Key developments continued with the publication of RFC 2663 in August 1999, which provided standardized terminology and considerations for NAT implementations, including discussions on compatibility with emerging protocols and IPv6 transition strategies. As IPv4 depletion persisted into the 2000s and beyond, NAT evolved further; for instance, RFC 6888 in April 2013 defined requirements for carrier-grade NAT (CGN), enabling large-scale deployments by Internet service providers to support millions of subscribers sharing limited public addresses. NAT's pervasive use, particularly its role in extending the lifespan of IPv4, has notably delayed the full transition to IPv6 by providing a practical workaround for address conservation amid the scarcity that prompted its initial development. This adoption during the 1990s Internet expansion not only alleviated immediate pressures but also shaped modern networking practices, with CGN adaptations addressing ongoing global IPv4 shortages.

Technical Operation

Basic Mechanism

Network Address Translation (NAT) operates by intercepting and modifying the IP headers of packets as they pass through a routing device, such as a router or firewall, to map addresses between private and public IP spaces. This process allows multiple devices on a private network to share a single public IP address, conserving the limited pool of available IPv4 addresses. The core mechanism involves rewriting the source or destination IP address (and often the port number) in the packet header, while maintaining a temporary mapping to ensure proper routing of return traffic. At its foundation, NAT relies on predefined rules that dictate how address translation should occur, typically configured on the NAT-enabled device. These rules specify which private IP addresses or ranges are to be translated to a public IP, often using a pool of public addresses if multiple are available. For protocols like TCP and UDP, which use port numbers for multiplexing, NAT also translates the port information to distinguish between connections from different internal devices sharing the same public IP. This port address translation (PAT) enables one-to-many mappings, where a single public IP can support thousands of simultaneous connections by assigning unique port numbers. The translation tables, also known as NAT bindings or state tables, are dynamic data structures maintained by the NAT device to track active translations. When an outbound packet from a private IP (e.g., 192.168.1.10) is processed, the device replaces the source IP with its public IP (e.g., 203.0.113.1) and may assign a new source port, storing the original private IP, port, public IP, and new port in the table. For inbound packets, the device consults this table to reverse the translation, rewriting the destination IP and port back to the original private values, ensuring the response reaches the correct internal device. These tables are typically timed out after inactivity to free resources, with timeouts varying by protocol (e.g., shorter for UDP than TCP). A simple example illustrates the flow: Consider a private host at 192.168.1.10:1234 sending a packet to a public server at 198.51.100.1:80. The NAT router intercepts the packet, changes the source to 203.0.113.1:4567 (using PAT), and forwards it. The server responds to 203.0.113.1:4567, and upon receipt, the router checks its translation table, rewrites the destination to 192.168.1.10:1234, and delivers it internally. This bidirectional mapping ensures seamless communication without the external network being aware of the private addresses. Private IP ranges, such as those defined in RFC 1918 (e.g., 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), are commonly used in this context to avoid conflicts with public addressing.

Address Translation Process

The address translation process in Network Address Translation (NAT) begins when a packet arrives at the NAT-enabled device, such as a router, from a private network. The device inspects the inbound packet's IP header to identify the source IP address and port, determining if a translation entry already exists in its translation table. If no entry exists, the NAT device creates a new translation binding by replacing the private source IP address with a public IP address and, for port address translation (PAT), assigning a unique public port number from its available pool. This modified packet is then forwarded to the destination on the public network, with the original details recorded for reverse translation. For return traffic, the NAT device receives the inbound packet, looks up the corresponding translation entry based on the public destination IP and port, and reverses the process by rewriting the destination IP and port to match the original private address before forwarding it to the internal host. This bidirectional mapping ensures seamless communication while conserving public IP addresses. NAT handles different protocols with specific mechanisms to maintain state and ensure proper translation. For TCP, the device tracks connection states using SYN and ACK flags to establish and terminate sessions, creating entries upon SYN packets and removing them after FIN or RST sequences, which allows for reliable stateful translation. In contrast, UDP translations are stateless and timeout-based, where the NAT device creates an entry upon the first outbound packet and removes it after a predefined idle period, such as 5 minutes for ongoing traffic in many implementations, to manage short-lived, connectionless traffic. For ICMP, NAT translates error messages by embedding and modifying the original IP header within the ICMP payload, ensuring that quoted addresses and ports are updated to reflect the translated mappings, as required for protocols like ping or traceroute to function across NAT boundaries. Edge cases in the translation process include port exhaustion, where the NAT device's pool of available ports is depleted due to high concurrent connections, leading to failed translations and dropped packets until ports are freed by timeouts or session closures. Additionally, handling fragmented packets requires the NAT device to translate only the first fragment containing the full IP header and ports, while subsequent fragments are forwarded without modification but associated with the initial translation entry, though this can introduce fragility if fragments arrive out of order or are lost.

Types and Variants

Source NAT

Source Network Address Translation (SNAT), also known as IP masquerading, is a technique where the source IP address and optionally the source port of outgoing IP packets are modified as they traverse a routing device, typically replacing private internal IP addresses with a public external IP address to enable communication with the internet. This process allows multiple devices on a private network to share a single public IP address by rewriting the packet headers during transit, ensuring that return traffic can be correctly routed back to the original internal hosts through maintained translation state. In operation, when a packet leaves the internal network, the NAT device records the original source details in a translation table and substitutes them with the external address, while incoming responses are demultiplexed using this table to restore the private source information. SNAT configurations vary between static and dynamic approaches to suit different network requirements. Static SNAT establishes a fixed one-to-one mapping between a specific private IP address and a public IP address, which is useful for scenarios requiring consistent external addressing for particular internal hosts, such as dedicated servers needing reliable inbound access. In contrast, dynamic SNAT assigns public IP addresses from a predefined pool to private addresses on a first-come, first-served basis, providing flexibility for temporary connections but potentially exhausting the pool if traffic volume is high. For more efficient sharing, SNAT often employs overload mode, commonly referred to as Port Address Translation (PAT), which extends the many-to-one mapping by also altering the source port numbers, allowing thousands of internal devices to utilize a single public IP through unique port combinations. A primary use case for SNAT is in home networking environments, where consumer routers implement it to allow all devices on a local area network (LAN), such as computers, smartphones, and smart home appliances, to access the internet via the single public IP address assigned by the internet service provider (ISP). This configuration conserves scarce IPv4 addresses and simplifies connectivity without requiring individual public IPs for each device, making it a standard feature in residential gateways.

Destination NAT

Destination Network Address Translation (DNAT) is a technique that modifies the destination IP address and optionally the port number in the header of incoming packets to redirect them to internal hosts or servers within a private network. This process occurs at the network edge device, such as a router or firewall, allowing external traffic destined for a public IP address to be forwarded to a private IP address behind the NAT boundary. DNAT is particularly useful for enabling access to services hosted on internal systems without exposing their private addresses directly to the internet. In terms of configuration, static DNAT establishes fixed, one-to-one mappings between a public destination IP/port and a specific private IP/port, which is ideal for consistent redirection to a single internal server. Dynamic DNAT, on the other hand, dynamically maps an incoming public destination IP to addresses from a pool of private IP addresses on a first-come, first-served basis or via session distribution, supporting scenarios like load balancing across several internal servers. These configurations are typically defined through rules in the NAT device's policy table, specifying the original destination, the translated destination, and any associated ports or protocols. A primary use case for DNAT is port forwarding, where it enables hosting public services such as web servers or email servers on devices with private IP addresses by redirecting inbound traffic from the public interface to the appropriate internal port. For instance, external requests to a public IP on port 80 can be translated to reach an internal web server on a private IP, ensuring seamless access while maintaining network segmentation. This approach is commonly applied in scenarios requiring external accessibility to internal resources without compromising the private addressing scheme.

NAT Tables and Management

Structure of NAT Tables

Network Address Translation (NAT) tables, also known as translation tables, are essential data structures maintained by NAT-enabled devices such as routers to track and manage the mappings between private (internal) and public (external) IP addresses and ports during packet traversal. These tables are typically stored in the volatile memory of the NAT device to enable fast lookups and updates, ensuring efficient real-time translation without persistent storage requirements. Entries in NAT tables generally consist of key fields that capture the original and translated network identifiers, along with metadata for session management. Common fields include the original source IP address and port (e.g., private_src_ip and private_src_port), the translated source IP address and port (e.g., global_src_ip and global_src_port), the protocol (such as TCP, UDP, or ICMP), a timeout value indicating the entry's expiry, and flags for additional attributes like session state or direction. For instance, in Network Address Port Translation (NAPT), which is a common variant, the table might store a tuple like {private_src_ip: 10.0.0.10, private_src_port: 3017, global_src_ip: 138.76.28.4, global_src_port: 1024, protocol: TCP, expiry_time: 86400 seconds}, where for outbound packets the private source is translated to the global source, and for inbound return traffic the global destination tuple is used to reverse-lookup the private source. NAT table entries are categorized into dynamic and static types to accommodate different translation needs. Dynamic entries are session-based and created automatically when a private host initiates an outbound connection, binding the private IP/port tuple to a temporary public equivalent until the session ends or times out, which supports efficient multiplexing for multiple internal devices sharing a single public IP. In contrast, static entries represent permanent mappings configured manually for consistent access, such as mapping a specific private IP to a fixed public IP, and they do not expire unless explicitly removed. The handling of bidirectional mappings in NAT tables ensures proper routing for return traffic, primarily through symmetric bindings that reverse the translation process for inbound packets using the same entry. For example, while dynamic entries focus on outbound-initiated sessions, static entries enable inbound access by pre-defining mappings, allowing external hosts to reach specific internal services via fixed public endpoints. This structure directly supports the address translation process by providing quick lookups to modify IP headers in transit packets.

Monitoring and Maintenance

Effective monitoring of Network Address Translation (NAT) tables is essential for maintaining network performance and reliability, involving tools that log entries, query table size, and generate alerts for high utilization or errors. In cloud environments like Amazon Web Services (AWS), CloudWatch provides metrics such as ActiveConnectionCount to monitor NAT gateway activity, allowing administrators to track table utilization in near real-time. Similarly, Google Cloud's Cloud NAT integrates with Cloud Monitoring to automatically send metrics like error rates, enabling custom dashboards and alerts for thresholds like excessive packet drops. For on-premises setups, Cisco routers support the "show ip nat statistics" command to query NAT table size and translation counts, helping identify potential overloads before they impact traffic. Logging entries, such as those capturing translation creations and timeouts, can be enabled on devices to record NAT events for later analysis, with best practices recommending selective logging to avoid performance overhead. Maintenance practices for NAT tables focus on clearing stale entries, scaling for high traffic volumes, and troubleshooting common issues like port exhaustion to prevent disruptions. Stale entries, which are inactive translations lingering due to incomplete sessions, are typically cleared automatically via configurable timeouts; for instance, Cisco IOS allows setting NAT translation timeouts to seconds or indefinite periods to manage table bloat efficiently. Scaling NAT for high traffic involves increasing available IP pools or ports, as recommended in Google Cloud NAT best practices, which advise monitoring port utilization to preempt exhaustion in bursty workloads. Troubleshooting port exhaustion, a frequent issue where available source ports are depleted, requires examining session logs and adjusting timeouts or pool sizes; Cisco documentation outlines steps like verifying firewall rules and monitoring ephemeral port usage to resolve such problems in Port Address Translation (PAT) scenarios. In Fortinet environments, diagnosing exhaustion involves checking IP pool usage via diagnostics commands and addressing causes like prolonged session timeouts. Best practices for NAT table management emphasize regular backups of static mappings and seamless integration with broader network management systems to ensure resilience and operational efficiency. Static NAT mappings, which are manually configured and persistent, should be backed up periodically as part of network configuration management, using automated tools to maintain versioned archives for quick recovery, as outlined in guidelines for device configuration backups. Integrating NAT monitoring with systems like AWS CloudWatch allows centralized alerting and correlation with other network metrics, facilitating proactive maintenance without isolated silos.

Applications and Uses

In Home Networking

In home networking, Network Address Translation (NAT) is primarily implemented within consumer-grade routers to enable multiple devices to share a single public IP address provided by the Internet Service Provider (ISP). This setup allows residential users to connect various gadgets, such as smartphones, laptops, smart TVs, and IoT devices, to the internet via a local Wi-Fi network without requiring individual public IP addresses for each. Consumer routers typically perform Source NAT (SNAT) by dynamically translating private IP addresses from the home network to the single public IP during outbound traffic, a process that aligns with basic SNAT mechanics where internal addresses are mapped to an external one. The benefits of NAT in home environments include efficient use of the limited IPv4 address space, cost savings for ISPs who can assign fewer public IPs, and simplified connectivity for users, as it supports seamless Wi-Fi access for numerous devices without additional configuration. However, challenges arise, particularly with inbound connections; for instance, NAT can block unsolicited incoming traffic, which is beneficial for security but problematic for applications like online gaming or media sharing that require port forwarding. To address this, many home routers incorporate Universal Plug and Play (UPnP), a protocol that allows devices to automatically request and configure port mappings through the NAT device, facilitating easier setup for peer-to-peer communications in gaming or file sharing, though it introduces potential security risks if not properly managed. Common setups in small office/home office (SOHO) routers often integrate NAT with Dynamic Host Configuration Protocol (DHCP) to automatically assign private IP addresses (typically from the 192.168.0.0/16 range) to devices on the local network, ensuring dynamic SNAT mappings are maintained in the router's NAT table for ongoing sessions. This combination is standard in devices from manufacturers like Linksys or Netgear, promoting plug-and-play functionality for home users while handling the translation transparently. RFC 2663 describes considerations for NAT in simple home gateways.

In Enterprise Environments

In enterprise environments, Network Address Translation (NAT) is widely implemented in firewalls and load balancers to segment internal networks from external ones, allowing organizations to conserve public IP addresses while maintaining controlled access to resources. Firewalls often integrate NAT to translate private IP addresses used within corporate intranets to a shared public IP for outbound traffic, enhancing network isolation and security by hiding internal topology from external threats. Similarly, load balancers employ NAT to distribute incoming traffic across multiple backend servers, using techniques like static Destination NAT (DNAT) to map specific public IPs or ports to internal server addresses, thereby facilitating reliable access to enterprise services such as web applications or databases without exposing individual server details. Advanced NAT features in enterprise settings include seamless integration with Virtual Private Networks (VPNs) to support secure remote access, where NAT rules are configured to exempt VPN traffic from translation, ensuring end-to-end connectivity for distributed workforces. Hierarchical NAT architectures are commonly deployed for multi-site connectivity, enabling large organizations with branch offices to use overlapping private address spaces by applying layered translation at core routers or gateways, which simplifies IP management across global networks. Additionally, NAT implementations must align with organizational security policies, such as those outlined in firewall guidelines, to enforce access controls and logging for compliance with standards like NIST recommendations, thereby mitigating risks in regulated industries. Despite these benefits, enterprises face significant challenges in managing large-scale NAT deployments, including the administration of extensive address pools to handle high volumes of concurrent sessions without performance degradation. Ensuring failover in high-availability setups requires redundant NAT configurations across clustered devices, such as dual firewalls, to prevent single points of failure and maintain continuous operation during hardware or link disruptions. These challenges are amplified in complex architectures, where improper NAT state management can lead to session disruptions or scalability issues, necessitating robust monitoring tools and policy automation.

Security and Limitations

Benefits for Security

Network Address Translation (NAT) provides significant security benefits by obscuring the internal network structure from external entities, thereby complicating reconnaissance efforts by potential attackers. By remapping private IP addresses to a single public IP address, NAT effectively hides the topology and individual devices within a local network from external scanners and probes, making it difficult for malicious actors to identify and target specific internal hosts. This address hiding mechanism acts as a form of obfuscation, reducing the attack surface exposed to the internet and preventing direct access to internal systems without explicit configuration changes. A key security advantage of NAT is its default blocking of unsolicited inbound connections, which inherently protects internal devices from unauthorized access attempts originating from the external network. In typical NAT implementations, such as those used in home routers or enterprise firewalls, incoming traffic is only permitted if it corresponds to an established outbound connection, thereby thwarting common threats like port scanning and unauthorized remote access. This behavior aligns with the principle of least privilege, ensuring that internal resources remain isolated unless explicitly allowed through port forwarding or similar rules. The stateful tracking employed by most NAT devices further enhances security by maintaining connection state tables that monitor the direction and legitimacy of traffic flows, allowing only response packets to return to the originating internal host while discarding unsolicited inbound packets. This dynamic tracking mechanism reduces exposure to attacks such as denial-of-service (DoS) attempts or exploitation of open ports, as it enforces a symmetric communication model where internal initiations are required for external responses. For instance, in carrier-grade NAT (CGNAT) deployments, this stateful approach scales to protect large numbers of users while minimizing the risk of inbound threats. While NAT offers these protective benefits, it is important to note that it does not provide encryption or authentication for traffic, meaning additional security measures like firewalls or VPNs are often necessary for comprehensive protection.

Detecting Malicious Activity

Detecting malicious activity in Network Address Translation (NAT) environments involves systematic verification of traffic patterns and mappings to identify potential threats, such as unauthorized access attempts or compromised internal devices. One key verification method is to check that all outbound-initiated connections originate from legitimate internal IP addresses or providers, ensuring no anomalous sources are masquerading as trusted endpoints. Additionally, security administrators can monitor for unusual patterns, including high-volume connections to unknown ports or IP addresses from non-standard sources, which may indicate scanning activities or data exfiltration efforts. These checks can be integrated with broader table monitoring practices to maintain ongoing vigilance. Indicators of compromise in NAT setups often manifest as discrepancies in traffic mappings, such as unexpected inbound initiations that do not correspond to prior outbound connections, suggesting possible exploitation of NAT traversal vulnerabilities or unauthorized port forwarding. Furthermore, mappings directing traffic to generalized suspicious destinations, such as known botnet IP ranges, without corresponding legitimate activity, serve as red flags for command-and-control communications or other malicious operations. Upon identifying potential threats, response strategies include isolating affected NAT mappings to prevent further communication, such as by dynamically blocking specific translations or quarantining associated internal hosts. Comprehensive logging of suspicious entries should be maintained for forensic analysis, capturing details like timestamps, involved ports, and generalized IP summaries to avoid exposing sensitive information while enabling thorough investigation.

Alternatives and Future Directions

Network Address Translation (NAT) interacts with several complementary technologies that either enhance its functionality or address its limitations in modern networking environments. One key complementary technology is IPv6, which provides a vastly larger address space—128 bits compared to IPv4's 32 bits—potentially reducing the reliance on NAT by allowing direct end-to-end connectivity without address sharing. However, during the transition from IPv4 to IPv6, hybrid solutions like NAT64 enable IPv6 hosts to communicate with IPv4 networks by translating between the two address formats, maintaining NAT's role in interoperability. Additionally, tunneling protocols such as Virtual Private Networks (VPNs) operate atop NAT, encapsulating traffic to create secure connections across NAT-traversed networks, often using protocols like IPsec that require NAT traversal extensions for proper operation. Alternatives to NAT include proxy servers, which can achieve similar address hiding and traffic management by acting as intermediaries that rewrite or forward requests on behalf of clients, though they typically operate at higher layers (e.g., application layer) and may introduce additional latency compared to NAT's network-layer approach. Full adoption of IPv6 serves as another alternative, eliminating the need for NAT by providing abundant public addresses for all devices, thereby restoring true end-to-end connectivity that was compromised by IPv4 address exhaustion. NAT's implementation can complicate peer-to-peer (P2P) applications, such as file sharing or VoIP, by obscuring internal IP addresses and ports, which hinders direct connections between devices behind different NATs. To mitigate this, techniques like Session Traversal Utilities for NAT (STUN) are employed, allowing clients to discover their public IP and port mappings through a STUN server, facilitating P2P traversal without requiring changes to the NAT device itself.

Evolving Standards

Network Address Translation (NAT) standards have continued to evolve to address the complexities of IPv4 exhaustion and the gradual shift toward IPv6, with RFC 4787 serving as a pivotal document published in 2007 that specifies behavioral requirements for NAT devices to ensure consistent handling of Unicast UDP traffic, which supports better interoperability in various environments including those involving IPv6 mechanisms like NAT64. This RFC outlines essential behaviors such as endpoint-independent mapping and filtering, which help mitigate issues in transitional environments where NAT must interoperate with emerging IPv6 mechanisms like NAT64. Compliance with these standards has been emphasized in implementations for carrier-grade NAT (CGN), enabling service providers to maintain transparency for end-user applications while scaling to support large subscriber bases. Advancements in Carrier Grade NAT (CGN) represent a key current evolution, allowing Internet Service Providers (ISPs) to efficiently manage massive user bases by sharing a limited pool of public IPv4 addresses among thousands of subscribers through large-scale address translation. Recent integrations, such as combining CGN with Broadband Network Gateway (BNG) services on disaggregated open switches, are enhancing operational efficiency and scalability for broadband networks, addressing the ongoing demand for IPv4 conservation amid slow IPv6 rollout. These developments build on standardized NAT behaviors to handle high-density environments without compromising performance. Looking toward future directions, NAT is increasingly integrated with Software-Defined Networking (SDN) to enable dynamic policy enforcement, where centralized controllers can programmatically adjust NAT mappings in real-time based on traffic patterns or security needs. As IPv6 adoption grows, reliance on NAT is expected to diminish, potentially eliminating the need for address translation in end-to-end communications and simplifying network architectures. Nonetheless, NAT retains potential applications in Internet of Things (IoT) networks, where secure traversal mechanisms can facilitate connectivity for resource-constrained devices behind NAT boundaries in heterogeneous environments. Challenges in this evolution include the ongoing standardization of protocols like NAT Port Mapping Protocol (NAT-PMP) and Port Control Protocol (PCP), which aim to improve port management for future devices by allowing hosts to explicitly request and manage port mappings through NAT gateways. NAT-PMP, detailed in RFC 6886, automates port mapping creation to support applications requiring inbound connections, while PCP, as specified in RFC 6887, extends this functionality for both IPv4 and IPv6, addressing limitations in carrier-grade deployments. These efforts face hurdles in achieving widespread adoption due to interoperability issues and the need for consistent implementation across diverse network equipment, particularly in scenarios involving multiple NAT layers.

References

  1. https://www.rfc-editor.org/rfc/rfc1631.html
  2. https://datatracker.ietf.org/doc/html/rfc3022
  3. https://www.cisco.com/site/us/en/learn/topics/networking/what-is-network-address-translation-nat.html
  4. https://www.fortinet.com/resources/cyberglossary/network-address-translation
  5. https://www.ietf.org/rfc/rfc3235.txt
  6. https://www.techtarget.com/searchnetworking/definition/Network-Address-Translation-NAT
  7. https://www.cisco.com/en/US/technologies/tk648/tk361/tk438/technologies_white_paper09186a0080091cb9.pdf
  8. https://www.noction.com/blog/network-address-translation-nat
  9. https://www.vmware.com/topics/network-address-translation
  10. https://datatracker.ietf.org/doc/html/rfc1918
  11. https://datatracker.ietf.org/doc/rfc1631/
  12. https://www.rfc-editor.org/info/rfc1631
  13. https://blog.apnic.net/2023/04/21/the-internet-twenty-five-years-later/
  14. https://www.theregister.com/2025/12/31/ipv6_at_30/
  15. https://www.rg-cs.co.uk/how-the-thirty-year-old-ipv6-still-underpins-the-internets-growth/
  16. https://datatracker.ietf.org/doc/html/rfc2663
  17. https://datatracker.ietf.org/doc/rfc6888/
  18. https://blog.apnic.net/2024/10/22/the-ipv6-transition/
  19. https://www.geeksforgeeks.org/computer-networks/network-address-translation-nat/
  20. https://www.timusnetworks.com/understanding-network-address-translation-a-comprehensive-guide/
  21. https://www.learncisco.net/courses/icnd-1/acls-and-nat/address-translation.html
  22. https://www.cisco.com/c/en/us/support/docs/ip/network-address-translation-nat/26704-nat-faq-00.html
  23. https://www.antaira.com/Whitepaper-Introduction-to-Network-Address-Translation
  24. https://www.ibm.com/docs/ssw_ibm_i_74/rzajb/rzajbrzajb4dportnat.htm
  25. https://www.rfc-editor.org/rfc/rfc5508.html
  26. https://www.zenarmor.com/docs/network-basics/what-is-port-address-translation-pat
  27. https://learn.microsoft.com/en-us/azure/load-balancer/load-balancer-outbound-connections
  28. https://datatracker.ietf.org/doc/html/rfc8900
  29. https://www.cisco.com/c/en/us/support/docs/ip/network-address-translation-nat/13772-12.html
  30. https://networklessons.com/ip-services/introduction-to-nat-and-pat
  31. https://www.certificationkits.com/cisco-certification/ccna-articles/cisco-ccna-network-address-translation-nat/static-nat-dynamic-nat-nat-overload-pat-a-configurations/
  32. https://www.networkacademy.io/ccna/network-services/nat-overload-pat
  33. https://jumpcloud.com/it-index/what-is-destination-nat-dnat
  34. https://docs.paloaltonetworks.com/pan-os/11-0/pan-os-networking-admin/nat/source-nat-and-destination-nat/destination-nat
  35. https://docs.fortinet.com/document/fortigate/7.6.5/administration-guide/728694/destination-nat
  36. https://www.cisco.com/c/en/us/td/docs/security/firepower/710/fdm/fptd-fdm-config-guide-710/fptd-fdm-nat.html
  37. https://documentation.meraki.com/SASE_and_SD-WAN/MX/Design_and_Configure/Configuration_Guides/NAT_and_Port_Forwarding/Port_Forwarding_and_NAT_Rules_on_the_MX
  38. https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway-cloudwatch.html
  39. https://cloud.google.com/blog/products/networking/6-best-practices-for-running-cloud-nat
  40. https://www.cisco.com/c/en/us/support/docs/ip/network-address-translation-nat/221481-8605-13.html
  41. https://community.cisco.com/t5/networking-knowledge-base/how-to-configure-a-nat-translation-timeout/ta-p/3109488
  42. https://www.cisco.com/c/en/us/support/docs/security/umbrella/224671-troubleshoot-port-exhaustion-when-using.pdf
  43. https://community.fortinet.com/t5/Support-Forum/NAT-port-is-exhausted/td-p/311292
  44. https://www.manageengine.com/network-configuration-manager/best-practices-for-backing-up-network-configurations.html
  45. https://www.tp-link.com/us/support/faq/4624/
  46. https://docs.netgate.com/tnsr/en/latest/recipes/basic-soho-router/index.html
  47. https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-41r1.pdf
  48. https://www.cisco.com/c/en/us/td/docs/routers/ios/config/17-x/sec-vpn/b-security-vpn/m_sec-zone-pol-fw-xe.html
  49. https://people.eecs.berkeley.edu/~randy/Courses/CS294K.S05/triad.pdf
  50. https://www.cisco.com/c/en/us/td/docs/security/asa/asa924/asdm724/vpn/asdm-724-vpn-config.pdf
  51. https://www.ietf.org/rfc/rfc2993.txt
  52. https://uknowledge.uky.edu/cgi/viewcontent.cgi?article=1091&context=cs_etds
  53. https://www.cyber.gc.ca/en/guidance/network-security-logging-monitoring-itsap80085
  54. https://www.expressvpn.com/blog/nat-firewall/
  55. https://twit.tv/posts/tech/your-home-network-part-botnet-how-instantly-check-your-ip-bot-activity
  56. https://www.rfc-editor.org/rfc/rfc4787
  57. https://datatracker.ietf.org/doc/html/rfc6146
  58. https://www.cisco.com/c/dam/en/us/td/docs/Technology/IPv6/cgn_ext_wp.pdf
  59. https://nfware.com/glossary/cgnat
  60. https://www.rtbrick.com/news-and-events/what-isps-can-expect-from-the-integration-of-cgnat-and-bng-services-on-a-single-open-switch
  61. https://blog.cloudflare.com/detecting-cgn-to-reduce-collateral-damage/
  62. https://www.celona.io/network-architecture/software-defined-networking
  63. https://pinggy.io/blog/how_ipv6_solves_the_nat_problem/
  64. https://dl.acm.org/doi/10.1145/3230640
  65. https://datatracker.ietf.org/doc/html/rfc6886
  66. https://www.rfc-editor.org/rfc/rfc6887.html
Add your contribution
Related Hubs
Contribute something
User Avatar
No comments yet.