draft-ietf-tram-turnbis-11.txt   draft-ietf-tram-turnbis-12.txt 
TRAM WG T. Reddy, Ed. TRAM WG T. Reddy, Ed.
Internet-Draft McAfee Internet-Draft McAfee
Intended status: Standards Track A. Johnston, Ed. Updates: 5766,6156 (if approved) A. Johnston, Ed.
Expires: December 3, 2017 Unaffiliated Intended status: Standards Track Rowan University
P. Matthews Expires: April 26, 2018 P. Matthews
Alcatel-Lucent Alcatel-Lucent
J. Rosenberg J. Rosenberg
jdrosen.net jdrosen.net
June 1, 2017 October 23, 2017
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-11 draft-ietf-tram-turnbis-12
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
the relay. TURN differs from some other relay control protocols in the relay. TURN differs from some other relay control protocols in
that it allows a client to communicate with multiple peers using a that it allows a client to communicate with multiple peers using a
single relay address. single relay address.
The TURN protocol was designed to be used as part of the ICE The TURN protocol was designed to be used as part of the ICE
(Interactive Connectivity Establishment) approach to NAT traversal, (Interactive Connectivity Establishment) approach to NAT traversal,
though it also can be used without ICE. though it also can be used without ICE.
This document obsoletes [RFC5766] and [RFC6156].
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 https://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 April 26, 2018.
This Internet-Draft will expire on December 3, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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 (https://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
skipping to change at page 2, line 37 skipping to change at page 2, line 38
2.4. Send Mechanism . . . . . . . . . . . . . . . . . . . . . 12 2.4. Send Mechanism . . . . . . . . . . . . . . . . . . . . . 12
2.5. Channels . . . . . . . . . . . . . . . . . . . . . . . . 14 2.5. Channels . . . . . . . . . . . . . . . . . . . . . . . . 14
2.6. Unprivileged TURN Servers . . . . . . . . . . . . . . . . 16 2.6. Unprivileged TURN Servers . . . . . . . . . . . . . . . . 16
2.7. Avoiding IP Fragmentation . . . . . . . . . . . . . . . . 16 2.7. Avoiding IP Fragmentation . . . . . . . . . . . . . . . . 16
2.8. RTP Support . . . . . . . . . . . . . . . . . . . . . . . 18 2.8. RTP Support . . . . . . . . . . . . . . . . . . . . . . . 18
2.9. Discovery of TURN server . . . . . . . . . . . . . . . . 18 2.9. Discovery of TURN server . . . . . . . . . . . . . . . . 18
2.9.1. TURN URI Scheme Semantics . . . . . . . . . . . . . . 18 2.9.1. TURN URI Scheme Semantics . . . . . . . . . . . . . . 18
2.10. Happy Eyeballs for TURN . . . . . . . . . . . . . . . . . 18 2.10. Happy Eyeballs for TURN . . . . . . . . . . . . . . . . . 18
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 19 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 19
4. General Behavior . . . . . . . . . . . . . . . . . . . . . . 21 4. General Behavior . . . . . . . . . . . . . . . . . . . . . . 21
5. Allocations . . . . . . . . . . . . . . . . . . . . . . . . . 23 5. Allocations . . . . . . . . . . . . . . . . . . . . . . . . . 24
6. Creating an Allocation . . . . . . . . . . . . . . . . . . . 25 6. Creating an Allocation . . . . . . . . . . . . . . . . . . . 25
6.1. Sending an Allocate Request . . . . . . . . . . . . . . . 25 6.1. Sending an Allocate Request . . . . . . . . . . . . . . . 25
6.2. Receiving an Allocate Request . . . . . . . . . . . . . . 26 6.2. Receiving an Allocate Request . . . . . . . . . . . . . . 26
6.3. Receiving an Allocate Success Response . . . . . . . . . 31 6.3. Receiving an Allocate Success Response . . . . . . . . . 31
6.4. Receiving an Allocate Error Response . . . . . . . . . . 32 6.4. Receiving an Allocate Error Response . . . . . . . . . . 32
7. Refreshing an Allocation . . . . . . . . . . . . . . . . . . 34 7. Refreshing an Allocation . . . . . . . . . . . . . . . . . . 34
7.1. Sending a Refresh Request . . . . . . . . . . . . . . . . 34 7.1. Sending a Refresh Request . . . . . . . . . . . . . . . . 34
7.2. Receiving a Refresh Request . . . . . . . . . . . . . . . 35 7.2. Receiving a Refresh Request . . . . . . . . . . . . . . . 35
7.3. Receiving a Refresh Response . . . . . . . . . . . . . . 35 7.3. Receiving a Refresh Response . . . . . . . . . . . . . . 36
8. Permissions . . . . . . . . . . . . . . . . . . . . . . . . . 36 8. Permissions . . . . . . . . . . . . . . . . . . . . . . . . . 36
9. CreatePermission . . . . . . . . . . . . . . . . . . . . . . 37 9. CreatePermission . . . . . . . . . . . . . . . . . . . . . . 37
9.1. Forming a CreatePermission Request . . . . . . . . . . . 37 9.1. Forming a CreatePermission Request . . . . . . . . . . . 37
9.2. Receiving a CreatePermission Request . . . . . . . . . . 37 9.2. Receiving a CreatePermission Request . . . . . . . . . . 38
9.3. Receiving a CreatePermission Response . . . . . . . . . . 38 9.3. Receiving a CreatePermission Response . . . . . . . . . . 38
10. Send and Data Methods . . . . . . . . . . . . . . . . . . . . 38 10. Send and Data Methods . . . . . . . . . . . . . . . . . . . . 38
10.1. Forming a Send Indication . . . . . . . . . . . . . . . 38 10.1. Forming a Send Indication . . . . . . . . . . . . . . . 39
10.2. Receiving a Send Indication . . . . . . . . . . . . . . 39 10.2. Receiving a Send Indication . . . . . . . . . . . . . . 39
10.3. Receiving a UDP Datagram . . . . . . . . . . . . . . . . 40 10.3. Receiving a UDP Datagram . . . . . . . . . . . . . . . . 40
10.4. Receiving a Data Indication with DATA attribute . . . . 40 10.4. Receiving a Data Indication with DATA attribute . . . . 40
10.5. Receiving an ICMP Packet . . . . . . . . . . . . . . . . 41 10.5. Receiving an ICMP Packet . . . . . . . . . . . . . . . . 41
10.6. Receiving a Data Indication with an ICMP attribute . . . 41 10.6. Receiving a Data Indication with an ICMP attribute . . . 42
11. Channels . . . . . . . . . . . . . . . . . . . . . . . . . . 42 11. Channels . . . . . . . . . . . . . . . . . . . . . . . . . . 42
11.1. Sending a ChannelBind Request . . . . . . . . . . . . . 44 11.1. Sending a ChannelBind Request . . . . . . . . . . . . . 44
11.2. Receiving a ChannelBind Request . . . . . . . . . . . . 44 11.2. Receiving a ChannelBind Request . . . . . . . . . . . . 44
11.3. Receiving a ChannelBind Response . . . . . . . . . . . . 45 11.3. Receiving a ChannelBind Response . . . . . . . . . . . . 45
11.4. The ChannelData Message . . . . . . . . . . . . . . . . 46 11.4. The ChannelData Message . . . . . . . . . . . . . . . . 46
11.5. Sending a ChannelData Message . . . . . . . . . . . . . 46 11.5. Sending a ChannelData Message . . . . . . . . . . . . . 46
11.6. Receiving a ChannelData Message . . . . . . . . . . . . 47 11.6. Receiving a ChannelData Message . . . . . . . . . . . . 47
11.7. Relaying Data from the Peer . . . . . . . . . . . . . . 48 11.7. Relaying Data from the Peer . . . . . . . . . . . . . . 48
12. Packet Translations . . . . . . . . . . . . . . . . . . . . . 48 12. Packet Translations . . . . . . . . . . . . . . . . . . . . . 48
12.1. IPv4-to-IPv6 Translations . . . . . . . . . . . . . . . 48 12.1. IPv4-to-IPv6 Translations . . . . . . . . . . . . . . . 48
12.2. IPv6-to-IPv6 Translations . . . . . . . . . . . . . . . 49 12.2. IPv6-to-IPv6 Translations . . . . . . . . . . . . . . . 49
12.3. IPv6-to-IPv4 Translations . . . . . . . . . . . . . . . 50 12.3. IPv6-to-IPv4 Translations . . . . . . . . . . . . . . . 51
13. IP Header Fields . . . . . . . . . . . . . . . . . . . . . . 51 13. IP Header Fields . . . . . . . . . . . . . . . . . . . . . . 51
14. New STUN Methods . . . . . . . . . . . . . . . . . . . . . . 53 14. New STUN Methods . . . . . . . . . . . . . . . . . . . . . . 53
15. New STUN Attributes . . . . . . . . . . . . . . . . . . . . . 53 15. New STUN Attributes . . . . . . . . . . . . . . . . . . . . . 53
15.1. CHANNEL-NUMBER . . . . . . . . . . . . . . . . . . . . . 54 15.1. CHANNEL-NUMBER . . . . . . . . . . . . . . . . . . . . . 54
15.2. LIFETIME . . . . . . . . . . . . . . . . . . . . . . . . 54 15.2. LIFETIME . . . . . . . . . . . . . . . . . . . . . . . . 54
15.3. XOR-PEER-ADDRESS . . . . . . . . . . . . . . . . . . . . 54 15.3. XOR-PEER-ADDRESS . . . . . . . . . . . . . . . . . . . . 55
15.4. DATA . . . . . . . . . . . . . . . . . . . . . . . . . . 54 15.4. DATA . . . . . . . . . . . . . . . . . . . . . . . . . . 55
15.5. XOR-RELAYED-ADDRESS . . . . . . . . . . . . . . . . . . 54 15.5. XOR-RELAYED-ADDRESS . . . . . . . . . . . . . . . . . . 55
15.6. REQUESTED-ADDRESS-FAMILY . . . . . . . . . . . . . . . . 55 15.6. REQUESTED-ADDRESS-FAMILY . . . . . . . . . . . . . . . . 55
15.7. EVEN-PORT . . . . . . . . . . . . . . . . . . . . . . . 55 15.7. EVEN-PORT . . . . . . . . . . . . . . . . . . . . . . . 56
15.8. REQUESTED-TRANSPORT . . . . . . . . . . . . . . . . . . 56 15.8. REQUESTED-TRANSPORT . . . . . . . . . . . . . . . . . . 56
15.9. DONT-FRAGMENT . . . . . . . . . . . . . . . . . . . . . 56 15.9. DONT-FRAGMENT . . . . . . . . . . . . . . . . . . . . . 57
15.10. RESERVATION-TOKEN . . . . . . . . . . . . . . . . . . . 56 15.10. RESERVATION-TOKEN . . . . . . . . . . . . . . . . . . . 57
15.11. ADDITIONAL-ADDRESS-FAMILY . . . . . . . . . . . . . . . 57 15.11. ADDITIONAL-ADDRESS-FAMILY . . . . . . . . . . . . . . . 57
15.12. ADDRESS-ERROR-CODE Attribute . . . . . . . . . . . . . . 57 15.12. ADDRESS-ERROR-CODE Attribute . . . . . . . . . . . . . . 57
15.13. ICMP Attribute . . . . . . . . . . . . . . . . . . . . . 58 15.13. ICMP Attribute . . . . . . . . . . . . . . . . . . . . . 58
16. New STUN Error Response Codes . . . . . . . . . . . . . . . . 58 16. New STUN Error Response Codes . . . . . . . . . . . . . . . . 59
17. Detailed Example . . . . . . . . . . . . . . . . . . . . . . 59 17. Detailed Example . . . . . . . . . . . . . . . . . . . . . . 60
18. Security Considerations . . . . . . . . . . . . . . . . . . . 67 18. Security Considerations . . . . . . . . . . . . . . . . . . . 68
18.1. Outsider Attacks . . . . . . . . . . . . . . . . . . . . 67 18.1. Outsider Attacks . . . . . . . . . . . . . . . . . . . . 68
18.1.1. Obtaining Unauthorized Allocations . . . . . . . . . 67 18.1.1. Obtaining Unauthorized Allocations . . . . . . . . . 68
18.1.2. Offline Dictionary Attacks . . . . . . . . . . . . . 67 18.1.2. Offline Dictionary Attacks . . . . . . . . . . . . . 68
18.1.3. Faked Refreshes and Permissions . . . . . . . . . . 68 18.1.3. Faked Refreshes and Permissions . . . . . . . . . . 69
18.1.4. Fake Data . . . . . . . . . . . . . . . . . . . . . 68 18.1.4. Fake Data . . . . . . . . . . . . . . . . . . . . . 69
18.1.5. Impersonating a Server . . . . . . . . . . . . . . . 69 18.1.5. Impersonating a Server . . . . . . . . . . . . . . . 70
18.1.6. Eavesdropping Traffic . . . . . . . . . . . . . . . 69 18.1.6. Eavesdropping Traffic . . . . . . . . . . . . . . . 70
18.1.7. TURN Loop Attack . . . . . . . . . . . . . . . . . . 70 18.1.7. TURN Loop Attack . . . . . . . . . . . . . . . . . . 71
18.2. Firewall Considerations . . . . . . . . . . . . . . . . 70 18.2. Firewall Considerations . . . . . . . . . . . . . . . . 71
18.2.1. Faked Permissions . . . . . . . . . . . . . . . . . 71 18.2.1. Faked Permissions . . . . . . . . . . . . . . . . . 72
18.2.2. Blacklisted IP Addresses . . . . . . . . . . . . . . 71 18.2.2. Blacklisted IP Addresses . . . . . . . . . . . . . . 72
18.2.3. Running Servers on Well-Known Ports . . . . . . . . 72 18.2.3. Running Servers on Well-Known Ports . . . . . . . . 73
18.3. Insider Attacks . . . . . . . . . . . . . . . . . . . . 72 18.3. Insider Attacks . . . . . . . . . . . . . . . . . . . . 73
18.3.1. DoS against TURN Server . . . . . . . . . . . . . . 72 18.3.1. DoS against TURN Server . . . . . . . . . . . . . . 73
18.3.2. Anonymous Relaying of Malicious Traffic . . . . . . 72 18.3.2. Anonymous Relaying of Malicious Traffic . . . . . . 73
18.3.3. Manipulating Other Allocations . . . . . . . . . . . 73 18.3.3. Manipulating Other Allocations . . . . . . . . . . . 74
18.4. Tunnel Amplification Attack . . . . . . . . . . . . . . 73 18.4. Tunnel Amplification Attack . . . . . . . . . . . . . . 74
18.5. Other Considerations . . . . . . . . . . . . . . . . . . 74 18.5. Other Considerations . . . . . . . . . . . . . . . . . . 75
19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 74 19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 75
20. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 75 20. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 76
21. Changes since RFC 5766 . . . . . . . . . . . . . . . . . . . 77 21. Changes since RFC 5766 . . . . . . . . . . . . . . . . . . . 78
22. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 77 22. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 78
23. References . . . . . . . . . . . . . . . . . . . . . . . . . 77 23. References . . . . . . . . . . . . . . . . . . . . . . . . . 78
23.1. Normative References . . . . . . . . . . . . . . . . . . 77 23.1. Normative References . . . . . . . . . . . . . . . . . . 78
23.2. Informative References . . . . . . . . . . . . . . . . . 79 23.2. Informative References . . . . . . . . . . . . . . . . . 80
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 83
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 5, line 46 skipping to change at page 5, line 48
per relayed transport address; a feature not supported by other per relayed transport address; a feature not supported by other
approaches (e.g., SOCKS [RFC1928]). However, care has been taken to approaches (e.g., SOCKS [RFC1928]). However, care has been taken to
make sure that TURN is suitable for other types of applications. make sure that TURN is suitable for other types of applications.
TURN was designed as one piece in the larger ICE approach to NAT TURN was designed as one piece in the larger ICE approach to NAT
traversal. Implementors of TURN are urged to investigate ICE and traversal. Implementors of TURN are urged to investigate ICE and
seriously consider using it for their application. However, it is seriously consider using it for their application. However, it is
possible to use TURN without ICE. possible to use TURN without ICE.
TURN is an extension to the STUN (Session Traversal Utilities for TURN is an extension to the STUN (Session Traversal Utilities for
NAT) protocol [RFC5389]. Most, though not all, TURN messages are NAT) protocol [I-D.ietf-tram-stunbis]. Most, though not all, TURN
STUN-formatted messages. A reader of this document should be messages are STUN-formatted messages. A reader of this document
familiar with STUN. should be familiar with STUN.
2. Overview of Operation 2. Overview of Operation
This section gives an overview of the operation of TURN. It is non- This section gives an overview of the operation of TURN. It is non-
normative. normative.
In a typical configuration, a TURN client is connected to a private In a typical configuration, a TURN client is connected to a private
network [RFC1918] and through one or more NATs to the public network [RFC1918] and through one or more NATs to the public
Internet. On the public Internet is a TURN server. Elsewhere in the Internet. On the public Internet is a TURN server. Elsewhere in the
Internet are one or more peers with which the TURN client wishes to Internet are one or more peers with which the TURN client wishes to
communicate. These peers may or may not be behind one or more NATs. communicate. These peers may or may not be behind one or more NATs.
The client uses the server as a relay to send packets to these peers The client uses the server as a relay to send packets to these peers
and to receive packets from these peers. and to receive packets from these peers.
Peer A Peer A
Server-Reflexive +---------+ Server-Reflexive +---------+
Transport Address | | Transport Address | |
192.0.2.150:32102 | | 192.0.2.150:32102 | |
| /| | | /| |
TURN | / ^| Peer A | TURN | / ^| Peer A |
Client's Server | / || | Client's Server | / || |
Host Transport Transport | // || | Host Transport Transport | // || |
Address Address | // |+---------+ Address Address | // |+---------+
10.1.1.2:49721 192.0.2.15:3478 |+-+ // Peer A 198.51.100.2:49721 192.0.2.15:3478 |+-+ // Peer A
| | ||N| / Host Transport | | ||N| / Host Transport
| +-+ | ||A|/ Address | +-+ | ||A|/ Address
| | | | v|T| 192.168.100.2:49582 | | | | v|T| 203.0.113.2:49582
| | | | /+-+ | | | | /+-+
+---------+| | | |+---------+ / +---------+ +---------+| | | |+---------+ / +---------+
| || |N| || | // | | | || |N| || | // | |
| TURN |v | | v| TURN |/ | | | TURN |v | | v| TURN |/ | |
| Client |----|A|----------| Server |------------------| Peer B | | Client |----|A|----------| Server |------------------| Peer B |
| | | |^ | |^ ^| | | | | |^ | |^ ^| |
| | |T|| | || || | | | |T|| | || || |
+---------+ | || +---------+| |+---------+ +---------+ | || +---------+| |+---------+
| || | | | || | |
| || | | | || | |
+-+| | | +-+| | |
| | | | | |
| | | | | |
Client's | Peer B Client's | Peer B
Server-Reflexive Relayed Transport Server-Reflexive Relayed Transport
Transport Address Transport Address Address Transport Address Transport Address Address
192.0.2.1:7000 192.0.2.15:50000 192.0.2.210:49191 192.0.2.1:7000 192.0.2.15:50000 192.0.2.210:49191
Figure 1 Figure 1
Figure 1 shows a typical deployment. In this figure, the TURN client Figure 1 shows a typical deployment. In this figure, the TURN client
and the TURN server are separated by a NAT, with the client on the and the TURN server are separated by a NAT, with the client on the
private side and the server on the public side of the NAT. This NAT private side and the server on the public side of the NAT. This NAT
is assumed to be a "bad" NAT; for example, it might have a mapping is assumed to be a "bad" NAT; for example, it might have a mapping
property of "address-and-port-dependent mapping" (see [RFC4787]). property of "address-and-port-dependent mapping" (see [RFC4787]).
The client talks to the server from a (IP address, port) combination The client talks to the server from a (IP address, port) combination
skipping to change at page 8, line 4 skipping to change at page 8, line 4
encapsulate this data inside a TURN message and send it to the client encapsulate this data inside a TURN message and send it to the client
along with an indication of which peer sent the data. Since the TURN along with an indication of which peer sent the data. Since the TURN
message always contains an indication of which peer the client is message always contains an indication of which peer the client is
communicating with, the client can use a single allocation to communicating with, the client can use a single allocation to
communicate with multiple peers. communicate with multiple peers.
When the peer is behind a NAT, then the client must identify the peer When the peer is behind a NAT, then the client must identify the peer
using its server-reflexive transport address rather than its host using its server-reflexive transport address rather than its host
transport address. For example, to send application data to Peer A transport address. For example, to send application data to Peer A
in the example above, the client must specify 192.0.2.150:32102 (Peer in the example above, the client must specify 192.0.2.150:32102 (Peer
A's server-reflexive transport address) rather than A's server-reflexive transport address) rather than 203.0.113.2:49582
192.168.100.2:49582 (Peer A's host transport address). (Peer A's host transport address).
Each allocation on the server belongs to a single client and has Each allocation on the server belongs to a single client and has
exactly one relayed transport address that is used only by that exactly one relayed transport address that is used only by that
allocation. Thus, when a packet arrives at a relayed transport allocation. Thus, when a packet arrives at a relayed transport
address on the server, the server knows for which client the data is address on the server, the server knows for which client the data is
intended. intended.
The client may have multiple allocations on a server at the same The client may have multiple allocations on a server at the same
time. time.
skipping to change at page 19, line 44 skipping to change at page 19, line 44
and HelloVerifyRequest is received from the TURN servers on both and HelloVerifyRequest is received from the TURN servers on both
IP addresses families then the client can silently abandon the IP addresses families then the client can silently abandon the
connection on the IP address family with lower precedence. connection on the IP address family with lower precedence.
3. Terminology 3. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Readers are expected to be familiar with [RFC5389] and the terms Readers are expected to be familiar with [I-D.ietf-tram-stunbis] and
defined there. the terms defined there.
The following terms are used in this document: The following terms are used in this document:
TURN: The protocol spoken between a TURN client and a TURN server. TURN: The protocol spoken between a TURN client and a TURN server.
It is an extension to the STUN protocol [RFC5389]. The protocol It is an extension to the STUN protocol [I-D.ietf-tram-stunbis].
allows a client to allocate and use a relayed transport address.
The protocol allows a client to allocate and use a relayed
transport address.
TURN client: A STUN client that implements this specification. TURN client: A STUN client that implements this specification.
TURN server: A STUN server that implements this specification. It TURN server: A STUN server that implements this specification. It
relays data between a TURN client and its peer(s). relays data between a TURN client and its peer(s).
Peer: A host with which the TURN client wishes to communicate. The Peer: A host with which the TURN client wishes to communicate. The
TURN server relays traffic between the TURN client and its TURN server relays traffic between the TURN client and its
peer(s). The peer does not interact with the TURN server using peer(s). The peer does not interact with the TURN server using
the protocol defined in this document; rather, the peer receives the protocol defined in this document; rather, the peer receives
skipping to change at page 21, line 28 skipping to change at page 21, line 31
message-digest. To prevent reply attacks, the server should message-digest. To prevent reply attacks, the server should
change the nonce regularly. change the nonce regularly.
4. General Behavior 4. General Behavior
This section contains general TURN processing rules that apply to all This section contains general TURN processing rules that apply to all
TURN messages. TURN messages.
TURN is an extension to STUN. All TURN messages, with the exception TURN is an extension to STUN. All TURN messages, with the exception
of the ChannelData message, are STUN-formatted messages. All the of the ChannelData message, are STUN-formatted messages. All the
base processing rules described in [RFC5389] apply to STUN-formatted base processing rules described in [I-D.ietf-tram-stunbis] apply to
messages. This means that all the message-forming and message- STUN-formatted messages. This means that all the message-forming and
processing descriptions in this document are implicitly prefixed with message-processing descriptions in this document are implicitly
the rules of [RFC5389]. prefixed with the rules of [I-D.ietf-tram-stunbis].
[RFC5389] specifies an authentication mechanism called the long-term [I-D.ietf-tram-stunbis] specifies an authentication mechanism called
credential mechanism. TURN servers and clients MUST implement this the long-term credential mechanism. TURN servers and clients MUST
mechanism. The server MUST demand that all requests from the client implement this mechanism. The server MUST demand that all requests
be authenticated using this mechanism, or that a equally strong or from the client be authenticated using this mechanism, or that a
stronger mechanism for client authentication is used. equally strong or stronger mechanism for client authentication is
used.
Note that the long-term credential mechanism applies only to requests Note that the long-term credential mechanism applies only to requests
and cannot be used to authenticate indications; thus, indications in and cannot be used to authenticate indications; thus, indications in
TURN are never authenticated. If the server requires requests to be TURN are never authenticated. If the server requires requests to be
authenticated, then the server's administrator MUST choose a realm authenticated, then the server's administrator MUST choose a realm
value that will uniquely identify the username and password value that will uniquely identify the username and password
combination that the client must use, even if the client uses combination that the client must use, even if the client uses
multiple servers under different administrations. The server's multiple servers under different administrations. The server's
administrator MAY choose to allocate a unique username to each administrator MAY choose to allocate a unique username to each
client, or MAY choose to allocate the same username to more than one client, or MAY choose to allocate the same username to more than one
skipping to change at page 22, line 26 skipping to change at page 22, line 28
When a TURN message arrives at the server from the client, the server When a TURN message arrives at the server from the client, the server
uses the 5-tuple in the message to identify the associated uses the 5-tuple in the message to identify the associated
allocation. For all TURN messages (including ChannelData) EXCEPT an allocation. For all TURN messages (including ChannelData) EXCEPT an
Allocate request, if the 5-tuple does not identify an existing Allocate request, if the 5-tuple does not identify an existing
allocation, then the message MUST either be rejected with a 437 allocation, then the message MUST either be rejected with a 437
Allocation Mismatch error (if it is a request) or silently ignored Allocation Mismatch error (if it is a request) or silently ignored
(if it is an indication or a ChannelData message). A client (if it is an indication or a ChannelData message). A client
receiving a 437 error response to a request other than Allocate MUST receiving a 437 error response to a request other than Allocate MUST
assume the allocation no longer exists. assume the allocation no longer exists.
[RFC5389] defines a number of attributes, including the SOFTWARE and [I-D.ietf-tram-stunbis] defines a number of attributes, including the
FINGERPRINT attributes. The client SHOULD include the SOFTWARE SOFTWARE and FINGERPRINT attributes. The client SHOULD include the
attribute in all Allocate and Refresh requests and MAY include it in SOFTWARE attribute in all Allocate and Refresh requests and MAY
any other requests or indications. The server SHOULD include the include it in any other requests or indications. The server SHOULD
SOFTWARE attribute in all Allocate and Refresh responses (either include the SOFTWARE attribute in all Allocate and Refresh responses
success or failure) and MAY include it in other responses or (either 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]. [I-D.ietf-tram-stunbis].
TURN, as defined in this specification, supports both IPv4 and IPv6. TURN, as defined in this specification, supports both IPv4 and IPv6.
IPv6 support in TURN includes IPv4-to-IPv6, IPv6-to-IPv6, and IPv6- IPv6 support in TURN includes IPv4-to-IPv6, IPv6-to-IPv6, and IPv6-
to-IPv4 relaying. The REQUESTED-ADDRESS-FAMILY attribute allows a to-IPv4 relaying. The REQUESTED-ADDRESS-FAMILY attribute allows a
client to explicitly request the address type the TURN server will 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 (e.g., an IPv4-only node may request the TURN server to
allocate an IPv6 address). The ADDITIONAL-ADDRESS-FAMILY attribute allocate an IPv6 address). The ADDITIONAL-ADDRESS-FAMILY attribute
allows a client to request the server to allocate one IPv4 and one allows a client to request the server to allocate one IPv4 and one
IPv6 relay address in a single Allocate request. This saves local IPv6 relay address in a single Allocate request. This saves local
ports on the client and reduces the number of messages sent between ports on the client and reduces the number of messages sent between
skipping to change at page 23, line 17 skipping to change at page 23, line 21
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
use of TCP and (D)TLS transport. use of TCP and (D)TLS transport.
When UDP transport is used between the client and the server, the When UDP transport is used between the client and the server, the
client will retransmit a request if it does not receive a response client will retransmit a request if it does not receive a response
within a certain timeout period. Because of this, the server may within a certain timeout period. Because of this, the server may
receive two (or more) requests with the same 5-tuple and same receive two (or more) requests with the same 5-tuple and same
transaction id. STUN requires that the server recognize this case transaction id. STUN requires that the server recognize this case
and treat the request as idempotent (see [RFC5389]). Some and treat the request as idempotent (see [I-D.ietf-tram-stunbis]).
implementations may choose to meet this requirement by remembering Some implementations may choose to meet this requirement by
all received requests and the corresponding responses for 40 seconds. remembering all received requests and the corresponding responses for
Other implementations may choose to reprocess the request and arrange 40 seconds. Other implementations may choose to reprocess the
that such reprocessing returns essentially the same response. To aid request and arrange that such reprocessing returns essentially the
implementors who choose the latter approach (the so-called "stateless same response. To aid implementors who choose the latter approach
stack approach"), this specification includes some implementation (the so-called "stateless stack approach"), this specification
notes on how this might be done. Implementations are free to choose includes some implementation notes on how this might be done.
either approach or choose some other approach that gives the same Implementations are free to choose either approach or choose some
results. other approach that gives the same results.
When TCP transport is used between the client and the server, it is When TCP transport is used between the client and the server, it is
possible that a bit error will cause a length field in a TURN packet possible that a bit error will cause a length field in a TURN packet
to become corrupted, causing the receiver to lose synchronization to become corrupted, causing the receiver to lose synchronization
with the incoming stream of TURN messages. A client or server that with the incoming stream of TURN messages. A client or server that
detects a long sequence of invalid TURN messages over TCP transport detects a long sequence of invalid TURN messages over TCP transport
SHOULD close the corresponding TCP connection to help the other end SHOULD close the corresponding TCP connection to help the other end
detect this situation more rapidly. detect this situation more rapidly.
To mitigate either intentional or unintentional denial-of-service To mitigate either intentional or unintentional denial-of-service
skipping to change at page 23, line 49 skipping to change at page 24, line 8
the number of allocations active at one time for a given username and the number of allocations active at one time for a given username and
on the amount of bandwidth those allocations can use. The server on the amount of bandwidth those allocations can use. The server
should reject new allocations that would exceed the limit on the should reject new allocations that would exceed the limit on the
allowed number of allocations active at one time with a 486 allowed number of allocations active at one time with a 486
(Allocation Quota Exceeded) (see Section 6.2), and should discard (Allocation Quota Exceeded) (see Section 6.2), and should discard
application data traffic that exceeds the bandwidth quota. application data traffic that exceeds the bandwidth quota.
5. Allocations 5. Allocations
All TURN operations revolve around allocations, and all TURN messages All TURN operations revolve around allocations, and all TURN messages
are associated with an allocation. An allocation conceptually are associated with either a single or dual allocation. An
consists of the following state data: allocation conceptually consists of the following state data:
o the relayed transport address; o the relayed transport address or addresses;
o the 5-tuple: (client's IP address, client's port, server IP o the 5-tuple: (client's IP address, client's port, server IP
address, server port, transport protocol); address, server port, transport protocol);
o the authentication information; o the authentication information;
o the time-to-expiry; o the time-to-expiry for each relayed transport address;
o a list of permissions; o a list of permissions for each relayed transport address;
o a list of channel to peer bindings. o a list of channel to peer bindings for each relayed transport
address.
The relayed transport address is the transport address allocated by The relayed transport address is the transport address allocated by
the server for communicating with peers, while the 5-tuple describes the server for communicating with peers, while the 5-tuple describes
the communication path between the client and the server. On the the communication path between the client and the server. On the
client, the 5-tuple uses the client's host transport address; on the client, the 5-tuple uses the client's host transport address; on the
server, the 5-tuple uses the client's server-reflexive transport server, the 5-tuple uses the client's server-reflexive transport
address. address. The relayed transport address MUST be unique across all
allocations, so it can be used to uniquely identify the allocation.
Both the relayed transport address and the 5-tuple MUST be unique
across all allocations, so either one can be used to uniquely
identify the allocation.
The authentication information (e.g., username, password, realm, and The authentication information (e.g., username, password, realm, and
nonce) is used to both verify subsequent requests and to compute the nonce) is used to both verify subsequent requests and to compute the
message integrity of responses. The username, realm, and nonce message integrity of responses. The username, realm, and nonce
values are initially those used in the authenticated Allocate request values are initially those used in the authenticated Allocate request
that creates the allocation, though the server can change the nonce that creates the allocation, though the server can change the nonce
value during the lifetime of the allocation using a 438 (Stale Nonce) value during the lifetime of the allocation using a 438 (Stale Nonce)
reply. Note that, rather than storing the password explicitly, for reply. Note that, rather than storing the password explicitly, for
security reasons, it may be desirable for the server to store the key security reasons, it may be desirable for the server to store the key
value, which is an secure hash over the username, realm, and password value, which is an secure hash over the username, realm, and password
skipping to change at page 26, line 11 skipping to change at page 26, line 15
If the client wishes to obtain one IPv6 and one IPv4 relayed If the client wishes to obtain one IPv6 and one IPv4 relayed
transport addresses then it includes an ADDITIONAL-ADDRESS-FAMILY transport addresses then it includes an ADDITIONAL-ADDRESS-FAMILY
attribute in the request. This attribute specifies that the server attribute in the request. This attribute specifies that the server
must allocate both address types. The attribute value in the must allocate both address types. The attribute value in the
ADDITIONAL-ADDRESS-FAMILY MUST be set to 0x02 (IPv6 address family). ADDITIONAL-ADDRESS-FAMILY MUST be set to 0x02 (IPv6 address family).
Clients MUST NOT include REQUESTED-ADDRESS-FAMILY and ADDITIONAL- Clients MUST NOT include REQUESTED-ADDRESS-FAMILY and ADDITIONAL-
ADDRESS-FAMILY attributes in the same request. Clients MUST NOT ADDRESS-FAMILY attributes in the same request. Clients MUST NOT
include ADDITIONAL-ADDRESS-FAMILY attribute in a Allocate request include ADDITIONAL-ADDRESS-FAMILY attribute in a Allocate request
that contains a RESERVATION-TOKEN attribute. Clients MUST NOT that contains a RESERVATION-TOKEN attribute. Clients MUST NOT
include ADDITIONAL-ADDRESS-FAMILY attribute in a Allocate request include ADDITIONAL-ADDRESS-FAMILY attribute in a Allocate request
that contains a EVEN-PORT attribute with the R bit set to 1. that contains an EVEN-PORT attribute with the R bit set to 1.
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 hint, and the server may elect to use desired value. This is just a hint, and the server may elect to 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
skipping to change at page 26, line 49 skipping to change at page 27, line 4
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 [I-D.ietf-tram-stunbis] unless the client and
another mechanism through some procedure outside the scope of server agree to use another mechanism through some procedure
this document. outside the scope of 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 existing allocation. If yes, the server rejects the request
with 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
skipping to change at page 28, line 18 skipping to change at page 28, line 21
(Bad Request) error. Otherwise, and the server checks if it can (Bad Request) error. Otherwise, and the server checks if it can
allocate relayed transport addresses of both address types. If allocate relayed transport addresses of both address types. If
the server cannot satisfy the request, then the server rejects the server cannot satisfy the request, then the server rejects
the request with a 508 (Insufficient Capacity) error. If the the request with a 508 (Insufficient Capacity) error. If the
server can partially meet the request, i.e. if it can only server can partially meet the request, i.e. if it can only
allocate one relayed transport address of a specific address allocate one relayed transport address of a specific address
type, then it includes ADDRESS-ERROR-CODE attribute in the type, then it includes ADDRESS-ERROR-CODE attribute in the
response to inform the client the reason for partial failure of response to inform the client the reason for partial failure of
the request. The error code value signaled in the ADDRESS- the request. The error code value signaled in the ADDRESS-
ERROR-CODE attribute could be 440 (Address Family not Supported) ERROR-CODE attribute could be 440 (Address Family not Supported)
or 508 (Insufficient Capacity). or 508 (Insufficient Capacity). If the server can fully meet
the request, then the server allocates one IPv4 and one IPv6
relay address, and returns an Allocate success response
containing the relayed transport addresses assigned to the dual
allocation.
10. At any point, the server MAY choose to reject the request with a 10. At any point, the server MAY choose to reject the request with a
486 (Allocation Quota Reached) error if it feels the client is 486 (Allocation Quota Reached) error if it feels the client is
trying to exceed some locally defined allocation quota. The trying to exceed some locally defined allocation quota. The
server is free to define this allocation quota any way it server is free to define this allocation quota any way it
wishes, but SHOULD define it based on the username used to wishes, but SHOULD define it based on the username used to
authenticate the request, and not on the client's transport authenticate the request, and not on the client's transport
address. address.
11. Also at any point, the server MAY choose to reject the request 11. Also at any point, the server MAY choose to reject the request
with a 300 (Try Alternate) error if it wishes to redirect the with a 300 (Try Alternate) error if it wishes to redirect the
client to a different server. The use of this error code and client to a different server. The use of this error code and
attribute follow the specification in [RFC5389]. attribute follow the specification in [I-D.ietf-tram-stunbis].
If all the checks pass, the server creates the allocation. The If all the checks pass, the server creates either the single or dual
5-tuple is set to the 5-tuple from the Allocate request, while the allocation. The 5-tuple is set to the 5-tuple from the Allocate
list of permissions and the list of channels are initially empty. request, while the 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 attribute, the server o If the request contains a RESERVATION-TOKEN attribute, the server
uses the previously reserved transport address corresponding to uses the previously reserved transport address corresponding to
the 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
skipping to change at page 30, line 36 skipping to change at page 30, line 46
NOTE: The XOR-MAPPED-ADDRESS attribute is included in the response NOTE: The XOR-MAPPED-ADDRESS attribute is included in the response
as a convenience to the client. TURN itself does not make use of as a convenience to the client. TURN itself does not make use of
this value, but clients running ICE can often need this value and this value, but clients running ICE can often need this value and
can thus avoid having to do an extra Binding transaction with some can thus avoid having to do an extra Binding transaction with some
STUN server to learn it. STUN server to learn it.
The response (either success or error) is sent back to the client on The response (either success or error) is sent back to the client on
the 5-tuple. the 5-tuple.
NOTE: When the Allocate request is sent over UDP, section 7.3.1 of NOTE: When the Allocate request is sent over UDP, section 6.3.1 of
[RFC5389] requires that the server handle the possible [I-D.ietf-tram-stunbis] requires that the server handle the
retransmissions of the request so that retransmissions do not possible retransmissions of the request so that retransmissions do
cause multiple allocations to be created. Implementations may not cause multiple allocations to be created. Implementations may
achieve this using the so-called "stateless stack approach" as achieve this using the so-called "stateless stack approach" as
follows. To detect retransmissions when the original request was follows. To detect retransmissions when the original request was
successful in creating an allocation, the server can store the successful in creating an allocation, the server can store the
transaction id that created the request with the allocation data transaction id that created the request with the allocation data
and compare it with incoming Allocate requests on the same and compare it with incoming Allocate requests on the same
5-tuple. Once such a request is detected, the server can stop 5-tuple. Once such a request is detected, the server can stop
parsing the request and immediately generate a success response. parsing the request and immediately generate a success response.
When building this response, the value of the LIFETIME attribute When building this response, the value of the LIFETIME attribute
can be taken from the time-to-expiry field in the allocate state can be taken from the time-to-expiry field in the allocate state
data, even though this value may differ slightly from the LIFETIME data, even though this value may differ slightly from the LIFETIME
skipping to change at page 31, line 25 skipping to change at page 31, line 34
will eventually timeout, since the client will not refresh it. will eventually timeout, since the client will not refresh it.
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 or
part of an address family that the client understands and is prepared addresses are part of an address family or families that the client
to handle. If these two addresses are not part of an address family understands and is prepared to handle. If these addresses are not
which the client is prepared to handle, then the client MUST delete part of an address family or families which the client is prepared to
the allocation (Section 7) and MUST NOT attempt to create another handle, then the client MUST delete the allocation (Section 7) and
allocation on that server until it believes the mismatch has been MUST NOT attempt to create another allocation on that server until it
fixed. believes the mismatch has been fixed.
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 32, line 23 skipping to change at page 32, line 29
choose to retry the Allocate request using a different transport choose to retry the Allocate request using a different transport
(e.g., TCP instead of UDP). (e.g., TCP instead of UDP).
o 300 (Try Alternate): The server would like the client to use the o 300 (Try Alternate): The server would like the client to use the
server specified in the ALTERNATE-SERVER attribute instead. The server specified in the ALTERNATE-SERVER attribute instead. The
client considers the current transaction as having failed, but client considers the current transaction as having failed, but
SHOULD try the Allocate request with the alternate server before SHOULD try the Allocate request with the alternate server before
trying any other servers (e.g., other servers discovered using the trying any other servers (e.g., other servers discovered using the
SRV procedures). When trying the Allocate request with the SRV procedures). When trying the Allocate request with the
alternate server, the client follows the ALTERNATE-SERVER alternate server, the client follows the ALTERNATE-SERVER
procedures specified in [RFC5389]. procedures specified in [I-D.ietf-tram-stunbis].
o 400 (Bad Request): The server believes the client's request is o 400 (Bad Request): The server believes the client's request is
malformed for some reason. The client considers the current malformed for some reason. The client considers the current
transaction as having failed. The client MAY notify the user or transaction as having failed. The client MAY notify the user or
operator and SHOULD NOT retry the request with this server until operator and SHOULD NOT retry the request with this server until
it believes the problem has been fixed. it believes the problem has been fixed.
o 401 (Unauthorized): If the client has followed the procedures of o 401 (Unauthorized): If the client has followed the procedures of
the long-term credential mechanism and still gets this error, then the long-term credential mechanism and still gets this error, then
the server is not accepting the client's credentials. In this the server is not accepting the client's credentials. In this
skipping to change at page 33, line 20 skipping to change at page 33, line 27
transport address that was used by another client that recently transport address that was used by another client that recently
crashed. The client considers the current transaction as having crashed. The client considers the current transaction as having
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 [I-D.ietf-tram-stunbis].
o 440 (Address Family not Supported): The server does not support o 440 (Address Family not Supported): The server does not support
the address family requested by the client. If the client the address family requested by the client. If the client
receives an Allocate error response with the 440 (Unsupported receives an Allocate error response with the 440 (Unsupported
Address Family) error code, the client MUST NOT retry the request. 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.
skipping to change at page 34, line 7 skipping to change at page 34, line 12
o 508 (Insufficient Capacity): The server has no more relayed o 508 (Insufficient Capacity): The server has no more relayed
transport addresses available, or has none with the requested transport addresses available, or has none with the requested
properties, or the one that was reserved is no longer available. properties, or the one that was reserved is no longer available.
The client considers the current operation as having failed. If The client considers the current operation as having failed. If
the client is using either the EVEN-PORT or the RESERVATION-TOKEN the client is using either the EVEN-PORT or the RESERVATION-TOKEN
attribute, then the client MAY choose to remove or modify this attribute, then the client MAY choose to remove or modify this
attribute and try again immediately. Otherwise, the client SHOULD attribute and try again immediately. Otherwise, the client SHOULD
wait at least 1 minute before trying to create any more wait at least 1 minute before trying to create any more
allocations on this server. allocations on this server.
An unknown error response MUST be handled as described in [RFC5389]. An unknown error response MUST be handled as described in
[I-D.ietf-tram-stunbis].
7. Refreshing an Allocation 7. Refreshing an Allocation
A Refresh transaction can be used to either (a) refresh an existing A Refresh transaction can be used to either (a) refresh an existing
allocation and update its time-to-expiry or (b) delete an existing allocation and update its time-to-expiry or (b) delete an existing
allocation. allocation.
If a client wishes to continue using an allocation, then the client If a client wishes to continue using an allocation, then the client
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
skipping to change at page 48, line 33 skipping to change at page 48, line 42
As discussed in Section 2.6, translations in TURN are designed so 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 that a TURN server can be implemented as an application that runs in
userland under commonly available operating systems and that does not userland under commonly available operating systems and that does not
require special privileges. The translations specified in the require special privileges. The translations specified in the
following sections follow this principle. following sections follow this principle.
The descriptions below have two parts: a preferred behavior and an The descriptions below have two parts: a preferred behavior and an
alternate behavior. The server SHOULD implement the preferred alternate behavior. The server SHOULD implement the preferred
behavior. Otherwise, the server MUST implement the alternate behavior. Otherwise, the server MUST implement the alternate
behavior and MUST NOT do anything else for the reasons detailed in behavior and MUST NOT do anything else for the reasons detailed in
[RFC6145]. [RFC7915].
12.1. IPv4-to-IPv6 Translations 12.1. IPv4-to-IPv6 Translations
Traffic Class Traffic Class
Preferred behavior: As specified in Section 4 of [RFC6145]. Preferred behavior: As specified in Section 4 of [RFC7915].
Alternate behavior: The relay sets the Traffic Class to the Alternate behavior: The relay sets the Traffic Class to the
default value for outgoing packets. default value for outgoing packets.
Flow Label Flow Label
Preferred behavior: The relay sets the Flow label to 0. The relay 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 can choose to set the Flow label to a different value if it
supports the IPv6 Flow Label field[RFC3697]. supports the IPv6 Flow Label field[RFC6437].
Alternate behavior: the relay sets the Flow label to the default Alternate behavior: the relay sets the Flow label to the default
value for outgoing packets. value for outgoing packets.
Hop Limit Hop Limit
Preferred behavior: As specified in Section 4 of [RFC6145]. Preferred behavior: As specified in Section 4 of [RFC7915].
Alternate behavior: The relay sets the Hop Limit to the default Alternate behavior: The relay sets the Hop Limit to the default
value for outgoing packets. value for outgoing packets.
Fragmentation Fragmentation
Preferred behavior: As specified in Section 4 of [RFC6145]. Preferred behavior: As specified in Section 4 of [RFC7915].
Alternate behavior: The relay assembles incoming fragments. The Alternate behavior: The relay assembles incoming fragments. The
relay follows its default behavior to send outgoing packets. relay follows its default behavior to send outgoing packets.
For both preferred and alternate behavior, the DONT-FRAGMENT For both preferred and alternate behavior, the DONT-FRAGMENT
attribute MUST be ignored by the server. attribute MUST be ignored by the server.
Extension Headers Extension Headers
Preferred behavior: The relay sends outgoing packet without any Preferred behavior: The relay sends outgoing packet without any
IPv6 extension headers, with the exception of the Fragmentation IPv6 extension headers, with the exception of the Fragmentation
header as described above. header as described above.
Alternate behavior: Same as preferred. Alternate behavior: Same as preferred.
12.2. IPv6-to-IPv6 Translations 12.2. IPv6-to-IPv6 Translations
Flow Label Flow Label
The relay should consider that it is handling two different IPv6 The relay should consider that it is handling two different IPv6
flows. Therefore, the Flow label [RFC3697] SHOULD NOT be copied as flows. Therefore, the Flow label [RFC6437] SHOULD NOT be copied as
part of the translation. part of the translation.
Preferred behavior: The relay sets the Flow label to 0. The relay 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 can choose to set the Flow label to a different value if it
supports the IPv6 Flow Label field[RFC3697]. supports the IPv6 Flow Label field[RFC6437].
Alternate behavior: The relay sets the Flow label to the default Alternate behavior: The relay sets the Flow label to the default
value for outgoing packets. value for outgoing packets.
Hop Limit Hop Limit
Preferred behavior: The relay acts as a regular router with Preferred behavior: The relay acts as a regular router with
respect to decrementing the Hop Limit and generating an ICMPv6 respect to decrementing the Hop Limit and generating an ICMPv6
error if it reaches zero. error if it reaches zero.
skipping to change at page 50, line 50 skipping to change at page 51, line 11
Preferred behavior: The relay sends outgoing packet without any Preferred behavior: The relay sends outgoing packet without any
IPv6 extension headers, with the exception of the Fragmentation IPv6 extension headers, with the exception of the Fragmentation
header as described above. header as described above.
Alternate behavior: Same as preferred. Alternate behavior: Same as preferred.
12.3. IPv6-to-IPv4 Translations 12.3. IPv6-to-IPv4 Translations
Type of Service and Precedence Type of Service and Precedence
Preferred behavior: As specified in Section 5 of [RFC6145]. Preferred behavior: As specified in Section 5 of [RFC7915].
Alternate behavior: The relay sets the Type of Service and Alternate behavior: The relay sets the Type of Service and
Precedence to the default value for outgoing packets. Precedence to the default value for outgoing packets.
Time to Live Time to Live
Preferred behavior: As specified in Section 5 of [RFC6145]. Preferred behavior: As specified in Section 5 of [RFC7915].
Alternate behavior: The relay sets the Time to Live to the default Alternate behavior: The relay sets the Time to Live to the default
value for outgoing packets. value for outgoing packets.
Fragmentation Fragmentation
Preferred behavior: As specified in Section 5 of [RFC6145]. Preferred behavior: As specified in Section 5 of [RFC7915].
Additionally, when the outgoing packet's size exceeds the Additionally, when the outgoing packet's size exceeds the
outgoing link's MTU, the relay needs to generate an ICMP error outgoing link's MTU, the relay needs to generate an ICMP error
(ICMPv6 Packet Too Big) reporting the MTU size. If the packet is (ICMPv6 Packet Too Big) reporting the MTU size. If the packet is
being sent to the peer, the relay SHOULD reduce the MTU reported 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 in the ICMP message by 48 bytes to allow room for the overhead of
a Data indication. a Data indication.
Alternate behavior: The relay assembles incoming fragments. The Alternate behavior: The relay assembles incoming fragments. The
relay follows its default behavior to send outgoing packets. relay follows its default behavior to send outgoing packets.
skipping to change at page 54, line 6 skipping to change at page 54, line 26
0x0021: Reserved (was TIMER-VAL) 0x0021: Reserved (was TIMER-VAL)
0x0022: RESERVATION-TOKEN 0x0022: RESERVATION-TOKEN
TBD-CA: ADDITIONAL-ADDRESS-FAMILY TBD-CA: ADDITIONAL-ADDRESS-FAMILY
TBD-CA: ADDRESS-ERROR-CODE TBD-CA: ADDRESS-ERROR-CODE
TBD-CA: ICMP TBD-CA: ICMP
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 [I-D.ietf-tram-stunbis]).
15.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
skipping to change at page 54, line 35 skipping to change at page 55, line 10
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.
15.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 [I-D.ietf-tram-stunbis].
15.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.
15.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]. [I-D.ietf-tram-stunbis].
15.6. REQUESTED-ADDRESS-FAMILY 15.6. REQUESTED-ADDRESS-FAMILY
This attribute is used by clients to request the allocation of a This attribute is used by clients to request the allocation of a
specific address type from a server. The following is the format of specific address type from a server. The following is the format of
the REQUESTED-ADDRESS-FAMILY attribute. Note that TURN attributes the REQUESTED-ADDRESS-FAMILY attribute. Note that TURN attributes
are TLV (Type-Length-Value) encoded, with a 16-bit type, a 16-bit are TLV (Type-Length-Value) encoded, with a 16-bit type, a 16-bit
length, and a variable-length value. length, and a variable-length value.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Family | Reserved | | Family | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: the type of the REQUESTED-ADDRESS-FAMILY attribute is 0x0017. Type: the type of the REQUESTED-ADDRESS-FAMILY attribute is 0x0017.
As specified in [RFC5389], attributes with values between 0x0000 As specified in [I-D.ietf-tram-stunbis], attributes with values
and 0x7FFF are comprehension-required, which means that the client between 0x0000 and 0x7FFF are comprehension-required, which means
or server cannot successfully process the message unless it that the client or server cannot successfully process the message
understands the attribute. unless it understands the attribute.
Length: this 16-bit field contains the length of the attribute in Length: this 16-bit field contains the length of the attribute in
bytes. The length of this attribute is 4 bytes. bytes. The length of this attribute is 4 bytes.
Family: there are two values defined for this field and specified in Family: there are two values defined for this field and specified in
[RFC5389], Section 15.1: 0x01 for IPv4 addresses and 0x02 for IPv6 [I-D.ietf-tram-stunbis], Section 14.1: 0x01 for IPv4 addresses and
addresses. 0x02 for IPv6 addresses.
Reserved: at this point, the 24 bits in the Reserved field MUST be 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. set to zero by the client and MUST be ignored by the server.
The REQUEST-ADDRESS-TYPE attribute MAY only be present in Allocate The REQUEST-ADDRESS-TYPE attribute MAY only be present in Allocate
requests. requests.
15.7. EVEN-PORT 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
skipping to change at page 57, line 33 skipping to change at page 58, line 16
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Family | Rsvd |Class| Number | | Family | Rsvd |Class| Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason Phrase (variable) .. | Reason Phrase (variable) ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: the type of the ADDRESS-ERROR-CODE attribute is TBD-CA. As Type: the type of the ADDRESS-ERROR-CODE attribute is TBD-CA. As
specified in [RFC5389], attributes with values between 0x8000 and specified in [I-D.ietf-tram-stunbis], attributes with values
0xFFFF are comprehension-optional, which means that the client or between 0x8000 and 0xFFFF are comprehension-optional, which means
server can safely ignore the attribute if they don't understand that the client or server can safely ignore the attribute if they
it. don't understand it.
Length: this 16-bit field contains the length of the attribute in Length: this 16-bit field contains the length of the attribute in
bytes. bytes.
Family: there are two values defined for this field and specified in Family: there are two values defined for this field and specified in
[RFC5389], Section 15.1: 0x01 for IPv4 addresses and 0x02 for IPv6 [I-D.ietf-tram-stunbis], Section 14.1: 0x01 for IPv4 addresses and
addresses. 0x02 for IPv6 addresses.
Reserved: at this point, the 13 bits in the Reserved field MUST be Reserved: at this point, the 13 bits in the Reserved field MUST be
set to zero by the client and MUST be ignored by the server. set to zero by the client and MUST be ignored by the server.
Class: The Class represents the hundreds digit of the error code and Class: The Class represents the hundreds digit of the error code and
is defined in section 15.6 of [RFC5389]. is defined in section 14.8 of [I-D.ietf-tram-stunbis].
Number: this 8-bit field contains the reason server cannot allocate Number: this 8-bit field contains the reason server cannot allocate
one of the requested address types. The error code values could one of the requested address types. The error code values could
be either 440 (unsupported address family) or 508 (insufficient be either 440 (unsupported address family) or 508 (insufficient
capacity). The number representation is defined in section 15.6 capacity). The number representation is defined in section 14.8
of [RFC5389]. of [I-D.ietf-tram-stunbis].
Reason Phrase: The recommended reason phrases for error codes 440 Reason Phrase: The recommended reason phrases for error codes 440
and 508 are explained in Section 16. and 508 are explained in Section 16.
The ADDRESS-ERROR-CODE attribute MAY only be present in Allocate The ADDRESS-ERROR-CODE attribute MAY only be present in Allocate
responses. responses.
15.13. ICMP Attribute 15.13. ICMP Attribute
This attribute is used by servers to signal the reason an UDP packet This attribute is used by servers to signal the reason an UDP packet
was dropped. The following is the format of the ICMP attribute. was dropped. The following is the format of the ICMP attribute.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Type | Code | | Reserved | ICMP Type | ICMP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved: This field MUST be set to 0 when sent, and MUST be ignored Reserved: This field MUST be set to 0 when sent, and MUST be ignored
when received. when received.
Type: The field contains the value in the ICMP type. Its ICMP Type: The field contains the value in the ICMP type. Its
interpretation depends whether the ICMP was received over IPv4 or interpretation depends whether the ICMP was received over IPv4 or
IPv6. IPv6.
Code: The field contains the value in the ICMP code. Its ICMP Code: The field contains the value in the ICMP code. Its
interpretation depends whether the ICMP was received over IPv4 or interpretation depends whether the ICMP was received over IPv4 or
IPv6. IPv6.
16. New STUN Error Response Codes 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.
skipping to change at page 60, line 46 skipping to change at page 61, line 46
|<-- Allocate success response ------| | | |<-- Allocate success response ------| | |
| Transaction-Id=0xC271E932AD7446A32C234492 | | | Transaction-Id=0xC271E932AD7446A32C234492 | |
| SOFTWARE="Example server, version 1.17" | | | SOFTWARE="Example server, version 1.17" | |
| LIFETIME=1200 (20 minutes) | | | | LIFETIME=1200 (20 minutes) | | |
| XOR-RELAYED-ADDRESS=192.0.2.15:50000 | | | XOR-RELAYED-ADDRESS=192.0.2.15:50000 | |
| XOR-MAPPED-ADDRESS=192.0.2.1:7000 | | | XOR-MAPPED-ADDRESS=192.0.2.1:7000 | |
| MESSAGE-INTEGRITY=... | | | | MESSAGE-INTEGRITY=... | | |
The client begins by selecting a host transport address to use for The client begins by selecting a host transport address to use for
the TURN session; in this example, the client has selected the TURN session; in this example, the client has selected
10.1.1.2:49721 as shown in Figure 1. The client then sends an 198.51.100.2:49721 as shown in Figure 1. The client then sends an
Allocate request to the server at the server transport address. The Allocate request to the server at the server transport address. The
client randomly selects a 96-bit transaction id of client randomly selects a 96-bit transaction id of
0xA56250D3F17ABE679422DE85 for this transaction; this is encoded in 0xA56250D3F17ABE679422DE85 for this transaction; this is encoded in
the transaction id field in the fixed header. The client includes a the transaction id field in the fixed header. The client includes a
SOFTWARE attribute that gives information about the client's SOFTWARE attribute that gives information about the client's
software; here the value is "Example client, version 1.03" to software; here the value is "Example client, version 1.03" to
indicate that this is version 1.03 of something called the Example indicate that this is version 1.03 of something called the Example
client. The client includes the LIFETIME attribute because it wishes client. The client includes the LIFETIME attribute because it wishes
the allocation to have a longer lifetime than the default of 10 the allocation to have a longer lifetime than the default of 10
minutes; the value of this attribute is 3600 seconds, which minutes; the value of this attribute is 3600 seconds, which
skipping to change at page 61, line 27 skipping to change at page 62, line 27
ALGORITHM, MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256 attribute. ALGORITHM, MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256 attribute.
Finally, note that the order of attributes in a message is arbitrary Finally, note that the order of attributes in a message is arbitrary
(except for the MESSAGE-INTEGRITY, MESSAGE-INTEGRITY-SHA256 and (except for the MESSAGE-INTEGRITY, MESSAGE-INTEGRITY-SHA256 and
FINGERPRINT attributes) and the client could have used a different FINGERPRINT attributes) and the client could have used a different
order. order.
Servers require any request to be authenticated. Thus, when the Servers require any request to be authenticated. Thus, when the
server receives the initial Allocate request, it rejects the request server receives the initial Allocate request, it rejects the request
because the request does not contain the authentication attributes. because the request does not contain the authentication attributes.
Following the procedures of the long-term credential mechanism of Following the procedures of the long-term credential mechanism of
STUN [RFC5389], the server includes an ERROR-CODE attribute with a STUN [I-D.ietf-tram-stunbis], the server includes an ERROR-CODE
value of 401 (Unauthorized), a REALM attribute that specifies the attribute with a value of 401 (Unauthorized), a REALM attribute that
authentication realm used by the server (in this case, the server's specifies the authentication realm used by the server (in this case,
domain "example.com"), and a nonce value in a NONCE attribute. The the server's domain "example.com"), and a nonce value in a NONCE
NONCE attribute starts with the "nonce cookie" with the STUN Security attribute. The NONCE attribute starts with the "nonce cookie" with
Feature "Password algorithm" bit set to 1. The server includes a the STUN Security Feature "Password algorithm" bit set to 1. The
PASSWORD-ALGORITHMS attribute that specifies the list of algorithms server includes a PASSWORD-ALGORITHMS attribute that specifies the
that the server can use to derive the long-term password. If the list of algorithms that the server can use to derive the long-term
server sets the STUN Security Feature "Username anonymity" bit to 1 password. If the server sets the STUN Security Feature "Username
then the client uses the USERHASH attribute instead of the USERNAME anonymity" bit to 1 then the client uses the USERHASH attribute
attribute in the Allocate request to anonymise the username. The instead of the USERNAME attribute in the Allocate request to
server also includes a SOFTWARE attribute that gives information anonymise the username. The server also includes a SOFTWARE
about the server's software. attribute that gives information about the server's software.
The client, upon receipt of the 401 error, re-attempts the Allocate The client, upon receipt of the 401 error, re-attempts the Allocate
request, this time including the authentication attributes. The request, this time including the authentication attributes. The
client selects a new transaction id, and then populates the new client selects a new transaction id, and then populates the new
Allocate request with the same attributes as before. The client Allocate request with the same attributes as before. The client
includes a USERNAME attribute and uses the realm value received from includes a USERNAME attribute and uses the realm value received from
the server to help it determine which value to use; here the client the server to help it determine which value to use; here the client
is configured to use the username "George" for the realm is configured to use the username "George" for the realm
"example.com". The client includes the PASSWORD-ALGORITHM attribute "example.com". The client includes the PASSWORD-ALGORITHM attribute
indicating the algorithm that the server must use to derive the long- indicating the algorithm that the server must use to derive the long-
skipping to change at page 74, line 42 skipping to change at page 75, line 42
18.5. Other Considerations 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.
19. IANA Considerations 19. IANA Considerations
Since TURN is an extension to STUN [RFC5389], the methods, Since TURN is an extension to STUN [I-D.ietf-tram-stunbis], the
attributes, and error codes defined in this specification are new methods, attributes, and error codes defined in this specification
methods, attributes, and error codes for STUN. IANA has added these are new methods, attributes, and error codes for STUN. IANA has
new protocol elements to the IANA registry of STUN protocol elements. added these 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 14. 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 15. 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 16. specification are listed in Section 16.
skipping to change at page 77, line 35 skipping to change at page 78, line 35
o Add support for receiving ICMP packets. o Add support for receiving ICMP packets.
o Updates PMTUD. o Updates PMTUD.
22. Acknowledgements 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. The authors would also like to
acknowledge that this document inherits material from [RFC6156].
Thanks to Justin Uberti, Pal Martinsen, Oleg Moskalenko, Aijun Wang Thanks to Justin Uberti, Pal Martinsen, Oleg Moskalenko, Aijun Wang
and Simon Perreault for their help on SSODA mechanism. Authors would and Simon Perreault for their help on SSODA mechanism. Authors would
like to thank Gonzalo Salgueiro, Simon Perreault, Jonathan Lennox and like to thank Gonzalo Salgueiro, Simon Perreault, Jonathan Lennox and
Oleg Moskalenko for comments and review. The authors would like to Oleg Moskalenko for comments and review. The authors would like to
thank Marc for his contributions to the text. thank Marc for his contributions to the text.
23. References 23. References
23.1. Normative References 23.1. Normative References
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, [I-D.ietf-tram-stunbis]
"Session Traversal Utilities for NAT (STUN)", RFC 5389, Petit-Huguenin, M., Salgueiro, G., Rosenberg, J., Wing,
DOI 10.17487/RFC5389, October 2008, D., Mahy, R., and P. Matthews, "Session Traversal
<http://www.rfc-editor.org/info/rfc5389>. Utilities for NAT (STUN)", draft-ietf-tram-stunbis-12
(work in progress), March 2017.
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, DOI 10.17487/RFC0792, September 1981,
<https://www.rfc-editor.org/info/rfc792>.
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122,
DOI 10.17487/RFC1122, October 1989,
<https://www.rfc-editor.org/info/rfc1122>.
[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, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[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, Field) in the IPv4 and IPv6 Headers", RFC 2474,
DOI 10.17487/RFC2474, December 1998, DOI 10.17487/RFC2474, December 1998,
<http://www.rfc-editor.org/info/rfc2474>. <https://www.rfc-editor.org/info/rfc2474>.
[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", of Explicit Congestion Notification (ECN) to IP",
RFC 3168, DOI 10.17487/RFC3168, September 2001, RFC 3168, DOI 10.17487/RFC3168, September 2001,
<http://www.rfc-editor.org/info/rfc3168>. <https://www.rfc-editor.org/info/rfc3168>.
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
Communication Layers", STD 3, RFC 1122, Control Message Protocol (ICMPv6) for the Internet
DOI 10.17487/RFC1122, October 1989, Protocol Version 6 (IPv6) Specification", STD 89,
<http://www.rfc-editor.org/info/rfc1122>. RFC 4443, DOI 10.17487/RFC4443, March 2006,
<https://www.rfc-editor.org/info/rfc4443>.
[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Algorithm", RFC 6145, DOI 10.17487/RFC6145, April 2011, Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
<http://www.rfc-editor.org/info/rfc6145>. January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC3697] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme,
"IPv6 Flow Label Specification", RFC 3697, "IPv6 Flow Label Specification", RFC 6437,
DOI 10.17487/RFC3697, March 2004, DOI 10.17487/RFC6437, November 2011,
<http://www.rfc-editor.org/info/rfc3697>. <https://www.rfc-editor.org/info/rfc6437>.
[RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with
Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April
2012, <https://www.rfc-editor.org/info/rfc6555>.
[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,
"Default Address Selection for Internet Protocol Version 6
(IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012,
<https://www.rfc-editor.org/info/rfc6724>.
[RFC7065] Petit-Huguenin, M., Nandakumar, S., Salgueiro, G., and P. [RFC7065] Petit-Huguenin, M., Nandakumar, S., Salgueiro, G., and P.
Jones, "Traversal Using Relays around NAT (TURN) Uniform Jones, "Traversal Using Relays around NAT (TURN) Uniform
Resource Identifiers", RFC 7065, DOI 10.17487/RFC7065, Resource Identifiers", RFC 7065, DOI 10.17487/RFC7065,
November 2013, <http://www.rfc-editor.org/info/rfc7065>. November 2013, <https://www.rfc-editor.org/info/rfc7065>.
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, DOI 10.17487/RFC0792, September 1981,
<http://www.rfc-editor.org/info/rfc792>.
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet [RFC7915] Bao, C., Li, X., Baker, F., Anderson, T., and F. Gont,
Control Message Protocol (ICMPv6) for the Internet "IP/ICMP Translation Algorithm", RFC 7915,
Protocol Version 6 (IPv6) Specification", RFC 4443, DOI 10.17487/RFC7915, June 2016,
DOI 10.17487/RFC4443, March 2006, <https://www.rfc-editor.org/info/rfc7915>.
<http://www.rfc-editor.org/info/rfc4443>.
[I-D.ietf-tram-stunbis] 23.2. Informative References
Petit-Huguenin, M., Salgueiro, G., Rosenberg, J., Wing,
D., Mahy, R., and P. Matthews, "Session Traversal
Utilities for NAT (STUN)", draft-ietf-tram-stunbis-12
(work in progress), March 2017.
[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, [Frag-Harmful]
"Default Address Selection for Internet Protocol Version 6 "Fragmentation Considered Harmful", <Proc. SIGCOMM '87,
(IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, vol. 17, No. 5, October 1987>.
<http://www.rfc-editor.org/info/rfc6724>.
[RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with [I-D.ietf-tram-stun-pmtud]
Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April Petit-Huguenin, M. and G. Salgueiro, "Path MTU Discovery
2012, <http://www.rfc-editor.org/info/rfc6555>. Using Session Traversal Utilities for NAT (STUN)", draft-
ietf-tram-stun-pmtud-06 (work in progress), September
2017.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [I-D.rosenberg-mmusic-ice-nonsip]
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, Rosenberg, J., "Guidelines for Usage of Interactive
January 2012, <http://www.rfc-editor.org/info/rfc6347>. Connectivity Establishment (ICE) by non Session Initiation
Protocol (SIP) Protocols", draft-rosenberg-mmusic-ice-
nonsip-01 (work in progress), July 2008.
23.2. Informative References [Port-Numbers]
"IANA Port Numbers Registry", 2005,
<http://www.iana.org/assignments/port-numbers>.
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, [Protocol-Numbers]
DOI 10.17487/RFC1191, November 1990, "IANA Protocol Numbers Registry", 2005,
<http://www.rfc-editor.org/info/rfc1191>. <http://www.iana.org/assignments/protocol-numbers>.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981, DOI 10.17487/RFC0791, September 1981,
<http://www.rfc-editor.org/info/rfc791>. <https://www.rfc-editor.org/info/rfc791>.
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
DOI 10.17487/RFC1191, November 1990,
<https://www.rfc-editor.org/info/rfc1191>.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
and E. Lear, "Address Allocation for Private Internets", and E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,
<http://www.rfc-editor.org/info/rfc1918>. <https://www.rfc-editor.org/info/rfc1918>.
[RFC3424] Daigle, L., Ed. and IAB, "IAB Considerations for
UNilateral Self-Address Fixing (UNSAF) Across Network
Address Translation", RFC 3424, DOI 10.17487/RFC3424,
November 2002, <http://www.rfc-editor.org/info/rfc3424>.
[RFC4787] Audet, F., Ed. and C. Jennings, "Network Address
Translation (NAT) Behavioral Requirements for Unicast
UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January
2007, <http://www.rfc-editor.org/info/rfc4787>.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245,
DOI 10.17487/RFC5245, April 2010,
<http://www.rfc-editor.org/info/rfc5245>.
[RFC6062] Perreault, S., Ed. and J. Rosenberg, "Traversal Using
Relays around NAT (TURN) Extensions for TCP Allocations",
RFC 6062, DOI 10.17487/RFC6062, November 2010,
<http://www.rfc-editor.org/info/rfc6062>.
[RFC6156] Camarillo, G., Novo, O., and S. Perreault, Ed., "Traversal
Using Relays around NAT (TURN) Extension for IPv6",
RFC 6156, DOI 10.17487/RFC6156, April 2011,
<http://www.rfc-editor.org/info/rfc6156>.
[RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport-
Protocol Port Randomization", BCP 156, RFC 6056,
DOI 10.17487/RFC6056, January 2011,
<http://www.rfc-editor.org/info/rfc6056>.
[RFC5128] Srisuresh, P., Ford, B., and D. Kegel, "State of Peer-to-
Peer (P2P) Communication across Network Address
Translators (NATs)", RFC 5128, DOI 10.17487/RFC5128, March
2008, <http://www.rfc-editor.org/info/rfc5128>.
[RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and [RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and
L. Jones, "SOCKS Protocol Version 5", RFC 1928, L. Jones, "SOCKS Protocol Version 5", RFC 1928,
DOI 10.17487/RFC1928, March 1996, DOI 10.17487/RFC1928, March 1996,
<http://www.rfc-editor.org/info/rfc1928>. <https://www.rfc-editor.org/info/rfc1928>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002,
<https://www.rfc-editor.org/info/rfc3261>.
[RFC3424] Daigle, L., Ed. and IAB, "IAB Considerations for
UNilateral Self-Address Fixing (UNSAF) Across Network
Address Translation", RFC 3424, DOI 10.17487/RFC3424,
November 2002, <https://www.rfc-editor.org/info/rfc3424>.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
July 2003, <http://www.rfc-editor.org/info/rfc3550>. July 2003, <https://www.rfc-editor.org/info/rfc3550>.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, DOI 10.17487/RFC3711, March 2004, RFC 3711, DOI 10.17487/RFC3711, March 2004,
<http://www.rfc-editor.org/info/rfc3711>. <https://www.rfc-editor.org/info/rfc3711>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/info/rfc4086>.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, [RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
DOI 10.17487/RFC4302, December 2005, DOI 10.17487/RFC4302, December 2005,
<http://www.rfc-editor.org/info/rfc4302>. <https://www.rfc-editor.org/info/rfc4302>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, DOI 10.17487/RFC4303, December 2005, RFC 4303, DOI 10.17487/RFC4303, December 2005,
<http://www.rfc-editor.org/info/rfc4303>. <https://www.rfc-editor.org/info/rfc4303>.
[RFC4787] Audet, F., Ed. and C. Jennings, "Network Address
Translation (NAT) Behavioral Requirements for Unicast
UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January
2007, <https://www.rfc-editor.org/info/rfc4787>.
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007,
<http://www.rfc-editor.org/info/rfc4821>. <https://www.rfc-editor.org/info/rfc4821>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002,
<http://www.rfc-editor.org/info/rfc3261>.
[I-D.rosenberg-mmusic-ice-nonsip]
Rosenberg, J., "Guidelines for Usage of Interactive
Connectivity Establishment (ICE) by non Session Initiation
Protocol (SIP) Protocols", draft-rosenberg-mmusic-ice-
nonsip-01 (work in progress), July 2008.
[I-D.ietf-tram-stun-pmtud]
Petit-Huguenin, M. and G. Salgueiro, "Path MTU Discovery
Using Session Traversal Utilities for NAT (STUN)", draft-
ietf-tram-stun-pmtud-05 (work in progress), February 2017.
[RFC8155] Patil, P., Reddy, T., and D. Wing, "Traversal Using Relays [RFC5128] Srisuresh, P., Ford, B., and D. Kegel, "State of Peer-to-
around NAT (TURN) Server Auto Discovery", RFC 8155, Peer (P2P) Communication across Network Address
DOI 10.17487/RFC8155, April 2017, Translators (NATs)", RFC 5128, DOI 10.17487/RFC5128, March
<http://www.rfc-editor.org/info/rfc8155>. 2008, <https://www.rfc-editor.org/info/rfc5128>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
"Randomness Requirements for Security", BCP 106, RFC 4086, (ICE): A Protocol for Network Address Translator (NAT)
DOI 10.17487/RFC4086, June 2005, Traversal for Offer/Answer Protocols", RFC 5245,
<http://www.rfc-editor.org/info/rfc4086>. DOI 10.17487/RFC5245, April 2010,
<https://www.rfc-editor.org/info/rfc5245>.
[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, Traversal Utilities for NAT (STUN)", RFC 5766,
DOI 10.17487/RFC5766, April 2010, DOI 10.17487/RFC5766, April 2010,
<http://www.rfc-editor.org/info/rfc5766>. <https://www.rfc-editor.org/info/rfc5766>.
[RFC5928] Petit-Huguenin, M., "Traversal Using Relays around NAT [RFC5928] Petit-Huguenin, M., "Traversal Using Relays around NAT
(TURN) Resolution Mechanism", RFC 5928, (TURN) Resolution Mechanism", RFC 5928,
DOI 10.17487/RFC5928, August 2010, DOI 10.17487/RFC5928, August 2010,
<http://www.rfc-editor.org/info/rfc5928>. <https://www.rfc-editor.org/info/rfc5928>.
[Port-Numbers] [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport-
"IANA Port Numbers Registry", 2005, Protocol Port Randomization", BCP 156, RFC 6056,
<http://www.iana.org/assignments/port-numbers>. DOI 10.17487/RFC6056, January 2011,
<https://www.rfc-editor.org/info/rfc6056>.
[Frag-Harmful] [RFC6062] Perreault, S., Ed. and J. Rosenberg, "Traversal Using
"Fragmentation Considered Harmful", <Proc. SIGCOMM '87, Relays around NAT (TURN) Extensions for TCP Allocations",
vol. 17, No. 5, October 1987>. RFC 6062, DOI 10.17487/RFC6062, November 2010,
<https://www.rfc-editor.org/info/rfc6062>.
[Protocol-Numbers] [RFC6156] Camarillo, G., Novo, O., and S. Perreault, Ed., "Traversal
"IANA Protocol Numbers Registry", 2005, Using Relays around NAT (TURN) Extension for IPv6",
<http://www.iana.org/assignments/protocol-numbers>. RFC 6156, DOI 10.17487/RFC6156, April 2011,
<https://www.rfc-editor.org/info/rfc6156>.
[RFC8155] Patil, P., Reddy, T., and D. Wing, "Traversal Using Relays
around NAT (TURN) Server Auto Discovery", RFC 8155,
DOI 10.17487/RFC8155, April 2017,
<https://www.rfc-editor.org/info/rfc8155>.
Authors' Addresses Authors' Addresses
Tirumaleswar Reddy (editor) Tirumaleswar Reddy (editor)
McAfee, Inc. McAfee, Inc.
Embassy Golf Link Business Park Embassy Golf Link Business Park
Bangalore, Karnataka 560071 Bangalore, Karnataka 560071
India India
Email: kondtir@gmail.com Email: kondtir@gmail.com
Alan Johnston (editor) Alan Johnston (editor)
Unaffiliated Rowan University
Bellevue, WA Glassboro, NJ
USA USA
Email: alan.b.johnston@gmail.com Email: alan.b.johnston@gmail.com
Philip Matthews Philip Matthews
Alcatel-Lucent Alcatel-Lucent
600 March Road 600 March Road
Ottawa, Ontario Ottawa, Ontario
Canada Canada
 End of changes. 100 change blocks. 
328 lines changed or deleted 335 lines changed or added

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