NAT traversal

From Infogalactic: the planetary knowledge core
Jump to: navigation, search

NAT traversal (or network address translation traversal) is a computer networking methodology with the goal of establishing and maintaining Internet protocol connections across gateways that implement network address translation (NAT). NAT breaks the principle of end-to-end connectivity originally envisioned in the design of the Internet.

NAT traversal techniques are required for certain client-to-client network applications, such as peer-to-peer file sharing and Voice over IP.[1]

Explanation

Many techniques exist, but no single method works in every situation since NAT behavior is not standardized. Many NAT traversal techniques require assistance from a server at a publicly routable IP address. Some methods use the server only when establishing the connection, while others are based on relaying all data through it, which adds bandwidth costs and increases latency, detrimental to real-time voice and video communications.

Most NAT behavior-based techniques bypass enterprise security policies. Enterprise security experts prefer techniques that explicitly cooperate with NAT and firewalls, allowing NAT traversal while still enabling marshalling at the NAT to enforce enterprise security policies. IETF standards based on this security model are Realm-Specific IP (RSIP) and middlebox communications (MIDCOM).

NAT devices are commonly used to alleviate IPv4 address exhaustion by allowing the use of private IP addresses on home and corporate networks behind routers with a single public IP address facing the public Internet. The internal network devices communicate with hosts on the external network by changing the source address of outgoing requests to that of the NAT device and relaying replies back to the originating device.

This leaves the internal network ill-suited for hosting servers, as the NAT device has no automatic method of determining the internal host for which incoming packets are destined. This is not a problem for home users behind NAT devices doing general web access and e-mail. However, applications such as peer-to-peer file sharing, VoIP services and the online services of current generation video game consoles require clients to be servers as well, thereby posing a problem for users behind NAT devices, as incoming requests cannot be easily correlated to the proper internal host. Furthermore, many of these types of services carry IP address and port number information in the application data, potentially requiring substitution or special traversal techniques for NAT traversal.

Techniques

The following NAT traversal techniques are available:

  • Socket Secure (SOCKS) is a technology created in the early 1990s that uses proxy servers to relay traffic between networks or systems.
  • Traversal Using Relays around NAT (TURN) is a relay protocol designed specifically for NAT traversal.
  • NAT hole punching is a general technique that exploits how NATs handle some protocols (for example, UDP, TCP, or ICMP) to allow previously blocked packets through the NAT.
  • Session Traversal Utilities for NAT (STUN) is a standardized set of methods and a network protocol for NAT hole punching. It was designed for UDP but was also extended to TCP.
  • Interactive Connectivity Establishment (ICE) is a complete protocol for using STUN and/or TURN to do NAT traversal while picking the best network route available. It fills in some of the missing pieces and deficiencies that were not mentioned by STUN specification.
  • UPnP Internet Gateway Device Protocol (IGDP) is supported by many small NAT gateways in home or small office settings. It allows a device on a network to ask the router to open a port.
  • NAT-PMP is a protocol introduced by Apple as an alternative to IGDP.
  • PCP is a successor or NAT-PMP.
  • Application-level gateway (ALG) is a component of a firewall or NAT that allows for configuring NAT traversal filters.[2] It is claimed by numerous people that this technique creates more problems than it solves.[3]

Symmetric NAT

The recent proliferation of symmetric NATs has reduced NAT traversal success rates in many practical situations like mobile and public WiFi internet connections. Hole punching techniques like STUN and ICE are unable to traverse symmetric NATs without the help of a relay server (e.g. TURN). Techniques that traverse symmetric NATs by attempting to predict the next port that will be opened by each NAT device were discovered in 2003 by Yutaka Takeda at Panasonic Communications Research Laboratory[4] and in 2008 by researchers at Waseda University.[5] Port prediction techniques are only effective with NAT devices which use known deterministic algorithms for port selection. This predictable yet non-static port allocation scheme is uncommon in large scale NATs such as those used in 4G LTE networks and thus the Waseda University technique is largely ineffective on those mobile broadband networks.

IPsec

IPsec virtual private network clients use NAT traversal in order to have Encapsulating Security Payload packets traverse NAT. IPsec uses several protocols in its operation which must be enabled to traverse firewalls and network address translators:

Many routers provide explicit features, often called IPsec Passthrough.

In Windows XP, NAT traversal is enabled by default, but in Windows XP with Service Pack 2 it has been disabled by default for the case when the VPN server is also behind a NAT device, because of a rare and controversial security issue.[6] IPsec NAT-T patches are also available for Windows 2000, Windows NT and Windows 98.

NAT traversal and IPsec may be used to enable opportunistic encryption of traffic between systems. NAT traversal allows systems behind NATs to request and establish secure connections on demand.

Hosted NAT traversal

Hosted NAT traversal (HNT) is set of mechanisms including media relaying and latching used by intermediaries.[citation needed] The IETF advises against using latching over the Internet and recommends ICE for security reasons.[7]

IETF standards documents

  • RFC 1579 – Firewall Friendly FTP
  • RFC 2663 – IP Network Address Translator (NAT) Terminology and Considerations
  • RFC 2709 – Security Model with Tunnel-mode IPsec for NAT Domains
  • RFC 2993 – Architectural Implications of NAT
  • RFC 3022 – Traditional IP Network Address Translator (Traditional NAT)
  • RFC 3027 – Protocol Complications with the IP Network Address Translator (NAT)
  • RFC 3235 – Network Address Translator (NAT)-Friendly Application Design Guidelines
  • RFC 3715 – IPsec-Network Address Translation (NAT) Compatibility
  • RFC 3947 – Negotiation of NAT-Traversal in the IKE
  • RFC 5128 – State of Peer-to-Peer (P2P) Communication across Network Address Translators (NATs)
  • RFC 5245 – Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols

See also

<templatestyles src="Div col/styles.css"/>

References

  1. Lua error in package.lua at line 80: module 'strict' not found.
  2. Lua error in package.lua at line 80: module 'strict' not found.
  3. Lua error in package.lua at line 80: module 'strict' not found.
  4. Lua error in package.lua at line 80: module 'strict' not found.
  5. Lua error in package.lua at line 80: module 'strict' not found.
  6. Lua error in package.lua at line 80: module 'strict' not found.
  7. Latching: Hosted NAT Traversal (HNT) for Media in Real-Time Communication draft-ietf-mmusic-latching-04 2013-10-08

External links