doc: Add RFC documents

1 files changed, 789 insertions, 0 deletions

diff --git a/doc/rfc/rfc8831.txt b/doc/rfc/rfc8831.txt
new file mode 100644
index 0000000..a790137
--- /dev/null
+++ b/doc/rfc/rfc8831.txt
@@ -0,0 +1,789 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                          R. Jesup
+Request for Comments: 8831                                       Mozilla
+Category: Standards Track                                      S. Loreto
+ISSN: 2070-1721                                                 Ericsson
+                                                                M. Tüxen
+                                         Münster Univ. of Appl. Sciences
+                                                            January 2021
+
+
+                          WebRTC Data Channels
+
+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 the non-media data
+   transport aspects of the WebRTC framework.  It provides an
+   architectural overview of how the Stream Control Transmission
+   Protocol (SCTP) is used in the WebRTC context as a generic transport
+   service that allows web browsers to exchange generic data from peer
+   to peer.
+
+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/rfc8831.
+
+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.  Use Cases
+     3.1.  Use Cases for Unreliable Data Channels
+     3.2.  Use Cases for Reliable Data Channels
+   4.  Requirements
+   5.  SCTP over DTLS over UDP Considerations
+   6.  The Usage of SCTP for Data Channels
+     6.1.  SCTP Protocol Considerations
+     6.2.  SCTP Association Management
+     6.3.  SCTP Streams
+     6.4.  Data Channel Definition
+     6.5.  Opening a Data Channel
+     6.6.  Transferring User Data on a Data Channel
+     6.7.  Closing a Data Channel
+   7.  Security Considerations
+   8.  IANA Considerations
+   9.  References
+     9.1.  Normative References
+     9.2.  Informative References
+   Acknowledgements
+   Authors' Addresses
+
+1.  Introduction
+
+   In the WebRTC framework, communication between the parties consists
+   of media (for example, audio and video) and non-media data.  Media is
+   sent using the Secure Real-time Transport Protocol (SRTP) and is not
+   specified further here.  Non-media data is handled by using the
+   Stream Control Transmission Protocol (SCTP) [RFC4960] encapsulated in
+   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].
+
+                               +----------+
+                               |   SCTP   |
+                               +----------+
+                               |   DTLS   |
+                               +----------+
+                               | ICE/UDP  |
+                               +----------+
+
+                       Figure 1: Basic Stack Diagram
+
+   The encapsulation of SCTP over DTLS (see [RFC8261]) over ICE/UDP (see
+   [RFC8445]) provides a NAT traversal solution together with
+   confidentiality, source authentication, and integrity-protected
+   transfers.  This data transport service operates in parallel to the
+   SRTP media transports, and all of them can eventually share a single
+   UDP port number.
+
+   SCTP, as specified in [RFC4960] with the partial reliability
+   extension (PR-SCTP) defined in [RFC3758] and the additional policies
+   defined in [RFC7496], provides multiple streams natively with
+   reliable, and the relevant partially reliable, delivery modes for
+   user messages.  Using the reconfiguration extension defined in
+   [RFC6525] allows an increase in the number of streams during the
+   lifetime of an SCTP association and allows individual SCTP streams to
+   be reset.  Using [RFC8260] allows the interleave of large messages to
+   avoid monopolization and adds support for prioritizing SCTP streams.
+
+   The remainder of this document is organized as follows: Sections 3
+   and 4 provide use cases and requirements for both unreliable and
+   reliable peer-to-peer data channels; Section 5 discusses SCTP over
+   DTLS over UDP; and Section 6 specifies how SCTP should be used by the
+   WebRTC protocol framework for transporting non-media data between web
+   browsers.
+
+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.  Use Cases
+
+   This section defines use cases specific to data channels.  Please
+   note that this section is informational only.
+
+3.1.  Use Cases for Unreliable Data Channels
+
+   U-C 1:  A real-time game where position and object state information
+           are sent via one or more unreliable data channels.  Note that
+           at any time, there may not be any SRTP media channels or all
+           SRTP media channels may be inactive, and there may also be
+           reliable data channels in use.
+
+   U-C 2:  Providing non-critical information to a user about the reason
+           for a state update in a video chat or conference, such as
+           mute state.
+
+3.2.  Use Cases for Reliable Data Channels
+
+   U-C 3:  A real-time game where critical state information needs to be
+           transferred, such as control information.  Such a game may
+           have no SRTP media channels, or they may be inactive at any
+           given time or may only be added due to in-game actions.
+
+   U-C 4:  Non-real-time file transfers between people chatting.  Note
+           that this may involve a large number of files to transfer
+           sequentially or in parallel, such as when sharing a folder of
+           images or a directory of files.
+
+   U-C 5:  Real-time text chat during an audio and/or video call with an
+           individual or with multiple people in a conference.
+
+   U-C 6:  Renegotiation of the configuration of the PeerConnection.
+
+   U-C 7:  Proxy browsing, where a browser uses data channels of a
+           PeerConnection to send and receive HTTP/HTTPS requests and
+           data, for example, to avoid local Internet filtering or
+           monitoring.
+
+4.  Requirements
+
+   This section lists the requirements for Peer-to-Peer (P2P) data
+   channels between two browsers.  Please note that this section is
+   informational only.
+
+   Req. 1:   Multiple simultaneous data channels must be supported.
+             Note that there may be zero or more SRTP media streams in
+             parallel with the data channels in the same PeerConnection,
+             and the number and state (active/inactive) of these SRTP
+             media streams may change at any time.
+
+   Req. 2:   Both reliable and unreliable data channels must be
+             supported.
+
+   Req. 3:   Data channels of a PeerConnection must be congestion
+             controlled either individually, as a class, or in
+             conjunction with the SRTP media streams of the
+             PeerConnection.  This ensures that data channels don't
+             cause congestion problems for these SRTP media streams, and
+             that the WebRTC PeerConnection does not cause excessive
+             problems when run in parallel with TCP connections.
+
+   Req. 4:   The application should be able to provide guidance as to
+             the relative priority of each data channel relative to each
+             other and relative to the SRTP media streams.  This will
+             interact with the congestion control algorithms.
+
+   Req. 5:   Data channels must be secured, which allows for
+             confidentiality, integrity, and source authentication.  See
+             [RFC8826] and [RFC8827] for detailed information.
+
+   Req. 6:   Data channels must provide message fragmentation support
+             such that IP-layer fragmentation can be avoided no matter
+             how large a message the JavaScript application passes to be
+             sent.  It also must ensure that large data channel
+             transfers don't unduly delay traffic on other data
+             channels.
+
+   Req. 7:   The data channel transport protocol must not encode local
+             IP addresses inside its protocol fields; doing so reveals
+             potentially private information and leads to failure if the
+             address is depended upon.
+
+   Req. 8:   The data channel transport protocol should support
+             unbounded-length "messages" (i.e., a virtual socket stream)
+             at the application layer for such things as image-file-
+             transfer; implementations might enforce a reasonable
+             message size limit.
+
+   Req. 9:   The data channel transport protocol should avoid IP
+             fragmentation.  It must support Path MTU (PMTU) discovery
+             and must not rely on ICMP or ICMPv6 being generated or
+             being passed back, especially for PMTU discovery.
+
+   Req. 10:  It must be possible to implement the protocol stack in the
+             user application space.
+
+5.  SCTP over DTLS over UDP Considerations
+
+   The important features of SCTP in the WebRTC context are the
+   following:
+
+   *  Usage of TCP-friendly congestion control.
+
+   *  modifiable congestion control for integration with the SRTP media
+      stream congestion control.
+
+   *  Support of multiple unidirectional streams, each providing its own
+      notion of ordered message delivery.
+
+   *  Support of ordered and out-of-order message delivery.
+
+   *  Support of arbitrarily large user messages by providing
+      fragmentation and reassembly.
+
+   *  Support of PMTU discovery.
+
+   *  Support of reliable or partially reliable message transport.
+
+   The WebRTC data channel mechanism does not support SCTP multihoming.
+   The SCTP layer will simply act as if it were running on a single-
+   homed host, since that is the abstraction that the DTLS layer (a
+   connection-oriented, unreliable datagram service) exposes.
+
+   The encapsulation of SCTP over DTLS defined in [RFC8261] provides
+   confidentiality, source authentication, and integrity-protected
+   transfers.  Using DTLS over UDP in combination with Interactive
+   Connectivity Establishment (ICE) [RFC8445] enables middlebox
+   traversal in IPv4- and IPv6-based networks.  SCTP as specified in
+   [RFC4960] MUST be used in combination with the extension defined in
+   [RFC3758] and provides the following features for transporting non-
+   media data between browsers:
+
+   *  Support of multiple unidirectional streams.
+
+   *  Ordered and unordered delivery of user messages.
+
+   *  Reliable and partially reliable transport of user messages.
+
+   Each SCTP user message contains a Payload Protocol Identifier (PPID)
+   that is passed to SCTP by its upper layer on the sending side and
+   provided to its upper layer on the receiving side.  The PPID can be
+   used to multiplex/demultiplex multiple upper layers over a single
+   SCTP association.  In the WebRTC context, the PPID is used to
+   distinguish between UTF-8 encoded user data, binary-encoded user
+   data, and the Data Channel Establishment Protocol (DCEP) defined in
+   [RFC8832].  Please note that the PPID is not accessible via the
+   JavaScript API.
+
+   The encapsulation of SCTP over DTLS, together with the SCTP features
+   listed above, satisfies all the requirements listed in Section 4.
+
+   The layering of protocols for WebRTC is shown in Figure 2.
+
+                                 +------+------+------+
+                                 | DCEP | UTF-8|Binary|
+                                 |      | Data | Data |
+                                 +------+------+------+
+                                 |        SCTP        |
+                   +----------------------------------+
+                   | STUN | SRTP |        DTLS        |
+                   +----------------------------------+
+                   |                ICE               |
+                   +----------------------------------+
+                   | UDP1 | UDP2 | UDP3 | ...         |
+                   +----------------------------------+
+
+                      Figure 2: WebRTC Protocol Layers
+
+   This stack (especially in contrast to DTLS over SCTP [RFC6083] and in
+   combination with SCTP over UDP [RFC6951]) has been chosen for the
+   following reasons:
+
+   *  supports the transmission of arbitrarily large user messages;
+
+   *  shares the DTLS connection with the SRTP media channels of the
+      PeerConnection; and
+
+   *  provides privacy for the SCTP control information.
+
+   Referring to the protocol stack shown in Figure 2:
+
+   *  the usage of DTLS 1.0 over UDP is specified in [RFC4347];
+
+   *  the usage of DTLS 1.2 over UDP in specified in [RFC6347];
+
+   *  the usage of DTLS 1.3 over UDP is specified in an upcoming
+      document [TLS-DTLS13]; and
+
+   *  the usage of SCTP on top of DTLS is specified in [RFC8261].
+
+   Please note that the demultiplexing Session Traversal Utilities for
+   NAT (STUN) [RFC5389] vs. SRTP vs. DTLS is done as described in
+   Section 5.1.2 of [RFC5764], and SCTP is the only payload of DTLS.
+
+   Since DTLS is typically implemented in user application space, the
+   SCTP stack also needs to be a user application space stack.
+
+   The ICE/UDP layer can handle IP address changes during a session
+   without needing interaction with the DTLS and SCTP layers.  However,
+   SCTP SHOULD be notified when an address change has happened.  In this
+   case, SCTP SHOULD retest the Path MTU and reset the congestion state
+   to the initial state.  In the case of window-based congestion control
+   like the one specified in [RFC4960], this means setting the
+   congestion window and slow-start threshold to its initial values.
+
+   Incoming ICMP or ICMPv6 messages can't be processed by the SCTP
+   layer, since there is no way to identify the corresponding
+   association.  Therefore, SCTP MUST support performing Path MTU
+   discovery without relying on ICMP or ICMPv6 as specified in [RFC4821]
+   by using probing messages specified in [RFC4820].  The initial Path
+   MTU at the IP layer SHOULD NOT exceed 1200 bytes for IPv4 and 1280
+   bytes for IPv6.
+
+   In general, the lower-layer interface of an SCTP implementation
+   should be adapted to address the differences between IPv4 and IPv6
+   (being connectionless) or DTLS (being connection oriented).
+
+   When the protocol stack shown in Figure 2 is used, DTLS protects the
+   complete SCTP packet, so it provides confidentiality, integrity, and
+   source authentication of the complete SCTP packet.
+
+   SCTP provides congestion control on a per-association basis.  This
+   means that all SCTP streams within a single SCTP association share
+   the same congestion window.  Traffic not being sent over SCTP is not
+   covered by SCTP congestion control.  Using a congestion control
+   different from the standard one might improve the impact on the
+   parallel SRTP media streams.
+
+   SCTP uses the same port number concept as TCP and UDP.  Therefore, an
+   SCTP association uses two port numbers, one at each SCTP endpoint.
+
+6.  The Usage of SCTP for Data Channels
+
+6.1.  SCTP Protocol Considerations
+
+   The DTLS encapsulation of SCTP packets as described in [RFC8261] MUST
+   be used.
+
+   This SCTP stack and its upper layer MUST support the usage of
+   multiple SCTP streams.  A user message can be sent ordered or
+   unordered and with partial or full reliability.
+
+   The following SCTP protocol extensions are required:
+
+   *  The stream reconfiguration extension defined in [RFC6525] MUST be
+      supported.  It is used for closing channels.
+
+   *  The dynamic address reconfiguration extension defined in [RFC5061]
+      MUST be used to signal the support of the stream reset extension
+      defined in [RFC6525].  Other features of [RFC5061] are OPTIONAL.
+
+   *  The partial reliability extension defined in [RFC3758] MUST be
+      supported.  In addition to the timed reliability PR-SCTP policy
+      defined in [RFC3758], the limited retransmission policy defined in
+      [RFC7496] MUST be supported.  Limiting the number of
+      retransmissions to zero, combined with unordered delivery,
+      provides a UDP-like service where each user message is sent
+      exactly once and delivered in the order received.
+
+   The support for message interleaving as defined in [RFC8260] SHOULD
+   be used.
+
+6.2.  SCTP Association Management
+
+   In the WebRTC context, the SCTP association will be set up when the
+   two endpoints of the WebRTC PeerConnection agree on opening it, as
+   negotiated by the JavaScript Session Establishment Protocol (JSEP),
+   which is typically an exchange of the Session Description Protocol
+   (SDP) [RFC8829].  It will use the DTLS connection selected via ICE,
+   and typically this will be shared via BUNDLE or equivalent with DTLS
+   connections used to key the SRTP media streams.
+
+   The number of streams negotiated during SCTP association setup SHOULD
+   be 65535, which is the maximum number of streams that can be
+   negotiated during the association setup.
+
+   SCTP supports two ways of terminating an SCTP association.  The first
+   method is a graceful one, where a procedure that ensures no messages
+   are lost during the shutdown of the association is used.  The second
+   method is a non-graceful one, where one side can just abort the
+   association.
+
+   Each SCTP endpoint continuously supervises the reachability of its
+   peer by monitoring the number of retransmissions of user messages and
+   test messages.  In case of excessive retransmissions, the association
+   is terminated in a non-graceful way.
+
+   If an SCTP association is closed in a graceful way, all of its data
+   channels are closed.  In case of a non-graceful teardown, all data
+   channels are also closed, but an error indication SHOULD be provided
+   if possible.
+
+6.3.  SCTP Streams
+
+   SCTP defines a stream as a unidirectional logical channel existing
+   within an SCTP association to another SCTP endpoint.  The streams are
+   used to provide the notion of in-sequence delivery and for
+   multiplexing.  Each user message is sent on a particular stream,
+   either ordered or unordered.  Ordering is preserved only for ordered
+   messages sent on the same stream.
+
+6.4.  Data Channel Definition
+
+   Data channels are defined such that their accompanying application-
+   level API can closely mirror the API for WebSockets, which implies
+   bidirectional streams of data and a textual field called 'label' used
+   to identify the meaning of the data channel.
+
+   The realization of a data channel is a pair of one incoming stream
+   and one outgoing SCTP stream having the same SCTP stream identifier.
+   How these SCTP stream identifiers are selected is protocol and
+   implementation dependent.  This allows a bidirectional communication.
+
+   Additionally, each data channel has the following properties in each
+   direction:
+
+   *  reliable or unreliable message transmission: In case of unreliable
+      transmissions, the same level of unreliability is used.  Note
+      that, in SCTP, this is a property of an SCTP user message and not
+      of an SCTP stream.
+
+   *  in-order or out-of-order message delivery for message sent: Note
+      that, in SCTP, this is a property of an SCTP user message and not
+      of an SCTP stream.
+
+   *  a priority, which is a 2-byte unsigned integer: These priorities
+      MUST be interpreted as weighted-fair-queuing scheduling priorities
+      per the definition of the corresponding stream scheduler
+      supporting interleaving in [RFC8260].  For use in WebRTC, the
+      values used SHOULD be one of 128 ("below normal"), 256 ("normal"),
+      512 ("high"), or 1024 ("extra high").
+
+   *  an optional label.
+
+   *  an optional protocol.
+
+   Note that for a data channel being negotiated with the protocol
+   specified in [RFC8832], all of the above properties are the same in
+   both directions.
+
+6.5.  Opening a Data Channel
+
+   Data channels can be opened by using negotiation within the SCTP
+   association (called in-band negotiation) or out-of-band negotiation.
+   Out-of-band negotiation is defined as any method that results in an
+   agreement as to the parameters of a channel and the creation thereof.
+   The details are out of scope of this document.  Applications using
+   data channels need to use the negotiation methods consistently on
+   both endpoints.
+
+   A simple protocol for in-band negotiation is specified in [RFC8832].
+
+   When one side wants to open a channel using out-of-band negotiation,
+   it picks a stream.  Unless otherwise defined or negotiated, the
+   streams are picked based on the DTLS role (the client picks even
+   stream identifiers, and the server picks odd stream identifiers).
+   However, the application is responsible for avoiding collisions with
+   existing streams.  If it attempts to reuse a stream that is part of
+   an existing data channel, the addition MUST fail.  In addition to
+   choosing a stream, the application SHOULD also determine the options
+   to be used for sending messages.  The application MUST ensure in an
+   application-specific manner that the application at the peer will
+   also know the selected stream to be used, as well as the options for
+   sending data from that side.
+
+6.6.  Transferring User Data on a Data Channel
+
+   All data sent on a data channel in both directions MUST be sent over
+   the underlying stream using the reliability defined when the data
+   channel was opened, unless the options are changed or per-message
+   options are specified by a higher level.
+
+   The message orientation of SCTP is used to preserve the message
+   boundaries of user messages.  Therefore, senders MUST NOT put more
+   than one application message into an SCTP user message.  Unless the
+   deprecated PPID-based fragmentation and reassembly is used, the
+   sender MUST include exactly one application message in each SCTP user
+   message.
+
+   The SCTP Payload Protocol Identifiers (PPIDs) are used to signal the
+   interpretation of the "payload data".  The following PPIDs MUST be
+   used (see Section 8):
+
+   WebRTC String:  to identify a non-empty JavaScript string encoded in
+      UTF-8.
+
+   WebRTC String Empty:  to identify an empty JavaScript string encoded
+      in UTF-8.
+
+   WebRTC Binary:  to identify non-empty JavaScript binary data
+      (ArrayBuffer, ArrayBufferView, or Blob).
+
+   WebRTC Binary Empty:  to identify empty JavaScript binary data
+      (ArrayBuffer, ArrayBufferView, or Blob).
+
+   SCTP does not support the sending of empty user messages.  Therefore,
+   if an empty message has to be sent, the appropriate PPID (WebRTC
+   String Empty or WebRTC Binary Empty) is used, and the SCTP user
+   message of one zero byte is sent.  When receiving an SCTP user
+   message with one of these PPIDs, the receiver MUST ignore the SCTP
+   user message and process it as an empty message.
+
+   The usage of the PPIDs "WebRTC String Partial" and "WebRTC Binary
+   Partial" is deprecated.  They were used for a PPID-based
+   fragmentation and reassembly of user messages belonging to reliable
+   and ordered data channels.
+
+   If a message with an unsupported PPID is received or some error
+   condition related to the received message is detected by the receiver
+   (for example, illegal ordering), the receiver SHOULD close the
+   corresponding data channel.  This implies in particular that
+   extensions using additional PPIDs can't be used without prior
+   negotiation.
+
+   The SCTP base protocol specified in [RFC4960] does not support the
+   interleaving of user messages.  Therefore, sending a large user
+   message can monopolize the SCTP association.  To overcome this
+   limitation, [RFC8260] defines an extension to support message
+   interleaving, which SHOULD be used.  As long as message interleaving
+   is not supported, the sender SHOULD limit the maximum message size to
+   16 KB to avoid monopolization.
+
+   It is recommended that the message size be kept within certain size
+   bounds, as applications will not be able to support arbitrarily large
+   single messages.  This limit has to be negotiated, for example, by
+   using [RFC8841].
+
+   The sender SHOULD disable the Nagle algorithm (see [RFC1122]) to
+   minimize the latency.
+
+6.7.  Closing a Data Channel
+
+   Closing of a data channel MUST be signaled by resetting the
+   corresponding outgoing streams [RFC6525].  This means that if one
+   side decides to close the data channel, it resets the corresponding
+   outgoing stream.  When the peer sees that an incoming stream was
+   reset, it also resets its corresponding outgoing stream.  Once this
+   is completed, the data channel is closed.  Resetting a stream sets
+   the Stream Sequence Numbers (SSNs) of the stream back to 'zero' with
+   a corresponding notification to the application layer that the reset
+   has been performed.  Streams are available for reuse after a reset
+   has been performed.
+
+   [RFC6525] also guarantees that all the messages are delivered (or
+   abandoned) before the stream is reset.
+
+7.  Security Considerations
+
+   This document does not add any additional considerations to the ones
+   given in [RFC8826] and [RFC8827].
+
+   It should be noted that a receiver must be prepared for a sender that
+   tries to send arbitrarily large messages.
+
+8.  IANA Considerations
+
+   This document uses six already registered SCTP Payload Protocol
+   Identifiers (PPIDs): "DOMString Last", "Binary Data Partial", "Binary
+   Data Last", "DOMString Partial", "WebRTC String Empty", and "WebRTC
+   Binary Empty".  [RFC4960] creates the "SCTP Payload Protocol
+   Identifiers" registry from which these identifiers were assigned.
+   IANA has updated the reference of these six assignments to point to
+   this document and changed the names of the first four PPIDs.  The
+   corresponding dates remain unchanged.
+
+   The six assignments have been updated to read:
+
+       +======================+===========+===========+============+
+       | Value                | SCTP PPID | Reference | Date       |
+       +======================+===========+===========+============+
+       | WebRTC String        | 51        | RFC 8831  | 2013-09-20 |
+       +----------------------+-----------+-----------+------------+
+       | WebRTC Binary        | 52        | RFC 8831  | 2013-09-20 |
+       | Partial (deprecated) |           |           |            |
+       +----------------------+-----------+-----------+------------+
+       | WebRTC Binary        | 53        | RFC 8831  | 2013-09-20 |
+       +----------------------+-----------+-----------+------------+
+       | WebRTC String        | 54        | RFC 8831  | 2013-09-20 |
+       | Partial (deprecated) |           |           |            |
+       +----------------------+-----------+-----------+------------+
+       | WebRTC String Empty  | 56        | RFC 8831  | 2014-08-22 |
+       +----------------------+-----------+-----------+------------+
+       | WebRTC Binary Empty  | 57        | RFC 8831  | 2014-08-22 |
+       +----------------------+-----------+-----------+------------+
+
+                                  Table 1
+
+9.  References
+
+9.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <https://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC3758]  Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P.
+              Conrad, "Stream Control Transmission Protocol (SCTP)
+              Partial Reliability Extension", RFC 3758,
+              DOI 10.17487/RFC3758, May 2004,
+              <https://www.rfc-editor.org/info/rfc3758>.
+
+   [RFC4820]  Tuexen, M., Stewart, R., and P. Lei, "Padding Chunk and
+              Parameter for the Stream Control Transmission Protocol
+              (SCTP)", RFC 4820, DOI 10.17487/RFC4820, March 2007,
+              <https://www.rfc-editor.org/info/rfc4820>.
+
+   [RFC4821]  Mathis, M. and J. Heffner, "Packetization Layer Path MTU
+              Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007,
+              <https://www.rfc-editor.org/info/rfc4821>.
+
+   [RFC4960]  Stewart, R., Ed., "Stream Control Transmission Protocol",
+              RFC 4960, DOI 10.17487/RFC4960, September 2007,
+              <https://www.rfc-editor.org/info/rfc4960>.
+
+   [RFC5061]  Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M.
+              Kozuka, "Stream Control Transmission Protocol (SCTP)
+              Dynamic Address Reconfiguration", RFC 5061,
+              DOI 10.17487/RFC5061, September 2007,
+              <https://www.rfc-editor.org/info/rfc5061>.
+
+   [RFC6525]  Stewart, R., Tuexen, M., and P. Lei, "Stream Control
+              Transmission Protocol (SCTP) Stream Reconfiguration",
+              RFC 6525, DOI 10.17487/RFC6525, February 2012,
+              <https://www.rfc-editor.org/info/rfc6525>.
+
+   [RFC7496]  Tuexen, M., Seggelmann, R., Stewart, R., and S. Loreto,
+              "Additional Policies for the Partially Reliable Stream
+              Control Transmission Protocol Extension", RFC 7496,
+              DOI 10.17487/RFC7496, April 2015,
+              <https://www.rfc-editor.org/info/rfc7496>.
+
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+              May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+   [RFC8260]  Stewart, R., Tuexen, M., Loreto, S., and R. Seggelmann,
+              "Stream Schedulers and User Message Interleaving for the
+              Stream Control Transmission Protocol", RFC 8260,
+              DOI 10.17487/RFC8260, November 2017,
+              <https://www.rfc-editor.org/info/rfc8260>.
+
+   [RFC8261]  Tuexen, M., Stewart, R., Jesup, R., and S. Loreto,
+              "Datagram Transport Layer Security (DTLS) Encapsulation of
+              SCTP Packets", RFC 8261, DOI 10.17487/RFC8261, November
+              2017, <https://www.rfc-editor.org/info/rfc8261>.
+
+   [RFC8445]  Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive
+              Connectivity Establishment (ICE): A Protocol for Network
+              Address Translator (NAT) Traversal", RFC 8445,
+              DOI 10.17487/RFC8445, July 2018,
+              <https://www.rfc-editor.org/info/rfc8445>.
+
+   [RFC8826]  Rescorla, E., "Security Considerations for WebRTC",
+              RFC 8826, DOI 10.17487/RFC8826, January 2021,
+              <https://www.rfc-editor.org/info/rfc8826>.
+
+   [RFC8827]  Rescorla, E., "WebRTC Security Architecture", RFC 8827,
+              DOI 10.17487/RFC8827, January 2021,
+              <https://www.rfc-editor.org/info/rfc8827>.
+
+   [RFC8829]  Uberti, J., Jennings, C., and E. Rescorla, Ed.,
+              "JavaScript Session Establishment Protocol (JSEP)",
+              RFC 8829, DOI 10.17487/RFC8829, January 2021,
+              <https://www.rfc-editor.org/info/rfc8829>.
+
+   [RFC8832]  Jesup, R., Loreto, S., and M. Tüxen, "WebRTC Data Channel
+              Establishment Protocol", RFC 8832, DOI 10.17487/RFC8832,
+              January 2021, <https://www.rfc-editor.org/info/rfc8832>.
+
+   [RFC8841]  Holmberg, C., Shpount, R., Loreto, S., and G. Camarillo,
+              "Session Description Protocol (SDP) Offer/Answer
+              Procedures for Stream Control Transmission Protocol (SCTP)
+              over Datagram Transport Layer Security (DTLS) Transport",
+              RFC 8841, DOI 10.17487/RFC8841, January 2021,
+              <https://www.rfc-editor.org/info/rfc8841>.
+
+9.2.  Informative References
+
+   [RFC1122]  Braden, R., Ed., "Requirements for Internet Hosts -
+              Communication Layers", STD 3, RFC 1122,
+              DOI 10.17487/RFC1122, October 1989,
+              <https://www.rfc-editor.org/info/rfc1122>.
+
+   [RFC4347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
+              Security", RFC 4347, DOI 10.17487/RFC4347, April 2006,
+              <https://www.rfc-editor.org/info/rfc4347>.
+
+   [RFC5389]  Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
+              "Session Traversal Utilities for NAT (STUN)", RFC 5389,
+              DOI 10.17487/RFC5389, October 2008,
+              <https://www.rfc-editor.org/info/rfc5389>.
+
+   [RFC5764]  McGrew, D. and E. Rescorla, "Datagram Transport Layer
+              Security (DTLS) Extension to Establish Keys for the Secure
+              Real-time Transport Protocol (SRTP)", RFC 5764,
+              DOI 10.17487/RFC5764, May 2010,
+              <https://www.rfc-editor.org/info/rfc5764>.
+
+   [RFC6083]  Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram
+              Transport Layer Security (DTLS) for Stream Control
+              Transmission Protocol (SCTP)", RFC 6083,
+              DOI 10.17487/RFC6083, January 2011,
+              <https://www.rfc-editor.org/info/rfc6083>.
+
+   [RFC6347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
+              Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
+              January 2012, <https://www.rfc-editor.org/info/rfc6347>.
+
+   [RFC6951]  Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream
+              Control Transmission Protocol (SCTP) Packets for End-Host
+              to End-Host Communication", RFC 6951,
+              DOI 10.17487/RFC6951, May 2013,
+              <https://www.rfc-editor.org/info/rfc6951>.
+
+   [TLS-DTLS13]
+              Rescorla, E., Tschofenig, H., and N. Modadugu, "The
+              Datagram Transport Layer Security (DTLS) Protocol Version
+              1.3", Work in Progress, Internet-Draft, draft-ietf-tls-
+              dtls13-39, 2 November 2020,
+              <https://tools.ietf.org/html/draft-ietf-tls-dtls13-39>.
+
+Acknowledgements
+
+   Many thanks for comments, ideas, and text from Harald Alvestrand,
+   Richard Barnes, Adam Bergkvist, Alissa Cooper, Benoit Claise, Spencer
+   Dawkins, Gunnar Hellström, Christer Holmberg, Cullen Jennings, Paul
+   Kyzivat, Eric Rescorla, Adam Roach, Irene Rüngeler, Randall Stewart,
+   Martin Stiemerling, Justin Uberti, and Magnus Westerlund.
+
+Authors' Addresses
+
+   Randell Jesup
+   Mozilla
+   United States of America
+
+   Email: randell-ietf@jesup.org
+
+
+   Salvatore Loreto
+   Ericsson
+   Hirsalantie 11
+   FI-02420 Jorvas
+   Finland
+
+   Email: salvatore.loreto@ericsson.com
+
+
+   Michael Tüxen
+   Münster University of Applied Sciences
+   Stegerwaldstrasse 39
+   48565  Steinfurt
+   Germany
+
+   Email: tuexen@fh-muenster.de