draft-ietf-tram-turn-server-discovery-02.txt   draft-ietf-tram-turn-server-discovery-03.txt 
TRAM P. Patil TRAM P. Patil
Internet-Draft T. Reddy Internet-Draft T. Reddy
Intended status: Standards Track D. Wing Intended status: Standards Track D. Wing
Expires: November 14, 2015 Cisco Expires: November 21, 2015 Cisco
May 13, 2015 May 20, 2015
TURN Server Auto Discovery TURN Server Auto Discovery
draft-ietf-tram-turn-server-discovery-02 draft-ietf-tram-turn-server-discovery-03
Abstract Abstract
Current Traversal Using Relays around NAT (TURN) server discovery Current Traversal Using Relays around NAT (TURN) server discovery
mechanisms are relatively static and limited to explicit mechanisms are relatively static and limited to explicit
configuration. These are usually under the administrative control of configuration. These are usually under the administrative control of
the application or TURN service provider, and not the enterprise, the application or TURN service provider, and not the enterprise,
ISP, or the network in which the client is located. Enterprises and ISP, or the network in which the client is located. Enterprises and
ISPs wishing to provide their own TURN servers need auto discovery ISPs wishing to provide their own TURN servers need auto discovery
mechanisms that a TURN client could use with no or minimal mechanisms that a TURN client could use with no or minimal
skipping to change at page 1, line 39 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 14, 2015. This Internet-Draft will expire on November 21, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 48 skipping to change at page 2, line 48
02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
TURN [RFC5766] is a protocol that is often used to improve the TURN [RFC5766] is a protocol that is often used to improve the
connectivity of Peer-to-Peer (P2P) applications (as defined in connectivity of Peer-to-Peer (P2P) applications (as defined in
section 2.7 of [RFC5128]). TURN allows a connection to be section 2.7 of [RFC5128]). TURN allows a connection to be
established when one or both sides are incapable of a direct P2P established when one or both sides are incapable of a direct P2P
connection. It is an important building block for interactive, real- connection. It is an important building block for interactive, real-
time communication using audio, video, collaboration etc. While TURN time communication using audio, video, collaboration etc.
services are extensively used today, the means to auto discover TURN
servers do not exist. TURN clients are usually explicitly configured While TURN services are extensively used today, the means to auto
with a well known TURN server. To allow TURN applications operate discover TURN servers do not exist. TURN clients are usually
seamlessly across different types of networks and encourage the use explicitly configured with a well known TURN server. To allow TURN
of TURN without the need for manual configuration, it is important applications operate seamlessly across different types of networks
that there exists an auto discovery mechanism for TURN services. Web and encourage the use of TURN without the need for manual
Real-Time Communication (WebRTC) [I-D.ietf-rtcweb-overview] usages configuration, it is important that there exists an auto discovery
and related extensions, which are mostly based on web applications, mechanism for TURN services. Web Real-Time Communication (WebRTC)
need this immediately. [I-D.ietf-rtcweb-overview] usages and related extensions, which are
mostly based on web applications, need this immediately.
This document describes three discovery mechanisms. The reason for This document describes three discovery mechanisms. The reason for
providing multiple mechanisms is to maximize the opportunity for providing multiple mechanisms is to maximize the opportunity for
discovery, based on the network in the which the TURN client finds discovery, based on the network in which the TURN client finds
itself. itself. The three discovery mechanisms are:
o A resolution mechanism based on straightforward Naming Authority o A resolution mechanism based on straightforward Naming Authority
Pointer (S-NAPTR) resource records in the Domain Name System Pointer (S-NAPTR) resource records in the Domain Name System
(DNS). [RFC5928] describes details on retrieving a list of server (DNS). [RFC5928] describes details on retrieving a list of server
transport addresses from DNS that can be used to create a TURN transport addresses from DNS that can be used to create a TURN
allocation. allocation.
o DNS Service Discovery o DNS Service Discovery
o A mechanism based on anycast address for TURN. o A mechanism based on anycast address for TURN.
skipping to change at page 3, line 43 skipping to change at page 3, line 44
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Discovery Procedure 3. Discovery Procedure
A TURN client that implements the auto discovery algorithm uses the A TURN client that implements the auto discovery algorithm uses the
following mechanisms for discovery: following mechanisms for discovery:
1. Local Configuration : Local or manual configuration should be 1. Local Configuration : If local or manual configuration exists,
tried first, as it may be an explicit preferred choice of a user. they should be tried first, as it may be an explicit preferred
An implementation MAY give the user an opportunity (e.g., by choice of a user. An implementation MAY give the user an
means of configuration file options or menu items) to specify a opportunity (e.g., by means of configuration file options or menu
TURN server for every address family. items) to specify a TURN server for every address family.
2. Service Resolution : Service Resolution : The TURN client 2. Service Resolution : The TURN client attempts to perform TURN
attempts to perform TURN service resolution using the host's DNS service resolution using the host's DNS domain.
domain.
3. DNS Service Discovery (DNS SD) 3. DNS SD: DNS Service Discovery.
4. Anycast : Send TURN allocate request to the assigned TURN anycast 4. Anycast : Send TURN allocate request to the assigned TURN anycast
request for each combination of interface and address family. request for each combination of interface and address family.
Not all TURN servers may be discovered using NAPTR records or DNS SD; Not all TURN servers may be discovered using NAPTR records or DNS SD;
Similarly, not all TURN servers may support anycast. For best Similarly, not all TURN servers may support anycast. For best
results, a client MUST implement all discovery mechanisms described results, a client MUST implement all discovery mechanisms described
above. above.
The document does not prescribe a strict order that a client must The document does not prescribe a strict order that a client must
follow for discovery. An implementation may choose to perform steps follow for discovery. An implementation may choose to perform steps
2,3 and 4 in parallel for discovery OR choose to follow any desired 2,3 and 4 in parallel for discovery OR choose to follow any desired
order and stop the discovery procedure if a mechanism succeeds. order and stop the discovery procedure if a mechanism succeeds.
On hosts with more than one interface or address family (IPv4/v6), On hosts with more than one interface or address family (IPv4/v6),
the TURN server discovery procedure has to be performed for each the TURN server discovery procedure has to be performed for each
combination of interface and address family. A client MAY optionaly combination of interface and address family. A client MAY optionaly
choose to perform the discovery procedure only for a desired choose to perform the discovery procedure only for a desired
interface/address combination, if the client does not wish to interface/address combination if the client does not wish to discover
discover a TURN server for all combinations of interface and address a TURN server for all combinations of interface and address family.
family.
4. Discovery using Service Resolution 4. Discovery using Service Resolution
This mechanism is performed in two steps: This mechanism is performed in two steps:
1. A DNS domain name is retrieved for each combination of interface 1. A DNS domain name is retrieved for each combination of interface
and address family. and address family.
2. Retrieved DNS domain names are then used for S-NAPTR lookups as 2. Retrieved DNS domain names are then used for S-NAPTR lookups as
per [RFC5928]. Further DNS lookups may be necessary to determine per [RFC5928]. Further DNS lookups may be necessary to determine
skipping to change at page 10, line 48 skipping to change at page 10, line 48
routers should be configured to drop such packets. Such routers should be configured to drop such packets. Such
configuration can occur naturally via BGP messages advertising that configuration can occur naturally via BGP messages advertising that
no route exists to said address. no route exists to said address.
Sensitive clients that do not wish to leak information about their Sensitive clients that do not wish to leak information about their
presence can set an IP TTL on their TURN requests that limits how far presence can set an IP TTL on their TURN requests that limits how far
they can travel into the public Internet. they can travel into the public Internet.
10. Acknowledgements 10. Acknowledgements
The authors would like to thank Simon Perrault, Paul Kyzivat and Troy The authors would like to thank Simon Perrault, Paul Kyzivat, Troy
Shields for their review and valuable comments. Thanks to Adam Roach Shields and Eduardo Gueiros for their review and valuable comments.
for his detailed review and suggesting DNS Service Discovery as an Thanks to Adam Roach for his detailed review and suggesting DNS
additional discovery mechanism. Service Discovery as an additional discovery mechanism.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987. specification", STD 13, RFC 1035, November 1987.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
 End of changes. 10 change blocks. 
32 lines changed or deleted 31 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/