Traversal Using Relays around NAT (TURN) Resolution Mechanism
RFC 5928

Internet Engineering Task Force (IETF)                 M. Petit-Huguenin
Request for Comments: 5928                                  Unaffiliated
Category: Standards Track                                    August 2010
ISSN: 2070-1721

     Traversal Using Relays around NAT (TURN) Resolution Mechanism

Abstract

   This document defines a resolution mechanism to generate a list of
   server transport addresses that can be tried to create a Traversal
   Using Relays around NAT (TURN) allocation.

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc5928.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Petit-Huguenin               Standards Track                    [Page 1]
RFC 5928                     TURN Resolution                 August 2010

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Resolution Mechanism . . . . . . . . . . . . . . . . . . . . .  3
   4.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     4.1.  Multiple Protocols . . . . . . . . . . . . . . . . . . . .  6
     4.2.  Remote Hosting . . . . . . . . . . . . . . . . . . . . . .  7
     4.3.  Compatibility with TURN  . . . . . . . . . . . . . . . . .  8
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
     6.1.  RELAY Application Service Tag Registration . . . . . . . .  9
     6.2.  turn.udp Application Protocol Tag Registration . . . . . .  9
     6.3.  turn.tcp Application Protocol Tag Registration . . . . . .  9
     6.4.  turn.tls Application Protocol Tag Registration . . . . . . 10
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 10
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 11

1.  Introduction

   The Traversal Using Relays around NAT (TURN) specification [RFC5766]
   defines a process for a TURN client to find TURN servers by using DNS
   SRV resource records, but this process does not let the TURN server
   administrators provision the preferred TURN transport protocol
   between the client and the server and does not allow the TURN client
   to discover this preference.  This document defines an S-NAPTR
   application [RFC3958] for this purpose.  This application defines
   "RELAY" as an application service tag and "turn.udp", "turn.tcp", and
   "turn.tls" as application protocol tags.

   Another usage of the resolution mechanism described in this document
   would be Remote Hosting as described in [RFC3958], Section 4.4.  For
   example, a Voice over IP (VoIP) provider who does not want to deploy
   TURN servers could use the servers deployed by another company but
   could still want to provide configuration parameters to its customers
   without explicitly showing this relationship.  The mechanism permits
   one to implement this indirection, without preventing the company
   hosting the TURN servers from managing them as it sees fit.

   [TURN-URI] can be used as a convenient way of carrying the four
   components (see Section 3) needed by the resolution mechanism
   described in this document.  A reference implementation is available
   [REF-IMPL].

Petit-Huguenin               Standards Track                    [Page 2]
RFC 5928                     TURN Resolution                 August 2010