Editing Network address translation (section)

==Issues and limitations==
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 [[Transmission Control Protocol|TCP]] connections from the outside network, or that use stateless protocols such as those using [[User Datagram Protocol|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 {{slink||Applications affected by NAT}}), but fail when both systems are separated from the internet by NAT. The use of NAT also complicates [[tunneling protocol]]s 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.<ref name=rfc3439>{{cite IETF|rfc=3439|title=Some Internet Architectural Guidelines and Philosophy|last1=Bush|first1=R.|last2=Meyer|first2=D.|publisher=[[IETF]]|date=2002}}</ref> 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.<ref name=rfc4864>{{Cite IETF|last=Velde|first=G. Van de|last2=Hain|first2=T.|last3=Droms|first3=R.|last4=Carpenter|first4=B.|last5=Klein|first5=E.|date=2007|title=Local Network Protection for IPv6|rfc=4864|publisher=[[IETF]]}}</ref>

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 ===
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 [[Transmission Control Protocol|TCP]] and [[User Datagram Protocol|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.