draft-ietf-tram-turnbis-15.txt   draft-ietf-tram-turnbis-16.txt 
TRAM WG T. Reddy, Ed. TRAM WG T. Reddy, Ed.
Internet-Draft McAfee Internet-Draft McAfee
Obsoletes: 5766,6156 (if approved) A. Johnston, Ed. Obsoletes: 5766,6156 (if approved) A. Johnston, Ed.
Intended status: Standards Track Rowan University Intended status: Standards Track Rowan University
Expires: September 19, 2018 P. Matthews Expires: September 28, 2018 P. Matthews
Alcatel-Lucent Alcatel-Lucent
J. Rosenberg J. Rosenberg
jdrosen.net jdrosen.net
March 18, 2018 March 27, 2018
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-15 draft-ietf-tram-turnbis-16
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 2, line 4 skipping to change at page 2, line 4
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 https://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 September 19, 2018. This Internet-Draft will expire on September 28, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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
(https://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
skipping to change at page 43, line 19 skipping to change at page 43, line 19
and Data indications. and Data indications.
The ChannelData message (see Section 12.4) starts with a two-byte The ChannelData message (see Section 12.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:
0x0000 through 0x3FFF: These values can never be used for channel 0x0000 through 0x3FFF: These values can never be used for channel
numbers. numbers.
0x4000 through 0x4FFF: These values are the allowed channel 0x4000 through 0x4FFF: These values are the allowed channel
numbers (16,384 possible values). numbers (4096 possible values).
0x5000-0xFFFF: Reserved (For DTLS-SRTP multiplexing collision 0x5000-0xFFFF: Reserved (For DTLS-SRTP multiplexing collision
avoidance, see [RFC7983]. avoidance, see [RFC7983].
0x8000 through 0xFFFF: These values are reserved for future use. According to [RFC7983], ChannelData messages can be distinguished
from other multiplexed protocols by examining the first byte of the
message:
Because of this division, ChannelData messages can be distinguished [0..3] STUN
from STUN-formatted messages (e.g., Allocate request, Send
indication, etc.) by examining the first two bits of the message:
0b00: STUN-formatted message (since the first two bits of a STUN- [16..19] ZRTP
formatted message are always zero).
0b01: ChannelData message (since the channel number is the first [20..63] DTLS
field in the ChannelData message and channel numbers fall in the
range 0x4000 - 0x7FFF).
0b10: Reserved [64..79] TURN Channel
0b11: Reserved [128..191] RTP/RTCP
The reserved values may be used in the future to extend the range of others Reserved, MUST be dropped and an alert MAY be logged
channel numbers. Thus, an implementation MUST NOT assume that a TURN
message always starts with a 0 bit. Reserved values may be used in the future by other protocols. When
the client uses channel binding, it MUST comply with the
demultiplexing scheme discussed above.
Channel bindings are always initiated by the client. The client can Channel bindings are always initiated by the client. The client can
bind a channel to a peer at any time during the lifetime of the bind a channel to a peer at any time during the lifetime of the
allocation. The client may bind a channel to a peer before allocation. The client may bind a channel to a peer before
exchanging data with it, or after exchanging data with it (using Send exchanging data with it, or after exchanging data with it (using Send
and Data indications) for some time, or may choose never to bind a and Data indications) for some time, or may choose never to bind a
channel to it. The client can also bind channels to some peers while channel to it. The client can also bind channels to some peers while
not binding channels to other peers. not binding channels to other peers.
Channel bindings are specific to an allocation, so that the use of a Channel bindings are specific to an allocation, so that the use of a
skipping to change at page 67, line 29 skipping to change at page 67, line 29
| REALM="example.com" | | | | REALM="example.com" | | |
| NONCE="obMatJos2AAABnpSw1Xw239bBwGYhjN" | | | NONCE="obMatJos2AAABnpSw1Xw239bBwGYhjN" | |
| PASSWORD-ALGORITHMS=MD5 and SHA256 | | | PASSWORD-ALGORITHMS=MD5 and SHA256 | |
| | | | | | | |
|--- Refresh request --------------->| | | |--- Refresh request --------------->| | |
| Transaction-Id=0x427BD3E625A85FC731DC4191 | | | Transaction-Id=0x427BD3E625A85FC731DC4191 | |
| SOFTWARE="Example client 1.03" | | | | SOFTWARE="Example client 1.03" | | |
| USERNAME="George" | | | | USERNAME="George" | | |
| REALM="example.com" | | | | REALM="example.com" | | |
| NONCE="obMatJos2AAABnpSw1Xw239bBwGYhjNj" | | | NONCE="obMatJos2AAABnpSw1Xw239bBwGYhjNj" | |
| PASSWORD-ALGORITHMS=MD5 and SHA256 | |
| PASSWORD-ALGORITHM=SHA256 | | | | PASSWORD-ALGORITHM=SHA256 | | |
| MESSAGE-INTEGRITY=... | | | | MESSAGE-INTEGRITY=... | | |
| | | | | | | |
|<-- Refresh success response -------| | | |<-- Refresh success response -------| | |
| Transaction-Id=0x427BD3E625A85FC731DC4191 | | | Transaction-Id=0x427BD3E625A85FC731DC4191 | |
| SOFTWARE="Example server, version 1.17" | | | SOFTWARE="Example server, version 1.17" | |
| LIFETIME=600 (10 minutes) | | | | LIFETIME=600 (10 minutes) | | |
Sometime before the 20 minute lifetime is up, the client refreshes Sometime before the 20 minute lifetime is up, the client refreshes
the allocation. This is done using a Refresh request. As before, the allocation. This is done using a Refresh request. As before,
 End of changes. 13 change blocks. 
19 lines changed or deleted 19 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/