One document matched: draft-petithuguenin-behave-turn-uri-02.txt
Differences from draft-petithuguenin-behave-turn-uri-01.txt
Network Working Group M. Petit-Huguenin
Internet-Draft 8x8, Inc.
Intended status: Standards Track July 14, 2008
Expires: January 15, 2009
Traversal Using Relays around NAT (TURN) Uniform Resource Identifiers
draft-petithuguenin-behave-turn-uri-02
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 15, 2009.
Abstract
This document defines two URI schemes and the resolution mechanism to
convert these URIs to a list of server transport addresses that can
be used between a Traversal Using Relays around NAT (TURN) client and
server.
Petit-Huguenin Expires January 15, 2009 [Page 1]
Internet-Draft TURN URIs July 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Syntax of a TURN or TURNS URI . . . . . . . . . . . . . . . . . 3
4. TURN or TURNS URI Resolution . . . . . . . . . . . . . . . . . 3
5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
9. Normative References . . . . . . . . . . . . . . . . . . . . . 7
Appendix A. Release notes . . . . . . . . . . . . . . . . . . . . 7
A.1. Modifications between -02 and -01 . . . . . . . . . . . . . 7
A.2. Modifications between -01 and -00 . . . . . . . . . . . . . 7
A.3. Design Notes . . . . . . . . . . . . . . . . . . . . . . . 8
A.4. TODO List . . . . . . . . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8
Intellectual Property and Copyright Statements . . . . . . . . . . 9
Petit-Huguenin Expires January 15, 2009 [Page 2]
Internet-Draft TURN URIs July 2008
1. Introduction
The TURN specification [I-D.ietf-behave-turn] 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 for the TURN client to discover this preference.
This document defines a S-NAPTR application [RFC3958] for this
purpose. This application defines "RELAY" as application service tag
and "turn.udp", "turn.tcp", and "turn.tls" as application protocol
tags.
To simplify the provisioning of TURN clients, this document also
defines a TURN and a TURNS URI scheme and a resolution mechanism to
convert this URIs into a list of IP addresses, ports and TURN
transport protocols.
2. Terminology
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 [RFC2119].
3. Syntax of a TURN or TURNS URI
A TURN/TURNS URI has the following ABNF syntax [RFC5234]:
turnURI = scheme "://" authority [ "?" query ]
scheme = "turn" / "turns"
authority = host [ ":" port ]
query = "transport=" transport
transport = "udp" / "tcp" / transport-ext
transport-ext = 1*unreserved
<host>, <port> and <unreserved> are specified in [RFC3986].
4. TURN or TURNS URI Resolution
The URI resolution algorithm uses <scheme>, <host>, <port> and
<transport> as input. It also uses a list ordered by preference of
TURN transports (UDP, TCP, TLS) supported by the application using
the TURN client. The output of the algorithm is a list of {IP
address, transport, port} tuples that a TURN client can try to
contact a TURN server.
Petit-Huguenin Expires January 15, 2009 [Page 3]
Internet-Draft TURN URIs July 2008
The resolution stops when a TURN client gets a successful Allocate
response from a TURN server. After receiving a successful Allocate
response, the resolution context MUST be discarded and the URI
resolution algorithm MUST be restarted from the beginning for any
subsequent allocation.
In some steps <transport> and <scheme> have to be converted to a TURN
transport. If <scheme> is defined as "turn" and <transport> is
defined as "udp" then the TURN UDP transport is used. If <scheme> is
defined as "turn" and <transport> is defined as "tcp" then the TURN
TCP transport is used. If <scheme> is defined as "turns" and
<transport> is defined as "tcp" then the TURN TLS transport is used.
First the resolution algorithm checks that the URI can be resolved
with the list of TURN transports supported:
o If <scheme> is defined as "turn" and <transport> is defined as
"udp" but the list of TURN transports does not contain UDP then
the resolution MUST stop with an error.
o If <scheme> is defined as "turn" and <transport> is defined as
"tcp" but the list of TURN transports does not contain TCP or TLS
then the resolution MUST stop with an error.
o If <scheme> is defined as "turns" and <transport> is defined as
"udp" then the algorithm MUST stop with an error.
o If <scheme> is defined as "turns" and <transport> is defined as
"tcp" but the list of TURN transports does not contain TLS then
the resolution MUST stop with an error.
o If <scheme> is defined as "turns" and <transport> is not defined
but the list of TURN transports does not contain TLS then the
resolution MUST stop with an error.
Then the algorithm applies the following steps.
1. If <host> is an IP address then it indicates the specific IP
address to be used. If <port> is not defined, the default port
declared in [I-D.ietf-behave-turn] for the SRV service name
defined in <scheme> is used. If <transport> is defined then
<scheme> and <transport> are converted to a TURN transport as
specified above. If <transport> is not defined, the TURN
transports supported by the application are tried by preference
order. If the TURN client cannot contact a TURN server with this
IP address and port on any of the transports then the resolution
MUST stop with an error.
2. If <host> is a domain name and <port> is defined, then <host> is
resolved to a list of IP addresses via DNS A and AAAA queries.
If <transport> is defined then <scheme> and <transport> are
converted to a TURN transport as specified above. If <transport>
is not defined, the TURN transports supported by the application
Petit-Huguenin Expires January 15, 2009 [Page 4]
Internet-Draft TURN URIs July 2008
are tried by preference order. If the TURN client cannot contact
a TURN server with this port and any combination of transports
and resolved IP addresses then the resolution MUST stop with an
error.
3. If <host> is a domain name and <port> is not defined but
<transport> is defined then <host> is converted to a list of IP
address and port tuples via a DNS SRV query as defined in
[I-D.ietf-behave-turn] section 6.1. <scheme> is used for the
service name and <transport> is used for the protocol name in the
SRV algorithm [RFC2782]. If the TURN client cannot contact a
TURN server on any of the IP address, port and transport tuples
returned by the SRV algorithm then the resolution MUST stop with
an error. The SRV algorithm recommends to do an A query if the
SRV query returns an error or no SRV RR. In this case the
default port declared in [I-D.ietf-behave-turn] for the SRV
service name defined in <scheme> must be used for contacting the
TURN server. This specification also modifies this algorithm by
recommending to do an A or AAAA query in this case.
4. If <host> is a domain name and <port> and <transport> are not
defined, then <host> is converted to an ordered list of IP
address, port and transport tuples via the S-NAPTR algorithm
defined in [RFC3958] with a "RELAY" Application Service Tag. The
TURN transports supported by the application are converted in
Application Protocol Tags by using "turn.udp" if the TURN
transport is UDP, "turn.tcp" if the TURN transport is TCP and
"turn.tls" if the TURN transport is TLS. The order to try the
protocol tags is provided by the ranking of the first set of
NAPTR records. If multiple protocol tags have the same ranking,
the preferred order set by the application is used. If the TURN
client cannot contact a TURN server with any of the IP address,
port and transport tuples returned by the S-NAPTR algorithm then
the resolution MUST stop with an error. If the first NAPTR SRV
query does not return any result then <host> is converted to a
list of IP address and port tuples by using the algorithm
specified in step 3 for each of the TURN transports supported by
the application by order of preference.
5. Example
With the DNS RRs in Figure 1 and a preferred protocol list of {TLS,
TCP, UDP}, the resolution algorithm will convert the
"turn://example.com" URI to the list of IP addresses, port and
protocol tuples in Table 1.
Petit-Huguenin Expires January 15, 2009 [Page 5]
Internet-Draft TURN URIs July 2008
example.com.
IN NAPTR 100 10 "" "RELAY:turn.udp" "" datagram.example.com.
IN NAPTR 200 10 "" "RELAY:turn.tcp:turn.tls" "" stream.example.com.
datagram.example.com.
IN NAPTR 100 10 "S" "RELAY:turn.udp" "" _udp._turn.example.com.
stream.example.com.
IN NAPTR 100 10 "A" "RELAY:turn.tls" "" a.example.com.
IN NAPTR 200 10 "S" "RELAY:turn.tcp" "" _tcp._turn.example.com.
_udp._turn.example.com.
IN SRV 0 0 5000 a.example.com.
_tcp._turn.example.com.
IN SRV 0 0 5000 a.example.com.
a.example.com.
IN A 192.0.2.1
Figure 1
+-------+----------+------------+------+
| Order | Protocol | IP address | Port |
+-------+----------+------------+------+
| 1 | UDP | 192.0.2.1 | 5000 |
| 2 | TLS | 192.0.2.1 | 3478 |
| 3 | TCP | 192.0.2.1 | 5000 |
+-------+----------+------------+------+
Table 1
6. Security Considerations
TBD
7. IANA Considerations
TBD
8. Acknowledgements
Thanks to Eilon Yardeni, Dan Wing and Alfred Hoenes for their
comments, suggestions and questions that helped to improve this
Petit-Huguenin Expires January 15, 2009 [Page 6]
Internet-Draft TURN URIs July 2008
document.
9. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
February 2000.
[RFC3958] Daigle, L. and A. Newton, "Domain-Based Application
Service Location Using SRV RRs and the Dynamic Delegation
Discovery Service (DDDS)", RFC 3958, January 2005.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
[I-D.ietf-behave-turn]
Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using
Relays around NAT (TURN): Relay Extensions to Session
Traversal Utilities for NAT (STUN)",
draft-ietf-behave-turn-09 (work in progress), July 2008.
Appendix A. Release notes
This section must be removed before publication as an RFC.
A.1. Modifications between -02 and -01
o Receiving a successful Allocate response stops the resolution
mechanism and the resolution context must be discarded after this.
o Changed from opaque to hierarchical URIs because the ";" character
is used in <reg-name>.
o Various nits.
A.2. Modifications between -01 and -00
o Added <transport-ext> in the ABNF.
o Use the <rulename> and "literal" usages for free-form text defined
by [RFC5234].
Petit-Huguenin Expires January 15, 2009 [Page 7]
Internet-Draft TURN URIs July 2008
o Fixed various typos.
o Put the rule to convert <scheme> and <transport> to a TURN
transport in a separate paragraph.
o Modified the SRV usage to be in line with RFC 2782.
o Clarified that the NAPTR protocol ranking must be used before the
application ranking.
o Added an example.
o Added release notes.
A.3. Design Notes
o The Application Service Tag is "RELAY" so other relaying
mechanisms (e.g. TWIST) than TURN can be registered as
Application Protocol Tags.
o S-NAPTR was preferred to U-NAPTR because there is no use case for
U-NAPTR.
o <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.
A.4. TODO List
o Dan Wing: Add generic parameters on TURN URI. [Parameters can be
optional or mandatory. Add text explaining that parameters to be
defined in the future must be only for the purpose of guiding the
resolution mechanism.]
o Add security section.
o Add IANA registration for the URI and Application Tags.
Author's Address
Marc Petit-Huguenin
8x8, Inc.
3151 Jay Street
Santa Clara, CA 95054
US
Phone: +1 408 654 0875
Email: marc@8x8.com
Petit-Huguenin Expires January 15, 2009 [Page 8]
Internet-Draft TURN URIs July 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Petit-Huguenin Expires January 15, 2009 [Page 9]
| PAFTECH AB 2003-2026 | 2026-04-23 16:13:15 |