Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)
draft-ietf-tram-turnbis-27
| Document | Type | Active Internet-Draft (tram WG) | |
|---|---|---|---|
| Last updated | 2019-07-11 (latest revision 2019-06-26) | ||
| Stream | IETF | ||
| Intended RFC status | Proposed Standard | ||
| Formats | plain text xml pdf html bibtex | ||
| Reviews | |||
| Stream | WG state | Submitted to IESG for Publication | |
| Document shepherd | Brandon Williams | ||
| Shepherd write-up | Show (last changed 2019-03-01) | ||
| IESG | IESG state | IESG Evaluation::Revised I-D Needed | |
| Consensus Boilerplate | Yes | ||
| Telechat date |
Has 3 DISCUSSes. Has enough positions to pass once DISCUSS positions are resolved. |
||
| Responsible AD | Magnus Westerlund | ||
| Send notices to | Brandon Williams <brandon.williams@akamai.com> | ||
| IANA | IANA review state | IANA OK - Actions Needed | |
| IANA action state | None | ||
TRAM WG T. Reddy, Ed.
Internet-Draft McAfee
Obsoletes: 5766, 6156 (if approved) A. Johnston, Ed.
Intended status: Standards Track Villanova University
Expires: December 29, 2019 P. Matthews
Alcatel-Lucent
J. Rosenberg
jdrosen.net
June 27, 2019
Traversal Using Relays around NAT (TURN): Relay Extensions to Session
Traversal Utilities for NAT (STUN)
draft-ietf-tram-turnbis-27
Abstract
If a host is located behind a NAT, then in certain situations it can
be impossible for that host to communicate directly with other hosts
(peers). In these situations, it is necessary for the host to use
the services of an intermediate node that acts as a communication
relay. This specification defines a protocol, called TURN (Traversal
Using Relays around NAT), that allows the host to control the
operation of the relay and to exchange packets with its peers using
the relay. TURN differs from other relay control protocols in that
it allows a client to communicate with multiple peers using a single
relay address.
The TURN protocol was designed to be used as part of the ICE
(Interactive Connectivity Establishment) approach to NAT traversal,
though it also can be used without ICE.
This document obsoletes RFC 5766 and RFC 6156.
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 https://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."
Reddy, et al. Expires December 29, 2019 [Page 1]
Internet-Draft TURN June 2019
This Internet-Draft will expire on December 29, 2019.
Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://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 . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 8
3.1. Transports . . . . . . . . . . . . . . . . . . . . . . . 11
3.2. Allocations . . . . . . . . . . . . . . . . . . . . . . . 12
3.3. Permissions . . . . . . . . . . . . . . . . . . . . . . . 14
3.4. Send Mechanism . . . . . . . . . . . . . . . . . . . . . 15
3.5. Channels . . . . . . . . . . . . . . . . . . . . . . . . 17
3.6. Unprivileged TURN Servers . . . . . . . . . . . . . . . . 19
3.7. Avoiding IP Fragmentation . . . . . . . . . . . . . . . . 19
3.8. RTP Support . . . . . . . . . . . . . . . . . . . . . . . 21
3.9. Happy Eyeballs for TURN . . . . . . . . . . . . . . . . . 21
4. Discovery of TURN server . . . . . . . . . . . . . . . . . . 22
4.1. TURN URI Scheme Semantics . . . . . . . . . . . . . . . . 22
5. General Behavior . . . . . . . . . . . . . . . . . . . . . . 23
6. Allocations . . . . . . . . . . . . . . . . . . . . . . . . . 25
7. Creating an Allocation . . . . . . . . . . . . . . . . . . . 26
7.1. Sending an Allocate Request . . . . . . . . . . . . . . . 26
7.2. Receiving an Allocate Request . . . . . . . . . . . . . . 28
7.3. Receiving an Allocate Success Response . . . . . . . . . 33
7.4. Receiving an Allocate Error Response . . . . . . . . . . 34
8. Refreshing an Allocation . . . . . . . . . . . . . . . . . . 36
8.1. Sending a Refresh Request . . . . . . . . . . . . . . . . 36
Show full document text