Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)
RFC 8656
Internet Engineering Task Force (IETF) T. Reddy, Ed.
Request for Comments: 8656 McAfee
Obsoletes: 5766, 6156 A. Johnston, Ed.
Category: Standards Track Villanova University
ISSN: 2070-1721 P. Matthews
Alcatel-Lucent
J. Rosenberg
jdrosen.net
February 2020
Traversal Using Relays around NAT (TURN): Relay Extensions to Session
Traversal Utilities for NAT (STUN)
Abstract
If a host is located behind a NAT, it can be impossible for that host
to communicate directly with other hosts (peers) in certain
situations. 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 "Traversal
Using Relays around NAT" (TURN), 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 Interactive
Connectivity Establishment (ICE) approach to NAT traversal, though it
can also be used without ICE.
This document obsoletes RFCs 5766 and 6156.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8656.
Copyright Notice
Copyright (c) 2020 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
2. Terminology
3. Overview of Operation
3.1. Transports
3.2. Allocations
3.3. Permissions
3.4. Send Mechanism
3.5. Channels
3.6. Unprivileged TURN Servers
3.7. Avoiding IP Fragmentation
3.8. RTP Support
3.9. Happy Eyeballs for TURN
4. Discovery of TURN Server
4.1. TURN URI Scheme Semantics
5. General Behavior
6. Allocations
7. Creating an Allocation
7.1. Sending an Allocate Request
7.2. Receiving an Allocate Request
7.3. Receiving an Allocate Success Response
7.4. Receiving an Allocate Error Response
8. Refreshing an Allocation
8.1. Sending a Refresh Request
8.2. Receiving a Refresh Request
8.3. Receiving a Refresh Response
9. Permissions
10. CreatePermission
10.1. Forming a CreatePermission Request
10.2. Receiving a CreatePermission Request
10.3. Receiving a CreatePermission Response
11. Send and Data Methods
11.1. Forming a Send Indication
11.2. Receiving a Send Indication
11.3. Receiving a UDP Datagram
11.4. Receiving a Data Indication
11.5. Receiving an ICMP Packet
11.6. Receiving a Data Indication with an ICMP Attribute
12. Channels
12.1. Sending a ChannelBind Request
12.2. Receiving a ChannelBind Request
12.3. Receiving a ChannelBind Response
12.4. The ChannelData Message
12.5. Sending a ChannelData Message
12.6. Receiving a ChannelData Message
12.7. Relaying Data from the Peer
13. Packet Translations
13.1. IPv4-to-IPv6 Translations
13.2. IPv6-to-IPv6 Translations
13.3. IPv6-to-IPv4 Translations
14. UDP-to-UDP Relay
15. TCP-to-UDP Relay
16. UDP-to-TCP Relay
17. STUN Methods
18. STUN Attributes
18.1. CHANNEL-NUMBER
18.2. LIFETIME
18.3. XOR-PEER-ADDRESS
18.4. DATA
18.5. XOR-RELAYED-ADDRESS
18.6. REQUESTED-ADDRESS-FAMILY
18.7. EVEN-PORT
18.8. REQUESTED-TRANSPORT
Show full document text