draft-ietf-tram-turnbis-09.txt   draft-ietf-tram-turnbis-10.txt 
TRAM WG T. Reddy, Ed. TRAM WG T. Reddy, Ed.
Internet-Draft Cisco Systems, Inc. Internet-Draft
Intended status: Standards Track A. Johnston, Ed. Intended status: Standards Track A. Johnston, Ed.
Expires: May 3, 2017 Unaffiliated Expires: November 10, 2017 Unaffiliated
P. Matthews P. Matthews
Alcatel-Lucent Alcatel-Lucent
J. Rosenberg J. Rosenberg
jdrosen.net jdrosen.net
October 30, 2016 May 9, 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-09 draft-ietf-tram-turnbis-10
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 May 3, 2017. This Internet-Draft will expire on November 10, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 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 (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
skipping to change at page 2, line 34 skipping to change at page 2, line 34
2.1. Transports . . . . . . . . . . . . . . . . . . . . . . . 8 2.1. Transports . . . . . . . . . . . . . . . . . . . . . . . 8
2.2. Allocations . . . . . . . . . . . . . . . . . . . . . . . 9 2.2. Allocations . . . . . . . . . . . . . . . . . . . . . . . 9
2.3. Permissions . . . . . . . . . . . . . . . . . . . . . . . 11 2.3. Permissions . . . . . . . . . . . . . . . . . . . . . . . 11
2.4. Send Mechanism . . . . . . . . . . . . . . . . . . . . . 12 2.4. Send Mechanism . . . . . . . . . . . . . . . . . . . . . 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
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 18 2.10. Happy Eyeballs for TURN . . . . . . . . . . . . . . . . . 18
4. General Behavior . . . . . . . . . . . . . . . . . . . . . . 20 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 19
5. Allocations . . . . . . . . . . . . . . . . . . . . . . . . . 22 4. General Behavior . . . . . . . . . . . . . . . . . . . . . . 21
5. Allocations . . . . . . . . . . . . . . . . . . . . . . . . . 23
6. Creating an Allocation . . . . . . . . . . . . . . . . . . . 24 6. Creating an Allocation . . . . . . . . . . . . . . . . . . . 24
6.1. Sending an Allocate Request . . . . . . . . . . . . . . . 24 6.1. Sending an Allocate Request . . . . . . . . . . . . . . . 25
6.2. Receiving an Allocate Request . . . . . . . . . . . . . . 25 6.2. Receiving an Allocate Request . . . . . . . . . . . . . . 26
6.3. Receiving an Allocate Success Response . . . . . . . . . 30 6.3. Receiving an Allocate Success Response . . . . . . . . . 31
6.4. Receiving an Allocate Error Response . . . . . . . . . . 31 6.4. Receiving an Allocate Error Response . . . . . . . . . . 31
7. Refreshing an Allocation . . . . . . . . . . . . . . . . . . 33 7. Refreshing an Allocation . . . . . . . . . . . . . . . . . . 34
7.1. Sending a Refresh Request . . . . . . . . . . . . . . . . 33 7.1. Sending a Refresh Request . . . . . . . . . . . . . . . . 34
7.2. Receiving a Refresh Request . . . . . . . . . . . . . . . 34 7.2. Receiving a Refresh Request . . . . . . . . . . . . . . . 34
7.3. Receiving a Refresh Response . . . . . . . . . . . . . . 34 7.3. Receiving a Refresh Response . . . . . . . . . . . . . . 35
8. Permissions . . . . . . . . . . . . . . . . . . . . . . . . . 35 8. Permissions . . . . . . . . . . . . . . . . . . . . . . . . . 36
9. CreatePermission . . . . . . . . . . . . . . . . . . . . . . 36 9. CreatePermission . . . . . . . . . . . . . . . . . . . . . . 37
9.1. Forming a CreatePermission Request . . . . . . . . . . . 36 9.1. Forming a CreatePermission Request . . . . . . . . . . . 37
9.2. Receiving a CreatePermission Request . . . . . . . . . . 36 9.2. Receiving a CreatePermission Request . . . . . . . . . . 37
9.3. Receiving a CreatePermission Response . . . . . . . . . . 37 9.3. Receiving a CreatePermission Response . . . . . . . . . . 38
10. Send and Data Methods . . . . . . . . . . . . . . . . . . . . 37 10. Send and Data Methods . . . . . . . . . . . . . . . . . . . . 38
10.1. Forming a Send Indication . . . . . . . . . . . . . . . 37 10.1. Forming a Send Indication . . . . . . . . . . . . . . . 38
10.2. Receiving a Send Indication . . . . . . . . . . . . . . 38 10.2. Receiving a Send Indication . . . . . . . . . . . . . . 39
10.3. Receiving a UDP Datagram . . . . . . . . . . . . . . . . 39 10.3. Receiving a UDP Datagram . . . . . . . . . . . . . . . . 40
10.4. Receiving a Data Indication with DATA attribute . . . . 39 10.4. Receiving a Data Indication with DATA attribute . . . . 40
10.5. Receiving an ICMP Packet . . . . . . . . . . . . . . . . 40 10.5. Receiving an ICMP Packet . . . . . . . . . . . . . . . . 40
10.6. Receiving a Data Indication with an ICMP attribute . . . 40 10.6. Receiving a Data Indication with an ICMP attribute . . . 41
11. Channels . . . . . . . . . . . . . . . . . . . . . . . . . . 41 11. Channels . . . . . . . . . . . . . . . . . . . . . . . . . . 42
11.1. Sending a ChannelBind Request . . . . . . . . . . . . . 43 11.1. Sending a ChannelBind Request . . . . . . . . . . . . . 44
11.2. Receiving a ChannelBind Request . . . . . . . . . . . . 43 11.2. Receiving a ChannelBind Request . . . . . . . . . . . . 44
11.3. Receiving a ChannelBind Response . . . . . . . . . . . . 44 11.3. Receiving a ChannelBind Response . . . . . . . . . . . . 45
11.4. The ChannelData Message . . . . . . . . . . . . . . . . 45 11.4. The ChannelData Message . . . . . . . . . . . . . . . . 45
11.5. Sending a ChannelData Message . . . . . . . . . . . . . 45 11.5. Sending a ChannelData Message . . . . . . . . . . . . . 46
11.6. Receiving a ChannelData Message . . . . . . . . . . . . 46 11.6. Receiving a ChannelData Message . . . . . . . . . . . . 47
11.7. Relaying Data from the Peer . . . . . . . . . . . . . . 47 11.7. Relaying Data from the Peer . . . . . . . . . . . . . . 48
12. Packet Translations . . . . . . . . . . . . . . . . . . . . . 47 12. Packet Translations . . . . . . . . . . . . . . . . . . . . . 48
12.1. IPv4-to-IPv6 Translations . . . . . . . . . . . . . . . 47 12.1. IPv4-to-IPv6 Translations . . . . . . . . . . . . . . . 48
12.2. IPv6-to-IPv6 Translations . . . . . . . . . . . . . . . 48 12.2. IPv6-to-IPv6 Translations . . . . . . . . . . . . . . . 49
12.3. IPv6-to-IPv4 Translations . . . . . . . . . . . . . . . 49 12.3. IPv6-to-IPv4 Translations . . . . . . . . . . . . . . . 50
13. IP Header Fields . . . . . . . . . . . . . . . . . . . . . . 50 13. IP Header Fields . . . . . . . . . . . . . . . . . . . . . . 51
14. New STUN Methods . . . . . . . . . . . . . . . . . . . . . . 52 14. New STUN Methods . . . . . . . . . . . . . . . . . . . . . . 53
15. New STUN Attributes . . . . . . . . . . . . . . . . . . . . . 52 15. New STUN Attributes . . . . . . . . . . . . . . . . . . . . . 53
15.1. CHANNEL-NUMBER . . . . . . . . . . . . . . . . . . . . . 53 15.1. CHANNEL-NUMBER . . . . . . . . . . . . . . . . . . . . . 54
15.2. LIFETIME . . . . . . . . . . . . . . . . . . . . . . . . 53 15.2. LIFETIME . . . . . . . . . . . . . . . . . . . . . . . . 54
15.3. XOR-PEER-ADDRESS . . . . . . . . . . . . . . . . . . . . 53 15.3. XOR-PEER-ADDRESS . . . . . . . . . . . . . . . . . . . . 54
15.4. DATA . . . . . . . . . . . . . . . . . . . . . . . . . . 53 15.4. DATA . . . . . . . . . . . . . . . . . . . . . . . . . . 54
15.5. XOR-RELAYED-ADDRESS . . . . . . . . . . . . . . . . . . 53 15.5. XOR-RELAYED-ADDRESS . . . . . . . . . . . . . . . . . . 54
15.6. REQUESTED-ADDRESS-FAMILY . . . . . . . . . . . . . . . . 54 15.6. REQUESTED-ADDRESS-FAMILY . . . . . . . . . . . . . . . . 55
15.7. EVEN-PORT . . . . . . . . . . . . . . . . . . . . . . . 54 15.7. EVEN-PORT . . . . . . . . . . . . . . . . . . . . . . . 55
15.8. REQUESTED-TRANSPORT . . . . . . . . . . . . . . . . . . 55 15.8. REQUESTED-TRANSPORT . . . . . . . . . . . . . . . . . . 56
15.9. DONT-FRAGMENT . . . . . . . . . . . . . . . . . . . . . 55 15.9. DONT-FRAGMENT . . . . . . . . . . . . . . . . . . . . . 56
15.10. RESERVATION-TOKEN . . . . . . . . . . . . . . . . . . . 55 15.10. RESERVATION-TOKEN . . . . . . . . . . . . . . . . . . . 56
15.11. ADDITIONAL-ADDRESS-FAMILY . . . . . . . . . . . . . . . 56 15.11. ADDITIONAL-ADDRESS-FAMILY . . . . . . . . . . . . . . . 57
15.12. ADDRESS-ERROR-CODE Attribute . . . . . . . . . . . . . . 56 15.12. ADDRESS-ERROR-CODE Attribute . . . . . . . . . . . . . . 57
15.13. ICMP Attribute . . . . . . . . . . . . . . . . . . . . . 57 15.13. ICMP Attribute . . . . . . . . . . . . . . . . . . . . . 58
16. New STUN Error Response Codes . . . . . . . . . . . . . . . . 57 16. New STUN Error Response Codes . . . . . . . . . . . . . . . . 58
17. Detailed Example . . . . . . . . . . . . . . . . . . . . . . 58 17. Detailed Example . . . . . . . . . . . . . . . . . . . . . . 59
18. Security Considerations . . . . . . . . . . . . . . . . . . . 65 18. Security Considerations . . . . . . . . . . . . . . . . . . . 66
18.1. Outsider Attacks . . . . . . . . . . . . . . . . . . . . 65 18.1. Outsider Attacks . . . . . . . . . . . . . . . . . . . . 66
18.1.1. Obtaining Unauthorized Allocations . . . . . . . . . 65 18.1.1. Obtaining Unauthorized Allocations . . . . . . . . . 66
18.1.2. Offline Dictionary Attacks . . . . . . . . . . . . . 66 18.1.2. Offline Dictionary Attacks . . . . . . . . . . . . . 67
18.1.3. Faked Refreshes and Permissions . . . . . . . . . . 66 18.1.3. Faked Refreshes and Permissions . . . . . . . . . . 67
18.1.4. Fake Data . . . . . . . . . . . . . . . . . . . . . 66 18.1.4. Fake Data . . . . . . . . . . . . . . . . . . . . . 67
18.1.5. Impersonating a Server . . . . . . . . . . . . . . . 67 18.1.5. Impersonating a Server . . . . . . . . . . . . . . . 68
18.1.6. Eavesdropping Traffic . . . . . . . . . . . . . . . 67 18.1.6. Eavesdropping Traffic . . . . . . . . . . . . . . . 68
18.1.7. TURN Loop Attack . . . . . . . . . . . . . . . . . . 68 18.1.7. TURN Loop Attack . . . . . . . . . . . . . . . . . . 69
18.2. Firewall Considerations . . . . . . . . . . . . . . . . 69 18.2. Firewall Considerations . . . . . . . . . . . . . . . . 70
18.2.1. Faked Permissions . . . . . . . . . . . . . . . . . 69 18.2.1. Faked Permissions . . . . . . . . . . . . . . . . . 70
18.2.2. Blacklisted IP Addresses . . . . . . . . . . . . . . 70 18.2.2. Blacklisted IP Addresses . . . . . . . . . . . . . . 71
18.2.3. Running Servers on Well-Known Ports . . . . . . . . 70 18.2.3. Running Servers on Well-Known Ports . . . . . . . . 71
18.3. Insider Attacks . . . . . . . . . . . . . . . . . . . . 71
18.3. Insider Attacks . . . . . . . . . . . . . . . . . . . . 70 18.3.1. DoS against TURN Server . . . . . . . . . . . . . . 71
18.3.1. DoS against TURN Server . . . . . . . . . . . . . . 70 18.3.2. Anonymous Relaying of Malicious Traffic . . . . . . 72
18.3.2. Anonymous Relaying of Malicious Traffic . . . . . . 71 18.3.3. Manipulating Other Allocations . . . . . . . . . . . 72
18.3.3. Manipulating Other Allocations . . . . . . . . . . . 71 18.4. Tunnel Amplification Attack . . . . . . . . . . . . . . 72
18.4. Tunnel Amplification Attack . . . . . . . . . . . . . . 71 18.5. Other Considerations . . . . . . . . . . . . . . . . . . 73
18.5. Other Considerations . . . . . . . . . . . . . . . . . . 72 19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 73
19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 72 20. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 74
20. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 73 21. Changes since RFC 5766 . . . . . . . . . . . . . . . . . . . 76
21. Changes since RFC 5766 . . . . . . . . . . . . . . . . . . . 75 22. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 76
22. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 75 23. References . . . . . . . . . . . . . . . . . . . . . . . . . 77
23. References . . . . . . . . . . . . . . . . . . . . . . . . . 76 23.1. Normative References . . . . . . . . . . . . . . . . . . 77
23.1. Normative References . . . . . . . . . . . . . . . . . . 76 23.2. Informative References . . . . . . . . . . . . . . . . . 78
23.2. Informative References . . . . . . . . . . . . . . . . . 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 81
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 80
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 18, line 25 skipping to change at page 18, line 25
even port number and the associated RTP Control Protocol (RTCP) even port number and the associated RTP Control Protocol (RTCP)
stream, if present, be on the next highest port. To allow clients to stream, if present, be on the next highest port. To allow clients to
work with peers that still require this, TURN allows the client to work with peers that still require this, TURN allows the client to
request that the server allocate a relayed transport address with an request that the server allocate a relayed transport address with an
even port number, and to optionally request the server reserve the even port number, and to optionally request the server reserve the
next-highest port number for a subsequent allocation. next-highest port number for a subsequent allocation.
2.9. Discovery of TURN server 2.9. Discovery of TURN server
Methods of TURN server discovery, including using anycast, are Methods of TURN server discovery, including using anycast, are
described in [I-D.ietf-tram-turn-server-discovery]. The syntax of described in [RFC8155]. The syntax of the "turn" and "turn" URIs are
the "turn" and "turn" URIs are defined in Section 3.1 of [RFC7065]. defined in Section 3.1 of [RFC7065].
2.9.1. TURN URI Scheme Semantics 2.9.1. TURN URI Scheme Semantics
The "turn" and "turns" URI schemes are used to designate a TURN The "turn" and "turns" URI schemes are used to designate a TURN
server (also known as a relay) on Internet hosts accessible using the server (also known as a relay) on Internet hosts accessible using the
TURN protocol. The TURN protocol supports sending messages over UDP, TURN protocol. The TURN protocol supports sending messages over UDP,
TCP, TLS-over-TCP or DTLS-over-UDP. The "turns" URI scheme MUST be TCP, TLS-over-TCP or DTLS-over-UDP. The "turns" URI scheme MUST be
used when TURN is run over TLS-over-TCP or in DTLS-over-UDP, and the used when TURN is run over TLS-over-TCP or in DTLS-over-UDP, and the
"turn" scheme MUST be used otherwise. The required <host> part of "turn" scheme MUST be used otherwise. The required <host> part of
the "turn" URI denotes the TURN server host. The <port> part, if the "turn" URI denotes the TURN server host. The <port> part, if
present, denotes the port on which the TURN server is awaiting present, denotes the port on which the TURN server is awaiting
connection requests. If it is absent, the default port is 3478 for connection requests. If it is absent, the default port is 3478 for
both UDP and TCP. The default port for TURN over TLS and TURN over both UDP and TCP. The default port for TURN over TLS and TURN over
DTLS is 5349. DTLS is 5349.
2.10. Happy Eyeballs for TURN
If an IPv4 path to reach a TURN server is found, but the TURN
server's IPv6 path is not working, a dual-stack TURN client can
experience a significant connection delay compared to an IPv4-only
TURN client. To overcome these connection setup problems, the TURN
client MUST query both A and AAAA records for the TURN server
specified using a domain name and try connecting to the TURN server
using both IPv6 and IPv4 addresses in a fashion similar to the Happy
Eyeballs mechanism defined in [RFC6555]. The TURN client performs
the following steps based on the transport protocol being used to
connect to the TURN server.
o For TCP, initiate TCP connection to both IP address families as
discussed in [RFC6555], and use the first TCP connection that is
established. If connections are established on both IP address
families then terminate the TCP connection using the IP address
family with lower precedence [RFC6724].
o For clear text UDP, send TURN Allocate requests to both IP address
families as discussed in [RFC6555], without authentication
information. If the TURN server requires authentication, it will
send back a 401 unauthenticated response and the TURN client uses
the first UDP connection on which a 401 error response is
received. If a 401 error response is received from both IP
address families then the TURN client will silently abandon the
UDP connection on the IP address family with lower precedence. If
the TURN server does not require authentication (as described in
Section 9 of [RFC8155]), it is possible for both Allocate requests
to succeed. In this case, the TURN client sends a Refresh with
LIFETIME value of 0 on the allocation using the IP address family
with lower precedence to delete the allocation.
o For DTLS over UDP, initiate DTLS handshake to both IP address
families as discussed in [RFC6555] and use the first DTLS session
that is established. If the DTLS session is established on both
IP addresses families then the client sends DTLS close_notify
alert to terminate the DTLS session using 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 [RFC5389] and the terms
defined there. defined there.
The following terms are used in this document: The following terms are used in this document:
skipping to change at page 24, line 30 skipping to change at page 25, line 26
over-TCP or DTLS-over-UDP. Since this specification only allows UDP over-TCP or DTLS-over-UDP. Since this specification only allows UDP
between the server and the peers, it is RECOMMENDED that the client between the server and the peers, it is RECOMMENDED that the client
pick UDP unless it has a reason to use a different transport. One pick UDP unless it has a reason to use a different transport. One
reason to pick a different transport would be that the client reason to pick a different transport would be that the client
believes, either through configuration or by experiment, that it is believes, either through configuration or by experiment, that it is
unable to contact any TURN server using UDP. See Section 2.1 for unable to contact any TURN server using UDP. See Section 2.1 for
more discussion. more discussion.
The client also picks a server transport address, which SHOULD be The client also picks a server transport address, which SHOULD be
done as follows. The client uses the procedures described in done as follows. The client uses the procedures described in
[I-D.ietf-tram-turn-server-discovery] to discover a TURN server and [RFC8155] to discover a TURN server and TURN server resolution
TURN server resolution mechanism defined in [RFC5928] to get a list mechanism defined in [RFC5928] to get a list of server transport
of server transport addresses that can be tried to create a TURN addresses that can be tried to create a TURN allocation.
allocation.
The client MUST include a REQUESTED-TRANSPORT attribute in the The client MUST include a REQUESTED-TRANSPORT attribute in the
request. This attribute specifies the transport protocol between the request. This attribute specifies the transport protocol between the
server and the peers (note that this is NOT the transport protocol server and the peers (note that this is NOT the transport protocol
that appears in the 5-tuple). In this specification, the REQUESTED- that appears in the 5-tuple). In this specification, the REQUESTED-
TRANSPORT type is always UDP. This attribute is included to allow TRANSPORT type is always UDP. This attribute is included to allow
future extensions to specify other protocols. future extensions to specify other protocols.
If the client wishes to obtain a relayed transport address of a If the client wishes to obtain a relayed transport address of a
specific address type then it includes a REQUESTED-ADDRESS-FAMILY specific address type then it includes a REQUESTED-ADDRESS-FAMILY
skipping to change at page 77, line 14 skipping to change at page 78, line 14
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
Control Message Protocol (ICMPv6) for the Internet Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification", RFC 4443, Protocol Version 6 (IPv6) Specification", RFC 4443,
DOI 10.17487/RFC4443, March 2006, DOI 10.17487/RFC4443, March 2006,
<http://www.rfc-editor.org/info/rfc4443>. <http://www.rfc-editor.org/info/rfc4443>.
[I-D.ietf-tram-stunbis] [I-D.ietf-tram-stunbis]
Petit-Huguenin, M., Salgueiro, G., Rosenberg, J., Wing, Petit-Huguenin, M., Salgueiro, G., Rosenberg, J., Wing,
D., Mahy, R., and P. Matthews, "Session Traversal D., Mahy, R., and P. Matthews, "Session Traversal
Utilities for NAT (STUN)", draft-ietf-tram-stunbis-08 Utilities for NAT (STUN)", draft-ietf-tram-stunbis-12
(work in progress), June 2016. (work in progress), March 2017.
[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,
<http://www.rfc-editor.org/info/rfc6724>.
[RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with
Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April
2012, <http://www.rfc-editor.org/info/rfc6555>.
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,
DOI 10.17487/RFC1191, November 1990, DOI 10.17487/RFC1191, November 1990,
<http://www.rfc-editor.org/info/rfc1191>. <http://www.rfc-editor.org/info/rfc1191>.
[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>. <http://www.rfc-editor.org/info/rfc791>.
skipping to change at page 79, line 14 skipping to change at page 80, line 24
[I-D.rosenberg-mmusic-ice-nonsip] [I-D.rosenberg-mmusic-ice-nonsip]
Rosenberg, J., "Guidelines for Usage of Interactive Rosenberg, J., "Guidelines for Usage of Interactive
Connectivity Establishment (ICE) by non Session Initiation Connectivity Establishment (ICE) by non Session Initiation
Protocol (SIP) Protocols", draft-rosenberg-mmusic-ice- Protocol (SIP) Protocols", draft-rosenberg-mmusic-ice-
nonsip-01 (work in progress), July 2008. nonsip-01 (work in progress), July 2008.
[I-D.ietf-tram-stun-pmtud] [I-D.ietf-tram-stun-pmtud]
Petit-Huguenin, M. and G. Salgueiro, "Path MTU Discovery Petit-Huguenin, M. and G. Salgueiro, "Path MTU Discovery
Using Session Traversal Utilities for NAT (STUN)", draft- Using Session Traversal Utilities for NAT (STUN)", draft-
ietf-tram-stun-pmtud-03 (work in progress), October 2016. ietf-tram-stun-pmtud-05 (work in progress), February 2017.
[I-D.ietf-tram-turn-server-discovery] [RFC8155] Patil, P., Reddy, T., and D. Wing, "Traversal Using Relays
Patil, P., Reddy, T., and D. Wing, "TURN Server Auto around NAT (TURN) Server Auto Discovery", RFC 8155,
Discovery", draft-ietf-tram-turn-server-discovery-10 (work DOI 10.17487/RFC8155, April 2017,
in progress), October 2016. <http://www.rfc-editor.org/info/rfc8155>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086, "Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005, DOI 10.17487/RFC4086, June 2005,
<http://www.rfc-editor.org/info/rfc4086>. <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, Traversal Utilities for NAT (STUN)", RFC 5766,
DOI 10.17487/RFC5766, April 2010, DOI 10.17487/RFC5766, April 2010,
skipping to change at page 80, line 8 skipping to change at page 81, line 16
"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]
"IANA Protocol Numbers Registry", 2005, "IANA Protocol Numbers Registry", 2005,
<http://www.iana.org/assignments/protocol-numbers>. <http://www.iana.org/assignments/protocol-numbers>.
Authors' Addresses Authors' Addresses
Tirumaleswar Reddy (editor) Tirumaleswar Reddy (editor)
Cisco Systems, Inc.
Cessna Business Park, Varthur Hobl
Sarjapur Marathalli Outer Ring Road
Bangalore, Karnataka 560103 Bangalore, Karnataka 560103
India India
Email: tireddy@cisco.com Email: kondtir@gmail.com
Alan Johnston (editor) Alan Johnston (editor)
Unaffiliated Unaffiliated
Bellevue, WA Bellevue, WA
USA USA
Email: alan.b.johnston@gmail.com Email: alan.b.johnston@gmail.com
Philip Matthews Philip Matthews
Alcatel-Lucent Alcatel-Lucent
 End of changes. 20 change blocks. 
100 lines changed or deleted 145 lines changed or added

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