STUN - Revision history

Horemu at 12:40, 25 April 2011

2011-04-25T12:40:45Z

Horemu at 18:17, 25 September 2006

2006-09-25T18:17:40Z

Mg5151 at 07:11, 22 September 2006

2006-09-22T07:11:44Z

New page

STUN (Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)) is a network protocol allowing a client behind a NAT (or multiple NATs) to find out its public address, the type of NAT it is behind and the internet side port associated by the NAT with a particular local port. This information is used to set up UDP communication between two hosts that are both behind NAT routers. The protocol is defined in RFC 3489.

STUN is a client-server protocol. A VoIP phone or software package may include a STUN client, which will send a request to a STUN server. The server then reports back to the STUN client what the public IP address of the NAT router is, and what port was opened by the NAT to allow incoming traffic back in to the network.

The response also allows the STUN client to determine what type of NAT is in use, as different types of NATs handle incoming UDP packets differently. It will work with three of four main types: full cone, restricted cone, and port restricted cone. It will not work with symmetric NAT (also known as bi-directional NAT) which is often found in the networks of large companies. For details on the different types of NAT, see network address translation.

Once a client has discovered its external addresses, it can relate it to its peers. If the NATs are full cone then either side can initiate communication. If they are restricted cone or restricted port cone both sides must start transmitting together.

Note that using the techniques described in the STUN RFC does not necessarily require using the STUN protocol; they can be used in the design of any UDP protocol.

Protocols like SIP use UDP packets for the transfer of sound/video/text signaling traffic over the Internet. Unfortunately as both endpoints are often behind NAT, a connection cannot be set up in the traditional way. This is where STUN is useful.

An example of a well-known VoIP application that uses STUN is Google Talk, which interoperates with STUN servers situated in Google's datacenters.

The STUN server is contacted on UDP port 3478, however the server will hint clients to perform tests on alternate IP and port number too (STUN servers have two IP addresses). The RFC states that this port and IP are arbitrary.

← Older revision		Revision as of 12:40, 25 April 2011
Line 1:		Line 1:
−	~~<div class="breadcrumb">~~	+	{{Breadcrumb\|0\|0\|Glossary}}
−	{{up}} ~~[[Glossary]]~~
−	~~</div>~~

	'''STUN''' = '''S'''imple '''T'''raversal of '''U'''ser Datagram Protocol ([[UDP]]) Through '''N'''etwork Address Translators ([[NAT\|NATs]])		'''STUN''' = '''S'''imple '''T'''raversal of '''U'''ser Datagram Protocol ([[UDP]]) Through '''N'''etwork Address Translators ([[NAT\|NATs]])

@@ Line 1: / Line 1: @@
-STUN (Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)) is a network protocol allowing a client behind a NAT (or multiple NATs) to find out its public address, the type of NAT it is behind and the internet side port associated by the NAT with a particular local port. This information is used to set up UDP communication between two hosts that are both behind NAT routers. The protocol is defined in RFC 3489.
+<div class="breadcrumb">
-STUN is a client-server protocol. A VoIP phone or software package may include a STUN client, which will send a request to a STUN server. The server then reports back to the STUN client what the public IP address of the NAT router is, and what port was opened by the NAT to allow incoming traffic back in to the network.
+'''STUN''' = '''S'''imple '''T'''raversal of '''U'''ser Datagram Protocol ([[UDP]]) Through '''N'''etwork Address Translators ([[NAT|NATs]])
 The response also allows the STUN client to determine what type of NAT is in use, as different types of NATs handle incoming UDP packets differently. It will work with three of four main types: full cone, restricted cone, and port restricted cone. It will not work with symmetric NAT (also known as bi-directional NAT) which is often found in the networks of large companies. For details on the different types of NAT, see network address translation.
@@ Line 9: / Line 17: @@
 Note that using the techniques described in the STUN RFC does not necessarily require using the STUN protocol; they can be used in the design of any UDP protocol.
-Protocols like SIP use UDP packets for the transfer of sound/video/text signaling traffic over the Internet. Unfortunately as both endpoints are often behind NAT, a connection cannot be set up in the traditional way. This is where STUN is useful.
+Protocols like [[SIP]] use UDP packets for the transfer of sound/video/text signaling traffic over the Internet. Unfortunately as both endpoints are often behind NAT, a connection cannot be set up in the traditional way. This is where STUN is useful.
 An example of a well-known VoIP application that uses STUN is Google Talk, which interoperates with STUN servers situated in Google's datacenters.
 The STUN server is contacted on UDP port 3478, however the server will hint clients to perform tests on alternate IP and port number too (STUN servers have two IP addresses). The RFC states that this port and IP are arbitrary.