RFC 6314
NAT Traversal Practices for Client-Server SIP
Pages: 60
Informational
Informational
Part 4 of 4 – Pages 48 to 60
5.2.2. Address/Port-Dependent NAT
5.2.2.1. STUN Failure
This section highlights that although using STUN techniques is the preferred mechanism for traversal of NAT, it does not solve every case. The use of basic STUN on its own will not guarantee traversal through every NAT type, hence the recommendation that ICE is the preferred option.
Client ADDRESS/PORT-Dependent STUN [..] NAT Server | | | | |(1) BIND Req | | | |Src=L-PRIV-1 | | | |Dest=STUN-PUB | | | |----------------->| | | | |(2) BIND Req | | | |Src=NAT-PUB-1 | | | |Dest=STUN-PUB | | | |----------------->| | | | | | | |(3) BIND Resp | | | |<-----------------| | | |Src=STUN-PUB | | | |Dest=NAT-PUB-1 | | | |Map=NAT-PUB-1 | | | | | | |(4) BIND Resp | | | |<-----------------| | | |Src=STUN-PUB | | | |Dest=L-PRIV-1 | | | |Map=NAT-PUB-1 | | | | | | | |(5)SIP INVITE | | | |------------------------------------------------------->| | | | | | | |(6)SIP 200 OK | | |<------------------------------------| | | | | |(7)SIP 200 OK | | | |<-----------------| | | | | | | |========================================================| |>>>>>>>>>>>>>>Outgoing Media sent from L-PRIV-1>>>>>>>>>| |========================================================| | | | | | x=====================================| | xIncoming Media sent to L-PRIV-1<<<<<<| | x=====================================| | | | | |(8)SIP ACK | | | |----------------->| | | | |(9) SIP ACK | | | |------------------------------------>| | | | | Figure 18: Address/Port-Dependent NAT with STUN - Failure
The example in Figure 18 is conveyed in the context of a client behind the Address/Port-Dependent NAT initiating a call. It should be noted that the same problem applies when a client receives a SIP invitation and is behind a Address/Port-Dependent NAT. o In Figure 18, the client behind the NAT obtains a server reflexive representation using standard STUN mechanisms (1)-(4) that have been used in previous examples in this document (e.g., Section 5.2.1.1.1). o The external mapped address (server reflexive) obtained is also used in the outgoing SDP contained in the SIP INVITE request (5). o In this example, the client is still able to send media to the external client. The problem occurs when the client outside the NAT tries to use the reflexive address supplied in the outgoing INVITE request to traverse media back through the Address/ Port-Dependent NAT. o A Address/Port-Dependent NAT has differing rules from the Endpoint-Independent type of NAT (as defined in RFC 4787 [RFC4787]). For any internal IP address and port combination, data sent to a different external destination does not provide the same public mapping at the NAT. In Figure 18, the STUN query produced a valid external mapping for receiving media. This mapping, however, can only be used in the context of the original STUN request that was sent to the STUN server. Any packets that attempt to use the mapped address and that do not originate from the STUN server IP address and optionally port will be dropped at the NAT. Figure 18 shows the media being dropped at the NAT after (7) and before (8). This then leads to one-way audio.5.2.2.2. TURN Solution
As identified in Section 5.2.2.1, STUN provides a useful tool for the traversal of the majority of NATs but fails with Address/ Port-Dependent NAT. The TURN extensions [RFC5766] address this scenario. TURN extends STUN to allow a client to request a relayed address at the TURN server rather than a reflexive representation. This then introduces a media relay in the path for NAT traversal (as described in Section 4.2.3.2). The following example explains how TURN solves the previous failure when using STUN to traverse a Address/Port-Dependent NAT. It should be noted that TURN works most effectively when used in conjunction with ICE. Using TURN on its own results in all media being relayed through a TURN server; this is not efficient.
L Address/Port-Dependent TURN [..]
NAT Server
| | | |
|(1) Alloc Req | | |
|Src=L-PRIV-1 | | |
|Dest=STUN-PUB-1 | | |
|----------------->| | |
| | | |
| |(2) Alloc Req | |
| |Src=NAT-PUB-1 | |
| |Dest=STUN-PUB-1 | |
| |----------------->| |
| | | |
| |(3) Alloc Resp | |
| |<-----------------| |
| |Src=STUN-PUB-1 | |
| |Dest=NAT-PUB-1 | |
| |Map=NAT-PUB-1 | |
| |Rel=STUN-PUB-2 | |
| | | |
|(4) Alloc Resp | | |
|<-----------------| | |
|Src=STUN-PUB-1 | | |
|Dest=L-PRIV-1 | | |
|Map=NAT-PUB-1 | | |
|Rel=STUN-PUB-2 | | |
| | | |
|(5) Alloc Req | | |
|Src=L-PRIV-2 | | |
|Dest=STUN-PUB-1 | | |
|----------------->| | |
| | | |
| |(6) Alloc Req | |
| |Src=NAT-PUB-2 | |
| |Dest=STUN-PUB-1 | |
| |----------------->| |
| | | |
| |(7) Alloc Resp | |
| |<-----------------| |
| |Src=STUN-PUB-1 | |
| |Dest=NAT-PUB-2 | |
| |Map=NAT-PUB-2 | |
| |Rel=STUN-PUB-3 | |
| | | |
|(8) Alloc Resp | | |
|<-----------------| | |
|Src=STUN-PUB-1 | | |
|Dest=L-PRIV-2 | | |
|Map=NAT-PUB-2 | | | |Rel=STUN-PUB-3 | | | | | | | |(9)SIP INVITE | | | |----------------->| | | | | | | | |(10)SIP INVITE | | | |------------------------------------>| | | | | | | |(11)SIP 200 OK | | |<------------------------------------| | | | | |(12)SIP 200 OK | | | |<-----------------| | | | | | | |========================================================| |>>>>>>>>>>>>>Outgoing Media sent from L-PRIV-1>>>>>>>>>>| |========================================================| | | | | | | |==================| | | |<<<Media Sent to<<| | | |<<<<STUN-PUB-2<<<<| | | |==================| | | | | |=====================================| | |<Incoming Media Relayed to L-PRIV-1<<| | |=====================================| | | | | | | | |==================| | | |<<<RTCP Sent to<<>| | | |<<<<STUN-PUB-3<<<<| | | |==================| | | | | |=====================================| | |<<Incoming RTCP Relayed to L-PRIV-2<<| | |=====================================| | | | | | |(13)SIP ACK | | | |----------------->| | | | | | | | |(14) SIP ACK | | | |------------------------------------>| | | | | Figure 19: Address/Port-Dependent NAT with TURN - Success
o In this example, client L issues a TURN allocate request (1) to
obtained a relay address at the STUN server. The request
traverses through the Address/Port-Dependent NAT and reaches the
STUN server (2). The STUN server generates an Allocate response
(3) that contains both a server reflexive address (Map=NAT-PUB-1)
of the client and also a relayed address (Rel=STUN-PUB-2). The
relayed address maps to an address mapping on the STUN server that
is bound to the public pinhole that has been opened on the NAT by
the Allocate request. This results in any traffic sent to the
TURN server relayed address (Rel=STUN-PUB-2) being forwarded to
the external representation of the pinhole created by the Allocate
request (NAT-PUB-1).
o The TURN derived address (STUN-PUB-2) arrives back at the
originating client (4) in an Allocate response. This address can
then be used in the SDP for the outgoing SIP INVITE request as
shown in the following example (note that the example also
includes client L obtaining a second relay address for use in the
RTCP attribute (5-8)):
v=0
o=test 2890844342 2890842164 IN IP4 $L-PRIV-1
c=IN IP4 $STUN-PUB-2.address
t=0 0
m=audio $STUN-PUB-2.port RTP/AVP 0
a=rtcp:$STUN-PUB-3.port
o On receiving the INVITE request, the User Agent Server (UAS) is
able to stream media and RTCP to the relay address (STUN-PUB-2 and
STUN-PUB-3) at the STUN server. As shown in Figure 19 (between
messages (12) and (13), the media from the UAS is directed to the
relayed address at the STUN server. The STUN server then forwards
the traffic to the open pinholes in the Address/Port-Dependent NAT
(NAT-PUB-1 and NAT-PUB-2). The media traffic is then able to
traverse the Address/Port-Dependent NAT and arrives back at client
L.
o TURN on its own will work for Address/Port-Dependent and other
types of NAT mentioned in this specification but should only be
used as a last resort. The relaying of media through an external
entity is not an efficient mechanism for NAT traversal and comes
at a high processing cost.
5.2.2.3. ICE Solution
The previous two examples have highlighted the problem with using
core STUN for all forms of NAT traversal and a solution using TURN
for the Address/Port-Dependent NAT case. The RECOMMENDED mechanism
for traversing all varieties of NAT is using ICE, as detailed in Section 4.2.3.3. ICE makes use of core STUN, TURN and any other mechanism (e.g., NAT-PMP[NAT-PMP], UPnP IGD[UPnP-IGD]) to provide a list of prioritized addresses that can be used for media traffic. Detailed examples of ICE can be found in Section 5.2.1.2.1. These examples are associated with an Endpoint-Independent type NAT but can be applied to any NAT type variation, including Address/ Port-Dependent type NAT. The ICE procedures carried out are the same. For a list of candidate addresses, a client will choose where to send media dependent on the results of the STUN connectivity checks and associated priority (highest priority wins). It should be noted that the inclusion of a NAT displaying Address/Port-Dependent properties does not automatically result in relayed media. In fact, ICE processing will avoid use of media relay with the exception of two clients that both happen to be behind a NAT using Address/ Port-Dependent characteristics. The connectivity checks and associated selection algorithm enable traversal in this case. Figure 20 and the following description provide a guide as to how this is achieved using the ICE connectivity checks. This is an abbreviated example that assumes successful SIP offer/answer exchange and illustrates the connectivity check flow.
L Address/Port-Dependent Endpoint-Independent R
L-NAT R-NAT
|========================================================|
| SIP OFFER/ANSWER EXCHANGE |
|========================================================|
| | | |
| | |(1)Bind Req |
| | |<-----------------|
| | |Src=R=PRIV-1 |
| | |Dest=L-NAT-PUB-1 |
| | | |
| |(2)Bind Req | |
| x<-----------------| |
| |Src=R-NAT-PUB-1 | |
| |Dest=L-NAT-PUB-1 | |
| | | |
|(3)Bind Req | | |
|----------------->| | |
|Src=L-PRIV-1 | | |
|Dest=R-NAT-PUB-1 | | |
| | | |
| |(4)Bind Req | |
| |----------------->| |
| |Src=L-NAT-PUB-1 | |
| |Dest=R-NAT-PUB-1 | |
| | | |
| | |(5)Bind Req |
| | |----------------->|
| | |Src=L-NAT-PUB-1 |
| | |Dest=R-PRIV-1 |
| | | |
| | |(6)Bind Resp |
| | |<-----------------|
| | |Src=R-PRIV-1 |
| | |Dest=L-NAT-PUB-1 |
| | | |
| |(7)Bind Resp | |
| |<-----------------| |
| |Src=R-NAT-PUB-1 | |
| |Dest=L-NAT-PUB-1 | |
| | | |
|(8)Bind Resp | | |
|<-----------------| | |
|Src=R-NAT-PUB-1 | | |
|Dest=L-PRIV-1 | | |
| | | |
| | |(9)Bind Req | | | |<-----------------| | | |Src=R-Priv-1 | | | |Dest=L-NAT-PUB-1 | | |(10)Bind Req | | | |<-----------------| | | |Src=R-NAT-PUB-1 | | | |Dest=L-NAT-PUB-1 | | | | | | |(11)Bind Req | | | |<-----------------| | | |Src=R-NAT-PUB-1 | | | |Dest=L-PRIV-1 | | | | | | | |(12)Bind Resp | | | |----------------->| | | |Src=L-PRIV-1 | | | |Dest=L-NAT-PUB-1 | | | | | | | | |(13)Bind Resp | | | |----------------->| | | |Src=L-NAT-PUB-1 | | | |Dest=R-NAT-PUB-1 | | | | | | | | |(14)Bind Resp | | | |----------------->| | | |Src=L-NAT-PUB-1 | | | |Dest=R-PRIV-1 | | | | | Figure 20: Single Address/Port-Dependent NAT - Success In this abbreviated example, client R has already received a SIP INVITE request and is starting its connectivity checks with client L. Client R generates a connectivity check (1) and sends to client L's information as presented in the SDP offer. The request arrives at client L's Address/Port-Dependent NAT and fails to traverse as there is no NAT binding. This would then move the connectivity check to a failed state. In the meantime, client L has received the SDP answer in the SIP request and will also commence connectivity checks. A check is dispatched (3) to client R. The check is able to traverse the NAT due to the association set up in the previously failed check (1). The full Bind request/response is shown in steps (3)-(8). As part of a candidate pair, client R will now successfully be able to complete the checks, as illustrated in steps (9)-(14). The result is a successful pair of candidates that can be used without the need to relay any media.
In conclusion, the only time media needs to be relayed is a result of clients both behind Address/Port-Dependent NATs. As you can see from the example in this section, neither side would be able to complete connectivity checks with the exception of the Relayed candidates.6. IPv4-IPv6 Transition
This section describes how IPv6-only SIP User Agents can communicate with IPv4-only SIP User Agents. While the techniques discussed in this document primarily contain examples of traversing NATs to allow communications between hosts in private and public networks, they are by no means limited to such scenarios. The same NAT traversal techniques can also be used to establish communication in a heterogeneous network environment -- e.g., communication between an IPv4 host and an IPv6 host.6.1. IPv4-IPv6 Transition for SIP Signaling
IPv4-IPv6 translations at the SIP level usually take place at dual- stack proxies that have both IPv4 and IPv6 DNS entries. Since these translations do not involve NATs that are placed in the middle of two SIP entities, they fall outside the scope of this document. A detailed description of this type of translation can be found in [RFC6157].7. Security Considerations
There are no security considerations beyond the ones inherited by reference.8. Acknowledgments
The authors would like to thank the members of the IETF SIPPING WG for their comments and suggestions. Expert review and detailed contribution including text was provided by Dan Wing, who was supportive throughout. Detailed comments were provided by Vijay Gurbani, Kaiduan Xie, Remi Denis-Courmont, Hadriel Kaplan, Phillip Matthews, Spencer Dawkins, and Hans Persson.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002. [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. [RFC3327] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts", RFC 3327, December 2002. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [RFC3581] Rosenberg, J. and H. Schulzrinne, "An Extension to the Session Initiation Protocol (SIP) for Symmetric Response Routing", RFC 3581, August 2003. [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP)", RFC 3605, October 2003. [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006. [RFC4787] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007. [RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", BCP 131, RFC 4961, July 2007.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010. [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008. [RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client-Initiated Connections in the Session Initiation Protocol (SIP)", RFC 5626, October 2009. [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and Control Packets on a Single Port", RFC 5761, April 2010. [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. [RFC5923] Gurbani, V., Mahy, R., and B. Tate, "Connection Reuse in the Session Initiation Protocol (SIP)", RFC 5923, June 2010.9.2. Informative References
[MIDDLEBOXES] Stucker, B. and H. Tschofenig, "Analysis of Middlebox Interactions for Signaling Protocol Communication along the Media Path", Work in Progress, July 2010. [NAT-PMP] Cheshire, S., "NAT Port Mapping Protocol (NAT-PMP)", Work in Progress, April 2008. [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation", RFC 3424, November 2002. [RFC5780] MacDonald, D. and B. Lowekamp, "NAT Behavior Discovery Using Session Traversal Utilities for NAT (STUN)", RFC 5780, May 2010.
[RFC5853] Hautakorpi, J., Camarillo, G., Penfield, R., Hawrylyshen, A., and M. Bhatia, "Requirements from Session Initiation Protocol (SIP) Session Border Control (SBC) Deployments", RFC 5853, April 2010. [RFC6157] Camarillo, G., El Malki, K., and V. Gurbani, "IPv6 Transition in the Session Initiation Protocol (SIP)", RFC 6157, April 2011. [UPnP-IGD] UPnP Forum, "Universal Plug and Play Internet Gateway Device v1.0", 2000, <http://www.upnp.org/specs/gw/igd1/>.Authors' Addresses
Chris Boulton NS-Technologies EMail: chris@ns-technologies.com Jonathan Rosenberg Skype EMail: jdrosen@jdrosen.net Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland EMail: Gonzalo.Camarillo@ericsson.com Francois Audet Skype EMail: francois.audet@skype.net