Traversal Using Relays around NAT (TURN) Uniform Resource IdentifiersImpedance Mismatchpetithug@acm.orgCisco Systems170 West Tasman DriveSan JoseCA95134USsnandaku@cisco.comCisco Systems7200-12 Kit Creek RoadResearch Triangle ParkNC27709USgsalguei@cisco.comCisco Systems7025 Kit Creek RoadResearch Triangle ParkNC27709USpaulej@packetizer.com
TSV
BEHAVE
This document specifies the syntax of Uniform Resource Identifier (URI) schemes for the Traversal Using Relays around NAT (TURN) protocol.
It defines two URI schemes that can be used to provision the configuration values needed by the resolution mechanism defined in .
This document specifies the syntax and semantics of the Uniform Resource Identifier (URI) scheme for the Traversal Using Relays around NAT (TURN) protocol.
The TURN protocol is a specification allowing hosts behind NAT to control the operation of a relay server.
The relay server allows hosts to exchange packets with its peers.
The peers themselves may also be behind NATs.
RFC 5766 defines the specifics of the TURN protocol.
The "turn" and "turns" URI schemes are used to designate a TURN server (also known as a relay) on Internet hosts accessible using the TURN protocol.
With the advent of standards such as , we anticipate a plethora of endpoints and web applications to be able to identify and communicate with such a TURN server to carry out the TURN protocol.
This also implies those endpoints and/or applications to be provisioned with appropriate configuration required to identify the TURN server.
Having an inconsistent syntax has its drawbacks and can result in non-interoperable solutions.
It can result in solutions that are ambiguous and have implementation limitations on the different aspects of the syntax and alike.
The "turn/turns" URI scheme helps alleviate most of these issues by providing a consistent way to describe, configure and exchange the information identifying a TURN server.
This would also prevent the shortcomings inherent with encoding similar information in non-uniform syntaxes such as the ones proposed in , for example.
defines a resolution mechanism to convert a secure flag, a host name or IP address, an eventually empty port, and an eventually empty transport to a list of IP address, port, and TURN transport tuples.To simplify the provisioning of TURN clients, this document defines a TURN and a TURNS URI scheme that can carry the four components needed for the resolution mechanism.The key words "MUST", "MUST NOT", "REQUIRED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .The "turn" URI takes the following form (the syntax below is non-normative):turn:<host>:<port>turns:<host>:<port>Note that the <port> part and the preceding ":" (colon) character, is OPTIONAL.A TURN/TURNS URI has the following formal ABNF syntax :
<unreserved>, <sub-delims>, and <pct-encoded> are specified in .
The core rules <DIGIT> and <HEXDIGIT> are used as described in Appendix B of RFC 5234 .
The <host>, <port> and <transport> components are passed without modification to the algorithm.
<secure> is set to false if <scheme> is equal to "turn" and set to true if <scheme> is equal to "turns" and passed to the algorithm with the other components.
The TURN protocol supports sending messages over UDP, TCP or TLS-over-TCP.
The "turns" URI scheme MUST be used when TURN is run over TLS-over-TCP (or in the future DTLS-over-UDP) and the "turn" scheme MUST be used otherwise.
The required <host> part of the "turn" URI denotes the TURN server host.
The <port> part, if present, denotes the port on which the TURN server is awaiting connection requests.
If it is absent, the default port is 3478 for both UDP and TCP.
The default port for TURN over TLS is 5349.
Note to RFC Editor: Please remove this section before publication.
This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in .
According to , "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, by considering the running code as evidence of valuable experimentation and feedback that has made the implemented protocols more mature.
It is up to the individual working groups to use this information as they see fit".
turnuri 0.3.4A reference implementation of this document and of RFC 5928.Beta.Fully implements this specification and RFC 5928.AGPL3Marc Petit-Huguenin <marc@petit-huguenin.org>.http://debian.implementers.org/stable/source/turnuri.tar.gzlibjingle 0.7.1Libjingle is a set of components provided by Google to implement Jingle protocols XEP-166 (http://xmpp.org/extensions/xep-0166.html) and XEP-167 (http://xmpp.org/extensions/xep-0167.html).Beta.Implements draft-petithuguenin-behave-turn-uris-01 without IPv6.BSD 3-clauses license.https://code.google.com/p/chromium/https://code.google.com/p/chromium/codesearch#chromium/src/third_party/libjingle/source/talk/app/webrtc/peerconnection.ccFirefox Aurora 21Mozilla Firefox is a free and open source web browser.Beta.Implements draft-petithuguenin-behave-turn-uri-03 without RFC 5928.Mozilla Public License, v2.0.http://www.mozilla.org/en-US/firefox/channel/http://hg.mozilla.org/mozilla-central/rev/6b5016ab9ebbSecurity considerations for the resolution mechanism are discussed in .The "turn" and "turns" URI schemes do not introduce any specific security issues beyond the security considerations discussed in .This section contains the registration information for the "turn" and "turns" URI Schemes (in accordance with ).URI scheme name: turnStatus: permanentURI scheme syntax: See .URI scheme semantics: See .Encoding considerations: There are no encoding considerations beyond those in .Applications/protocols that use this URI scheme name:The "turn" URI scheme is intended to be used by applications that might need access to a TURN server.Interoperability considerations: N/ASecurity considerations: See .Contact: Marc Petit-Huguenin <petithug@acm.org>Author/Change controller: The IESGReferences: RFCXXXX[[NOTE TO RFC EDITOR: Please change XXXX to the number assigned to this specification, and remove this paragraph on publication.]]URI scheme name: turnsStatus: permanentURI scheme syntax: See .URI scheme semantics: See .Encoding considerations: There are no encoding considerations beyond those in .Applications/protocols that use this URI scheme name:The "turns" URI scheme is intended to be used by applications that might need access to a TURN server over a secure connection.Interoperability considerations: N/ASecurity considerations: See .Contact: Marc Petit-Huguenin <petithug@acm.org>Author/Change controller: The IESGReferences: RFCXXXX[[NOTE TO RFC EDITOR: Please change XXXX to the number assigned to this specification, and remove this paragraph on publication.]]Thanks to Margaret Wasserman, Magnus Westerlund, Juergen Schoenwaelder, Sean Turner, Ted Hardie, Dave Thaler, Alfred E. Heggestad, Eilon Yardeni, Dan Wing, Alfred Hoenes, and Jim Kleck for their comments, suggestions and questions that helped to improve the draft-petithuguenin-behave-turn-uri-bis document.Many thanks to Cullen Jennings for his detailed review and thoughtful comments on the draft-nandakumar-rtcweb-turn-uri document.Thanks to Bjoern Hoehrmann for his comments, suggestions and questions that helped to improve the this document.The <turn-port> and <turn-host> ABNF productions have been copied from the <port> and <host> ABNF productions from .Key words for use in RFCs to Indicate Requirement LevelsHarvard University1350 Mass. Ave.CambridgeMA 02138- +1 617 495 3864sob@harvard.edu
General
keyword
In many standards track documents several words are used to signify
the requirements in the specification. These words are often
capitalized. This document defines these words as they should be
interpreted in IETF documents. Authors who follow these guidelines
should incorporate this phrase near the beginning of their document:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
RFC 2119.
Note that the force of these words is modified by the requirement
level of the document in which they are used.
Uniform Resource Identifier (URI): Generic SyntaxWorld Wide Web ConsortiumMassachusetts Institute of Technology77 Massachusetts AvenueCambridgeMA02139USA+1-617-253-5702+1-617-258-5999timbl@w3.orghttp://www.w3.org/People/Berners-Lee/Day Software5251 California Ave., Suite 110IrvineCA92617USA+1-949-679-2960+1-949-679-2972fielding@gbiv.comhttp://roy.gbiv.com/Adobe Systems Incorporated345 Park AveSan JoseCA95110USA+1-408-536-3024LMM@acm.orghttp://larry.masinter.net/
Applications
uniform resource identifierURIURLURNWWWresource
A Uniform Resource Identifier (URI) is a compact sequence of characters
that identifies an abstract or physical resource. This specification
defines the generic URI syntax and a process for resolving URI references
that might be in relative form, along with guidelines and security
considerations for the use of URIs on the Internet.
The URI syntax defines a grammar that is a superset of all valid URIs,
allowing an implementation to parse the common components of a URI
reference without knowing the scheme-specific requirements of every
possible identifier. This specification does not define a generative
grammar for URIs; that task is performed by the individual
specifications of each URI scheme.
Augmented BNF for Syntax Specifications: ABNFTraversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)Traversal Using Relays around NAT (TURN) Resolution MechanismGuidelines and Registration Procedures for New URI SchemesWebRTC 1.0: Real-time Communication Between BrowsersImproving Awareness of Running Code: the Implementation Status Section
This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section.
This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, by considering the running code as evidence of valuable experimentation and feedback that has made the implemented protocols more mature.
The process in this document is offered as an experiment.
Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications.
The authors of this document intend to collate experiences with this experiment and to report them to the community.
shows how the <secure>, <port> and <transport> components are populated from various URIs.
For all these examples, the <host> component is populated with "example.org".
URI<secure><port><transport>turn:example.orgfalseturns:example.orgtrueturn:example.org:8000false8000turn:example.org?transport=udpfalseUDPturn:example.org?transport=tcpfalseTCPturns:example.org?transport=tcptrueTLSThis section must be removed before publication as an RFC.
One recurring comment was to stop using the suffix "s" on URI scheme, and to move the secure option to a parameter (e.g. ";proto=tls").
We decided against this idea because the STUN URI does not have a ";proto=" parameter and we would have lost the symmetry between the TURN and STUN URIs.
A more detailed account of the reasoning behind this is available at <http://blog.marc.petit-huguenin.org/2012/09/on-design-of-stun-and-turn-uri-formats.html>
Following the advice of RFC 4395 section 2.2., and because the TURN URI does not describe a hierarchical structure, the TURN URIs are opaque URIs.
<password> is not used in the URIs because it is deprecated.
<username> is not used in the URIs because it is not used to guide the resolution mechanism.
As discussed in Dublin, there is no generic parameters in the URI to prevent compatibility issues.Added implementation status (from draft-sheffer-running-code) for turnuri, Chromium and Firefox.