Editing Network address translation (section)

=={{anchor|PORT-TRANSLATION}}Methods of translation==<!-- Other articles link here. -->
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''.

{| class="wikitable"
|+ NAT types
|-
| {{anchor|Full-cone NAT}}<!-- Other articles link here. -->'''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.
| [[Image:Full Cone NAT.svg|right|400px]]
|-
| {{anchor|Restricted-cone NAT}}<!-- Other articles link here. -->'''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.
| [[Image:Restricted Cone NAT.svg|right|400px]]
|-
| {{anchor|Port-restricted cone NAT}}<!-- Other articles link here. -->'''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.
| [[Image:Port Restricted Cone NAT.svg|right|400px]]
|-
| {{anchor|Symmetric NAT}}'''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.
| [[Image:Symmetric NAT.svg|right|400px]]
|}

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.<ref name="rfc4787" /> 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===

RFC 4787 distinguishes between NAT mapping and NAT filtering.<ref name="rfc4787" />

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. [https://docs.netgate.com/tnsr/en/latest/nat/modes.html Netgate TNSR]).