draft-ietf-tram-turnbis-05.txt   draft-ietf-tram-turnbis-06.txt 
TRAM WG T. Reddy, Ed. TRAM WG T. Reddy, Ed.
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Intended status: Standards Track A. Johnston, Ed. Intended status: Standards Track A. Johnston, Ed.
Expires: January 7, 2016 Avaya Expires: March 14, 2016 Avaya
P. Matthews P. Matthews
Alcatel-Lucent Alcatel-Lucent
J. Rosenberg J. Rosenberg
jdrosen.net jdrosen.net
July 6, 2015 September 11, 2015
Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Using Relays around NAT (TURN): Relay Extensions to Session
Traversal Utilities for NAT (STUN) Traversal Utilities for NAT (STUN)
draft-ietf-tram-turnbis-05 draft-ietf-tram-turnbis-06
Abstract Abstract
If a host is located behind a NAT, then in certain situations it can If a host is located behind a NAT, then in certain situations it can
be impossible for that host to communicate directly with other hosts be impossible for that host to communicate directly with other hosts
(peers). In these situations, it is necessary for the host to use (peers). In these situations, it is necessary for the host to use
the services of an intermediate node that acts as a communication the services of an intermediate node that acts as a communication
relay. This specification defines a protocol, called TURN (Traversal relay. This specification defines a protocol, called TURN (Traversal
Using Relays around NAT), that allows the host to control the Using Relays around NAT), that allows the host to control the
operation of the relay and to exchange packets with its peers using operation of the relay and to exchange packets with its peers using
skipping to change at page 1, line 49 skipping to change at page 1, line 49
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 7, 2016. This Internet-Draft will expire on March 14, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Overview of Operation . . . . . . . . . . . . . . . . . . . . 5 2. Overview of Operation . . . . . . . . . . . . . . . . . . . . 6
2.1. Transports . . . . . . . . . . . . . . . . . . . . . . . 8 2.1. Transports . . . . . . . . . . . . . . . . . . . . . . . 8
2.2. Allocations . . . . . . . . . . . . . . . . . . . . . . . 9 2.2. Allocations . . . . . . . . . . . . . . . . . . . . . . . 9
2.3. Permissions . . . . . . . . . . . . . . . . . . . . . . . 11 2.3. Permissions . . . . . . . . . . . . . . . . . . . . . . . 11
2.4. Send Mechanism . . . . . . . . . . . . . . . . . . . . . 11 2.4. Send Mechanism . . . . . . . . . . . . . . . . . . . . . 12
2.5. Channels . . . . . . . . . . . . . . . . . . . . . . . . 13 2.5. Channels . . . . . . . . . . . . . . . . . . . . . . . . 14
2.6. Unprivileged TURN Servers . . . . . . . . . . . . . . . . 15 2.6. Unprivileged TURN Servers . . . . . . . . . . . . . . . . 16
2.7. Avoiding IP Fragmentation . . . . . . . . . . . . . . . . 16 2.7. Avoiding IP Fragmentation . . . . . . . . . . . . . . . . 16
2.8. RTP Support . . . . . . . . . . . . . . . . . . . . . . . 17 2.8. RTP Support . . . . . . . . . . . . . . . . . . . . . . . 18
2.9. Discovery of TURN server . . . . . . . . . . . . . . . . 17 2.9. Discovery of TURN server . . . . . . . . . . . . . . . . 18
2.9.1. TURN URI Scheme Semantics . . . . . . . . . . . . . . 17 2.9.1. TURN URI Scheme Semantics . . . . . . . . . . . . . . 18
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 18 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 18
4. General Behavior . . . . . . . . . . . . . . . . . . . . . . 19 4. General Behavior . . . . . . . . . . . . . . . . . . . . . . 20
5. Allocations . . . . . . . . . . . . . . . . . . . . . . . . . 22 5. Allocations . . . . . . . . . . . . . . . . . . . . . . . . . 22
6. Creating an Allocation . . . . . . . . . . . . . . . . . . . 23 6. Creating an Allocation . . . . . . . . . . . . . . . . . . . 24
6.1. Sending an Allocate Request . . . . . . . . . . . . . . . 23 6.1. Sending an Allocate Request . . . . . . . . . . . . . . . 24
6.2. Receiving an Allocate Request . . . . . . . . . . . . . . 25 6.2. Receiving an Allocate Request . . . . . . . . . . . . . . 25
6.3. Receiving an Allocate Success Response . . . . . . . . . 29 6.3. Receiving an Allocate Success Response . . . . . . . . . 30
6.4. Receiving an Allocate Error Response . . . . . . . . . . 30 6.4. Receiving an Allocate Error Response . . . . . . . . . . 31
7. Refreshing an Allocation . . . . . . . . . . . . . . . . . . 32 7. Refreshing an Allocation . . . . . . . . . . . . . . . . . . 33
7.1. Sending a Refresh Request . . . . . . . . . . . . . . . . 32 7.1. Sending a Refresh Request . . . . . . . . . . . . . . . . 33
7.2. Receiving a Refresh Request . . . . . . . . . . . . . . . 33 7.2. Receiving a Refresh Request . . . . . . . . . . . . . . . 34
7.3. Receiving a Refresh Response . . . . . . . . . . . . . . 34 7.3. Receiving a Refresh Response . . . . . . . . . . . . . . 34
8. Permissions . . . . . . . . . . . . . . . . . . . . . . . . . 34 8. Permissions . . . . . . . . . . . . . . . . . . . . . . . . . 35
9. CreatePermission . . . . . . . . . . . . . . . . . . . . . . 35 9. CreatePermission . . . . . . . . . . . . . . . . . . . . . . 36
9.1. Forming a CreatePermission Request . . . . . . . . . . . 35 9.1. Forming a CreatePermission Request . . . . . . . . . . . 36
9.2. Receiving a CreatePermission Request . . . . . . . . . . 36 9.2. Receiving a CreatePermission Request . . . . . . . . . . 36
9.3. Receiving a CreatePermission Response . . . . . . . . . . 36 9.3. Receiving a CreatePermission Response . . . . . . . . . . 37
10. Send and Data Methods . . . . . . . . . . . . . . . . . . . . 37 10. Send, Data and SendError Methods . . . . . . . . . . . . . . 37
10.1. Forming a Send Indication . . . . . . . . . . . . . . . 37 10.1. Forming a Send Indication . . . . . . . . . . . . . . . 37
10.2. Receiving a Send Indication . . . . . . . . . . . . . . 37 10.2. Receiving a Send Indication . . . . . . . . . . . . . . 38
10.3. Receiving a UDP Datagram . . . . . . . . . . . . . . . . 38 10.3. Receiving a UDP Datagram . . . . . . . . . . . . . . . . 39
10.4. Receiving a Data Indication . . . . . . . . . . . . . . 38 10.4. Receiving a Data Indication . . . . . . . . . . . . . . 39
11. Channels . . . . . . . . . . . . . . . . . . . . . . . . . . 39 10.5. Receiving an ICMP Packet . . . . . . . . . . . . . . . . 40
11.1. Sending a ChannelBind Request . . . . . . . . . . . . . 41 10.6. Receiving a SendError Indication . . . . . . . . . . . . 40
11.2. Receiving a ChannelBind Request . . . . . . . . . . . . 41 11. Channels . . . . . . . . . . . . . . . . . . . . . . . . . . 40
11.3. Receiving a ChannelBind Response . . . . . . . . . . . . 42 11.1. Sending a ChannelBind Request . . . . . . . . . . . . . 42
11.4. The ChannelData Message . . . . . . . . . . . . . . . . 43 11.2. Receiving a ChannelBind Request . . . . . . . . . . . . 43
11.5. Sending a ChannelData Message . . . . . . . . . . . . . 43 11.3. Receiving a ChannelBind Response . . . . . . . . . . . . 44
11.6. Receiving a ChannelData Message . . . . . . . . . . . . 44 11.4. The ChannelData Message . . . . . . . . . . . . . . . . 44
11.7. Relaying Data from the Peer . . . . . . . . . . . . . . 45 11.5. Sending a ChannelData Message . . . . . . . . . . . . . 45
12. Packet Translations . . . . . . . . . . . . . . . . . . . . . 45 11.6. Receiving a ChannelData Message . . . . . . . . . . . . 46
12.1. IPv4-to-IPv6 Translations . . . . . . . . . . . . . . . 45 11.7. Relaying Data from the Peer . . . . . . . . . . . . . . 47
12.2. IPv6-to-IPv6 Translations . . . . . . . . . . . . . . . 46 12. Packet Translations . . . . . . . . . . . . . . . . . . . . . 47
12.3. IPv6-to-IPv4 Translations . . . . . . . . . . . . . . . 47 12.1. IPv4-to-IPv6 Translations . . . . . . . . . . . . . . . 47
13. IP Header Fields . . . . . . . . . . . . . . . . . . . . . . 48 12.2. IPv6-to-IPv6 Translations . . . . . . . . . . . . . . . 48
14. New STUN Methods . . . . . . . . . . . . . . . . . . . . . . 50 12.3. IPv6-to-IPv4 Translations . . . . . . . . . . . . . . . 49
15. New STUN Attributes . . . . . . . . . . . . . . . . . . . . . 50 13. IP Header Fields . . . . . . . . . . . . . . . . . . . . . . 50
15.1. CHANNEL-NUMBER . . . . . . . . . . . . . . . . . . . . . 51 14. New STUN Methods . . . . . . . . . . . . . . . . . . . . . . 52
15.2. LIFETIME . . . . . . . . . . . . . . . . . . . . . . . . 51 15. New STUN Attributes . . . . . . . . . . . . . . . . . . . . . 52
15.3. XOR-PEER-ADDRESS . . . . . . . . . . . . . . . . . . . . 51 15.1. CHANNEL-NUMBER . . . . . . . . . . . . . . . . . . . . . 53
15.4. DATA . . . . . . . . . . . . . . . . . . . . . . . . . . 51 15.2. LIFETIME . . . . . . . . . . . . . . . . . . . . . . . . 53
15.5. XOR-RELAYED-ADDRESS . . . . . . . . . . . . . . . . . . 51 15.3. XOR-PEER-ADDRESS . . . . . . . . . . . . . . . . . . . . 53
15.6. REQUESTED-ADDRESS-FAMILY . . . . . . . . . . . . . . . . 52 15.4. DATA . . . . . . . . . . . . . . . . . . . . . . . . . . 53
15.7. EVEN-PORT . . . . . . . . . . . . . . . . . . . . . . . 52 15.5. XOR-RELAYED-ADDRESS . . . . . . . . . . . . . . . . . . 54
15.8. REQUESTED-TRANSPORT . . . . . . . . . . . . . . . . . . 53 15.6. REQUESTED-ADDRESS-FAMILY . . . . . . . . . . . . . . . . 54
15.9. DONT-FRAGMENT . . . . . . . . . . . . . . . . . . . . . 53 15.7. EVEN-PORT . . . . . . . . . . . . . . . . . . . . . . . 54
15.10. RESERVATION-TOKEN . . . . . . . . . . . . . . . . . . . 53 15.8. REQUESTED-TRANSPORT . . . . . . . . . . . . . . . . . . 55
15.11. ADDITIONAL-ADDRESS-FAMILY . . . . . . . . . . . . . . . 54 15.9. DONT-FRAGMENT . . . . . . . . . . . . . . . . . . . . . 55
15.12. ADDRESS-ERROR-CODE Attribute . . . . . . . . . . . . . . 54 15.10. RESERVATION-TOKEN . . . . . . . . . . . . . . . . . . . 56
16. New STUN Error Response Codes . . . . . . . . . . . . . . . . 55 15.11. ADDITIONAL-ADDRESS-FAMILY . . . . . . . . . . . . . . . 56
17. Detailed Example . . . . . . . . . . . . . . . . . . . . . . 56 15.12. ADDRESS-ERROR-CODE Attribute . . . . . . . . . . . . . . 56
18. Security Considerations . . . . . . . . . . . . . . . . . . . 63 15.13. ICMP Attribute . . . . . . . . . . . . . . . . . . . . . 57
18.1. Outsider Attacks . . . . . . . . . . . . . . . . . . . . 63 16. New STUN Error Response Codes . . . . . . . . . . . . . . . . 58
18.1.1. Obtaining Unauthorized Allocations . . . . . . . . . 63 17. Detailed Example . . . . . . . . . . . . . . . . . . . . . . 58
18.1.2. Offline Dictionary Attacks . . . . . . . . . . . . . 64 18. Security Considerations . . . . . . . . . . . . . . . . . . . 65
18.1.3. Faked Refreshes and Permissions . . . . . . . . . . 64 18.1. Outsider Attacks . . . . . . . . . . . . . . . . . . . . 65
18.1.4. Fake Data . . . . . . . . . . . . . . . . . . . . . 64 18.1.1. Obtaining Unauthorized Allocations . . . . . . . . . 65
18.1.5. Impersonating a Server . . . . . . . . . . . . . . . 65 18.1.2. Offline Dictionary Attacks . . . . . . . . . . . . . 66
18.1.6. Eavesdropping Traffic . . . . . . . . . . . . . . . 65 18.1.3. Faked Refreshes and Permissions . . . . . . . . . . 66
18.1.7. TURN Loop Attack . . . . . . . . . . . . . . . . . . 66 18.1.4. Fake Data . . . . . . . . . . . . . . . . . . . . . 66
18.2. Firewall Considerations . . . . . . . . . . . . . . . . 67 18.1.5. Impersonating a Server . . . . . . . . . . . . . . . 67
18.2.1. Faked Permissions . . . . . . . . . . . . . . . . . 67 18.1.6. Eavesdropping Traffic . . . . . . . . . . . . . . . 67
18.2.2. Blacklisted IP Addresses . . . . . . . . . . . . . . 68 18.1.7. TURN Loop Attack . . . . . . . . . . . . . . . . . . 68
18.2.3. Running Servers on Well-Known Ports . . . . . . . . 68 18.2. Firewall Considerations . . . . . . . . . . . . . . . . 69
18.3. Insider Attacks . . . . . . . . . . . . . . . . . . . . 68 18.2.1. Faked Permissions . . . . . . . . . . . . . . . . . 69
18.3.1. DoS against TURN Server . . . . . . . . . . . . . . 68 18.2.2. Blacklisted IP Addresses . . . . . . . . . . . . . . 70
18.3.2. Anonymous Relaying of Malicious Traffic . . . . . . 69 18.2.3. Running Servers on Well-Known Ports . . . . . . . . 70
18.3.3. Manipulating Other Allocations . . . . . . . . . . . 69
18.4. Tunnel Amplification Attack . . . . . . . . . . . . . . 69 18.3. Insider Attacks . . . . . . . . . . . . . . . . . . . . 70
18.5. Other Considerations . . . . . . . . . . . . . . . . . . 70 18.3.1. DoS against TURN Server . . . . . . . . . . . . . . 70
19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 70 18.3.2. Anonymous Relaying of Malicious Traffic . . . . . . 71
20. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 71 18.3.3. Manipulating Other Allocations . . . . . . . . . . . 71
21. Changes since RFC 5766 . . . . . . . . . . . . . . . . . . . 73 18.4. Tunnel Amplification Attack . . . . . . . . . . . . . . 71
22. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 73 18.5. Other Considerations . . . . . . . . . . . . . . . . . . 72
23. References . . . . . . . . . . . . . . . . . . . . . . . . . 73 19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 72
23.1. Normative References . . . . . . . . . . . . . . . . . . 73 20. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 73
23.2. Informative References . . . . . . . . . . . . . . . . . 74 21. Changes since RFC 5766 . . . . . . . . . . . . . . . . . . . 75
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 76 22. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 75
23. References . . . . . . . . . . . . . . . . . . . . . . . . . 76
23.1. Normative References . . . . . . . . . . . . . . . . . . 76
23.2. Informative References . . . . . . . . . . . . . . . . . 77
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 79
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 12, line 30 skipping to change at page 13, line 7
is implied by the 5-tuple used for the Send indication. is implied by the 5-tuple used for the Send indication.
In the reverse direction, UDP datagrams arriving at the relayed In the reverse direction, UDP datagrams arriving at the relayed
transport address on the TURN server are converted into Data transport address on the TURN server are converted into Data
indications and sent to the client, with the server-reflexive indications and sent to the client, with the server-reflexive
transport address of the peer included in an XOR-PEER-ADDRESS transport address of the peer included in an XOR-PEER-ADDRESS
attribute and the data itself in a DATA attribute. Since the relayed attribute and the data itself in a DATA attribute. Since the relayed
transport address uniquely identified the allocation, the server transport address uniquely identified the allocation, the server
knows which client should receive the data. knows which client should receive the data.
Some ICMP (Internet Control Message Protocol) packets arriving at the
relayed transport address on the TURN server may be converted into
SendError indications and sent to the client, with the transport
address of the peer included in an XOR-PEER-ADDRESS attribute and the
ICMP type and code in a ICMP attribute. SendError indications are
also sent when using the channel machanism.
Send and Data indications cannot be authenticated, since the long- Send and Data indications cannot be authenticated, since the long-
term credential mechanism of STUN does not support authenticating term credential mechanism of STUN does not support authenticating
indications. This is not as big an issue as it might first appear, indications. This is not as big an issue as it might first appear,
since the client-to-server leg is only half of the total path to the since the client-to-server leg is only half of the total path to the
peer. Applications that want proper security should encrypt the data peer. Applications that want proper security should encrypt the data
sent between the client and a peer. sent between the client and a peer.
Because Send indications are not authenticated, it is possible for an Because Send indications are not authenticated, it is possible for an
attacker to send bogus Send indications to the server, which will attacker to send bogus Send indications to the server, which will
then relay these to a peer. To partly mitigate this attack, TURN then relay these to a peer. To partly mitigate this attack, TURN
skipping to change at page 17, line 5 skipping to change at page 17, line 35
fragmentation, it is recommended that the client use ChannelData fragmentation, it is recommended that the client use ChannelData
messages when transferring significant volumes of data, since the messages when transferring significant volumes of data, since the
overhead of the ChannelData message is less than Send and Data overhead of the ChannelData message is less than Send and Data
indications. indications.
The second approach the client and peer can take to avoid The second approach the client and peer can take to avoid
fragmentation is to use a path MTU discovery algorithm to determine fragmentation is to use a path MTU discovery algorithm to determine
the maximum amount of application data that can be sent without the maximum amount of application data that can be sent without
fragmentation. fragmentation.
Unfortunately, because servers implementing this version of TURN do Unfortunately, because servers implementing this version of TURN are
not relay ICMP messages, the classic path MTU discovery algorithm not required to relay ICMP messages, the classic path MTU discovery
defined in [RFC1191] is not able to discover the MTU of the algorithm defined in [RFC1191] is not able to discover the MTU of the
transmission path between the client and the peer. (Even if they did transmission path between the client and the peer.
relay ICMP messages, the algorithm would not always work since ICMP
messages are often filtered out by combined NAT/firewall devices).
So the client and server need to use a path MTU discovery algorithm So the client and server need to use a path MTU discovery algorithm
that does not require ICMP messages. The Packetized Path MTU that does not require ICMP messages. The Packetized Path MTU
Discovery algorithm defined in [RFC4821] is one such algorithm. Discovery algorithm defined in [RFC4821] is one such algorithm.
The details of how to use the algorithm of [RFC4821] with TURN are [I-D.petithuguenin-tram-stun-pmtud] is an implementation of [RFC4821]
still under investigation. However, as a step towards this goal, that is using STUN to discover the PMTUD, and so may be a suitable
this version of TURN supports a DONT-FRAGMENT attribute. When the approach to be used in conjunction with a TURN server, together with
client includes this attribute in a Send indication, this tells the the DONT-FRAGMENT attribute. When the client includes the DONT-
server to set the DF bit in the resulting UDP datagram that it sends FRAGMENT attribute in a Send indication, this tells the server to set
to the peer. Since some servers may be unable to set the DF bit, the the DF bit in the resulting UDP datagram that it sends to the peer.
client should also include this attribute in the Allocate request -- Since some servers may be unable to set the DF bit, the client should
any server that does not support the DONT-FRAGMENT attribute will also include this attribute in the Allocate request -- any server
indicate this by rejecting the Allocate request. that does not support the DONT-FRAGMENT attribute will indicate this
by rejecting the Allocate request.
2.8. RTP Support 2.8. RTP Support
One of the envisioned uses of TURN is as a relay for clients and One of the envisioned uses of TURN is as a relay for clients and
peers wishing to exchange real-time data (e.g., voice or video) using peers wishing to exchange real-time data (e.g., voice or video) using
RTP. To facilitate the use of TURN for this purpose, TURN includes RTP. To facilitate the use of TURN for this purpose, TURN includes
some special support for older versions of RTP. some special support for older versions of RTP.
Old versions of RTP [RFC3550] required that the RTP stream be on an Old versions of RTP [RFC3550] required that the RTP stream be on an
even port number and the associated RTP Control Protocol (RTCP) even port number and the associated RTP Control Protocol (RTCP)
skipping to change at page 37, line 5 skipping to change at page 37, line 37
idempotency of CreatePermission requests over UDP using the idempotency of CreatePermission requests over UDP using the
"stateless stack approach". Retransmitted CreatePermission "stateless stack approach". Retransmitted CreatePermission
requests will simply refresh the permissions. requests will simply refresh the permissions.
9.3. Receiving a CreatePermission Response 9.3. Receiving a CreatePermission Response
If the client receives a valid CreatePermission success response, If the client receives a valid CreatePermission success response,
then the client updates its data structures to indicate that the then the client updates its data structures to indicate that the
permissions have been installed or refreshed. permissions have been installed or refreshed.
10. Send and Data Methods 10. Send, Data and SendError Methods
TURN supports two mechanisms for sending and receiving data from TURN supports two mechanisms for sending and receiving data from
peers. This section describes the use of the Send and Data peers. This section describes the use of the Send and Data
mechanisms, while Section 11 describes the use of the Channel mechanisms, while Section 11 describes the use of the Channel
mechanism. mechanism.
10.1. Forming a Send Indication 10.1. Forming a Send Indication
The client can use a Send indication to pass data to the server for The client can use a Send indication to pass data to the server for
relaying to a peer. A client may use a Send indication even if a relaying to a peer. A client may use a Send indication even if a
skipping to change at page 39, line 17 skipping to change at page 40, line 5
NOTE: The latter check protects the client against an attacker who NOTE: The latter check protects the client against an attacker who
somehow manages to trick the server into installing permissions somehow manages to trick the server into installing permissions
not desired by the client. not desired by the client.
If the Data indication passes the above checks, the client delivers If the Data indication passes the above checks, the client delivers
the data octets inside the DATA attribute to the application, along the data octets inside the DATA attribute to the application, along
with an indication that they were received from the peer whose with an indication that they were received from the peer whose
transport address is given by the XOR-PEER-ADDRESS attribute. transport address is given by the XOR-PEER-ADDRESS attribute.
10.5. Receiving an ICMP Packet
When the server receives an ICMP packet at a currently allocated
relayed transport address, the server verifies that the type is
either 3, 11 or 12 for an ICMPv4 [RFC0792] packet or either 1, 2, or
3 for an ICMPv6 [RFC4443] packet. It also verifies that the IP
packet in the ICMP packet payload contain an UDP header. If either
of these conditions fail, then the ICMP packet is silently dropped.
The server looks up the allocation associated with the relayed
transport address. The server then checks to see whether the set of
permissions for the allocation allows the relaying of the ICMP packet
as described in Section 8.
If relaying is permitted then the server forms and sends a SendError
indication. The SendError indication MUST contain both an XOR-PEER-
ADDRESS and an ICMP attribute. The ICMP attribute is set to the
value of the type and code fields from the ICMP packet, and the XOR-
PEER-ADDRESS attribute is set to the destination IP address in the IP
header and to the destination port in the UDP header. Both are found
in the ICMP packet payload. The SendError indication is then sent on
the 5-tuple associated with the allocation.
10.6. Receiving a SendError Indication
When the client receives a SendError indication, it checks that the
SendError indication contains both an XOR-PEER-ADDRESS and an ICMP
attribute, and discards the indication if it does not. The client
SHOULD also check that the XOR-PEER-ADDRESS attribute value contains
an IP address with an active permission, and discard the SendError
indication otherwise.
If the SendError indication passes the above checks, the client
signals the application of the error condition, along with an
indication that it was received from the peer whose transport address
is given by the XOR-PEER-ADDRESS attribute. The application can make
sense of the meaning of the type and code values in the ICMP
attribute by using the family field in the XOR-PEER-ADDRESS
attribute.
11. Channels 11. Channels
Channels provide a way for the client and server to send application Channels provide a way for the client and server to send application
data using ChannelData messages, which have less overhead than Send data using ChannelData messages, which have less overhead than Send
and Data indications. and Data indications.
The ChannelData message (see Section 11.4) starts with a two-byte The ChannelData message (see Section 11.4) starts with a two-byte
field that carries the channel number. The values of this field are field that carries the channel number. The values of this field are
allocated as follows: allocated as follows:
skipping to change at page 45, line 22 skipping to change at page 47, line 14
11.7. Relaying Data from the Peer 11.7. Relaying Data from the Peer
When the server receives a UDP datagram on the relayed transport When the server receives a UDP datagram on the relayed transport
address associated with an allocation, the server processes it as address associated with an allocation, the server processes it as
described in Section 10.3. If that section indicates that a described in Section 10.3. If that section indicates that a
ChannelData message should be sent (because there is a channel bound ChannelData message should be sent (because there is a channel bound
to the peer that sent to the UDP datagram), then the server forms and to the peer that sent to the UDP datagram), then the server forms and
sends a ChannelData message as described in Section 11.5. sends a ChannelData message as described in Section 11.5.
When the server receives an ICMP packet on the relayed transport
address associated with an allocation, the server processes it as
described in Section 10.5. A SendError indication MUST be sent
regardless if there is a channel bound to the peer that was the
destination of the UDP datagram that triggered the reception of the
ICMP packet.
12. Packet Translations 12. Packet Translations
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
skipping to change at page 50, line 28 skipping to change at page 52, line 28
This section lists the codepoints for the new STUN methods defined in This section lists the codepoints for the new STUN methods defined in
this specification. See elsewhere in this document for the semantics this specification. See elsewhere in this document for the semantics
of these new methods. of these new methods.
0x003 : Allocate (only request/response semantics defined) 0x003 : Allocate (only request/response semantics defined)
0x004 : Refresh (only request/response semantics defined) 0x004 : Refresh (only request/response semantics defined)
0x006 : Send (only indication semantics defined) 0x006 : Send (only indication semantics defined)
0x007 : Data (only indication semantics defined) 0x007 : Data (only indication semantics defined)
0x008 : CreatePermission (only request/response semantics defined 0x008 : CreatePermission (only request/response semantics defined
0x009 : ChannelBind (only request/response semantics defined) 0x009 : ChannelBind (only request/response semantics defined)
TBD-DA : SendError (only indication semantics defined)
15. New STUN Attributes 15. New STUN Attributes
This STUN extension defines the following new attributes: This STUN extension defines the following new attributes:
0x000C: CHANNEL-NUMBER 0x000C: CHANNEL-NUMBER
0x000D: LIFETIME 0x000D: LIFETIME
0x0010: Reserved (was BANDWIDTH) 0x0010: Reserved (was BANDWIDTH)
0x0012: XOR-PEER-ADDRESS 0x0012: XOR-PEER-ADDRESS
0x0013: DATA 0x0013: DATA
0x0016: XOR-RELAYED-ADDRESS 0x0016: XOR-RELAYED-ADDRESS
0x0017: REQUESTED-ADDRESS-FAMILY 0x0017: REQUESTED-ADDRESS-FAMILY
0x0018: EVEN-PORT 0x0018: EVEN-PORT
0x0019: REQUESTED-TRANSPORT 0x0019: REQUESTED-TRANSPORT
0x001A: DONT-FRAGMENT 0x001A: DONT-FRAGMENT
0x0021: Reserved (was TIMER-VAL) 0x0021: Reserved (was TIMER-VAL)
0x0022: RESERVATION-TOKEN 0x0022: RESERVATION-TOKEN
TBD-CA: ADDITIONAL-ADDRESS-FAMILY TBD-CA: ADDITIONAL-ADDRESS-FAMILY
TBD-CA: ADDRESS-ERROR-CODE TBD-CA: ADDRESS-ERROR-CODE
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 [RFC5389]).
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
skipping to change at page 55, line 17 skipping to change at page 57, line 27
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 15.6
of [RFC5389]. of [RFC5389].
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
This attribute is used by servers to signal the reason an UDP packet
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Type | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved: This field MUST be set to 0 when sent, and MUST be ignored
when received.
Type: The field contains the value in the ICMP type. Its
interpretation depends whether the ICMP was received over IPv4 or
IPv6.
Code: The field contains the value in the ICMP code. Its
interpretation depends whether the ICMP was received over IPv4 or
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.
437 (Allocation Mismatch): A request was received by the server that 437 (Allocation Mismatch): A request was received by the server that
requires an allocation to be in place, but no allocation exists, requires an allocation to be in place, but no allocation exists,
or a request was received that requires no allocation, but an or a request was received that requires no allocation, but an
skipping to change at page 71, line 34 skipping to change at page 73, line 34
channel numbers in this range. channel numbers in this range.
o 0x8000 through 0xFFFF: Unassigned. o 0x8000 through 0xFFFF: Unassigned.
Any change to this registry must be made through an IETF Standards Any change to this registry must be made through an IETF Standards
Action. Action.
[Paragraphs in braces should be removed by the RFC Editor upon [Paragraphs in braces should be removed by the RFC Editor upon
publication] publication]
[The ADDITIONAL-ADDRESS-FAMILY, ADDRESS-ERROR-CODE attributes [The ADDITIONAL-ADDRESS-FAMILY, ADDRESS-ERROR-CODE and ICMP
requires that IANA allocate a value in the "STUN attributes Registry" attributes requires that IANA allocate a value in the "STUN
from the comprehension- optional range (0x8000-0xFFFF), to be attributes Registry" from the comprehension- optional range
replaced for TBD-CA throughout this document] (0x8000-0xFFFF), to be replaced for TBD-CA throughout this document]
[The SendErr method requires that IANA allocate a value in the "STUN
Methods Registry" from the range (0x000-0x7FF), to be replaced for
TBD-DA throughout this document]
20. IAB Considerations 20. IAB Considerations
The IAB has studied the problem of "Unilateral Self Address Fixing" The IAB has studied the problem of "Unilateral Self Address Fixing"
(UNSAF), which is the general process by which a client attempts to (UNSAF), which is the general process by which a client attempts to
determine its address in another realm on the other side of a NAT determine its address in another realm on the other side of a NAT
through a collaborative protocol-reflection mechanism [RFC3424]. The through a collaborative protocol-reflection mechanism [RFC3424]. The
TURN extension is an example of a protocol that performs this type of TURN extension is an example of a protocol that performs this type of
function. The IAB has mandated that any protocols developed for this function. The IAB has mandated that any protocols developed for this
purpose document a specific set of considerations. These purpose document a specific set of considerations. These
skipping to change at page 73, line 26 skipping to change at page 75, line 32
o REQUESTED-ADDRESS-FAMILY, ADDITIONAL-ADDRESS-FAMILY, AND ADDRESS- o REQUESTED-ADDRESS-FAMILY, ADDITIONAL-ADDRESS-FAMILY, AND ADDRESS-
ERRR-CODE attributes. ERRR-CODE attributes.
o 440 (Address Family not Supported) and 443 (Peer Address Family o 440 (Address Family not Supported) and 443 (Peer Address Family
Mismatch) responses. Mismatch) responses.
o Description of the tunnel amplification attack. o Description of the tunnel amplification attack.
o DTLS support. o DTLS support.
o More detail on packet translations. o More details on packet translations.
o Add support for receiving ICMP packets.
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.
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 for comments and review. like to thank Gonzalo Salgueiro for comments and review. The authors
would like to 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, [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389, "Session Traversal Utilities for NAT (STUN)", RFC 5389,
October 2008. DOI 10.17487/RFC5389, October 2008,
<http://www.rfc-editor.org/info/rfc5389>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://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, December Field) in the IPv4 and IPv6 Headers", RFC 2474,
1998. DOI 10.17487/RFC2474, December 1998,
<http://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", RFC of Explicit Congestion Notification (ECN) to IP",
3168, September 2001. RFC 3168, DOI 10.17487/RFC3168, September 2001,
<http://www.rfc-editor.org/info/rfc3168>.
[RFC1122] Braden, R., "Requirements for Internet Hosts - [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989. Communication Layers", STD 3, RFC 1122,
DOI 10.17487/RFC1122, October 1989,
<http://www.rfc-editor.org/info/rfc1122>.
[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
Algorithm", RFC 6145, April 2011. Algorithm", RFC 6145, DOI 10.17487/RFC6145, April 2011,
<http://www.rfc-editor.org/info/rfc6145>.
[RFC3697] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, [RFC3697] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering,
"IPv6 Flow Label Specification", RFC 3697, March 2004. "IPv6 Flow Label Specification", RFC 3697,
DOI 10.17487/RFC3697, March 2004,
<http://www.rfc-editor.org/info/rfc3697>.
[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, November 2013. Resource Identifiers", RFC 7065, DOI 10.17487/RFC7065,
November 2013, <http://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
Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification", RFC 4443,
DOI 10.17487/RFC4443, March 2006,
<http://www.rfc-editor.org/info/rfc4443>.
23.2. Informative References 23.2. Informative References
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
November 1990. DOI 10.17487/RFC1191, November 1990,
<http://www.rfc-editor.org/info/rfc1191>.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
1981. DOI 10.17487/RFC0791, September 1981,
<http://www.rfc-editor.org/info/rfc791>.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
E. Lear, "Address Allocation for Private Internets", BCP and E. Lear, "Address Allocation for Private Internets",
5, RFC 1918, February 1996. BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,
<http://www.rfc-editor.org/info/rfc1918>.
[RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral [RFC3424] Daigle, L., Ed. and IAB, "IAB Considerations for
Self-Address Fixing (UNSAF) Across Network Address UNilateral Self-Address Fixing (UNSAF) Across Network
Translation", RFC 3424, November 2002. Address Translation", RFC 3424, DOI 10.17487/RFC3424,
November 2002, <http://www.rfc-editor.org/info/rfc3424>.
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation [RFC4787] Audet, F., Ed. and C. Jennings, "Network Address
(NAT) Behavioral Requirements for Unicast UDP", BCP 127, Translation (NAT) Behavioral Requirements for Unicast
RFC 4787, January 2007. UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January
2007, <http://www.rfc-editor.org/info/rfc4787>.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT) (ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245, April Traversal for Offer/Answer Protocols", RFC 5245,
2010. DOI 10.17487/RFC5245, April 2010,
<http://www.rfc-editor.org/info/rfc5245>.
[RFC6062] Perreault, S. and J. Rosenberg, "Traversal Using Relays [RFC6062] Perreault, S., Ed. and J. Rosenberg, "Traversal Using
around NAT (TURN) Extensions for TCP Allocations", RFC Relays around NAT (TURN) Extensions for TCP Allocations",
6062, November 2010. RFC 6062, DOI 10.17487/RFC6062, November 2010,
<http://www.rfc-editor.org/info/rfc6062>.
[RFC6156] Camarillo, G., Novo, O., and S. Perreault, "Traversal [RFC6156] Camarillo, G., Novo, O., and S. Perreault, Ed., "Traversal
Using Relays around NAT (TURN) Extension for IPv6", RFC Using Relays around NAT (TURN) Extension for IPv6",
6156, April 2011. RFC 6156, DOI 10.17487/RFC6156, April 2011,
<http://www.rfc-editor.org/info/rfc6156>.
[RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport-
Protocol Port Randomization", BCP 156, RFC 6056, January Protocol Port Randomization", BCP 156, RFC 6056,
2011. 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- [RFC5128] Srisuresh, P., Ford, B., and D. Kegel, "State of Peer-to-
Peer (P2P) Communication across Network Address Peer (P2P) Communication across Network Address
Translators (NATs)", RFC 5128, March 2008. 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, March L. Jones, "SOCKS Protocol Version 5", RFC 1928,
1996. DOI 10.17487/RFC1928, March 1996,
<http://www.rfc-editor.org/info/rfc1928>.
[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, July 2003. Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
July 2003, <http://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, March 2004. RFC 3711, DOI 10.17487/RFC3711, March 2004,
<http://www.rfc-editor.org/info/rfc3711>.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December [RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
2005. DOI 10.17487/RFC4302, December 2005,
<http://www.rfc-editor.org/info/rfc4302>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
4303, December 2005. RFC 4303, DOI 10.17487/RFC4303, December 2005,
<http://www.rfc-editor.org/info/rfc4303>.
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
Discovery", RFC 4821, March 2007. Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007,
<http://www.rfc-editor.org/info/rfc4821>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. DOI 10.17487/RFC3261, June 2002,
<http://www.rfc-editor.org/info/rfc3261>.
[I-D.rosenberg-mmusic-ice-nonsip] [I-D.rosenberg-mmusic-ice-nonsip]
Rosenberg, J., "Guidelines for Usage of Interactive Rosenberg, J., "Guidelines for Usage of Interactive
Connectivity Establishment (ICE) by non Session Initiation Connectivity Establishment (ICE) by non Session Initiation
Protocol (SIP) Protocols", draft-rosenberg-mmusic-ice- Protocol (SIP) Protocols", draft-rosenberg-mmusic-ice-
nonsip-01 (work in progress), July 2008. nonsip-01 (work in progress), July 2008.
[I-D.petithuguenin-tram-stun-pmtud]
Petit-Huguenin, M. and G. Salgueiro, "Path MTU Discovery
Using Session Traversal Utilities for NAT (STUN)", draft-
petithuguenin-tram-stun-pmtud-01 (work in progress), July
2015.
[I-D.ietf-tram-turn-server-discovery] [I-D.ietf-tram-turn-server-discovery]
Patil, P., Reddy, T., and D. Wing, "TURN Server Auto Patil, P., Reddy, T., and D. Wing, "TURN Server Auto
Discovery", draft-ietf-tram-turn-server-discovery-03 (work Discovery", draft-ietf-tram-turn-server-discovery-04 (work
in progress), May 2015. in progress), July 2015.
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
Requirements for Security", BCP 106, RFC 4086, June 2005. "Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005,
<http://www.rfc-editor.org/info/rfc4086>.
[RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using
Relays around NAT (TURN): Relay Extensions to Session Relays around NAT (TURN): Relay Extensions to Session
Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. Traversal Utilities for NAT (STUN)", RFC 5766,
DOI 10.17487/RFC5766, April 2010,
<http://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, August 2010. (TURN) Resolution Mechanism", RFC 5928,
DOI 10.17487/RFC5928, August 2010,
<http://www.rfc-editor.org/info/rfc5928>.
[Port-Numbers] [Port-Numbers]
"IANA Port Numbers Registry", 2005, "IANA Port Numbers Registry", 2005,
<http://www.iana.org/assignments/port-numbers>. <http://www.iana.org/assignments/port-numbers>.
[Frag-Harmful] [Frag-Harmful]
"Fragmentation Considered Harmful", <Proc. SIGCOMM '87, "Fragmentation Considered Harmful", <Proc. SIGCOMM '87,
vol. 17, No. 5, October 1987>. vol. 17, No. 5, October 1987>.
[Protocol-Numbers] [Protocol-Numbers]
 End of changes. 55 change blocks. 
155 lines changed or deleted 294 lines changed or added

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