WebRTC Data Channel Establishment Protocol
RFC 8832
| Document | Type | RFC - Proposed Standard (January 2021; Errata) | |
|---|---|---|---|
| Authors | Randell Jesup , Salvatore Loreto , Michael Tüxen | ||
| Last updated | 2021-01-26 | ||
| Replaces | draft-jesup-rtcweb-data-protocol | ||
| Stream | Internet Engineering Task Force (IETF) | ||
| Formats | plain text html xml pdf htmlized (tools) htmlized bibtex | ||
| Reviews | |||
| Stream | WG state | Submitted to IESG for Publication | |
| Document shepherd | Ted Hardie | ||
| Shepherd write-up | Show (last changed 2014-10-09) | ||
| IESG | IESG state | RFC 8832 (Proposed Standard) | |
| Action Holders |
(None)
|
||
| Consensus Boilerplate | Yes | ||
| Telechat date | |||
| Responsible AD | Alissa Cooper | ||
| Send notices to | (None) | ||
| IANA | IANA review state | Version Changed - Review Needed | |
| IANA action state | RFC-Ed-Ack | ||
Internet Engineering Task Force (IETF) R. Jesup
Request for Comments: 8832 Mozilla
Category: Standards Track S. Loreto
ISSN: 2070-1721 Ericsson
M. Tüxen
Münster Univ. of Appl. Sciences
January 2021
WebRTC Data Channel Establishment Protocol
Abstract
The WebRTC framework specifies protocol support for direct
interactive rich communication using audio, video, and data between
two peers' web browsers. This document specifies a simple protocol
for establishing symmetric data channels between the peers. It uses
a two-way handshake and allows sending of user data without waiting
for the handshake to complete.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8832.
Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction
2. Conventions
3. Terminology
4. Protocol Overview
5. Message Formats
5.1. DATA_CHANNEL_OPEN Message
5.2. DATA_CHANNEL_ACK Message
6. Procedures
7. Security Considerations
8. IANA Considerations
8.1. SCTP Payload Protocol Identifier
8.2. New Standalone Registry for DCEP
8.2.1. New Message Type Registry
8.2.2. New Channel Type Registry
9. References
9.1. Normative References
9.2. Informative References
Acknowledgements
Authors' Addresses
1. Introduction
The Data Channel Establishment Protocol (DCEP) is designed to
provide, in the WebRTC data channel context [RFC8831], a simple in-
band method for opening symmetric data channels. As discussed in
[RFC8831], the protocol uses the Stream Control Transmission Protocol
(SCTP) [RFC4960] encapsulated in Datagram Transport Layer Security
(DTLS) (described in [RFC8261]). This allows DCEP to benefit from
the already standardized transport and security features of SCTP and
DTLS. DTLS 1.0 is defined in [RFC4347]; the present latest version,
DTLS 1.2, is defined in [RFC6347]; and an upcoming version, DTLS 1.3,
is defined in [TLS-DTLS13].
2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP?14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Terminology
This document uses the following terms:
Association: An SCTP association.
Stream: A unidirectional stream of an SCTP association. It is
uniquely identified by an SCTP stream identifier (0-65534). Note:
The SCTP stream identifier 65535 is reserved due to SCTP INIT and
INIT-ACK chunks only allowing a maximum of 65535 streams to be
negotiated (0-65534).
Stream Identifier: The SCTP stream identifier uniquely identifying a
stream.
Data Channel: Two streams with the same stream identifier, one in
each direction, which are managed together.
4. Protocol Overview
The Data Channel Establishment Protocol is a simple, low-overhead way
to establish bidirectional data channels over an SCTP association
with a consistent set of properties.
The set of consistent properties includes:
* reliable or unreliable message transmission. In case of
unreliable transmissions, the same level of unreliability is used.
* in-order or out-of-order message delivery.
* the priority of the data channel.
* an optional label for the data channel.
* an optional protocol for the data channel.
Show full document text