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 IETF
Formats plain text html xml pdf 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