Tech-invite3GPPspaceIETF RFCsSIP
93929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 6314

NAT Traversal Practices for Client-Server SIP

Pages: 60
Informational
Part 4 of 4 – Pages 48 to 60
First   Prev   None

Top   ToC   RFC6314 - Page 48   prevText

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.
Top   ToC   RFC6314 - Page 49
     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
Top   ToC   RFC6314 - Page 50
   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.
Top   ToC   RFC6314 - Page 51
       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     |                  |                  |
Top   ToC   RFC6314 - Page 52
       |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
Top   ToC   RFC6314 - Page 53
   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
Top   ToC   RFC6314 - Page 54
   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.
Top   ToC   RFC6314 - Page 55
       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     |                  |                  |
       |                  |                  |                  |
Top   ToC   RFC6314 - Page 56
       |                  |                  |(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.
Top   ToC   RFC6314 - Page 57
   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.
Top   ToC   RFC6314 - Page 58

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.
Top   ToC   RFC6314 - Page 59
   [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.
Top   ToC   RFC6314 - Page 60
   [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