draft-ietf-tram-turnbis-00.txt   draft-ietf-tram-turnbis-01.txt 
TRAM WG T. Reddy, Ed. TRAM WG T. Reddy, Ed.
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Intended status: Standards Track A. Johnston, Ed. Intended status: Standards Track A. Johnston, Ed.
Expires: February 28, 2015 Avaya Expires: August 2, 2015 Avaya
P. Matthews P. Matthews
Alcatel-Lucent Alcatel-Lucent
J. Rosenberg J. Rosenberg
jdrosen.net jdrosen.net
August 27, 2014 January 29, 2015
Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Using Relays around NAT (TURN): Relay Extensions to Session
Traversal Utilities for NAT (STUN) Traversal Utilities for NAT (STUN)
draft-ietf-tram-turnbis-00 draft-ietf-tram-turnbis-01
Abstract Abstract
If a host is located behind a NAT, then in certain situations it can 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 be impossible for that host to communicate directly with other hosts
(peers). In these situations, it is necessary for the host to use (peers). In these situations, it is necessary for the host to use
the services of an intermediate node that acts as a communication the services of an intermediate node that acts as a communication
relay. This specification defines a protocol, called TURN (Traversal relay. This specification defines a protocol, called TURN (Traversal
Using Relays around NAT), that allows the host to control the Using Relays around NAT), that allows the host to control the
operation of the relay and to exchange packets with its peers using operation of the relay and to exchange packets with its peers using
skipping to change at page 1, line 49 skipping to change at page 1, line 49
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 28, 2015. This Internet-Draft will expire on August 2, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Overview of Operation . . . . . . . . . . . . . . . . . . . . 5 2. Overview of Operation . . . . . . . . . . . . . . . . . . . . 5
2.1. Transports . . . . . . . . . . . . . . . . . . . . . . . 8 2.1. Transports . . . . . . . . . . . . . . . . . . . . . . . 8
2.2. Allocations . . . . . . . . . . . . . . . . . . . . . . . 9 2.2. Allocations . . . . . . . . . . . . . . . . . . . . . . . 9
2.3. Permissions . . . . . . . . . . . . . . . . . . . . . . . 11 2.3. Permissions . . . . . . . . . . . . . . . . . . . . . . . 11
2.4. Send Mechanism . . . . . . . . . . . . . . . . . . . . . 12 2.4. Send Mechanism . . . . . . . . . . . . . . . . . . . . . 11
2.5. Channels . . . . . . . . . . . . . . . . . . . . . . . . 14 2.5. Channels . . . . . . . . . . . . . . . . . . . . . . . . 13
2.6. Unprivileged TURN Servers . . . . . . . . . . . . . . . . 16 2.6. Unprivileged TURN Servers . . . . . . . . . . . . . . . . 15
2.7. Avoiding IP Fragmentation . . . . . . . . . . . . . . . . 16 2.7. Avoiding IP Fragmentation . . . . . . . . . . . . . . . . 16
2.8. RTP Support . . . . . . . . . . . . . . . . . . . . . . . 18 2.8. RTP Support . . . . . . . . . . . . . . . . . . . . . . . 17
2.9. Discovery of Servers . . . . . . . . . . . . . . . . . . 18 2.9. Discovery of Servers . . . . . . . . . . . . . . . . . . 17
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 18 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 17
4. General Behavior . . . . . . . . . . . . . . . . . . . . . . 20 4. General Behavior . . . . . . . . . . . . . . . . . . . . . . 19
5. Allocations . . . . . . . . . . . . . . . . . . . . . . . . . 22 5. Allocations . . . . . . . . . . . . . . . . . . . . . . . . . 22
6. Creating an Allocation . . . . . . . . . . . . . . . . . . . 23 6. Creating an Allocation . . . . . . . . . . . . . . . . . . . 23
6.1. Sending an Allocate Request . . . . . . . . . . . . . . . 23 6.1. Sending an Allocate Request . . . . . . . . . . . . . . . 23
6.2. Receiving an Allocate Request . . . . . . . . . . . . . . 25 6.2. Receiving an Allocate Request . . . . . . . . . . . . . . 25
6.3. Receiving an Allocate Success Response . . . . . . . . . 29 6.3. Receiving an Allocate Success Response . . . . . . . . . 29
6.4. Receiving an Allocate Error Response . . . . . . . . . . 30 6.4. Receiving an Allocate Error Response . . . . . . . . . . 30
7. Refreshing an Allocation . . . . . . . . . . . . . . . . . . 32 7. Refreshing an Allocation . . . . . . . . . . . . . . . . . . 32
7.1. Sending a Refresh Request . . . . . . . . . . . . . . . . 32 7.1. Sending a Refresh Request . . . . . . . . . . . . . . . . 32
7.2. Receiving a Refresh Request . . . . . . . . . . . . . . . 32 7.2. Receiving a Refresh Request . . . . . . . . . . . . . . . 33
7.3. Receiving a Refresh Response . . . . . . . . . . . . . . 33 7.3. Receiving a Refresh Response . . . . . . . . . . . . . . 34
8. Permissions . . . . . . . . . . . . . . . . . . . . . . . . . 33 8. Permissions . . . . . . . . . . . . . . . . . . . . . . . . . 34
9. CreatePermission . . . . . . . . . . . . . . . . . . . . . . 34 9. CreatePermission . . . . . . . . . . . . . . . . . . . . . . 35
9.1. Forming a CreatePermission Request . . . . . . . . . . . 35 9.1. Forming a CreatePermission Request . . . . . . . . . . . 35
9.2. Receiving a CreatePermission Request . . . . . . . . . . 35 9.2. Receiving a CreatePermission Request . . . . . . . . . . 36
9.3. Receiving a CreatePermission Response . . . . . . . . . . 36 9.3. Receiving a CreatePermission Response . . . . . . . . . . 36
10. Send and Data Methods . . . . . . . . . . . . . . . . . . . . 36 10. Send and Data Methods . . . . . . . . . . . . . . . . . . . . 36
10.1. Forming a Send Indication . . . . . . . . . . . . . . . 36 10.1. Forming a Send Indication . . . . . . . . . . . . . . . 37
10.2. Receiving a Send Indication . . . . . . . . . . . . . . 36 10.2. Receiving a Send Indication . . . . . . . . . . . . . . 37
10.3. Receiving a UDP Datagram . . . . . . . . . . . . . . . . 37 10.3. Receiving a UDP Datagram . . . . . . . . . . . . . . . . 38
10.4. Receiving a Data Indication . . . . . . . . . . . . . . 38 10.4. Receiving a Data Indication . . . . . . . . . . . . . . 38
11. Channels . . . . . . . . . . . . . . . . . . . . . . . . . . 38 11. Channels . . . . . . . . . . . . . . . . . . . . . . . . . . 39
11.1. Sending a ChannelBind Request . . . . . . . . . . . . . 40 11.1. Sending a ChannelBind Request . . . . . . . . . . . . . 41
11.2. Receiving a ChannelBind Request . . . . . . . . . . . . 40 11.2. Receiving a ChannelBind Request . . . . . . . . . . . . 41
11.3. Receiving a ChannelBind Response . . . . . . . . . . . . 41 11.3. Receiving a ChannelBind Response . . . . . . . . . . . . 42
11.4. The ChannelData Message . . . . . . . . . . . . . . . . 42 11.4. The ChannelData Message . . . . . . . . . . . . . . . . 43
11.5. Sending a ChannelData Message . . . . . . . . . . . . . 42 11.5. Sending a ChannelData Message . . . . . . . . . . . . . 43
11.6. Receiving a ChannelData Message . . . . . . . . . . . . 43 11.6. Receiving a ChannelData Message . . . . . . . . . . . . 44
11.7. Relaying Data from the Peer . . . . . . . . . . . . . . 44 11.7. Relaying Data from the Peer . . . . . . . . . . . . . . 45
12. IP Header Fields . . . . . . . . . . . . . . . . . . . . . . 44 12. Packet Translations . . . . . . . . . . . . . . . . . . . . . 45
13. New STUN Methods . . . . . . . . . . . . . . . . . . . . . . 45 12.1. IPv4-to-IPv6 Translations . . . . . . . . . . . . . . . 45
14. New STUN Attributes . . . . . . . . . . . . . . . . . . . . . 46 12.2. IPv6-to-IPv6 Translations . . . . . . . . . . . . . . . 46
14.1. CHANNEL-NUMBER . . . . . . . . . . . . . . . . . . . . . 46 12.3. IPv6-to-IPv4 Translations . . . . . . . . . . . . . . . 47
14.2. LIFETIME . . . . . . . . . . . . . . . . . . . . . . . . 47 13. IP Header Fields . . . . . . . . . . . . . . . . . . . . . . 48
14.3. XOR-PEER-ADDRESS . . . . . . . . . . . . . . . . . . . . 47 14. New STUN Methods . . . . . . . . . . . . . . . . . . . . . . 50
14.4. DATA . . . . . . . . . . . . . . . . . . . . . . . . . . 47 15. New STUN Attributes . . . . . . . . . . . . . . . . . . . . . 50
14.5. XOR-RELAYED-ADDRESS . . . . . . . . . . . . . . . . . . 47 15.1. CHANNEL-NUMBER . . . . . . . . . . . . . . . . . . . . . 51
14.6. EVEN-PORT . . . . . . . . . . . . . . . . . . . . . . . 47 15.2. LIFETIME . . . . . . . . . . . . . . . . . . . . . . . . 51
14.7. REQUESTED-TRANSPORT . . . . . . . . . . . . . . . . . . 48 15.3. XOR-PEER-ADDRESS . . . . . . . . . . . . . . . . . . . . 51
14.8. DONT-FRAGMENT . . . . . . . . . . . . . . . . . . . . . 48 15.4. DATA . . . . . . . . . . . . . . . . . . . . . . . . . . 51
14.9. RESERVATION-TOKEN . . . . . . . . . . . . . . . . . . . 48 15.5. XOR-RELAYED-ADDRESS . . . . . . . . . . . . . . . . . . 51
15. New STUN Error Response Codes . . . . . . . . . . . . . . . . 49 15.6. REQUESTED-ADDRESS-FAMILY . . . . . . . . . . . . . . . . 52
16. Detailed Example . . . . . . . . . . . . . . . . . . . . . . 49 15.7. EVEN-PORT . . . . . . . . . . . . . . . . . . . . . . . 52
17. Security Considerations . . . . . . . . . . . . . . . . . . . 56 15.8. REQUESTED-TRANSPORT . . . . . . . . . . . . . . . . . . 53
17.1. Outsider Attacks . . . . . . . . . . . . . . . . . . . . 56 15.9. DONT-FRAGMENT . . . . . . . . . . . . . . . . . . . . . 53
17.1.1. Obtaining Unauthorized Allocations . . . . . . . . . 56 15.10. RESERVATION-TOKEN . . . . . . . . . . . . . . . . . . . 53
17.1.2. Offline Dictionary Attacks . . . . . . . . . . . . . 57 15.11. ADDITIONAL-ADDRESS-FAMILY . . . . . . . . . . . . . . . 54
17.1.3. Faked Refreshes and Permissions . . . . . . . . . . 57 15.12. ADDRESS-ERROR-CODE Attribute . . . . . . . . . . . . . . 54
17.1.4. Fake Data . . . . . . . . . . . . . . . . . . . . . 57 16. New STUN Error Response Codes . . . . . . . . . . . . . . . . 55
17.1.5. Impersonating a Server . . . . . . . . . . . . . . . 58 17. Detailed Example . . . . . . . . . . . . . . . . . . . . . . 56
17.1.6. Eavesdropping Traffic . . . . . . . . . . . . . . . 58 18. Security Considerations . . . . . . . . . . . . . . . . . . . 63
17.1.7. TURN Loop Attack . . . . . . . . . . . . . . . . . . 59 18.1. Outsider Attacks . . . . . . . . . . . . . . . . . . . . 63
17.2. Firewall Considerations . . . . . . . . . . . . . . . . 60 18.1.1. Obtaining Unauthorized Allocations . . . . . . . . . 63
17.2.1. Faked Permissions . . . . . . . . . . . . . . . . . 60 18.1.2. Offline Dictionary Attacks . . . . . . . . . . . . . 64
17.2.2. Blacklisted IP Addresses . . . . . . . . . . . . . . 61 18.1.3. Faked Refreshes and Permissions . . . . . . . . . . 64
17.2.3. Running Servers on Well-Known Ports . . . . . . . . 61 18.1.4. Fake Data . . . . . . . . . . . . . . . . . . . . . 64
17.3. Insider Attacks . . . . . . . . . . . . . . . . . . . . 61 18.1.5. Impersonating a Server . . . . . . . . . . . . . . . 65
17.3.1. DoS against TURN Server . . . . . . . . . . . . . . 61 18.1.6. Eavesdropping Traffic . . . . . . . . . . . . . . . 65
17.3.2. Anonymous Relaying of Malicious Traffic . . . . . . 62 18.1.7. TURN Loop Attack . . . . . . . . . . . . . . . . . . 66
17.3.3. Manipulating Other Allocations . . . . . . . . . . . 62 18.2. Firewall Considerations . . . . . . . . . . . . . . . . 67
17.4. Other Considerations . . . . . . . . . . . . . . . . . . 62 18.2.1. Faked Permissions . . . . . . . . . . . . . . . . . 67
18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 62 18.2.2. Blacklisted IP Addresses . . . . . . . . . . . . . . 68
19. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 63 18.2.3. Running Servers on Well-Known Ports . . . . . . . . 68
20. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 64 18.3. Insider Attacks . . . . . . . . . . . . . . . . . . . . 68
21. References . . . . . . . . . . . . . . . . . . . . . . . . . 64 18.3.1. DoS against TURN Server . . . . . . . . . . . . . . 68
21.1. Normative References . . . . . . . . . . . . . . . . . . 65 18.3.2. Anonymous Relaying of Malicious Traffic . . . . . . 69
21.2. Informative References . . . . . . . . . . . . . . . . . 65 18.3.3. Manipulating Other Allocations . . . . . . . . . . . 69
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 67 18.4. Tunnel Amplification Attack . . . . . . . . . . . . . . 69
18.5. Other Considerations . . . . . . . . . . . . . . . . . . 70
19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 70
20. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 71
21. Changes since RFC 5766 . . . . . . . . . . . . . . . . . . . 73
22. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 73
23. References . . . . . . . . . . . . . . . . . . . . . . . . . 73
23.1. Normative References . . . . . . . . . . . . . . . . . . 73
23.2. Informative References . . . . . . . . . . . . . . . . . 74
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 76
1. Introduction 1. Introduction
A host behind a NAT may wish to exchange packets with other hosts, A host behind a NAT may wish to exchange packets with other hosts,
some of which may also be behind NATs. To do this, the hosts some of which may also be behind NATs. To do this, the hosts
involved can use "hole punching" techniques (see [RFC5128]) in an involved can use "hole punching" techniques (see [RFC5128]) in an
attempt discover a direct communication path; that is, a attempt discover a direct communication path; that is, a
communication path that goes from one host to another through communication path that goes from one host to another through
intervening NATs and routers, but does not traverse any relays. intervening NATs and routers, but does not traverse any relays.
skipping to change at page 9, line 12 skipping to change at page 9, line 15
most application data will be doubly encrypted (once by (D)TLS and most application data will be doubly encrypted (once by (D)TLS and
once to ensure it is still encrypted in the UDP datagram). once to ensure it is still encrypted in the UDP datagram).
There is an extension to TURN for TCP transport between the server There is an extension to TURN for TCP transport between the server
and the peers [RFC6062]. For this reason, allocations that use UDP and the peers [RFC6062]. For this reason, allocations that use UDP
between the server and the peers are known as UDP allocations, while between the server and the peers are known as UDP allocations, while
allocations that use TCP between the server and the peers are known allocations that use TCP between the server and the peers are known
as TCP allocations. This specification describes only UDP as TCP allocations. This specification describes only UDP
allocations. allocations.
Editor's Note: Should we merge RFC 6062 text on TCP transport into
this document?
TURN as defined in this specification, only supports IPv4. All IP
addresses in this specification must be IPv4 addresses. TURN usage
for IPv6 and for relaying between IPv4 and IPv6 is defined in
[RFC6156].
Editor's Note: Should we merge RFC 6156 text on IPv6 into this
document?
In some applications for TURN, the client may send and receive In some applications for TURN, the client may send and receive
packets other than TURN packets on the host transport address it uses packets other than TURN packets on the host transport address it uses
to communicate with the server. This can happen, for example, when to communicate with the server. This can happen, for example, when
using TURN with ICE. In these cases, the client can distinguish TURN using TURN with ICE. In these cases, the client can distinguish TURN
packets from other packets by examining the source address of the packets from other packets by examining the source address of the
arriving packet: those arriving from the TURN server will be TURN arriving packet: those arriving from the TURN server will be TURN
packets. packets.
2.2. Allocations 2.2. Allocations
skipping to change at page 21, line 29 skipping to change at page 20, line 46
attribute in all Allocate and Refresh requests and MAY include it in attribute in all Allocate and Refresh requests and MAY include it in
any other requests or indications. The server SHOULD include the any other requests or indications. The server SHOULD include the
SOFTWARE attribute in all Allocate and Refresh responses (either SOFTWARE attribute in all Allocate and Refresh responses (either
success or failure) and MAY include it in other responses or success or failure) and MAY include it in other responses or
indications. The client and the server MAY include the FINGERPRINT indications. The client and the server MAY include the FINGERPRINT
attribute in any STUN-formatted messages defined in this document. attribute in any STUN-formatted messages defined in this document.
TURN does not use the backwards-compatibility mechanism described in TURN does not use the backwards-compatibility mechanism described in
[RFC5389]. [RFC5389].
TURN, as defined in this specification, only supports IPv4. The TURN, as defined in this specification, supports both IPv4 and IPv6.
client's IP address, the server's IP address, and all IP addresses IPv6 support in TURN includes IPv4-to-IPv6, IPv6-to-IPv6, and IPv6-
appearing in a relayed transport address MUST be IPv4 addresses. to-IPv4 relaying. The REQUESTED-ADDRESS-FAMILY attribute allows a
client to explicitly request the address type the TURN server will
allocate (e.g., an IPv4-only node may request the TURN server to
allocate an IPv6 address). The ADDITIONAL-ADDRESS-FAMILY attribute
allows a client to request the server to allocate one IPv4 and one
IPv6 relay address in a single Allocate request. This saves local
ports on the client and reduces the number of messages sent between
the client and the TURN server.
By default, TURN runs on the same ports as STUN: 3478 for TURN over By default, TURN runs on the same ports as STUN: 3478 for TURN over
UDP and TCP, and 5349 for TURN over (D)TLS. However, TURN has its UDP and TCP, and 5349 for TURN over (D)TLS. However, TURN has its
own set of Service Record (SRV) names: "turn" for UDP and TCP, and own set of Service Record (SRV) names: "turn" for UDP and TCP, and
"turns" for (D)TLS. Either the SRV procedures or the ALTERNATE- "turns" for (D)TLS. Either the SRV procedures or the ALTERNATE-
SERVER procedures, both described in Section 6, can be used to run SERVER procedures, both described in Section 6, can be used to run
TURN on a different port. TURN on a different port.
To ensure interoperability, a TURN server MUST support the use of UDP To ensure interoperability, a TURN server MUST support the use of UDP
transport between the client and the server, and SHOULD support the transport between the client and the server, and SHOULD support the
skipping to change at page 24, line 33 skipping to change at page 24, line 8
wants to communicate with the server using UDP, TCP, TLS-over-TCP, or wants to communicate with the server using UDP, TCP, TLS-over-TCP, or
DTLS-over-UDP, respectively. DTLS-over-UDP, respectively.
The client MUST include a REQUESTED-TRANSPORT attribute in the The client MUST include a REQUESTED-TRANSPORT attribute in the
request. This attribute specifies the transport protocol between the request. This attribute specifies the transport protocol between the
server and the peers (note that this is NOT the transport protocol server and the peers (note that this is NOT the transport protocol
that appears in the 5-tuple). In this specification, the REQUESTED- that appears in the 5-tuple). In this specification, the REQUESTED-
TRANSPORT type is always UDP. This attribute is included to allow TRANSPORT type is always UDP. This attribute is included to allow
future extensions to specify other protocols. future extensions to specify other protocols.
If the client wishes to obtain a relayed transport address of a
specific address type then it includes a REQUESTED-ADDRESS-FAMILY
attribute in the request. This attribute indicates the specific
address type the client wishes the TURN server to allocate. Clients
MUST NOT include more than one REQUESTED-ADDRESS-FAMILY attribute in
an Allocate request. Clients MUST NOT include a REQUESTED-ADDRESS-
FAMILY attribute in an Allocate request that contains a RESERVATION-
TOKEN attribute, for the reasons outlined in [RFC6156].
If the client wishes to obtain one IPv6 and one IPv4 relayed
transport addresses then it includes an ADDITIONAL-ADDRESS-FAMILY
attribute in the request. This attribute specifies that the server
must allocate both address types. The attribute value in the
ADDITIONAL-ADDRESS-FAMILY MUST be set to 0x02 (IPv6 address family).
Clients MUST NOT include REQUESTED-ADDRESS-FAMILY and ADDITIONAL-
ADDRESS-FAMILY attributes in the same request. Clients MUST NOT
include ADDITIONAL-ADDRESS-FAMILY attribute in a Allocate request
that contains a RESERVATION-TOKEN attribute.
If the client wishes the server to initialize the time-to-expiry If the client wishes the server to initialize the time-to-expiry
field of the allocation to some value other than the default field of the allocation to some value other than the default
lifetime, then it MAY include a LIFETIME attribute specifying its lifetime, then it MAY include a LIFETIME attribute specifying its
desired value. This is just a request, and the server may elect to desired value. This is just a hint, and the server may elect to use
use a different value. Note that the server will ignore requests to a different value. Note that the server will ignore requests to
initialize the field to less than the default value. initialize the field to less than the default value.
If the client wishes to later use the DONT-FRAGMENT attribute in one If the client wishes to later use the DONT-FRAGMENT attribute in one
or more Send indications on this allocation, then the client SHOULD or more Send indications on this allocation, then the client SHOULD
include the DONT-FRAGMENT attribute in the Allocate request. This include the DONT-FRAGMENT attribute in the Allocate request. This
allows the client to test whether this attribute is supported by the allows the client to test whether this attribute is supported by the
server. server.
If the client requires the port number of the relayed transport If the client requires the port number of the relayed transport
address be even, the client includes the EVEN-PORT attribute. If address be even, the client includes the EVEN-PORT attribute. If
skipping to change at page 25, line 18 skipping to change at page 25, line 13
client MUST omit the EVEN-PORT attribute. client MUST omit the EVEN-PORT attribute.
Once constructed, the client sends the Allocate request on the Once constructed, the client sends the Allocate request on the
5-tuple. 5-tuple.
6.2. Receiving an Allocate Request 6.2. Receiving an Allocate Request
When the server receives an Allocate request, it performs the When the server receives an Allocate request, it performs the
following checks: following checks:
1. The server MUST require that the request be authenticated. This 1. The server MUST require that the request be authenticated. This
authentication MUST be done using the long-term credential authentication MUST be done using the long-term credential
mechanism of [RFC5389] unless the client and server agree to use mechanism of [RFC5389] unless the client and server agree to use
another mechanism through some procedure outside the scope of another mechanism through some procedure outside the scope of
this document. this document.
2. The server checks if the 5-tuple is currently in use by an 2. The server checks if the 5-tuple is currently in use by an
existing allocation. If yes, the server rejects the request with existing allocation. If yes, the server rejects the request
a 437 (Allocation Mismatch) error. with a 437 (Allocation Mismatch) error.
3. The server checks if the request contains a REQUESTED-TRANSPORT 3. The server checks if the request contains a REQUESTED-TRANSPORT
attribute. If the REQUESTED-TRANSPORT attribute is not included attribute. If the REQUESTED-TRANSPORT attribute is not included
or is malformed, the server rejects the request with a 400 (Bad or is malformed, the server rejects the request with a 400 (Bad
Request) error. Otherwise, if the attribute is included but Request) error. Otherwise, if the attribute is included but
specifies a protocol other that UDP, the server rejects the specifies a protocol other that UDP, the server rejects the
request with a 442 (Unsupported Transport Protocol) error. request with a 442 (Unsupported Transport Protocol) error.
4. The request may contain a DONT-FRAGMENT attribute. If it does, 4. The request may contain a DONT-FRAGMENT attribute. If it does,
but the server does not support sending UDP datagrams with the DF but the server does not support sending UDP datagrams with the
bit set to 1 (see Section 12), then the server treats the DONT- DF bit set to 1 (see Section 13), then the server treats the
FRAGMENT attribute in the Allocate request as an unknown DONT-FRAGMENT attribute in the Allocate request as an unknown
comprehension-required attribute. comprehension-required attribute.
5. The server checks if the request contains a RESERVATION-TOKEN 5. The server checks if the request contains a RESERVATION-TOKEN
attribute. If yes, and the request also contains an EVEN-PORT attribute. If yes, and the request also contains an EVEN-PORT
attribute, then the server rejects the request with a 400 (Bad or REQUESTED-ADDRESS-FAMILY or ADDITIONAL-ADDRESS-FAMILY
Request) error. Otherwise, it checks to see if the token is attribute, the server rejects the request with a 400 (Bad
valid (i.e., the token is in range and has not expired and the Request) error. Otherwise, it checks to see if the token is
corresponding relayed transport address is still available). If valid (i.e., the token is in range and has not expired and the
the token is not valid for some reason, the server rejects the corresponding relayed transport address is still available). If
request with a 508 (Insufficient Capacity) error. the token is not valid for some reason, the server rejects the
request with a 508 (Insufficient Capacity) error.
6. The server checks if the request contains an EVEN-PORT attribute. 6. The server checks if the request contains both REQUESTED-
If yes, then the server checks that it can satisfy the request ADDRESS-FAMILY and ADDITIONAL-ADDRESS-FAMILY attributes, then
(i.e., can allocate a relayed transport address as described the server rejects the request with a 400 (Bad Request) error.
below). If the server cannot satisfy the request, then the
server rejects the request with a 508 (Insufficient Capacity)
error.
7. At any point, the server MAY choose to reject the request with a 7. If the server does not support the address family requested by
486 (Allocation Quota Reached) error if it feels the client is the client in REQUESTED-ADDRESS-FAMILY or is disabled by local
trying to exceed some locally defined allocation quota. The policy, it MUST generate an Allocate error response, and it MUST
server is free to define this allocation quota any way it wishes, include an ERROR-CODE attribute with the 440 (Address Family not
but SHOULD define it based on the username used to authenticate Supported) response code. If the REQUESTED-ADDRESS-FAMILY
the request, and not on the client's transport address. attribute is absent, the server MUST allocate an IPv4 relayed
transport address for the TURN client.
8. Also at any point, the server MAY choose to reject the request 8. The server checks if the request contains an ADDITIONAL-ADDRESS-
with a 300 (Try Alternate) error if it wishes to redirect the FAMILY attribute. If yes, and the attribute value is 0x01 (IPv4
client to a different server. The use of this error code and address family), then the server rejects the request with a 400
attribute follow the specification in [RFC5389]. (Bad Request) error. Otherwise, and the server checks if it can
allocate relayed transport addresses of both address types. If
the server cannot satisfy the request, then the server rejects
the request with a 508 (Insufficient Capacity) error. If the
server can partially meet the request, i.e. if it can only
allocate one relayed transport address of a specific address
type, then it includes ADDRESS-ERROR-CODE attribute in the
response to inform the client the reason for partial failure of
the request. The error code value signaled in the ADDRESS-
ERROR-CODE attribute could be 440 (Address Family not Supported)
or 508 (Insufficient Capacity).
9. At any point, the server MAY choose to reject the request with a
486 (Allocation Quota Reached) error if it feels the client is
trying to exceed some locally defined allocation quota. The
server is free to define this allocation quota any way it
wishes, but SHOULD define it based on the username used to
authenticate the request, and not on the client's transport
address.
10. Also at any point, the server MAY choose to reject the request
with a 300 (Try Alternate) error if it wishes to redirect the
client to a different server. The use of this error code and
attribute follow the specification in [RFC5389].
If all the checks pass, the server creates the allocation. The If all the checks pass, the server creates the allocation. The
5-tuple is set to the 5-tuple from the Allocate request, while the 5-tuple is set to the 5-tuple from the Allocate request, while the
list of permissions and the list of channels are initially empty. list of permissions and the list of channels are initially empty.
The server chooses a relayed transport address for the allocation as The server chooses a relayed transport address for the allocation as
follows: follows:
o If the request contains a RESERVATION-TOKEN, the server uses the o If the request contains a RESERVATION-TOKEN attribute, the server
previously reserved transport address corresponding to the uses the previously reserved transport address corresponding to
included token (if it is still available). Note that the the included token (if it is still available). Note that the
reservation is a server-wide reservation and is not specific to a reservation is a server-wide reservation and is not specific to a
particular allocation, since the Allocate request containing the particular allocation, since the Allocate request containing the
RESERVATION-TOKEN uses a different 5-tuple than the Allocate RESERVATION-TOKEN uses a different 5-tuple than the Allocate
request that made the reservation. The 5-tuple for the Allocate request that made the reservation. The 5-tuple for the Allocate
request containing the RESERVATION-TOKEN attribute can be any request containing the RESERVATION-TOKEN attribute can be any
allowed 5-tuple; it can use a different client IP address and allowed 5-tuple; it can use a different client IP address and
port, a different transport protocol, and even different server IP port, a different transport protocol, and even different server IP
address and port (provided, of course, that the server IP address address and port (provided, of course, that the server IP address
and port are ones on which the server is listening for TURN and port are ones on which the server is listening for TURN
requests). requests).
skipping to change at page 27, line 32 skipping to change at page 27, line 49
NOTE: The use of randomized port assignments to avoid certain NOTE: The use of randomized port assignments to avoid certain
types of attacks is described in [RFC6056]. It is RECOMMENDED types of attacks is described in [RFC6056]. It is RECOMMENDED
that a TURN server implement a randomized port assignment that a TURN server implement a randomized port assignment
algorithm from [RFC6056]. This is especially applicable to algorithm from [RFC6056]. This is especially applicable to
servers that choose to pre-allocate a number of ports from the servers that choose to pre-allocate a number of ports from the
underlying OS and then later assign them to allocations; for underlying OS and then later assign them to allocations; for
example, a server may choose this technique to implement the EVEN- example, a server may choose this technique to implement the EVEN-
PORT attribute. PORT attribute.
Editor's Note: Should we recommend a specific algorithm from RFC
6056?
The server determines the initial value of the time-to-expiry field The server determines the initial value of the time-to-expiry field
as follows. If the request contains a LIFETIME attribute, then the as follows. If the request contains a LIFETIME attribute, then the
server computes the minimum of the client's proposed lifetime and the server computes the minimum of the client's proposed lifetime and the
server's maximum allowed lifetime. If this computed value is greater server's maximum allowed lifetime. If this computed value is greater
than the default lifetime, then the server uses the computed lifetime than the default lifetime, then the server uses the computed lifetime
as the initial value of the time-to-expiry field. Otherwise, the as the initial value of the time-to-expiry field. Otherwise, the
server uses the default lifetime. It is RECOMMENDED that the server server uses the default lifetime. It is RECOMMENDED that the server
use a maximum allowed lifetime value of no more than 3600 seconds (1 use a maximum allowed lifetime value of no more than 3600 seconds (1
hour). Servers that implement allocation quotas or charge users for hour). Servers that implement allocation quotas or charge users for
allocations in some way may wish to use a smaller maximum allowed allocations in some way may wish to use a smaller maximum allowed
skipping to change at page 29, line 18 skipping to change at page 29, line 32
Furthermore, if the client later retries with the same 5-tuple but Furthermore, if the client later retries with the same 5-tuple but
different transaction id, it will receive a 437 (Allocation different transaction id, it will receive a 437 (Allocation
Mismatch), which will cause it to retry with a different 5-tuple. Mismatch), which will cause it to retry with a different 5-tuple.
The server may use a smaller maximum lifetime value to minimize The server may use a smaller maximum lifetime value to minimize
the lifetime of allocations "orphaned" in this manner. the lifetime of allocations "orphaned" in this manner.
6.3. Receiving an Allocate Success Response 6.3. Receiving an Allocate Success Response
If the client receives an Allocate success response, then it MUST If the client receives an Allocate success response, then it MUST
check that the mapped address and the relayed transport address are check that the mapped address and the relayed transport address are
in an address family that the client understands and is prepared to part of an address family that the client understands and is prepared
handle. This specification only covers the case where these two to handle. If these two addresses are not part of an address family
addresses are IPv4 addresses. If these two addresses are not in an which the client is prepared to handle, then the client MUST delete
address family which the client is prepared to handle, then the the allocation (Section 7) and MUST NOT attempt to create another
client MUST delete the allocation (Section 7) and MUST NOT attempt to allocation on that server until it believes the mismatch has been
create another allocation on that server until it believes the fixed.
mismatch has been fixed.
The IETF is currently considering mechanisms for transitioning
between IPv4 and IPv6 that could result in a client originating an
Allocate request over IPv6, but the request would arrive at the
server over IPv4, or vice versa.
Editor's Note: This text on IPv6 should be updated.
Otherwise, the client creates its own copy of the allocation data Otherwise, the client creates its own copy of the allocation data
structure to track what is happening on the server. In particular, structure to track what is happening on the server. In particular,
the client needs to remember the actual lifetime received back from the client needs to remember the actual lifetime received back from
the server, rather than the value sent to the server in the request. the server, rather than the value sent to the server in the request.
The client must also remember the 5-tuple used for the request and The client must also remember the 5-tuple used for the request and
the username and password it used to authenticate the request to the username and password it used to authenticate the request to
ensure that it reuses them for subsequent messages. The client also ensure that it reuses them for subsequent messages. The client also
needs to track the channels and permissions it establishes on the needs to track the channels and permissions it establishes on the
server. server.
skipping to change at page 31, line 22 skipping to change at page 31, line 24
failed. The client SHOULD pick another client transport address failed. The client SHOULD pick another client transport address
and retry the Allocate request (using a different transaction id). and retry the Allocate request (using a different transaction id).
The client SHOULD try three different client transport addresses The client SHOULD try three different client transport addresses
before giving up on this server. Once the client gives up on the before giving up on this server. Once the client gives up on the
server, it SHOULD NOT try to create another allocation on the server, it SHOULD NOT try to create another allocation on the
server for 2 minutes. server for 2 minutes.
o 438 (Stale Nonce): See the procedures for the long-term credential o 438 (Stale Nonce): See the procedures for the long-term credential
mechanism [RFC5389]. mechanism [RFC5389].
o 440 (Address Family not Supported): The server does not support
the address family requested by the client. If the client
receives an Allocate error response with the 440 (Unsupported
Address Family) error code, the client MUST NOT retry the request.
o 441 (Wrong Credentials): The client should not receive this error o 441 (Wrong Credentials): The client should not receive this error
in response to a Allocate request. The client MAY notify the user in response to a Allocate request. The client MAY notify the user
or operator and SHOULD NOT retry the same request with this server or operator and SHOULD NOT retry the same request with this server
until it believes the problem has been fixed. until it believes the problem has been fixed.
o 442 (Unsupported Transport Address): The client should not receive o 442 (Unsupported Transport Address): The client should not receive
this error in response to a request for a UDP allocation. The this error in response to a request for a UDP allocation. The
client MAY notify the user or operator and SHOULD NOT reattempt client MAY notify the user or operator and SHOULD NOT reattempt
the request with this server until it believes the problem has the request with this server until it believes the problem has
been fixed. been fixed.
skipping to change at page 32, line 22 skipping to change at page 32, line 27
MUST refresh it before it expires. It is suggested that the client MUST refresh it before it expires. It is suggested that the client
refresh the allocation roughly 1 minute before it expires. If a refresh the allocation roughly 1 minute before it expires. If a
client no longer wishes to use an allocation, then it SHOULD client no longer wishes to use an allocation, then it SHOULD
explicitly delete the allocation. A client MAY refresh an allocation explicitly delete the allocation. A client MAY refresh an allocation
at any time for other reasons. at any time for other reasons.
7.1. Sending a Refresh Request 7.1. Sending a Refresh Request
If the client wishes to immediately delete an existing allocation, it If the client wishes to immediately delete an existing allocation, it
includes a LIFETIME attribute with a value of 0. All other forms of includes a LIFETIME attribute with a value of 0. All other forms of
the request refresh the allocation. the request refresh the allocation. The client MUST NOT include any
REQUESTED-ADDRESS-FAMILY attribute in its Refresh Request.
When refreshing a dual allocation, the client includes ADDITIONAL-
ADDRESS-FAMILY attribute indicating the address family type that
should be refreshed. If no ADDITIONAL-ADDRESS-FAMILY is included
then the request should be treated as applying to all current
allocations. The client MUST only include family types it previously
allocated and has not yet deleted. This process can also be used to
delete an allocation of a specific address type, by setting the
lifetime of that refresh request to 0. Deleting a single allocation
destroys any permissions or channels associated with that particular
allocation; it MUST NOT affect any permissions or channels associated
with allocations for the other address family.
The Refresh transaction updates the time-to-expiry timer of an The Refresh transaction updates the time-to-expiry timer of an
allocation. If the client wishes the server to set the time-to- allocation. If the client wishes the server to set the time-to-
expiry timer to something other than the default lifetime, it expiry timer to something other than the default lifetime, it
includes a LIFETIME attribute with the requested value. The server includes a LIFETIME attribute with the requested value. The server
then computes a new time-to-expiry value in the same way as it does then computes a new time-to-expiry value in the same way as it does
for an Allocate transaction, with the exception that a requested for an Allocate transaction, with the exception that a requested
lifetime of 0 causes the server to immediately delete the allocation. lifetime of 0 causes the server to immediately delete the allocation.
7.2. Receiving a Refresh Request 7.2. Receiving a Refresh Request
When the server receives a Refresh request, it processes as per When the server receives a Refresh request, it processes it as per
Section 4 plus the specific rules mentioned here. Section 4 plus the specific rules mentioned here.
If the server receives a Refresh Request with a REQUESTED-ADDRESS-
FAMILY attribute, and the value of the attribute does not match the
address family of the allocation, the server MUST reply with a 443
(Peer Address Family Mismatch) Refresh error response.
If the server receives a Refresh Request with an ADDITIONAL-ADDRESS-
FAMILY attribute and the attribute value does not match the address
family of the allocation, the server MUST reply with a 443 (Peer
Address Family Mismatch) Refresh error response.
The server computes a value called the "desired lifetime" as follows: The server computes a value called the "desired lifetime" as follows:
if the request contains a LIFETIME attribute and the attribute value if the request contains a LIFETIME attribute and the attribute value
is 0, then the "desired lifetime" is 0. Otherwise, if the request is 0, then the "desired lifetime" is 0. Otherwise, if the request
contains a LIFETIME attribute, then the server computes the minimum contains a LIFETIME attribute, then the server computes the minimum
of the client's requested lifetime and the server's maximum allowed of the client's requested lifetime and the server's maximum allowed
lifetime. If this computed value is greater than the default lifetime. If this computed value is greater than the default
lifetime, then the "desired lifetime" is the computed value. lifetime, then the "desired lifetime" is the computed value.
Otherwise, the "desired lifetime" is the default lifetime. Otherwise, the "desired lifetime" is the default lifetime.
Subsequent processing depends on the "desired lifetime" value: Subsequent processing depends on the "desired lifetime" value:
skipping to change at page 35, line 16 skipping to change at page 35, line 41
The client who wishes to install or refresh one or more permissions The client who wishes to install or refresh one or more permissions
can send a CreatePermission request to the server. can send a CreatePermission request to the server.
When forming a CreatePermission request, the client MUST include at When forming a CreatePermission request, the client MUST include at
least one XOR-PEER-ADDRESS attribute, and MAY include more than one least one XOR-PEER-ADDRESS attribute, and MAY include more than one
such attribute. The IP address portion of each XOR-PEER-ADDRESS such attribute. The IP address portion of each XOR-PEER-ADDRESS
attribute contains the IP address for which a permission should be attribute contains the IP address for which a permission should be
installed or refreshed. The port portion of each XOR-PEER-ADDRESS installed or refreshed. The port portion of each XOR-PEER-ADDRESS
attribute will be ignored and can be any arbitrary value. The attribute will be ignored and can be any arbitrary value. The
various XOR-PEER-ADDRESS attributes can appear in any order. various XOR-PEER-ADDRESS attributes can appear in any order. The
client MUST only include XOR-PEER-ADDRESS attributes with addresses
of the same address family as that of the relayed transport address
for the allocation. For dual allocations obtained using the
ADDITIONAL-FAMILY-ADDRESS attribute, the client can include XOR-PEER-
ADDRESS attributes with addresses of IPv4 and IPv6 address families.
9.2. Receiving a CreatePermission Request 9.2. Receiving a CreatePermission Request
When the server receives the CreatePermission request, it processes When the server receives the CreatePermission request, it processes
as per Section 4 plus the specific rules mentioned here. as per Section 4 plus the specific rules mentioned here.
The message is checked for validity. The CreatePermission request The message is checked for validity. The CreatePermission request
MUST contain at least one XOR-PEER-ADDRESS attribute and MAY contain MUST contain at least one XOR-PEER-ADDRESS attribute and MAY contain
multiple such attributes. If no such attribute exists, or if any of multiple such attributes. If no such attribute exists, or if any of
these attributes are invalid, then a 400 (Bad Request) error is these attributes are invalid, then a 400 (Bad Request) error is
returned. If the request is valid, but the server is unable to returned. If the request is valid, but the server is unable to
satisfy the request due to some capacity limit or similar, then a 508 satisfy the request due to some capacity limit or similar, then a 508
(Insufficient Capacity) error is returned. (Insufficient Capacity) error is returned.
If an XOR-PEER-ADDRESS attribute contains an address of an address
family that is not the same as that of the relayed transport address
for the allocation, the server MUST generate an error response with
the 443 (Peer Address Family Mismatch) response code.
The server MAY impose restrictions on the IP address allowed in the The server MAY impose restrictions on the IP address allowed in the
XOR-PEER-ADDRESS attribute -- if a value is not allowed, the server XOR-PEER-ADDRESS attribute -- if a value is not allowed, the server
rejects the request with a 403 (Forbidden) error. rejects the request with a 403 (Forbidden) error.
If the message is valid and the server is capable of carrying out the If the message is valid and the server is capable of carrying out the
request, then the server installs or refreshes a permission for the request, then the server installs or refreshes a permission for the
IP address contained in each XOR-PEER-ADDRESS attribute as described IP address contained in each XOR-PEER-ADDRESS attribute as described
in Section 8. The port portion of each attribute is ignored and may in Section 8. The port portion of each attribute is ignored and may
be any arbitrary value. be any arbitrary value.
skipping to change at page 37, line 27 skipping to change at page 38, line 16
the allocation, where the allocation is determined by the 5-tuple the allocation, where the allocation is determined by the 5-tuple
on which the Send indication arrived; on which the Send indication arrived;
o the destination transport address is taken from the XOR-PEER- o the destination transport address is taken from the XOR-PEER-
ADDRESS attribute; ADDRESS attribute;
o the data following the UDP header is the contents of the value o the data following the UDP header is the contents of the value
field of the DATA attribute. field of the DATA attribute.
The handling of the DONT-FRAGMENT attribute (if present), is The handling of the DONT-FRAGMENT attribute (if present), is
described in Section 12. described in Section 13.
The resulting UDP datagram is then sent to the peer. The resulting UDP datagram is then sent to the peer.
10.3. Receiving a UDP Datagram 10.3. Receiving a UDP Datagram
When the server receives a UDP datagram at a currently allocated When the server receives a UDP datagram at a currently allocated
relayed transport address, the server looks up the allocation relayed transport address, the server looks up the allocation
associated with the relayed transport address. The server then associated with the relayed transport address. The server then
checks to see whether the set of permissions for the allocation allow checks to see whether the set of permissions for the allocation allow
the relaying of the UDP datagram as described in Section 8. the relaying of the UDP datagram as described in Section 8.
skipping to change at page 40, line 30 skipping to change at page 41, line 19
11.1. Sending a ChannelBind Request 11.1. Sending a ChannelBind Request
A channel binding is created or refreshed using a ChannelBind A channel binding is created or refreshed using a ChannelBind
transaction. A ChannelBind transaction also creates or refreshes a transaction. A ChannelBind transaction also creates or refreshes a
permission towards the peer (see Section 8). permission towards the peer (see Section 8).
To initiate the ChannelBind transaction, the client forms a To initiate the ChannelBind transaction, the client forms a
ChannelBind request. The channel to be bound is specified in a ChannelBind request. The channel to be bound is specified in a
CHANNEL-NUMBER attribute, and the peer's transport address is CHANNEL-NUMBER attribute, and the peer's transport address is
specified in an XOR-PEER-ADDRESS attribute. Section 11.2 describes specified in an XOR-PEER-ADDRESS attribute. Section 11.2 describes
the restrictions on these attributes. the restrictions on these attributes. The client MUST only include
an XOR-PEER-ADDRESS attribute with an address of the same address
family as that of the relayed transport address for the allocation.
For dual allocations obtained using the ADDITIONAL-FAMILY-ADDRESS
attribute, the client can include XOR-PEER-ADDRESS attributes with
addresses of IPv4 and IPv6 address families. When using dual
allocation, the peer addresses of those channels may be of different
families. Thus, a single 5-tuple session may create several IPv4
channels and several IPv6 channels.
Rebinding a channel to the same transport address that it is already Rebinding a channel to the same transport address that it is already
bound to provides a way to refresh a channel binding and the bound to provides a way to refresh a channel binding and the
corresponding permission without sending data to the peer. Note corresponding permission without sending data to the peer. Note
however, that permissions need to be refreshed more frequently than however, that permissions need to be refreshed more frequently than
channels. channels.
11.2. Receiving a ChannelBind Request 11.2. Receiving a ChannelBind Request
When the server receives a ChannelBind request, it processes as per When the server receives a ChannelBind request, it processes as per
skipping to change at page 41, line 8 skipping to change at page 42, line 8
o The channel number is in the range 0x4000 through 0x7FFE o The channel number is in the range 0x4000 through 0x7FFE
(inclusive); (inclusive);
o The channel number is not currently bound to a different transport o The channel number is not currently bound to a different transport
address (same transport address is OK); address (same transport address is OK);
o The transport address is not currently bound to a different o The transport address is not currently bound to a different
channel number. channel number.
o If the XOR-PEER-ADDRESS attribute contains an address of an
address family that is not the same as that of the relayed
transport address for the allocation, the server MUST generate an
error response with the 443 (Peer Address Family Mismatch)
response code.
If any of these tests fail, the server replies with a 400 (Bad If any of these tests fail, the server replies with a 400 (Bad
Request) error. Request) error.
The server MAY impose restrictions on the IP address and port values The server MAY impose restrictions on the IP address and port values
allowed in the XOR-PEER-ADDRESS attribute -- if a value is not allowed in the XOR-PEER-ADDRESS attribute -- if a value is not
allowed, the server rejects the request with a 403 (Forbidden) error. allowed, the server rejects the request with a 403 (Forbidden) error.
If the request is valid, but the server is unable to fulfill the If the request is valid, but the server is unable to fulfill the
request due to some capacity limit or similar, the server replies request due to some capacity limit or similar, the server replies
with a 508 (Insufficient Capacity) error. with a 508 (Insufficient Capacity) error.
skipping to change at page 44, line 14 skipping to change at page 45, line 22
11.7. Relaying Data from the Peer 11.7. Relaying Data from the Peer
When the server receives a UDP datagram on the relayed transport When the server receives a UDP datagram on the relayed transport
address associated with an allocation, the server processes it as address associated with an allocation, the server processes it as
described in Section 10.3. If that section indicates that a described in Section 10.3. If that section indicates that a
ChannelData message should be sent (because there is a channel bound ChannelData message should be sent (because there is a channel bound
to the peer that sent to the UDP datagram), then the server forms and to the peer that sent to the UDP datagram), then the server forms and
sends a ChannelData message as described in Section 11.5. sends a ChannelData message as described in Section 11.5.
12. IP Header Fields 12. Packet Translations
As discussed in Section 2.6, translations in TURN are designed so
that a TURN server can be implemented as an application that runs in
userland under commonly available operating systems and that does not
require special privileges. The translations specified in the
following sections follow this principle.
The descriptions below have two parts: a preferred behavior and an
alternate behavior. The server SHOULD implement the preferred
behavior. Otherwise, the server MUST implement the alternate
behavior and MUST NOT do anything else for the reasons detailed in
[RFC6145].
12.1. IPv4-to-IPv6 Translations
Traffic Class
Preferred behavior: As specified in Section 4 of [RFC6145].
Alternate behavior: The relay sets the Traffic Class to the
default value for outgoing packets.
Flow Label
Preferred behavior: The relay sets the Flow label to 0. The relay
can choose to set the Flow label to a different value if it
supports the IPv6 Flow Label field[RFC3697].
Alternate behavior: the relay sets the Flow label to the default
value for outgoing packets.
Hop Limit
Preferred behavior: As specified in Section 4 of [RFC6145].
Alternate behavior: The relay sets the Hop Limit to the default
value for outgoing packets.
Fragmentation
Preferred behavior: As specified in Section 4 of [RFC6145].
Alternate behavior: The relay assembles incoming fragments. The
relay follows its default behavior to send outgoing packets.
For both preferred and alternate behavior, the DONT-FRAGMENT
attribute MUST be ignored by the server.
Extension Headers
Preferred behavior: The relay sends outgoing packet without any
IPv6 extension headers, with the exception of the Fragmentation
header as described above.
Alternate behavior: Same as preferred.
12.2. IPv6-to-IPv6 Translations
Flow Label
The relay should consider that it is handling two different IPv6
flows. Therefore, the Flow label [RFC3697] SHOULD NOT be copied as
part of the translation.
Preferred behavior: The relay sets the Flow label to 0. The relay
can choose to set the Flow label to a different value if it
supports the IPv6 Flow Label field[RFC3697].
Alternate behavior: The relay sets the Flow label to the default
value for outgoing packets.
Hop Limit
Preferred behavior: The relay acts as a regular router with
respect to decrementing the Hop Limit and generating an ICMPv6
error if it reaches zero.
Alternate behavior: The relay sets the Hop Limit to the default
value for outgoing packets.
Fragmentation
Preferred behavior: If the incoming packet did not include a
Fragment header and the outgoing packet size does not exceed the
outgoing link's MTU, the relay sends the outgoing packet without a
Fragment header.
If the incoming packet did not include a Fragment header and the
outgoing packet size exceeds the outgoing link's MTU, the relay
drops the outgoing packet and send an ICMP message of type 2 code
0 ("Packet too big") to the sender of the incoming packet. If
the packet is being sent to the peer, the relay reduces the MTU
reported in the ICMP message by 48 bytes to allow room for the
overhead of a Data indication.
If the incoming packet included a Fragment header and the outgoing
packet size (with a Fragment header included) does not exceed the
outgoing link's MTU, the relay sends the outgoing packet with a
Fragment header. The relay sets the fields of the Fragment header
as appropriate for a packet originating from the server.
If the incoming packet included a Fragment header and the outgoing
packet size exceeds the outgoing link's MTU, the relay MUST
fragment the outgoing packet into fragments of no more than 1280
bytes. The relay sets the fields of the Fragment header as
appropriate for a packet originating from the server.
Alternate behavior: The relay assembles incoming fragments. The
relay follows its default behavior to send outgoing packets.
For both preferred and alternate behavior, the DONT-FRAGMENT
attribute MUST be ignored by the server.
Extension Headers
Preferred behavior: The relay sends outgoing packet without any
IPv6 extension headers, with the exception of the Fragmentation
header as described above.
Alternate behavior: Same as preferred.
12.3. IPv6-to-IPv4 Translations
Type of Service and Precedence
Preferred behavior: As specified in Section 5 of [RFC6145].
Alternate behavior: The relay sets the Type of Service and
Precedence to the default value for outgoing packets.
Time to Live
Preferred behavior: As specified in Section 5 of [RFC6145].
Alternate behavior: The relay sets the Time to Live to the default
value for outgoing packets.
Fragmentation
Preferred behavior: As specified in Section 5 of [RFC6145].
Additionally, when the outgoing packet's size exceeds the
outgoing link's MTU, the relay needs to generate an ICMP error
(ICMPv6 Packet Too Big) reporting the MTU size. If the packet is
being sent to the peer, the relay SHOULD reduce the MTU reported
in the ICMP message by 48 bytes to allow room for the overhead of
a Data indication.
Alternate behavior: The relay assembles incoming fragments. The
relay follows its default behavior to send outgoing packets.
For both preferred and alternate behavior, the DONT-FRAGMENT
attribute MUST be ignored by the server.
13. IP Header Fields
This section describes how the server sets various fields in the IP This section describes how the server sets various fields in the IP
header when relaying between the client and the peer or vice versa. header when relaying between the client and the peer or vice versa.
The descriptions in this section apply: (a) when the server sends a The descriptions in this section apply: (a) when the server sends a
UDP datagram to the peer, or (b) when the server sends a Data UDP datagram to the peer, or (b) when the server sends a Data
indication or ChannelData message to the client over UDP transport. indication or ChannelData message to the client over UDP transport.
The descriptions in this section do not apply to TURN messages sent The descriptions in this section do not apply to TURN messages sent
over TCP or TLS transport from the server to the client. over TCP or TLS transport from the server to the client.
The descriptions below have two parts: a preferred behavior and an The descriptions below have two parts: a preferred behavior and an
skipping to change at page 45, line 44 skipping to change at page 50, line 16
packet may be too large for the outgoing link. If this is the packet may be too large for the outgoing link. If this is the
case, then the normal fragmentation rules apply [RFC1122]. case, then the normal fragmentation rules apply [RFC1122].
IPv4 Options IPv4 Options
Preferred Behavior: The outgoing packet is sent without any IPv4 Preferred Behavior: The outgoing packet is sent without any IPv4
options. options.
Alternate Behavior: Same as preferred. Alternate Behavior: Same as preferred.
13. New STUN Methods 14. New STUN Methods
This section lists the codepoints for the new STUN methods defined in This section lists the codepoints for the new STUN methods defined in
this specification. See elsewhere in this document for the semantics this specification. See elsewhere in this document for the semantics
of these new methods. of these new methods.
0x003 : Allocate (only request/response semantics defined) 0x003 : Allocate (only request/response semantics defined)
0x004 : Refresh (only request/response semantics defined) 0x004 : Refresh (only request/response semantics defined)
0x006 : Send (only indication semantics defined) 0x006 : Send (only indication semantics defined)
0x007 : Data (only indication semantics defined) 0x007 : Data (only indication semantics defined)
0x008 : CreatePermission (only request/response semantics defined 0x008 : CreatePermission (only request/response semantics defined
0x009 : ChannelBind (only request/response semantics defined) 0x009 : ChannelBind (only request/response semantics defined)
14. New STUN Attributes 15. New STUN Attributes
This STUN extension defines the following new attributes: This STUN extension defines the following new attributes:
0x000C: CHANNEL-NUMBER 0x000C: CHANNEL-NUMBER
0x000D: LIFETIME 0x000D: LIFETIME
0x0010: Reserved (was BANDWIDTH) 0x0010: Reserved (was BANDWIDTH)
0x0012: XOR-PEER-ADDRESS 0x0012: XOR-PEER-ADDRESS
0x0013: DATA 0x0013: DATA
0x0016: XOR-RELAYED-ADDRESS 0x0016: XOR-RELAYED-ADDRESS
0x0017: REQUESTED-ADDRESS-FAMILY
0x0018: EVEN-PORT 0x0018: EVEN-PORT
0x0019: REQUESTED-TRANSPORT 0x0019: REQUESTED-TRANSPORT
0x001A: DONT-FRAGMENT 0x001A: DONT-FRAGMENT
0x0021: Reserved (was TIMER-VAL) 0x0021: Reserved (was TIMER-VAL)
0x0022: RESERVATION-TOKEN 0x0022: RESERVATION-TOKEN
TBD-CA: ADDITIONAL-ADDRESS-FAMILY
TBD-CA: ADDRESS-ERROR-CODE
Some of these attributes have lengths that are not multiples of 4. Some of these attributes have lengths that are not multiples of 4.
By the rules of STUN, any attribute whose length is not a multiple of By the rules of STUN, any attribute whose length is not a multiple of
4 bytes MUST be immediately followed by 1 to 3 padding bytes to 4 bytes MUST be immediately followed by 1 to 3 padding bytes to
ensure the next attribute (if any) would start on a 4-byte boundary ensure the next attribute (if any) would start on a 4-byte boundary
(see [RFC5389]). (see [RFC5389]).
14.1. CHANNEL-NUMBER 15.1. CHANNEL-NUMBER
The CHANNEL-NUMBER attribute contains the number of the channel. The The CHANNEL-NUMBER attribute contains the number of the channel. The
value portion of this attribute is 4 bytes long and consists of a value portion of this attribute is 4 bytes long and consists of a
16-bit unsigned integer, followed by a two-octet RFFU (Reserved For 16-bit unsigned integer, followed by a two-octet RFFU (Reserved For
Future Use) field, which MUST be set to 0 on transmission and MUST be Future Use) field, which MUST be set to 0 on transmission and MUST be
ignored on reception. ignored on reception.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Channel Number | RFFU = 0 | | Channel Number | RFFU = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
14.2. LIFETIME 15.2. LIFETIME
The LIFETIME attribute represents the duration for which the server The LIFETIME attribute represents the duration for which the server
will maintain an allocation in the absence of a refresh. The value will maintain an allocation in the absence of a refresh. The value
portion of this attribute is 4-bytes long and consists of a 32-bit portion of this attribute is 4-bytes long and consists of a 32-bit
unsigned integral value representing the number of seconds remaining unsigned integral value representing the number of seconds remaining
until expiration. until expiration.
14.3. XOR-PEER-ADDRESS 15.3. XOR-PEER-ADDRESS
The XOR-PEER-ADDRESS specifies the address and port of the peer as The XOR-PEER-ADDRESS specifies the address and port of the peer as
seen from the TURN server. (For example, the peer's server-reflexive seen from the TURN server. (For example, the peer's server-reflexive
transport address if the peer is behind a NAT.) It is encoded in the transport address if the peer is behind a NAT.) It is encoded in the
same way as XOR-MAPPED-ADDRESS [RFC5389]. same way as XOR-MAPPED-ADDRESS [RFC5389].
14.4. DATA 15.4. DATA
The DATA attribute is present in all Send and Data indications. The The DATA attribute is present in all Send and Data indications. The
value portion of this attribute is variable length and consists of value portion of this attribute is variable length and consists of
the application data (that is, the data that would immediately follow the application data (that is, the data that would immediately follow
the UDP header if the data was been sent directly between the client the UDP header if the data was been sent directly between the client
and the peer). If the length of this attribute is not a multiple of and the peer). If the length of this attribute is not a multiple of
4, then padding must be added after this attribute. 4, then padding must be added after this attribute.
14.5. XOR-RELAYED-ADDRESS 15.5. XOR-RELAYED-ADDRESS
The XOR-RELAYED-ADDRESS is present in Allocate responses. It The XOR-RELAYED-ADDRESS is present in Allocate responses. It
specifies the address and port that the server allocated to the specifies the address and port that the server allocated to the
client. It is encoded in the same way as XOR-MAPPED-ADDRESS client. It is encoded in the same way as XOR-MAPPED-ADDRESS
[RFC5389]. [RFC5389].
14.6. EVEN-PORT 15.6. REQUESTED-ADDRESS-FAMILY
This attribute is used by clients to request the allocation of a
specific address type from a server. The following is the format of
the REQUESTED-ADDRESS-FAMILY attribute. Note that TURN attributes
are TLV (Type-Length-Value) encoded, with a 16-bit type, a 16-bit
length, and a variable-length value.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Family | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: the type of the REQUESTED-ADDRESS-FAMILY attribute is 0x0017.
As specified in [RFC5389], attributes with values between 0x0000
and 0x7FFF are comprehension-required, which means that the client
or server cannot successfully process the message unless it
understands the attribute.
Length: this 16-bit field contains the length of the attribute in
bytes. The length of this attribute is 4 bytes.
Family: there are two values defined for this field and specified in
[RFC5389], Section 15.1: 0x01 for IPv4 addresses and 0x02 for IPv6
addresses.
Reserved: at this point, the 24 bits in the Reserved field MUST be
set to zero by the client and MUST be ignored by the server.
The REQUEST-ADDRESS-TYPE attribute MAY only be present in Allocate
requests.
15.7. EVEN-PORT
This attribute allows the client to request that the port in the This attribute allows the client to request that the port in the
relayed transport address be even, and (optionally) that the server relayed transport address be even, and (optionally) that the server
reserve the next-higher port number. The value portion of this reserve the next-higher port number. The value portion of this
attribute is 1 byte long. Its format is: attribute is 1 byte long. Its format is:
0 0
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|R| RFFU | |R| RFFU |
skipping to change at page 48, line 15 skipping to change at page 53, line 17
R: If 1, the server is requested to reserve the next-higher port R: If 1, the server is requested to reserve the next-higher port
number (on the same IP address) for a subsequent allocation. If number (on the same IP address) for a subsequent allocation. If
0, no such reservation is requested. 0, no such reservation is requested.
The other 7 bits of the attribute's value must be set to zero on The other 7 bits of the attribute's value must be set to zero on
transmission and ignored on reception. transmission and ignored on reception.
Since the length of this attribute is not a multiple of 4, padding Since the length of this attribute is not a multiple of 4, padding
must immediately follow this attribute. must immediately follow this attribute.
14.7. REQUESTED-TRANSPORT 15.8. REQUESTED-TRANSPORT
This attribute is used by the client to request a specific transport This attribute is used by the client to request a specific transport
protocol for the allocated transport address. The value of this protocol for the allocated transport address. The value of this
attribute is 4 bytes with the following format: attribute is 4 bytes with the following format:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol | RFFU | | Protocol | RFFU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Protocol field specifies the desired protocol. The codepoints The Protocol field specifies the desired protocol. The codepoints
used in this field are taken from those allowed in the Protocol field used in this field are taken from those allowed in the Protocol field
in the IPv4 header and the NextHeader field in the IPv6 header in the IPv4 header and the NextHeader field in the IPv6 header
[Protocol-Numbers]. This specification only allows the use of [Protocol-Numbers]. This specification only allows the use of
codepoint 17 (User Datagram Protocol). codepoint 17 (User Datagram Protocol).
The RFFU field MUST be set to zero on transmission and MUST be The RFFU field MUST be set to zero on transmission and MUST be
ignored on reception. It is reserved for future uses. ignored on reception. It is reserved for future uses.
14.8. DONT-FRAGMENT 15.9. DONT-FRAGMENT
This attribute is used by the client to request that the server set This attribute is used by the client to request that the server set
the DF (Don't Fragment) bit in the IP header when relaying the the DF (Don't Fragment) bit in the IP header when relaying the
application data onward to the peer. This attribute has no value application data onward to the peer. This attribute has no value
part and thus the attribute length field is 0. part and thus the attribute length field is 0.
14.9. RESERVATION-TOKEN 15.10. RESERVATION-TOKEN
The RESERVATION-TOKEN attribute contains a token that uniquely The RESERVATION-TOKEN attribute contains a token that uniquely
identifies a relayed transport address being held in reserve by the identifies a relayed transport address being held in reserve by the
server. The server includes this attribute in a success response to server. The server includes this attribute in a success response to
tell the client about the token, and the client includes this tell the client about the token, and the client includes this
attribute in a subsequent Allocate request to request the server use attribute in a subsequent Allocate request to request the server use
that relayed transport address for the allocation. that relayed transport address for the allocation.
The attribute value is 8 bytes and contains the token value. The attribute value is 8 bytes and contains the token value.
15. New STUN Error Response Codes 15.11. ADDITIONAL-ADDRESS-FAMILY
This attribute is used by clients to request the allocation of a IPv4
and IPv6 address type from a server. The following is the format of
the ADDITIONAL-ADDRESS-FAMILY attribute.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Family | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: the type of the ADDITIONAL-ADDRESS-FAMILY attribute is TBD-CA.
As specified in [RFC5389], attributes with values between 0x8000
and 0xFFFF are comprehension-optional, which means that the client
or server can safely ignore the attribute if they don't understand
it.
Length: this 16-bit field contains the length of the attribute in
bytes. The length of this attribute is 4 bytes.
Family: there are two values defined for this field and specified in
[RFC5389], Section 15.1: 0x01 for IPv4 addresses and 0x02 for IPv6
addresses.
Reserved: at this point, the 24 bits in the Reserved field MUST be
set to zero by the client and MUST be ignored by the server.
The ADDITIONAL-ADDRESS-FAMILY attribute MAY be present in Allocate or
Refresh requests. The attribute value of 0x02 (IPv6 address) is the
only valid value in Allocate request.
15.12. ADDRESS-ERROR-CODE Attribute
This attribute is used by servers to signal the reason for not
allocating the requested address family. The following is the format
of the ADDRESS-ERROR-CODE attribute.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Family | Error code | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: the type of the ADDRESS-ERROR-CODE attribute is TBD-CA. As
specified in [RFC5389], attributes with values between 0x8000 and
0xFFFF are comprehension-optional, which means that the client or
server can safely ignore the attribute if they don't understand
it.
Length: this 16-bit field contains the length of the attribute in
bytes. The length of this attribute is 4 bytes.
Family: there are two values defined for this field and specified in
[RFC5389], Section 15.1: 0x01 for IPv4 addresses and 0x02 for IPv6
addresses.
Error code: this 8-bit field contains the reason server cannot
allocate one of the requested address types. The error code
values could be either 440 (unsupported address family) or 508
(insufficient capacity).
Reserved: at this point, the 16 bits in the Reserved field MUST be
set to zero by the client and MUST be ignored by the server.
The ADDRESS-ERROR-CODE attribute MAY only be present in Allocate
responses.
16. New STUN Error Response Codes
This document defines the following new error response codes: This document defines the following new error response codes:
403 (Forbidden): The request was valid but cannot be performed due 403 (Forbidden): The request was valid but cannot be performed due
to administrative or similar restrictions. to administrative or similar restrictions.
437 (Allocation Mismatch): A request was received by the server that 437 (Allocation Mismatch): A request was received by the server that
requires an allocation to be in place, but no allocation exists, requires an allocation to be in place, but no allocation exists,
or a request was received that requires no allocation, but an or a request was received that requires no allocation, but an
allocation exists. allocation exists.
440 (Address Family not Supported): The server does not support the
address family requested by the client.
441 (Wrong Credentials): The credentials in the (non-Allocate) 441 (Wrong Credentials): The credentials in the (non-Allocate)
request do not match those used to create the allocation. request do not match those used to create the allocation.
442 (Unsupported Transport Protocol): The Allocate request asked the 442 (Unsupported Transport Protocol): The Allocate request asked the
server to use a transport protocol between the server and the peer server to use a transport protocol between the server and the peer
that the server does not support. NOTE: This does NOT refer to that the server does not support. NOTE: This does NOT refer to
the transport protocol used in the 5-tuple. the transport protocol used in the 5-tuple.
443 (Peer Address Family Mismatch). A peer address is part of a
different address family than that of the relayed transport
address of the allocation.
486 (Allocation Quota Reached): No more allocations using this 486 (Allocation Quota Reached): No more allocations using this
username can be created at the present time. username can be created at the present time.
508 (Insufficient Capacity): The server is unable to carry out the 508 (Insufficient Capacity): The server is unable to carry out the
request due to some capacity limit being reached. In an Allocate request due to some capacity limit being reached. In an Allocate
response, this could be due to the server having no more relayed response, this could be due to the server having no more relayed
transport addresses available at that time, having none with the transport addresses available at that time, having none with the
requested properties, or the one that corresponds to the specified requested properties, or the one that corresponds to the specified
reservation token is not available. reservation token is not available.
16. Detailed Example 17. Detailed Example
This section gives an example of the use of TURN, showing in detail This section gives an example of the use of TURN, showing in detail
the contents of the messages exchanged. The example uses the network the contents of the messages exchanged. The example uses the network
diagram shown in the Overview (Figure 1). diagram shown in the Overview (Figure 1).
For each message, the attributes included in the message and their For each message, the attributes included in the message and their
values are shown. For convenience, values are shown in a human- values are shown. For convenience, values are shown in a human-
readable format rather than showing the actual octets; for example, readable format rather than showing the actual octets; for example,
"XOR-RELAYED-ADDRESS=192.0.2.15:9000" shows that the XOR-RELAYED- "XOR-RELAYED-ADDRESS=192.0.2.15:9000" shows that the XOR-RELAYED-
ADDRESS attribute is included with an address of 192.0.2.15 and a ADDRESS attribute is included with an address of 192.0.2.15 and a
skipping to change at page 56, line 11 skipping to change at page 63, line 11
in Allocate and Refresh messages. When the server receives the in Allocate and Refresh messages. When the server receives the
Refresh request, it notices that the nonce value has expired, and so Refresh request, it notices that the nonce value has expired, and so
replies with 438 (Stale Nonce) error given a new nonce value. The replies with 438 (Stale Nonce) error given a new nonce value. The
client then reattempts the request, this time with the new nonce client then reattempts the request, this time with the new nonce
value. This second attempt is accepted, and the server replies with value. This second attempt is accepted, and the server replies with
a success response. Note that the client did not include a LIFETIME a success response. Note that the client did not include a LIFETIME
attribute in the request, so the server refreshes the allocation for attribute in the request, so the server refreshes the allocation for
the default lifetime of 10 minutes (as can be seen by the LIFETIME the default lifetime of 10 minutes (as can be seen by the LIFETIME
attribute in the success response). attribute in the success response).
17. Security Considerations 18. Security Considerations
This section considers attacks that are possible in a TURN This section considers attacks that are possible in a TURN
deployment, and discusses how they are mitigated by mechanisms in the deployment, and discusses how they are mitigated by mechanisms in the
protocol or recommended practices in the implementation. protocol or recommended practices in the implementation.
Most of the attacks on TURN are mitigated by the server requiring Most of the attacks on TURN are mitigated by the server requiring
requests be authenticated. Thus, this specification requires the use requests be authenticated. Thus, this specification requires the use
of authentication. The mandatory-to-implement mechanism is the long- of authentication. The mandatory-to-implement mechanism is the long-
term credential mechanism of STUN. Other authentication mechanisms term credential mechanism of STUN. Other authentication mechanisms
of equal or stronger security properties may be used. However, it is of equal or stronger security properties may be used. However, it is
important to ensure that they can be invoked in an inter-operable important to ensure that they can be invoked in an inter-operable
way. way.
17.1. Outsider Attacks 18.1. Outsider Attacks
Outsider attacks are ones where the attacker has no credentials in Outsider attacks are ones where the attacker has no credentials in
the system, and is attempting to disrupt the service seen by the the system, and is attempting to disrupt the service seen by the
client or the server. client or the server.
17.1.1. Obtaining Unauthorized Allocations 18.1.1. Obtaining Unauthorized Allocations
An attacker might wish to obtain allocations on a TURN server for any An attacker might wish to obtain allocations on a TURN server for any
number of nefarious purposes. A TURN server provides a mechanism for number of nefarious purposes. A TURN server provides a mechanism for
sending and receiving packets while cloaking the actual IP address of sending and receiving packets while cloaking the actual IP address of
the client. This makes TURN servers an attractive target for the client. This makes TURN servers an attractive target for
attackers who wish to use it to mask their true identity. attackers who wish to use it to mask their true identity.
An attacker might also wish to simply utilize the services of a TURN An attacker might also wish to simply utilize the services of a TURN
server without paying for them. Since TURN services require server without paying for them. Since TURN services require
resources from the provider, it is anticipated that their usage will resources from the provider, it is anticipated that their usage will
come with a cost. come with a cost.
These attacks are prevented using the long-term credential mechanism, These attacks are prevented using the long-term credential mechanism,
which allows the TURN server to determine the identity of the which allows the TURN server to determine the identity of the
requestor and whether the requestor is allowed to obtain the requestor and whether the requestor is allowed to obtain the
allocation. allocation.
17.1.2. Offline Dictionary Attacks 18.1.2. Offline Dictionary Attacks
The long-term credential mechanism used by TURN is subject to offline The long-term credential mechanism used by TURN is subject to offline
dictionary attacks. An attacker that is capable of eavesdropping on dictionary attacks. An attacker that is capable of eavesdropping on
a message exchange between a client and server can determine the a message exchange between a client and server can determine the
password by trying a number of candidate passwords and seeing if one password by trying a number of candidate passwords and seeing if one
of them is correct. This attack works when the passwords are low of them is correct. This attack works when the passwords are low
entropy, such as a word from the dictionary. This attack can be entropy, such as a word from the dictionary. This attack can be
mitigated by using strong passwords with large entropy. In mitigated by using strong passwords with large entropy. In
situations where even stronger mitigation is required, (D)TLS situations where even stronger mitigation is required, (D)TLS
transport between the client and the server can be used. transport between the client and the server can be used.
17.1.3. Faked Refreshes and Permissions 18.1.3. Faked Refreshes and Permissions
An attacker might wish to attack an active allocation by sending it a An attacker might wish to attack an active allocation by sending it a
Refresh request with an immediate expiration, in order to delete it Refresh request with an immediate expiration, in order to delete it
and disrupt service to the client. This is prevented by and disrupt service to the client. This is prevented by
authentication of refreshes. Similarly, an attacker wishing to send authentication of refreshes. Similarly, an attacker wishing to send
CreatePermission requests to create permissions to undesirable CreatePermission requests to create permissions to undesirable
destinations is prevented from doing so through authentication. The destinations is prevented from doing so through authentication. The
motivations for such an attack are described in Section 17.2. motivations for such an attack are described in Section 18.2.
17.1.4. Fake Data 18.1.4. Fake Data
An attacker might wish to send data to the client or the peer, as if An attacker might wish to send data to the client or the peer, as if
they came from the peer or client, respectively. To do that, the they came from the peer or client, respectively. To do that, the
attacker can send the client a faked Data Indication or ChannelData attacker can send the client a faked Data Indication or ChannelData
message, or send the TURN server a faked Send Indication or message, or send the TURN server a faked Send Indication or
ChannelData message. ChannelData message.
Since indications and ChannelData messages are not authenticated, Since indications and ChannelData messages are not authenticated,
this attack is not prevented by TURN. However, this attack is this attack is not prevented by TURN. However, this attack is
generally present in IP-based communications and is not substantially generally present in IP-based communications and is not substantially
skipping to change at page 58, line 31 skipping to change at page 65, line 31
To mitigate this attack, TURN requires that the client establish a To mitigate this attack, TURN requires that the client establish a
permission to a host before sending it data. Thus, an attacker can permission to a host before sending it data. Thus, an attacker can
only attack hosts with which the client is already communicating, only attack hosts with which the client is already communicating,
unless the attacker is able to create authenticated requests. unless the attacker is able to create authenticated requests.
Furthermore, the server administrator may configure the server to Furthermore, the server administrator may configure the server to
restrict the range of IP addresses and ports to which it will relay restrict the range of IP addresses and ports to which it will relay
data. To provide even greater security, the server administrator can data. To provide even greater security, the server administrator can
require that the client use (D)TLS for all communication between the require that the client use (D)TLS for all communication between the
client and the server. client and the server.
17.1.5. Impersonating a Server 18.1.5. Impersonating a Server
When a client learns a relayed address from a TURN server, it uses When a client learns a relayed address from a TURN server, it uses
that relayed address in application protocols to receive traffic. that relayed address in application protocols to receive traffic.
Therefore, an attacker wishing to intercept or redirect that traffic Therefore, an attacker wishing to intercept or redirect that traffic
might try to impersonate a TURN server and provide the client with a might try to impersonate a TURN server and provide the client with a
faked relayed address. faked relayed address.
This attack is prevented through the long-term credential mechanism, This attack is prevented through the long-term credential mechanism,
which provides message integrity for responses in addition to which provides message integrity for responses in addition to
verifying that they came from the server. Furthermore, an attacker verifying that they came from the server. Furthermore, an attacker
cannot replay old server responses as the transaction id in the STUN cannot replay old server responses as the transaction id in the STUN
header prevents this. Replay attacks are further thwarted through header prevents this. Replay attacks are further thwarted through
frequent changes to the nonce value. frequent changes to the nonce value.
17.1.6. Eavesdropping Traffic 18.1.6. Eavesdropping Traffic
TURN concerns itself primarily with authentication and message TURN concerns itself primarily with authentication and message
integrity. Confidentiality is only a secondary concern, as TURN integrity. Confidentiality is only a secondary concern, as TURN
control messages do not include information that is particularly control messages do not include information that is particularly
sensitive. The primary protocol content of the messages is the IP sensitive. The primary protocol content of the messages is the IP
address of the peer. If it is important to prevent an eavesdropper address of the peer. If it is important to prevent an eavesdropper
on a TURN connection from learning this, TURN can be run over (D)TLS. on a TURN connection from learning this, TURN can be run over (D)TLS.
Confidentiality for the application data relayed by TURN is best Confidentiality for the application data relayed by TURN is best
provided by the application protocol itself, since running TURN over provided by the application protocol itself, since running TURN over
(D)TLS does not protect application data between the server and the (D)TLS does not protect application data between the server and the
peer. If confidentiality of application data is important, then the peer. If confidentiality of application data is important, then the
application should encrypt or otherwise protect its data. For application should encrypt or otherwise protect its data. For
example, for real-time media, confidentiality can be provided by example, for real-time media, confidentiality can be provided by
using SRTP. using SRTP.
17.1.7. TURN Loop Attack 18.1.7. TURN Loop Attack
An attacker might attempt to cause data packets to loop indefinitely An attacker might attempt to cause data packets to loop indefinitely
between two TURN servers. The attack goes as follows. First, the between two TURN servers. The attack goes as follows. First, the
attacker sends an Allocate request to server A, using the source attacker sends an Allocate request to server A, using the source
address of server B. Server A will send its response to server B, address of server B. Server A will send its response to server B,
and for the attack to succeed, the attacker must have the ability to and for the attack to succeed, the attacker must have the ability to
either view or guess the contents of this response, so that the either view or guess the contents of this response, so that the
attacker can learn the allocated relayed transport address. The attacker can learn the allocated relayed transport address. The
attacker then sends an Allocate request to server B, using the source attacker then sends an Allocate request to server B, using the source
address of server A. Again, the attacker must be able to view or address of server A. Again, the attacker must be able to view or
skipping to change at page 60, line 11 skipping to change at page 67, line 11
the attacker to have credentials acceptable to the server, which the attacker to have credentials acceptable to the server, which
turns this from an outsider attack into an insider attack and allows turns this from an outsider attack into an insider attack and allows
the attack to be traced back to the client initiating it. the attack to be traced back to the client initiating it.
The attack can be further mitigated by imposing a per-username limit The attack can be further mitigated by imposing a per-username limit
on the bandwidth used to relay data by allocations owned by that on the bandwidth used to relay data by allocations owned by that
username, to limit the impact of this attack on other allocations. username, to limit the impact of this attack on other allocations.
More mitigation can be achieved by decrementing the TTL when relaying More mitigation can be achieved by decrementing the TTL when relaying
data packets (if the underlying OS allows this). data packets (if the underlying OS allows this).
17.2. Firewall Considerations 18.2. Firewall Considerations
A key security consideration of TURN is that TURN should not weaken A key security consideration of TURN is that TURN should not weaken
the protections afforded by firewalls deployed between a client and a the protections afforded by firewalls deployed between a client and a
TURN server. It is anticipated that TURN servers will often be TURN server. It is anticipated that TURN servers will often be
present on the public Internet, and clients may often be inside present on the public Internet, and clients may often be inside
enterprise networks with corporate firewalls. If TURN servers enterprise networks with corporate firewalls. If TURN servers
provide a 'backdoor' for reaching into the enterprise, TURN will be provide a 'backdoor' for reaching into the enterprise, TURN will be
blocked by these firewalls. blocked by these firewalls.
TURN servers therefore emulate the behavior of NAT devices that TURN servers therefore emulate the behavior of NAT devices that
skipping to change at page 60, line 40 skipping to change at page 67, line 40
client, unless the client has tried to contact the attacker first. client, unless the client has tried to contact the attacker first.
It is important to note that some firewalls have policies that are It is important to note that some firewalls have policies that are
even more restrictive than address-dependent filtering. Firewalls even more restrictive than address-dependent filtering. Firewalls
can also be configured with address- and port-dependent filtering, or can also be configured with address- and port-dependent filtering, or
can be configured to disallow inbound traffic entirely. In these can be configured to disallow inbound traffic entirely. In these
cases, if a client is allowed to connect the TURN server, cases, if a client is allowed to connect the TURN server,
communications to the client will be less restrictive than what the communications to the client will be less restrictive than what the
firewall would normally allow. firewall would normally allow.
17.2.1. Faked Permissions 18.2.1. Faked Permissions
In firewalls and NAT devices, permissions are granted implicitly In firewalls and NAT devices, permissions are granted implicitly
through the traversal of a packet from the inside of the network through the traversal of a packet from the inside of the network
towards the outside peer. Thus, a permission cannot, by definition, towards the outside peer. Thus, a permission cannot, by definition,
be created by any entity except one inside the firewall or NAT. With be created by any entity except one inside the firewall or NAT. With
TURN, this restriction no longer holds. Since the TURN server sits TURN, this restriction no longer holds. Since the TURN server sits
outside the firewall, at attacker outside the firewall can now send a outside the firewall, at attacker outside the firewall can now send a
message to the TURN server and try to create a permission for itself. message to the TURN server and try to create a permission for itself.
This attack is prevented because all messages that create permissions This attack is prevented because all messages that create permissions
(i.e., ChannelBind and CreatePermission) are authenticated. (i.e., ChannelBind and CreatePermission) are authenticated.
17.2.2. Blacklisted IP Addresses 18.2.2. Blacklisted IP Addresses
Many firewalls can be configured with blacklists that prevent a Many firewalls can be configured with blacklists that prevent a
client behind the firewall from sending packets to, or receiving client behind the firewall from sending packets to, or receiving
packets from, ranges of blacklisted IP addresses. This is packets from, ranges of blacklisted IP addresses. This is
accomplished by inspecting the source and destination addresses of accomplished by inspecting the source and destination addresses of
packets entering and exiting the firewall, respectively. packets entering and exiting the firewall, respectively.
This feature is also present in TURN, since TURN servers are allowed This feature is also present in TURN, since TURN servers are allowed
to arbitrarily restrict the range of addresses of peers that they to arbitrarily restrict the range of addresses of peers that they
will relay to. will relay to.
17.2.3. Running Servers on Well-Known Ports 18.2.3. Running Servers on Well-Known Ports
A malicious client behind a firewall might try to connect to a TURN A malicious client behind a firewall might try to connect to a TURN
server and obtain an allocation which it then uses to run a server. server and obtain an allocation which it then uses to run a server.
For example, a client might try to run a DNS server or FTP server. For example, a client might try to run a DNS server or FTP server.
This is not possible in TURN. A TURN server will never accept This is not possible in TURN. A TURN server will never accept
traffic from a peer for which the client has not installed a traffic from a peer for which the client has not installed a
permission. Thus, peers cannot just connect to the allocated port in permission. Thus, peers cannot just connect to the allocated port in
order to obtain the service. order to obtain the service.
17.3. Insider Attacks 18.3. Insider Attacks
In insider attacks, a client has legitimate credentials but defies In insider attacks, a client has legitimate credentials but defies
the trust relationship that goes with those credentials. These the trust relationship that goes with those credentials. These
attacks cannot be prevented by cryptographic means but need to be attacks cannot be prevented by cryptographic means but need to be
considered in the design of the protocol. considered in the design of the protocol.
17.3.1. DoS against TURN Server 18.3.1. DoS against TURN Server
A client wishing to disrupt service to other clients might obtain an A client wishing to disrupt service to other clients might obtain an
allocation and then flood it with traffic, in an attempt to swamp the allocation and then flood it with traffic, in an attempt to swamp the
server and prevent it from servicing other legitimate clients. This server and prevent it from servicing other legitimate clients. This
is mitigated by the recommendation that the server limit the amount is mitigated by the recommendation that the server limit the amount
of bandwidth it will relay for a given username. This won't prevent of bandwidth it will relay for a given username. This won't prevent
a client from sending a large amount of traffic, but it allows the a client from sending a large amount of traffic, but it allows the
server to immediately discard traffic in excess. server to immediately discard traffic in excess.
Since each allocation uses a port number on the IP address of the Since each allocation uses a port number on the IP address of the
TURN server, the number of allocations on a server is finite. An TURN server, the number of allocations on a server is finite. An
attacker might attempt to consume all of them by requesting a large attacker might attempt to consume all of them by requesting a large
number of allocations. This is prevented by the recommendation that number of allocations. This is prevented by the recommendation that
the server impose a limit of the number of allocations active at a the server impose a limit of the number of allocations active at a
time for a given username. time for a given username.
17.3.2. Anonymous Relaying of Malicious Traffic 18.3.2. Anonymous Relaying of Malicious Traffic
TURN servers provide a degree of anonymization. A client can send TURN servers provide a degree of anonymization. A client can send
data to peers without revealing its own IP address. TURN servers may data to peers without revealing its own IP address. TURN servers may
therefore become attractive vehicles for attackers to launch attacks therefore become attractive vehicles for attackers to launch attacks
against targets without fear of detection. Indeed, it is possible against targets without fear of detection. Indeed, it is possible
for a client to chain together multiple TURN servers, such that any for a client to chain together multiple TURN servers, such that any
number of relays can be used before a target receives a packet. number of relays can be used before a target receives a packet.
Administrators who are worried about this attack can maintain logs Administrators who are worried about this attack can maintain logs
that capture the actual source IP and port of the client, and perhaps that capture the actual source IP and port of the client, and perhaps
even every permission that client installs. This will allow for even every permission that client installs. This will allow for
forensic tracing to determine the original source, should it be forensic tracing to determine the original source, should it be
discovered that an attack is being relayed through a TURN server. discovered that an attack is being relayed through a TURN server.
17.3.3. Manipulating Other Allocations 18.3.3. Manipulating Other Allocations
An attacker might attempt to disrupt service to other users of the An attacker might attempt to disrupt service to other users of the
TURN server by sending Refresh requests or CreatePermission requests TURN server by sending Refresh requests or CreatePermission requests
that (through source address spoofing) appear to be coming from that (through source address spoofing) appear to be coming from
another user of the TURN server. TURN prevents this by requiring another user of the TURN server. TURN prevents this by requiring
that the credentials used in CreatePermission, Refresh, and that the credentials used in CreatePermission, Refresh, and
ChannelBind messages match those used to create the initial ChannelBind messages match those used to create the initial
allocation. Thus, the fake requests from the attacker will be allocation. Thus, the fake requests from the attacker will be
rejected. rejected.
17.4. Other Considerations 18.4. Tunnel Amplification Attack
An attacker might attempt to cause data packets to loop numerous
times between a TURN server and a tunnel between IPv4 and IPv6. The
attack goes as follows.
Suppose an attacker knows that a tunnel endpoint will forward
encapsulated packets from a given IPv6 address (this doesn't
necessarily need to be the tunnel endpoint's address). Suppose he
then spoofs two packets from this address:
1. An Allocate request asking for a v4 address, and
2. A ChannelBind request establishing a channel to the IPv4 address
of the tunnel endpoint
Then he has set up an amplification attack:
o The TURN relay will re-encapsulate IPv6 UDP data in v4 and send it
to the tunnel endpoint
o The tunnel endpoint will de-encapsulate packets from the v4
interface and send them to v6
So if the attacker sends a packet of the following form...
IPv6: src=2001:DB9::1 dst=2001:DB8::2
UDP: <ports>
TURN: <channel id>
IPv6: src=2001:DB9::1 dst=2001:DB8::2
UDP: <ports>
TURN: <channel id>
IPv6: src=2001:DB9::1 dst=2001:DB8::2
UDP: <ports>
TURN: <channel id>
...
Then the TURN relay and the tunnel endpoint will send it back and
forth until the last TURN header is consumed, at which point the TURN
relay will send an empty packet, which the tunnel endpoint will drop.
The amplification potential here is limited by the MTU, so it's not
huge: IPv6+UDP+TURN takes 334 bytes, so a four-to-one amplification
out of a 1500-byte packet is possible. But the attacker could still
increase traffic volume by sending multiple packets or by
establishing multiple channels spoofed from different addresses
behind the same tunnel endpoint.
The attack is mitigated as follows. It is RECOMMENDED that TURN
relays not accept allocation or channel binding requests from
addresses known to be tunneled, and that they not forward data to
such addresses. In particular, a TURN relay MUST NOT accept Teredo
or 6to4 addresses in these requests.
18.5. Other Considerations
Any relay addresses learned through an Allocate request will not Any relay addresses learned through an Allocate request will not
operate properly with IPsec Authentication Header (AH) [RFC4302] in operate properly with IPsec Authentication Header (AH) [RFC4302] in
transport or tunnel mode. However, tunnel-mode IPsec Encapsulating transport or tunnel mode. However, tunnel-mode IPsec Encapsulating
Security Payload (ESP) [RFC4303] should still operate. Security Payload (ESP) [RFC4303] should still operate.
18. IANA Considerations 19. IANA Considerations
Since TURN is an extension to STUN [RFC5389], the methods, Since TURN is an extension to STUN [RFC5389], the methods,
attributes, and error codes defined in this specification are new attributes, and error codes defined in this specification are new
methods, attributes, and error codes for STUN. IANA has added these methods, attributes, and error codes for STUN. IANA has added these
new protocol elements to the IANA registry of STUN protocol elements. new protocol elements to the IANA registry of STUN protocol elements.
The codepoints for the new STUN methods defined in this specification The codepoints for the new STUN methods defined in this specification
are listed in Section 13. are listed in Section 14.
The codepoints for the new STUN attributes defined in this The codepoints for the new STUN attributes defined in this
specification are listed in Section 14. specification are listed in Section 15.
The codepoints for the new STUN error codes defined in this The codepoints for the new STUN error codes defined in this
specification are listed in Section 15. specification are listed in Section 16.
IANA has allocated the SRV service name of "turn" for TURN over UDP IANA has allocated the SRV service name of "turn" for TURN over UDP
or TCP, and the service name of "turns" for TURN over (D)TLS. or TCP, and the service name of "turns" for TURN over (D)TLS.
IANA has created a registry for TURN channel numbers, initially IANA has created a registry for TURN channel numbers, initially
populated as follows: populated as follows:
o 0x0000 through 0x3FFF: Reserved and not available for use, since o 0x0000 through 0x3FFF: Reserved and not available for use, since
they conflict with the STUN header. they conflict with the STUN header.
o 0x4000 through 0x7FFF: A TURN implementation is free to use o 0x4000 through 0x7FFF: A TURN implementation is free to use
channel numbers in this range. channel numbers in this range.
o 0x8000 through 0xFFFF: Unassigned. o 0x8000 through 0xFFFF: Unassigned.
Any change to this registry must be made through an IETF Standards Any change to this registry must be made through an IETF Standards
Action. Action.
19. IAB Considerations [Paragraphs in braces should be removed by the RFC Editor upon
publication]
[The ADDITIONAL-ADDRESS-FAMILY, ADDRESS-ERROR-CODE attributes
requires that IANA allocate a value in the "STUN attributes Registry"
from the comprehension- optional range (0x8000-0xFFFF), to be
replaced for TBD-CA throughout this document]
20. IAB Considerations
The IAB has studied the problem of "Unilateral Self Address Fixing" The IAB has studied the problem of "Unilateral Self Address Fixing"
(UNSAF), which is the general process by which a client attempts to (UNSAF), which is the general process by which a client attempts to
determine its address in another realm on the other side of a NAT determine its address in another realm on the other side of a NAT
through a collaborative protocol-reflection mechanism [RFC3424]. The through a collaborative protocol-reflection mechanism [RFC3424]. The
TURN extension is an example of a protocol that performs this type of TURN extension is an example of a protocol that performs this type of
function. The IAB has mandated that any protocols developed for this function. The IAB has mandated that any protocols developed for this
purpose document a specific set of considerations. These purpose document a specific set of considerations. These
considerations and the responses for TURN are documented in this considerations and the responses for TURN are documented in this
section. section.
skipping to change at page 64, line 40 skipping to change at page 73, line 9
Consideration 5: Discussion of the impact of the noted practical Consideration 5: Discussion of the impact of the noted practical
issues with existing deployed NATs and experience reports. issues with existing deployed NATs and experience reports.
Response: Some NATs deployed today exhibit a mapping behavior other Response: Some NATs deployed today exhibit a mapping behavior other
than Endpoint-Independent mapping. These NATs are difficult to work than Endpoint-Independent mapping. These NATs are difficult to work
with, as they make it difficult or impossible for protocols like ICE with, as they make it difficult or impossible for protocols like ICE
to use server-reflexive transport addresses on those NATs. A client to use server-reflexive transport addresses on those NATs. A client
behind such a NAT is often forced to use a relay protocol like TURN behind such a NAT is often forced to use a relay protocol like TURN
because "UDP hole punching" techniques [RFC5128] do not work. because "UDP hole punching" techniques [RFC5128] do not work.
20. Acknowledgements 21. Changes since RFC 5766
This section lists the major changes in the TURN protocol from the
original [RFC5766] specification.
o IPv6 support.
o REQUESTED-ADDRESS-FAMILY, ADDITIONAL-ADDRESS-FAMILY, AND ADDRESS-
ERRR-CODE attributes.
o 440 (Address Family not Supported) and 443 (Peer Address Family
Mismatch) responses.
o Description of the tunnel amplification attack.
o DTLS support.
o More detail on packet translations.
22. Acknowledgements
Most of the text in this note comes from the original TURN Most of the text in this note comes from the original TURN
specification, [RFC5766]. The authors would like to thank Rohan Mahy specification, [RFC5766]. The authors would like to thank Rohan Mahy
co-author of orginal TURN specification and everyone who had co-author of orginal TURN specification and everyone who had
contributed to that document. contributed to that document.
21. References Thanks to Justin Uberti, Pal Martinsen, Oleg Moskalenko, Aijun Wang
21.1. Normative References and Simon Perreault for their help on SSODA mechanism.
23. References
23.1. Normative References
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389, "Session Traversal Utilities for NAT (STUN)", RFC 5389,
October 2008. October 2008.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS "Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, December Field) in the IPv4 and IPv6 Headers", RFC 2474, December
1998. 1998.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP", RFC of Explicit Congestion Notification (ECN) to IP", RFC
3168, September 2001. 3168, September 2001.
[RFC1122] Braden, R., "Requirements for Internet Hosts - [RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989. Communication Layers", STD 3, RFC 1122, October 1989.
21.2. Informative References [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
Algorithm", RFC 6145, April 2011.
[RFC3697] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering,
"IPv6 Flow Label Specification", RFC 3697, March 2004.
23.2. Informative References
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
November 1990. November 1990.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September
1981. 1981.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets", BCP E. Lear, "Address Allocation for Private Internets", BCP
5, RFC 1918, February 1996. 5, RFC 1918, February 1996.
skipping to change at page 67, line 7 skipping to change at page 75, line 51
June 2002. June 2002.
[I-D.rosenberg-mmusic-ice-nonsip] [I-D.rosenberg-mmusic-ice-nonsip]
Rosenberg, J., "Guidelines for Usage of Interactive Rosenberg, J., "Guidelines for Usage of Interactive
Connectivity Establishment (ICE) by non Session Initiation Connectivity Establishment (ICE) by non Session Initiation
Protocol (SIP) Protocols", draft-rosenberg-mmusic-ice- Protocol (SIP) Protocols", draft-rosenberg-mmusic-ice-
nonsip-01 (work in progress), July 2008. nonsip-01 (work in progress), July 2008.
[I-D.ietf-tram-turn-server-discovery] [I-D.ietf-tram-turn-server-discovery]
Patil, P., Reddy, T., and D. Wing, "TURN Server Auto Patil, P., Reddy, T., and D. Wing, "TURN Server Auto
Discovery", draft-ietf-tram-turn-server-discovery-00 (work Discovery", draft-ietf-tram-turn-server-discovery-01 (work
in progress), July 2014. in progress), January 2015.
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005. Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using
Relays around NAT (TURN): Relay Extensions to Session Relays around NAT (TURN): Relay Extensions to Session
Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. Traversal Utilities for NAT (STUN)", RFC 5766, April 2010.
[Port-Numbers] [Port-Numbers]
"IANA Port Numbers Registry", 2005, "IANA Port Numbers Registry", 2005,
 End of changes. 82 change blocks. 
195 lines changed or deleted 644 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/