RFC 5766 - Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)
Publication Date: April 2010
Status: Standards Track
Authors: R. Mahy (Unaffiliated), P. Matthews (Alcatel-Lucent), J. Rosenberg (jdrosen.net)
Updated by: RFC 8656 (2019)
Abstract
If a host is located behind a NAT, in certain situations, it may 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 some 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 can also be used without ICE.
Table of Contents
- 1. Introduction
- 2. Overview of Operation
- 2.1 Transports
- 2.2 Allocations
- 2.3 Permissions
- 2.4 Send Mechanism
- 2.5 Channels
- 2.6 Unprivileged TURN Servers
- 2.7 Avoiding IP Fragmentation
- 2.8 RTP Support
- 2.9 Anycast Discovery of Servers
- 3. Terminology
- 4. General Behavior
- 5. Allocations
- 6. Creating an Allocation
- 6.1 Sending an Allocate Request
- 6.2 Receiving an Allocate Request
- 6.3 Receiving an Allocate Success Response
- 6.4 Receiving an Allocate Error Response
- 7. Refreshing an Allocation
- 7.1 Sending a Refresh Request
- 7.2 Receiving a Refresh Request
- 7.3 Receiving a Refresh Response
- 8. Permissions
- 9. CreatePermission
- 9.1 Forming a CreatePermission Request
- 9.2 Receiving a CreatePermission Request
- 9.3 Receiving a CreatePermission Response
- 10. Send and Data Methods
- 10.1 Forming a Send Indication
- 10.2 Receiving a Send Indication
- 10.3 Receiving a UDP Datagram
- 10.4 Receiving a Data Indication
- 11. Channels
- 11.1 Sending a ChannelBind Request
- 11.2 Receiving a ChannelBind Request
- 11.3 Receiving a ChannelBind Response
- 11.4 The ChannelData Message
- 11.5 Sending a ChannelData Message
- 11.6 Receiving a ChannelData Message
- 11.7 Relaying Data from the Peer
- 12. IP Header Fields
- 13. New STUN Methods
- 14. New STUN Attributes
- 14.1 CHANNEL-NUMBER
- 14.2 LIFETIME
- 14.3 XOR-PEER-ADDRESS
- 14.4 DATA
- 14.5 XOR-RELAYED-ADDRESS
- 14.6 EVEN-PORT
- 14.7 REQUESTED-TRANSPORT
- 14.8 DONT-FRAGMENT
- 14.9 RESERVATION-TOKEN
- 15. New STUN Error Response Codes
- 16. Detailed Example
- 17. Security Considerations
- 17.1 Outsider Attacks
- 17.2 Firewall Considerations
- 17.3 Insider Attacks
- 17.4 Other Considerations
- 18. IANA Considerations
- 19. IAB Considerations
- 20. Acknowledgements
- 21. References
- 21.1 Normative References
- 21.2 Informative References
Related Resources
- Official RFC: RFC 5766
- Official Page: RFC 5766 DataTracker
- Updated by: RFC 8656
- Errata: RFC Editor Errata