One document matched: draft-petithuguenin-behave-turn-uri-00.txt
Network Working Group M. Petit-Huguenin
Internet-Draft 8x8, Inc.
Intended status: Standards Track April 22, 2008
Expires: October 24, 2008
Traversal Using Relays around NAT (TURN) Uniform Resource Identifiers
draft-petithuguenin-behave-turn-uri-00
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 October 24, 2008.
Abstract
This document defines two URIs and the resolution mechanism to
convert these URIs to a list of server transport addresses that can
be used between a TURN client and server.
Petit-Huguenin Expires October 24, 2008 [Page 1]
Internet-Draft TURN URIs April 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. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5
6. Normative References . . . . . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6
Intellectual Property and Copyright Statements . . . . . . . . . . 7
Petit-Huguenin Expires October 24, 2008 [Page 2]
Internet-Draft TURN URIs April 2008
1. Introduction
The TURN [I-D.ietf-behave-turn] specification 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 servers administrator
provision the preferred TURN transport protocol between the client
and the servers 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 client, this document also
defines a TURN and a TURNS URI 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 ":" host [ ":" port ] [ ";transport=" transport ]
scheme = "turn" / "turns"
transport = "udp" / "tcp"
The URI host and port components are specified in [RFC3986].
4. TURN or TURNS URI Resolution
The URI resolution algorithm uses the URI scheme, URI host, URI port
and URI transport components 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, port and transport tuples that a TURN client can
try to contact a TURN server.
First the resolution algorithm checks that the URI can be resolved
with the list of TURN transports supported:
Petit-Huguenin Expires October 24, 2008 [Page 3]
Internet-Draft TURN URIs April 2008
o If the URI scheme component is defined as turn and the URI
transport component is defined as udp but the list of TURN
transports does not contain UDP then the resolution MUST stop with
an error.
o If the URI scheme component is defined as turn and the URI
transport component 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 the URI scheme component is defined as turns and the URI
transport component is defined as udp then the algorithm MUST stop
with an error.
o If the URI scheme component is defined as turns and the URI
transport component is defined as tcp but the list of TURN
transports does not contain TLS then the resolution MUST stop with
an error.
o If the URI scheme component is defined as turns and the URI
transport component 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. The resolution stops
when a TURN client successfully contacts a TURN server.
1. If the URI host component is an IP address then it indicates the
specific IP address to be used. If the URI port component is not
defined, the default port declared in [I-D.ietf-behave-turn] for
the SRV service name defined in the URI scheme component is used.
If the URI transport component is defined then the TURN UDP
transport is used if the URI scheme component is turn and the URI
transport component is udp, the TURN TCP transport is used if the
URI scheme component is turn and the URI transport component is
tcp and the TURN TLS transport is used if the URI scheme
component is turns and the URI transport component is tcp. If
the URI transport component 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 the URI host component is a domain name and the URI port
component is defined, then the URI host component is resolved to
a list of IP addresses via DNS A and AAAA queries. If the URI
transport component is defined then the TURN UDP transport is
used if the URI scheme component is turn and the URI transport
component is udp, the TURN TCP transport is used if the URI
scheme component is turn and the URI transport component is tcp
and the TURN TLS transport is used if the URI scheme component is
turns and the URI transport component is tcp. If the URI
transport component is not defined, the TURN transports supported
by the application are tried by preference order. If the TURN
Petit-Huguenin Expires October 24, 2008 [Page 4]
Internet-Draft TURN URIs April 2008
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 the URI host component is a domain name and the URI port
component is not defined but the URI transport component is
defined then the URI host component 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. The URI scheme component is
used for the service name and the URI transport component 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. If the DNS SRV
query does not return any result, then the URI host component is
converted to a list of IP addresses by using the default port
declared in [I-D.ietf-behave-turn] for the SRV service name
defined in the URI scheme component and step 2 of the resolution
algorithm.
4. If the URI host component is a domain name and the URI port and
transport components are not defined, then the URI host component
is converted to an ordered list of IP address, port and transport
tuples via the S-NAPTR algorithm defined in [RFC3958]. The
Application Service Tag used is RELAY. The TURN transports
supported by the application are tried by preference order by
using the turn.udp Application Protocol Tag if the TURN transport
is UDP, the turn.tcp Application Protocol Tag if the TURN
transport is TCP and the turn.tls Application Protocol Tag if the
TURN transport is TLS. 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 then the resolution MUST
stop with an error. If the first NAPTR SRV query does not return
any result then the URI host component is converted to a list of
IP address and port tuples by trying the TURN transports
supported by the application by preference order and step 3 of
the resolution algorithm.
5. Acknowledgements
Thanks to Eilon Yardeni for his comments on this document.
6. 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
Petit-Huguenin Expires October 24, 2008 [Page 5]
Internet-Draft TURN URIs April 2008
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-07 (work in progress),
February 2008.
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 October 24, 2008 [Page 6]
Internet-Draft TURN URIs April 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 October 24, 2008 [Page 7]
| PAFTECH AB 2003-2026 | 2026-04-23 22:31:24 |