TURN Server Auto Discovery
draft-ietf-tram-turn-server-discovery-12

Document Type Active Internet-Draft (tram WG)
Last updated 2017-02-28 (latest revision 2017-01-12)
Replaces draft-patil-tram-turn-serv-disc
Stream IETF
Intended RFC status Proposed Standard
Formats plain text xml pdf html bibtex
Reviews
Stream WG state Submitted to IESG for Publication Nov 2015
Document shepherd Simon Perreault
Shepherd write-up Show (last changed 2016-07-13)
IESG IESG state RFC Ed Queue
Consensus Boilerplate Yes
Telechat date
Responsible AD Spencer Dawkins
Send notices to "Simon Perreault" <sperreault@jive.com>
IANA IANA review state Version Changed - Review Needed
IANA action state RFC-Ed-Ack
RFC Editor RFC Editor state EDIT
TRAM                                                            P. Patil
Internet-Draft                                                  T. Reddy
Updates: 5766 (if approved)                                        Cisco
Intended status: Standards Track                                 D. Wing
Expires: July 16, 2017                                  January 12, 2017

                       TURN Server Auto Discovery
                draft-ietf-tram-turn-server-discovery-12

Abstract

   Current Traversal Using Relays around NAT (TURN) server discovery
   mechanisms are relatively static and limited to explicit
   configuration.  These are usually under the administrative control of
   the application or TURN service provider, and not the enterprise,
   ISP, or the network in which the client is located.  Enterprises and
   ISPs wishing to provide their own TURN servers need auto discovery
   mechanisms that a TURN client could use with no or minimal
   configuration.  This document describes three such mechanisms for
   TURN server discovery.

   This draft updates [RFC5766] to relax the requirement for mutual
   authentication in certain cases.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on July 16, 2017.

Copyright Notice

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

Patil, et al.             Expires July 16, 2017                 [Page 1]
Internet-Draft            TURN server auto disc             January 2017

   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Discovery Procedure . . . . . . . . . . . . . . . . . . . . .   3
   4.  Discovery using Service Resolution  . . . . . . . . . . . . .   4
     4.1.  Retrieving Domain Name  . . . . . . . . . . . . . . . . .   5
       4.1.1.  DHCP  . . . . . . . . . . . . . . . . . . . . . . . .   5
       4.1.2.  From own Identity . . . . . . . . . . . . . . . . . .   5
     4.2.  Resolution  . . . . . . . . . . . . . . . . . . . . . . .   6
   5.  DNS Service Discovery . . . . . . . . . . . . . . . . . . . .   6
     5.1.  mDNS  . . . . . . . . . . . . . . . . . . . . . . . . . .   7
   6.  Discovery using Anycast . . . . . . . . . . . . . . . . . . .   7
   7.  Deployment Considerations . . . . . . . . . . . . . . . . . .   8
     7.1.  Mobility and Changing IP addresses  . . . . . . . . . . .   8
     7.2.  Recursively Encapsulated TURN . . . . . . . . . . . . . .   8
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
     8.1.  IPv4 Anycast  . . . . . . . . . . . . . . . . . . . . . .   8
     8.2.  IPv6 Anycast  . . . . . . . . . . . . . . . . . . . . . .   9
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
     9.1.  Service Resolution  . . . . . . . . . . . . . . . . . . .  11
     9.2.  DNS Service Discovery . . . . . . . . . . . . . . . . . .  11
     9.3.  Anycast . . . . . . . . . . . . . . . . . . . . . . . . .  12
   10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  12
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  12
     11.2.  Informative References . . . . . . . . . . . . . . . . .  14
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  15

1.  Introduction

   TURN [RFC5766] is a protocol that is often used to improve the
   connectivity of Peer-to-Peer (P2P) applications (as defined in
   section 2.7 of [RFC5128]).  TURN allows a connection to be
Show full document text