NAT Classification Results using STUN

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119. In this document, the term NAT means port address translation. This is an unfortunate use of the terminology but is what NAT has come to mean.

A major issue in working with NAT traversal solutions for various protocols is that NATs behave in many different ways. RFC 3489 (STUN) classifies these and provides a method to test them. This draft describes the results of testing several residential style NATs. Several NATs attempt to use the same external port number as the internal host used. This is referred to as port preservation. On the NATs that did this, some were found to have different characteristics depending on whether the port was already in use or not. This was tested by running the STUN tests from a particular port on one internal IP address and then running them again from the same port on a different internal IP address. The results from the first interface, where the port was preserved are referred to as the primary type while the results from the second interface, which did not manage to get the same external port because it was already in use, is referred to as the secondary type. On most NATs the secondary type is the same as the primary but on some it is different; these are referred to as nondeterministic NATs, since a client with a single internal IP address can not figure out what the type of the NAT is. There are several NATs that would be detected as address restricted by the STUN tests but are not. These NATs always use the same external port as the internal port and store the IP address of the most recent internal host to send a packet on that port. The NATs then forward any traffic arriving to the external interface of the NAT on this port to the most recent internal host to use it. These NATs are labeled of type "Bad" in the result table since they do not meet the definitions of NAPT in RFC 3022. Interestingly, as long as the clients behind the NAT choose random port numbers, they often do work. STUN detects these NATs as address restricted although they are really not address restricted NATs. This type of NAT is easily detected by sending a STUN packet from the same port on two different internal IP addresses and looking at the mapped port in the return. If both packets were mapped to the same external port, the NAT is of the Bad type. Another important aspect of a NAT for some applications is whether it can send media from one internal host back to another host behind the same NAT. This is referred to as supporting hairpin media. Some NATs were rumored to exist that looked in arbitrary packets for either the NATs' external IP address or for the internal host IP address - either in binary or dotted decimal form - and rewrote it to something else. STUN could be extended to test for exactly this type of behavior by echoing arbitrary client data and the mapped address but sending the bits inverted so these evil NATs did not mess with them. NATs that do this will break integrity detection on payloads. To help organize the NATs by what types of applications they can support, the following groups are defined. The application of using a SIP phone with a TLS connection for signaling and using STUN for media ports is considered. It is assumed the RTP/RTCP media is on random port pairs as recommended for RTP. Group A: NATs that are deterministic, not symmetric, and support hairpin media. These NATs would work with many phones behind them. Group B: NATs that are not symmetric on the primary mapping. This group would work with many IP phones as long as the media ports did not conflict. This is unlikely to happen often but will occasionally happen. Because they may not support hairpin media, a call from one phone behind a NAT to another phone behind the same NAT may not work. Group D: NATs of the type Bad. These have the same limitations of group B but when the ports conflict, media gets delivered to a random phone behind the NAT. Group F: These NATs are symmetric and phones will not work.

The following table shows the results from several NATs. This includes some random NATs the author had lying around as well as every NAT that could be purchased in February 2004 in the San Jose Fry's, Best Buy, CompUSA, and Circuit City. Clearly this is not a very good approximation to a random sample. It is clear that the NATs widely purchased in the US are different from what are available in Japan or in Europe. In the following table the Prim column indicates the primary type of the NAT. A value of Port indicates port restricted, Cone is a full cone, Bad is described in the next section, Symm is Symmetric, and Addr is Address restricted. The Hair column value of Y or N indicates whether the NAT will hairpin media. The Pres column indicates whether the NAT attempts to preserve port numbers. The Sec column indicates the secondary type of the NAT, and a value of Same indicates it is the same as the primary type. The Grp indicates the group that this NAT falls into.

It is clear from discussions with various vendors and watching how tests have changed over the years that symmetric is becoming less common. This change is being driven primarily by the desire to make online gaming work; many games use methods similar to STUN for NAT traversal. The only symmetric NAT found was an old device. More recent version of the software on the same device were not symmetric. It is clear that other symmetric NATs are deployed, but it is hard to find them.

It is often assumed that symmetric NATs are more secure than port restricted NATs. This is not true - they are identical from a security point of view. They both only allow a packet to come inside the NAT if the host inside has previously sent to the exact same external IP and port. One can argue that cone is less secure than port restricted, but this is not true if the attacker can spoof the IP address, which is fairly easy to do in many cases. What level of security can be expected from NATs at all is a strange and curious topic. With all the NATs, if you allow packets out, packets can come in, so don't be surprised if NATs provide less security that anticipated.

The hairpin media tests were done by having a single host use STUN to find a public address on the NAT and then send media to itself and see if it was received. It is possible that NATs might not hairpin media to the same host but would hairpin media to another host behind the same NAT. It is possible that because of this, the hairpin results reported here are wrong. This sample set of NATs is very US-centric: D-Link, Lynksys, and Netgear dominate the US consumer market. It would be good to get more results from other places. These test results should be verified by another group. This has not been done yet.

Many people and several mailing lists have contributed to the material on understanding NATs in this document. Many thanks to Larry Metzger, Dan Wing, and Rohan Mahy. The STUN server and client is open source and available at http://sourceforge.net/projects/stun and thank you to Jason Fischl who runs the public STUN server at larry.gloo.net. Thanks to Yutaka Takeda who tested and found bugs and Christian Stredicke for getting people thinking.