rfc8831xml2.original.xml   rfc8831.xml 
<?xml version='1.0'?> <?xml version='1.0' encoding='utf-8'?>
<?rfc symrefs='yes'?> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<!DOCTYPE rfc SYSTEM 'rfc2629.dtd'>
<?rfc toc='yes' ?>
<?rfc compact='yes' ?>
<?rfc subcompact='no' ?>
<?rfc sortrefs='no' ?>
<?rfc strict='yes' ?>
<rfc category='std'
ipr='trust200902'
docName='draft-ietf-rtcweb-data-channel-13.txt'>
<front>
<title>WebRTC Data Channels</title>
<author initials='R.' surname='Jesup' fullname='Randell Jesup'>
<organization>Mozilla</organization>
<address>
<postal>
<street></street>
<code></code>
<city></city>
<country>US</country>
</postal>
<email>randell-ietf@jesup.org</email>
</address>
</author>
<author initials='S.' surname='Loreto' fullname='Salvatore Loreto'>
<organization>Ericsson</organization>
<address>
<postal>
<street>Hirsalantie 11</street>
<code>02420</code>
<city>Jorvas</city>
<country>FI</country>
</postal>
<email>salvatore.loreto@ericsson.com</email>
</address>
</author>
<author initials='M.' surname='Tuexen' fullname='Michael Tuexen'>
<organization abbrev='Muenster Univ. of Appl. Sciences'>
Muenster University of Applied Sciences</organization>
<address>
<postal>
<street>Stegerwaldstrasse 39</street>
<code>48565</code>
<city> Steinfurt</city>
<country>DE</country>
</postal>
<email>tuexen@fh-muenster.de</email>
</address>
</author>
<date /> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" number="8831"
<area>RAI</area> docName="draft-ietf-rtcweb-data-channel-13" category="std"
ipr="trust200902" submissionType="IETF" consensus="yes" obsoletes=""
updates="" xml:lang="en" symRefs="true" tocInclude="true"
sortRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 2.44.0 -->
<front>
<title>WebRTC Data Channels</title>
<seriesInfo name="RFC" value="8831"/>
<author initials="R." surname="Jesup" fullname="Randell Jesup">
<organization>Mozilla</organization>
<address>
<postal>
<street/>
<code/>
<city/>
<country>United States of America</country>
</postal>
<email>randell-ietf@jesup.org</email>
</address>
</author>
<author initials="S." surname="Loreto" fullname="Salvatore Loreto">
<organization>Ericsson</organization>
<address>
<postal>
<street>Hirsalantie 11</street>
<code>02420</code>
<city>Jorvas</city>
<country>Finland</country>
</postal>
<email>salvatore.loreto@ericsson.com</email>
</address>
</author>
<author initials="M." surname="Tüxen" fullname="Michael Tüxen">
<organization abbrev="Münster Univ. of Appl. Sciences">
Münster University of Applied Sciences</organization>
<address>
<postal>
<street>Stegerwaldstrasse 39</street>
<code>48565</code>
<city> Steinfurt</city>
<country>Germany</country>
</postal>
<email>tuexen@fh-muenster.de</email>
</address>
</author>
<date month="October" year="2020"/>
<area>RAI</area>
<abstract> <abstract>
<t>The WebRTC framework specifies protocol support for direct interactive <t>The WebRTC framework specifies protocol support for direct, interactive
rich communication using audio, video, and data between two peers' web-browsers. ,
rich communication using audio, video, and data between two peers' web browsers.
This document specifies the non-media data transport aspects of the WebRTC This document specifies the non-media data transport aspects of the WebRTC
framework. It provides an architectural overview of how the Stream Control framework. It provides an architectural overview of how the Stream Control
Transmission Protocol (SCTP) is used in the WebRTC context as a generic Transmission Protocol (SCTP) is used in the WebRTC context as a generic
transport service allowing WEB-browsers to exchange generic data from peer to transport service that allows web browsers to exchange generic data from peer to
peer.</t> peer.</t>
</abstract> </abstract>
</front> </front>
<middle>
<middle> <section numbered="true" toc="default">
<section title='Introduction'> <name>Introduction</name>
<t>In the WebRTC framework, communication between the parties consists of media <t>In the WebRTC framework, communication between the parties consists of
(for example audio and video) and non-media data. media
Media is sent using SRTP, and is not specified further here. (for example, audio and video) and non-media data.
Non-media data is handled by using SCTP <xref target='RFC4960'/> encapsulated Media is sent using the Secure Real-time Transport Protocol (SRTP)
in DTLS. DTLS 1.0 is defined in <xref target='RFC4347'/> and the present and is not specified further here.
latest version, DTLS 1.2, is defined in <xref target='RFC6347'/>.</t> Non-media data is handled by using the Stream Control Transmission Protocol (SCT
P) <xref target="RFC4960" format="default"/> encapsulated
<figure title='Basic stack diagram' in DTLS. DTLS 1.0 is defined in <xref target="RFC4347" format="default"/>, and t
anchor='fig-stack'> he present
<artwork align='center'> latest version, DTLS 1.2, is defined in <xref target="RFC6347" format="default"/
>.</t>
<figure anchor="fig-stack">
<name>Basic Stack Diagram</name>
<artwork align="center" name="" type="" alt=""><![CDATA[
+----------+ +----------+
| SCTP | | SCTP |
+----------+ +----------+
| DTLS | | DTLS |
+----------+ +----------+
| ICE/UDP | | ICE/UDP |
+----------+ +----------+
</artwork> ]]></artwork>
</figure> </figure>
<t>The encapsulation of SCTP over DTLS <t>The encapsulation of SCTP over DTLS
(see <xref target='I-D.ietf-tsvwg-sctp-dtls-encaps'/>) over ICE/UDP (see <xref target="RFC8261" format="default"/>) over ICE/UDP
(see <xref target='RFC5245'/>) provides a NAT traversal (see <xref target="RFC8445" format="default"/>) provides a NAT traversal
solution together with confidentiality, source authentication, and solution together with confidentiality, source authentication, and
integrity protected transfers. integrity-protected transfers.
This data transport service operates in parallel to the SRTP media transports, This data transport service operates in parallel to the SRTP media transports,
and all of them can eventually share a single UDP port number.</t> and all of them can eventually share a single UDP port number.</t>
<t>SCTP as specified in <xref target='RFC4960'/> with the partial reliability <t>SCTP, as specified in <xref target="RFC4960" format="default"/> with the part
extension defined in <xref target='RFC3758'/> and the additional policies ial reliability
defined in <xref target='I-D.ietf-tsvwg-sctp-prpolicies'/> extension (PR-SCTP) defined in <xref target="RFC3758" format="default"/> and the
additional policies
defined in <xref target="RFC7496" format="default"/>,
provides multiple streams natively with reliable, and the relevant provides multiple streams natively with reliable, and the relevant
partially-reliable delivery modes for user messages. partially reliable, delivery modes for user messages.
Using the reconfiguration extension defined in <xref target='RFC6525'/> Using the reconfiguration extension defined in <xref target="RFC6525" format="de
allows to increase the number of streams during the lifetime of an SCTP fault"/>
association and to reset individual SCTP streams. allows an increase in the number of streams during the lifetime of an SCTP
Using <xref target='I-D.ietf-tsvwg-sctp-ndata'/> allows to interleave association and allows individual SCTP streams to be reset.
large messages to avoid the monopolization and adds the support of Using <xref target="RFC8260" format="default"/> allows the interleave of large m
prioritizing of SCTP streams.</t> essages to
<t>The remainder of this document is organized as follows: avoid monopolization and adds support for
<xref target='sec-use-cases'/> and <xref target='sec-req'/> provide use cases prioritizing SCTP streams.</t>
and requirements for both unreliable and reliable peer to peer data channels; <t>The remainder of this document is organized as follows:
<xref target='sec-p-a-2'/> discusses SCTP over DTLS over UDP; Sections <xref target="sec-use-cases" format="counter"/> and <xref target="sec-r
<xref target='sec-sctp-usage'/> provides the specification of how SCTP should be eq" format="counter"/> provide use cases
and requirements for both unreliable and reliable peer-to-peer data channels;
<xref target="sec-p-a-2" format="default"/> discusses SCTP over DTLS over UDP; a
nd
<xref target="sec-sctp-usage" format="default"/> specifies how SCTP should be
used by the WebRTC protocol framework for transporting non-media data used by the WebRTC protocol framework for transporting non-media data
between WEB-browsers.</t> between web browsers.</t>
</section> </section>
<section numbered="true" toc="default">
<section title='Conventions'> <name>Conventions</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
in this document are to be interpreted as described in "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
<xref target='RFC2119'/>.</t> "<bcp14>SHOULD NOT</bcp14>",
</section> "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
<section title='Use Cases' are to be interpreted as described in BCP&nbsp;14
anchor='sec-use-cases'> <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
<t>This section defines use cases specific to data channels. when, they appear in all capitals, as shown here.</t>
</section>
<section anchor="sec-use-cases" numbered="true" toc="default">
<name>Use Cases</name>
<t>This section defines use cases specific to data channels.
Please note that this section is informational only.</t> Please note that this section is informational only.</t>
<section anchor="sec-use-cases-unreliable" numbered="true" toc="default">
<section title='Use Cases for Unreliable Data Channels' <name>Use Cases for Unreliable Data Channels</name>
anchor='sec-use-cases-unreliable'> <ol group="UseCases" spacing="normal" type="U-C %d:" indent="8">
<t><list style='format U-C %d:' counter='UseCases'> <li>A real-time game where position and object state information are
<t>A real-time game where position and object state information is
sent via one or more unreliable data channels. sent via one or more unreliable data channels.
Note that at any time there may be no SRTP media channels, or all SRTP media Note that at any time, there may not be any SRTP media channels or all SRTP medi
channels may be inactive, and that there may also be reliable data channels a
in use.</t> channels may be inactive, and there may also be reliable data channels
<t>Providing non-critical information to a user about the reason for a state in use.</li>
update in a video chat or conference, such as mute state.</t> <li>Providing non-critical information to a user about the reason for
</list></t> a state
</section> update in a video chat or conference, such as mute state.</li>
</ol>
<section title='Use Cases for Reliable Data Channels' </section>
anchor='sec-use-cases-reliable'> <section anchor="sec-use-cases-reliable" numbered="true" toc="default">
<t><list style='format U-C %d:' counter='UseCases'> <name>Use Cases for Reliable Data Channels</name>
<t> A real-time game where critical state information needs to be <ol group="UseCases" spacing="normal" type="U-C %d:" indent="8">
<li> A real-time game where critical state information needs to be
transferred, such as control information. transferred, such as control information.
Such a game may have no SRTP media channels, or they may be inactive at any 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.</t> given time or may only be added due to in-game actions.</li>
<t>Non-realtime file transfers between people chatting. <li>Non-real-time file transfers between people chatting.
Note that this may involve a large number of files to transfer sequentially 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. or in parallel, such as when sharing a folder of images or a directory of files.
</t> </li>
<t>Realtime text chat during an audio and/or video call with an individual <li>Real-time text chat during an audio and/or video call with an indi
or with multiple people in a conference.</t> vidual
<t>Renegotiation of the configuration of the PeerConnection.</t> or with multiple people in a conference.</li>
<t>Proxy browsing, where a browser uses data channels of a PeerConnection <li>Renegotiation of the configuration of the PeerConnection.</li>
to send and receive HTTP/HTTPS requests and data, for example to avoid local <li>Proxy browsing, where a browser uses data channels of a PeerConnec
Internet filtering or monitoring.</t> tion
</list></t> to send and receive HTTP/HTTPS requests and data, for example, to avoid local
</section> Internet filtering or monitoring.</li>
</section> </ol>
</section>
<section title='Requirements' </section>
anchor='sec-req'> <section anchor="sec-req" numbered="true" toc="default">
<t>This section lists the requirements for P2P data channels between <name>Requirements</name>
<t>This section lists the requirements for Peer-to-Peer (P2P) data channel
s between
two browsers. two browsers.
Please note that this section is informational only.</t> Please note that this section is informational only.</t>
<t><list style='format Req. %d:'> <ol spacing="normal" type="Req. %d:" indent="10">
<t>Multiple simultaneous data channels must be supported. <li>Multiple simultaneous data channels must be supported.
Note that there may be 0 or more SRTP media streams in parallel with the data 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) channels in the same PeerConnection, and the number and state (active/inactive)
of these SRTP media streams may change at any time.</t> of these SRTP media streams may change at any time.</li>
<t>Both reliable and unreliable data channels must be supported.</t> <li>Both reliable and unreliable data channels must be supported.</li>
<t>Data channels of a PeerConnection must be congestion controlled; <li>Data channels of a PeerConnection must be congestion controlled
either individually, as a class, or in conjunction with the SRTP media streams either individually, as a class, or in conjunction with the SRTP media streams
of the PeerConnection, to ensure that data channels don't cause congestion of the PeerConnection. This ensures that data channels don't cause congestion
problems for these SRTP media streams, and that the WebRTC PeerConnection does problems for these SRTP media streams, and that the WebRTC PeerConnection does
not cause excessive problems when run in parallel with TCP connections.</t> not cause excessive problems when run in parallel with TCP connections.</li>
<t>The application should be able to provide guidance as to the <li>The application should be able to provide guidance as to the
relative priority of each data channel relative to each other, relative priority of each data channel relative to each other
and relative to the SRTP media streams. and relative to the SRTP media streams.
This will interact with the congestion control algorithms.</t> This will interact with the congestion control algorithms.</li>
<t>Data channels must be secured; allowing for confidentiality, <li>Data channels must be secured, which allows for confidentiality,
integrity and source authentication. integrity, and source authentication.
See <xref target='I-D.ietf-rtcweb-security'/> and See <xref target="RFC8826" format="default"/> and
<xref target='I-D.ietf-rtcweb-security-arch'/> for detailed info.</t> <xref target="RFC8827" format="default"/> for detailed information.</li>
<!--<t>Consent and NAT traversal mechanism: These are handled by the <!--<t>Consent and NAT traversal mechanism: These are handled by the
PeerConnection's ICE <xref target='RFC5245'/> connectivity checks and PeerConnection's ICE <xref target='RFC5245'/> connectivity checks and
optional TURN servers.</t>--> optional TURN servers.</t>-->
<t>Data channels must provide message fragmentation support such that <li>Data channels must provide message fragmentation support such that
IP-layer fragmentation can be avoided no matter how large a message the 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 JavaScript application passes to be sent. It also must ensure that large
data channel transfers don't unduly delay traffic on other data data channel transfers don't unduly delay traffic on other data
channels.</t> channels.</li>
<t>The data channel transport protocol must not encode local IP addresses <li>The data channel transport protocol must not encode local IP address
inside its protocol fields; doing so reveals potentially private information, es
and leads to failure if the address is depended upon.</t> inside its protocol fields; doing so reveals potentially private information
<t>The data channel transport protocol should support unbounded-length "messages and leads to failure if the address is depended upon.</li>
" <li>The data channel transport protocol should support unbounded-length
(i.e., a virtual socket stream) at the application layer, for such things as "messages"
image-file-transfer; Implementations might enforce a reasonable message size (i.e., a virtual socket stream) at the application layer for such things as
limit.</t> image-file-transfer; implementations might enforce a reasonable message size
<t>The data channel transport protocol should avoid IP fragmentation. It limit.</li>
must support PMTU (Path MTU) discovery and must not rely on ICMP or ICMPv6 <li>The data channel transport protocol should avoid IP fragmentation. I
being generated or being passed back, especially for PMTU discovery.</t> t
<t>It must be possible to implement the protocol stack in the user must support Path MTU (PMTU) discovery and must not rely on ICMP or ICMPv6
application space.</t> being generated or being passed back, especially for PMTU discovery.</li>
</list></t> <li>It must be possible to implement the protocol stack in the user appl
</section> ication space.</li>
</ol>
<section title='SCTP over DTLS over UDP Considerations' </section>
anchor='sec-p-a-2'> <section anchor="sec-p-a-2" numbered="true" toc="default">
<t>The important features of SCTP in the WebRTC context are: <name>SCTP over DTLS over UDP Considerations</name>
<list style='symbols'> <t>The important features of SCTP in the WebRTC context are the following:
<t>Usage of a TCP-friendly congestion control.</t> </t>
<t>The congestion control is modifiable for integration with the <ul spacing="normal">
SRTP media stream congestion control.</t> <li>Usage of TCP-friendly congestion control.</li>
<t>Support of multiple unidirectional streams, each providing its own <li>modifiable congestion control for integration with the
notion of ordered message delivery.</t> SRTP media stream congestion control.</li>
<t>Support of ordered and out-of-order message delivery.</t> <li>Support of multiple unidirectional streams, each providing its own
<t>Supporting arbitrary large user messages by providing fragmentation notion of ordered message delivery.</li>
and reassembly.</t> <li>Support of ordered and out-of-order message delivery.</li>
<t>Support of PMTU-discovery.</t> <li>Support of arbitrarily large user messages by providing fragmentation
<t>Support of reliable or partially reliable message transport.</t> and reassembly.</li>
</list></t> <li>Support of PMTU discovery.</li>
<t>The WebRTC Data Channel mechanism does not support SCTP multihoming. <li>Support of reliable or partially reliable message transport.</li>
</ul>
<t>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, 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, since that is the abstraction that the DTLS layer (a connection-oriented,
unreliable datagram service) exposes.</t> unreliable datagram service) exposes.</t>
<t>The encapsulation of SCTP over DTLS defined in <t>The encapsulation of SCTP over DTLS defined in
<xref target='I-D.ietf-tsvwg-sctp-dtls-encaps'/> provides confidentiality, <xref target="RFC8261" format="default"/> provides confidentiality,
source authenticated, and integrity protected transfers. source authentication, and integrity-protected transfers.
Using DTLS over UDP in combination with ICE enables middlebox traversal Using DTLS over UDP in combination with Interactive Connectivity Establishment
in IPv4 and IPv6 based networks. (ICE) <xref target="RFC8445"/> enables middlebox traversal
SCTP as specified in <xref target='RFC4960'/> MUST be used in in IPv4- and IPv6-based networks.
combination with the extension defined in <xref target='RFC3758'/> and SCTP as specified in <xref target="RFC4960" format="default"/> <bcp14>MUST</bcp1
4> be used in
combination with the extension defined in <xref target="RFC3758" format="default
"/> and
provides the following features for transporting non-media data between provides the following features for transporting non-media data between
browsers: browsers:
<list style='symbols'> </t>
<t>Support of multiple unidirectional streams.</t> <ul spacing="normal">
<t>Ordered and unordered delivery of user messages.</t> <li>Support of multiple unidirectional streams.</li>
<t>Reliable and partial-reliable transport of user messages.</t> <li>Ordered and unordered delivery of user messages.</li>
</list></t> <li>Reliable and partially reliable transport of user messages.</li>
<t>Each SCTP user message contains a Payload Protocol Identifier (PPID) </ul>
<t>Each SCTP user message contains a Payload Protocol Identifier (PPID)
that is passed to SCTP by its upper layer on the sending side and that is passed to SCTP by its upper layer on the sending side and
provided to its upper layer on the receiving side. provided to its upper layer on the receiving side.
The PPID can be used to multiplex/demultiplex multiple upper layers over The PPID can be used to multiplex/demultiplex multiple upper layers over
a single SCTP association. a single SCTP association.
In the WebRTC context, the PPID is used to distinguish between In the WebRTC context, the PPID is used to distinguish between
UTF-8 encoded user data, UTF-8 encoded user data,
binary encoded userdata and binary-encoded user data, and
the Data Channel Establishment Protocol defined in the Data Channel Establishment Protocol (DCEP) defined in
<xref target='I-D.ietf-rtcweb-data-protocol'/>. <xref target="RFC8832" format="default"/>.
Please note that the PPID is not accessible via the Javascript API.</t> Please note that the PPID is not accessible via the Javascript API.</t>
<!-- <!--
<t>Moreover SCTP provides the possibility to transport different "protocols" <t>Moreover SCTP provides the possibility to transport different "protocols"
over multiple streams and associations using the PPID over multiple streams and associations using the PPID
(Payload Protocol Identifier). (Payload Protocol Identifier).
An application can set a different PPID with each send call. An application can set a different PPID with each send call.
This allows the receiving application to look at this information This allows the receiving application to look at this information
(as well as the stream id/seq) on receiving to know what type of protocol (as well as the stream id/seq) on receiving to know what type of protocol
the data payload has.</t> the data payload has.</t>
--> -->
<t>The encapsulation of SCTP over DTLS, together with the SCTP features listed <t>The encapsulation of SCTP over DTLS, together with the SCTP features listed
above satisfies all the requirements listed in <xref target='sec-req'/>.</t> above, satisfies all the requirements listed in <xref target="sec-req" format="d
<!-- efault"/>.</t>
<!--
<t>There are SCTP implementations for most Operating Systems in wide use:</t> <t>There are SCTP implementations for most Operating Systems in wide use:</t>
<t> <t>
<list style='empty'> <list style='empty'>
<t>Linux (mainline kernel 2.6.36)</t> <t>Linux (mainline kernel 2.6.36)</t>
<t>FreeBSD (release kernel 8.2)</t> <t>FreeBSD (release kernel 8.2)</t>
<t>Mac OS X</t> <t>Mac OS X</t>
<t>Windows (SctpDrv4)</t> <t>Windows (SctpDrv4)</t>
<t>Solaris (OpenSolaris 2009.06)</t> <t>Solaris (OpenSolaris 2009.06)</t>
<t>and a user-land SCTP implementation (based on the FreeBSD implementation).</t > <t>and a user-land SCTP implementation (based on the FreeBSD implementation).</t >
</list> </list>
skipping to change at line 296 skipping to change at line 292
they run on mobile and desktop operating systems, they run on mobile and desktop operating systems,
and they are highly portable to new operating systems. and they are highly portable to new operating systems.
This is achieved by having a fairly narrow portability layer to minimize This is achieved by having a fairly narrow portability layer to minimize
what needs to be supported on old operating systems and ported to new ones. what needs to be supported on old operating systems and ported to new ones.
This creates a need to implement as much functionality as possible This creates a need to implement as much functionality as possible
inside the application instead of relying on the operating system.</t> inside the application instead of relying on the operating system.</t>
<t>As a user-land implementation of SCTP is available, this meets <t>As a user-land implementation of SCTP is available, this meets
requirement 12.</t> requirement 12.</t>
</section> </section>
--> -->
<t>The layering of protocols for WebRTC is shown in the following <t>The layering of protocols for WebRTC is shown in <xref target="fig-sctp-layer
<xref target='fig-sctp-layering'/>.</t> ing" format="default"/>.</t>
<figure title='WebRTC protocol layers' <figure anchor="fig-sctp-layering">
anchor='fig-sctp-layering'> <name>WebRTC Protocol Layers</name>
<artwork align='center'> <artwork align="center" name="" type="" alt=""><![CDATA[
+------+------+------+ +------+------+------+
| DCEP | UTF-8|Binary| | DCEP | UTF-8|Binary|
| | data | data | | | Data | Data |
+------+------+------+ +------+------+------+
| SCTP | | SCTP |
+----------------------------------+ +----------------------------------+
| STUN | SRTP | DTLS | | STUN | SRTP | DTLS |
+----------------------------------+ +----------------------------------+
| ICE | | ICE |
+----------------------------------+ +----------------------------------+
| UDP1 | UDP2 | UDP3 | ... | | UDP1 | UDP2 | UDP3 | ... |
+----------------------------------+ +----------------------------------+
</artwork> ]]></artwork>
</figure> </figure>
<t>This stack (especially in contrast to DTLS over SCTP <xref target='RFC6083'/> <t>This stack (especially in contrast to DTLS over SCTP <xref target="RFC6
in combination with SCTP over UDP <xref target='RFC6951'/>) 083" format="default"/> and
has been chosen because it in combination with SCTP over UDP <xref target="RFC6951" format="default"/>)
<list style='symbols'> has been chosen for the following reasons:
<t>supports the transmission of arbitrary large user messages.</t> </t>
<t>shares the DTLS connection with the SRTP media channels of the PeerConnection <ul spacing="normal">
.</t> <li>supports the transmission of arbitrarily large user messages;</li>
<t>provides privacy for the SCTP control information.</t> <li>shares the DTLS connection with the SRTP media channels of the
</list></t> PeerConnection; and</li>
<t>Considering the protocol stack of <xref target='fig-sctp-layering'/> the <li>provides privacy for the SCTP control information.</li>
usage of DTLS 1.0 over UDP is specified in <xref target='RFC4347'/> and </ul>
the usage of DTLS 1.2 over UDP in specified in <xref target='RFC6347'/>, <t>In the protocol stack of <xref target="fig-sctp-layering" format="defau
lt"/>, the
usage of DTLS 1.0 over UDP is specified in <xref target="RFC4347" format="defaul
t"/> and
the usage of DTLS 1.2 over UDP in specified in <xref target="RFC6347" format="de
fault"/>,
while the usage of SCTP on top of DTLS is specified in while the usage of SCTP on top of DTLS is specified in
<xref target='I-D.ietf-tsvwg-sctp-dtls-encaps'/>. <xref target="RFC8261" format="default"/>.
Please note that the demultiplexing STUN vs. SRTP vs. DTLS is done Please note that the demultiplexing Session Traversal Utilities for NAT (STUN)
as described in Section 5.1.2 of <xref target='RFC5764'/> and SCTP <xref target="RFC5389"/> vs. SRTP vs. DTLS is done
as described in <xref target="RFC5764" sectionFormat="of" section="5.1.2"/>, and
SCTP
is the only payload of DTLS.</t> is the only payload of DTLS.</t>
<t>Since DTLS is typically implemented in user application space, the SCTP <t>Since DTLS is typically implemented in user application space, the SCTP
stack also needs to be a user application space stack.</t> stack also needs to be a user application space stack.</t>
<t>The ICE/UDP layer can handle IP address changes during a session without <t>The ICE/UDP layer can handle IP address changes during a session withou t
needing interaction with the DTLS and SCTP layers. needing interaction with the DTLS and SCTP layers.
However, SCTP SHOULD be notified when an address changes has happened. However, SCTP <bcp14>SHOULD</bcp14> be notified when an address change has happe
In this case SCTP SHOULD retest the Path MTU and reset the congestion ned.
In this case, SCTP <bcp14>SHOULD</bcp14> retest the Path MTU and reset the conge
stion
state to the initial state. state to the initial state.
In case of a window based congestion control like the one specified in In the case of window-based congestion control like the one specified in
<xref target='RFC4960'/>, this means setting the congestion window and <xref target="RFC4960" format="default"/>, this means setting the congestion win
slow start threshold to its initial values.</t> dow and
<t>Incoming ICMP or ICMPv6 messages can't be processed by slow-start threshold to its initial values.</t>
<t>Incoming ICMP or ICMPv6 messages can't be processed by
the SCTP layer, since there is no way to identify the corresponding the SCTP layer, since there is no way to identify the corresponding
association. Therefore SCTP MUST support performing Path MTU discovery association. Therefore, SCTP <bcp14>MUST</bcp14> support performing Path MTU dis
without relying on ICMP or ICMPv6 as specified in <xref target='RFC4821'/> covery
using probing messages specified in <xref target='RFC4820'/>. without relying on ICMP or ICMPv6 as specified in <xref target="RFC4821" format=
The initial Path MTU at the IP layer SHOULD NOT exceed 1200 bytes for IPv4 "default"/>
and 1280 for IPv6.</t> by using probing messages specified in <xref target="RFC4820" format="default"/>
<t>In general, the lower layer interface of an SCTP implementation should be .
adapted to address the differences between IPv4 and IPv6 (being connection-less) The initial Path MTU at the IP layer <bcp14>SHOULD NOT</bcp14> exceed 1200 bytes
or DTLS (being connection-oriented).</t> for IPv4
<t>When the protocol stack of <xref target='fig-sctp-layering'/> is used, DTLS and 1280 bytes for IPv6.</t>
protects the complete SCTP packet, so it provides confidentiality, integrity and <t>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).</t>
<t>When the protocol stack of <xref target="fig-sctp-layering" format="def
ault"/> is used, DTLS
protects the complete SCTP packet, so it provides confidentiality, integrity, an
d
source authentication of the complete SCTP packet.</t> source authentication of the complete SCTP packet.</t>
<t>SCTP provides congestion control on a per-association base. This means <t>SCTP provides congestion control on a per-association basis. This means
that all SCTP streams within a single SCTP association share the same that all SCTP streams within a single SCTP association share the same
congestion window. Traffic not being sent over SCTP is not covered by congestion window. Traffic not being sent over SCTP is not covered by
the SCTP congestion control. SCTP congestion control.
Using a congestion control different from than the standard one might improve Using a congestion control different from the standard one might improve
the impact on the parallel SRTP media streams.</t> the impact on the parallel SRTP media streams.</t>
<t>SCTP uses the same port number concept as TCP and UDP do. <t>SCTP uses the same port number concept as TCP and UDP.
Therefore an SCTP association uses two port numbers, one at each SCTP Therefore, an SCTP association uses two port numbers, one at each SCTP
end-point.</t> endpoint.</t>
</section> </section>
<section anchor="sec-sctp-usage" numbered="true" toc="default">
<section title='The Usage of SCTP for Data Channels' <name>The Usage of SCTP for Data Channels</name>
anchor='sec-sctp-usage'> <section numbered="true" toc="default">
<name>SCTP Protocol Considerations</name>
<section title='SCTP Protocol Considerations'> <t>The DTLS encapsulation of SCTP packets as described in
<t>The DTLS encapsulation of SCTP packets as described in <xref target="RFC8261" format="default"/> <bcp14>MUST</bcp14> be used.</t>
<xref target='I-D.ietf-tsvwg-sctp-dtls-encaps'/> MUST be used.</t> <t>This SCTP stack and its upper layer <bcp14>MUST</bcp14> support the u
<t>This SCTP stack and its upper layer MUST support the usage of multiple sage of multiple
SCTP streams. SCTP streams.
A user message can be sent ordered or unordered and with partial or full A user message can be sent ordered or unordered and with partial or full
reliability.</t> reliability.</t>
<t>The following SCTP protocol extensions are required: <t>The following SCTP protocol extensions are required:
<list style='symbols'> </t>
<t>The stream reconfiguration extension defined in <xref target='RFC6525'/> <ul spacing="normal">
MUST be supported. It is used for closing channels.</t> <li>The stream reconfiguration extension defined in <xref target="RFC6
<t>The dynamic address reconfiguration extension defined in 525" format="default"/>
<xref target='RFC5061'/> MUST be used to signal the support of the <bcp14>MUST</bcp14> be supported. It is used for closing channels.</li>
stream reset extension defined in <xref target='RFC6525'/>. <li>The dynamic address reconfiguration extension defined in
Other features of <xref target='RFC5061'/> are OPTIONAL.</t> <xref target="RFC5061" format="default"/> <bcp14>MUST</bcp14> be used to sign
<t>The partial reliability extension defined in <xref target='RFC3758'/> MUST al the support of the
stream reset extension defined in <xref target="RFC6525" format="default"/>.
Other features of <xref target="RFC5061" format="default"/> are <bcp14>OPTION
AL</bcp14>.</li>
<li>The partial reliability extension defined in <xref target="RFC3758
" format="default"/> <bcp14>MUST</bcp14>
be supported. In addition to the timed reliability PR-SCTP policy defined be supported. In addition to the timed reliability PR-SCTP policy defined
in <xref target='RFC3758'/>, the limited retransmission policy defined in in <xref target="RFC3758" format="default"/>, the limited retransmission poli
<xref target='I-D.ietf-tsvwg-sctp-prpolicies'/> MUST be supported. cy defined in
Limiting the number of retransmissions to zero combined with unordered <xref target="RFC7496" format="default"/> <bcp14>MUST</bcp14> be supported.
delivery provides a UDP-like service where each user message is sent Limiting the number of retransmissions to zero, combined with unordered
exactly once and delivered in the order received.</t> delivery, provides a UDP-like service where each user message is sent
</list></t> exactly once and delivered in the order received.</li>
<t>The support for message interleaving as defined in </ul>
<xref target='I-D.ietf-tsvwg-sctp-ndata'/> SHOULD be used.</t> <t>The support for message interleaving as defined in
</section> <xref target="RFC8260" format="default"/> <bcp14>SHOULD</bcp14> be used.</t>
</section>
<section title='SCTP Association Management' <section anchor="sec-sctp-management" numbered="true" toc="default">
anchor='sec-sctp-management'> <name>SCTP Association Management</name>
<t>In the WebRTC context, the SCTP association will be set up when the <t>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 two endpoints of the WebRTC PeerConnection agree on opening it, as negotiated
by JSEP (typically an exchange of SDP) <xref target='I-D.ietf-rtcweb-jsep'/>. by the JavaScript Session Establishment Protocol (JSEP), which is typically an
It will use the DTLS connection selected via ICE; typically this will be exchange of the Session Description Protocol (SDP) <xref target="RFC8829" format
="default"/>.
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 shared via BUNDLE or equivalent with DTLS connections used to key the
SRTP media streams.</t> SRTP media streams.</t>
<!-- FIXME: Bundle Issue. --> <!-- FIXME: Bundle Issue. -->
<t>The number of streams negotiated during SCTP association setup SHOULD <t>The number of streams negotiated during SCTP association setup <bcp14>SHOULD<
/bcp14>
be 65535, which is the maximum number of streams that can be negotiated during be 65535, which is the maximum number of streams that can be negotiated during
the association setup.</t> the association setup.</t>
<t>SCTP supports two ways of terminating an SCTP association.
<t>SCTP supports two ways of terminating an SCTP association. The first method is a graceful one, where a procedure that ensures no messages
A graceful one, using a procedure which ensures that no messages are lost are lost during the shutdown of the association is used.
during the shutdown of the association.
The second method is a non-graceful one, where one side can just abort the The second method is a non-graceful one, where one side can just abort the
association.</t> association.</t>
<t>Each SCTP end-point supervises continuously the reachability of its peer by <t>Each SCTP endpoint continuously supervises the reachability of its pe er by
monitoring the number of retransmissions of user messages and test messages. monitoring the number of retransmissions of user messages and test messages.
In case of excessive retransmissions, the association is terminated in a In case of excessive retransmissions, the association is terminated in a
non-graceful way.</t> non-graceful way.</t>
<t>If an SCTP association is closed in a graceful way, all of its data channels <t>If an SCTP association is closed in a graceful way, all of its data c hannels
are closed. are closed.
In case of a non-graceful teardown, all data channels are also closed, In case of a non-graceful teardown, all data channels are also closed,
but an error indication SHOULD be provided if possible.</t> but an error indication <bcp14>SHOULD</bcp14> be provided if possible.</t>
</section> </section>
<section numbered="true" toc="default">
<section title='SCTP Streams'> <name>SCTP Streams</name>
<t>SCTP defines a stream as a unidirectional logical channel existing within <t>SCTP defines a stream as a unidirectional logical channel existing wi
thin
an SCTP association to another SCTP endpoint. The streams are used to an SCTP association to another SCTP endpoint. The streams are used to
provide the notion of in-sequence delivery and for multiplexing. provide the notion of in-sequence delivery and for multiplexing.
Each user message is sent on a particular stream, either ordered or unordered. 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.</t> Ordering is preserved only for ordered messages sent on the same stream.</t>
</section> </section>
<section numbered="true" toc="default">
<section title='Data Channel Definition'> <name>Data Channel Definition</name>
<t>Data channels are defined such that their accompanying application-level API <t>Data channels are defined such that their accompanying application-le
vel API
can closely mirror the API for WebSockets, which implies bidirectional streams 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 of data and a textual field called 'label' used to identify the meaning of the
data channel.</t> data channel.</t>
<t>The realization of a data channel is a pair of one incoming stream and <t>The realization of a data channel is a pair of one incoming stream an d
one outgoing SCTP stream having the same SCTP stream identifier. one outgoing SCTP stream having the same SCTP stream identifier.
How these SCTP stream identifiers are selected is protocol and implementation How these SCTP stream identifiers are selected is protocol and implementation
dependent. This allows a bidirectional communication.</t> dependent. This allows a bidirectional communication.</t>
<t>Additionally, each data channel has the following properties in each <t>Additionally, each data channel has the following properties in each
direction: direction:
<list style='symbols'> </t>
<t>reliable or unreliable message transmission. <ul spacing="normal">
<li>reliable or unreliable message transmission:
In case of unreliable transmissions, the same level of unreliability is used. In case of unreliable transmissions, the same level of unreliability is used.
Please note that in SCTP this is a property of an SCTP user message and not Note that, in SCTP, this is a property of an SCTP user message and not
of an SCTP stream.</t> of an SCTP stream.</li>
<t>in-order or out-of-order message delivery for message sent. <li>in-order or out-of-order message delivery for message sent:
Please note that in SCTP this is a property of an SCTP user message and not Note that, in SCTP, this is a property of an SCTP user message and not
of an SCTP stream.</t> of an SCTP stream.</li>
<t>A priority, which is a 2 byte unsigned integer. <li>a priority, which is a 2-byte unsigned integer:
These priorities MUST be interpreted as weighted-fair-queuing scheduling These priorities <bcp14>MUST</bcp14> be interpreted as weighted-fair-queuing sch
eduling
priorities per the definition of the corresponding stream scheduler priorities per the definition of the corresponding stream scheduler
supporting interleaving in <xref target='I-D.ietf-tsvwg-sctp-ndata'/>. supporting interleaving in <xref target="RFC8260" format="default"/>.
For use in WebRTC, the values used SHOULD be one of 128 ("below normal"), For use in WebRTC, the values used <bcp14>SHOULD</bcp14> be one of 128 ("below n
256 ("normal"), 512 ("high") or 1024 ("extra high").</t> ormal"),
<t>an optional label.</t> 256 ("normal"), 512 ("high"), or 1024 ("extra high").</li>
<t>an optional protocol.</t> <li>an optional label.</li>
</list></t> <li>an optional protocol.</li>
<t>Please note that for a data channel being negotiated with the protocol </ul>
specified in <xref target='I-D.ietf-rtcweb-data-protocol'/> all of the above <t>Note that for a data channel being negotiated with the protocol
specified in <xref target="RFC8832" format="default"/>, all of the above
properties are the same in both directions.</t> properties are the same in both directions.</t>
</section> </section>
<section numbered="true" toc="default">
<section title='Opening a Data Channel'> <name>Opening a Data Channel</name>
<t>Data channels can be opened by using negotiation within the SCTP association, <t>Data channels can be opened by using negotiation within the SCTP asso
called in-band negotiation, or out-of-band negotiation. ciation
Out-of-band negotiation is defined as any method which results in an agreement (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. as to the parameters of a channel and the creation thereof.
The details are out of scope of this document. Applications using data The details are out of scope of this document. Applications using data
channels need to use the negotiation methods consistently on both end-points.</t channels need to use the negotiation methods consistently on both endpoints.</t>
> <t>A simple protocol for in-band negotiation is specified in
<t>A simple protocol for in-band negotiation is specified in <xref target="RFC8832" format="default"/>.</t>
<xref target='I-D.ietf-rtcweb-data-protocol'/>.</t> <t>When one side wants to open a channel using out-of-band negotiation,
<t>When one side wants to open a channel using out-of-band negotiation, it it
picks a stream. picks a stream.
Unless otherwise defined or negotiated, the streams are picked based on Unless otherwise defined or negotiated, the streams are picked based on
the DTLS role (the client picks even stream identifiers, the DTLS role (the client picks even stream identifiers, and
the server odd stream identifiers). the server picks odd stream identifiers).
However, the application is responsible for avoiding collisions with However, the application is responsible for avoiding collisions with
existing streams. existing streams.
If it attempts to re-use a stream which is part of an existing data channel, If it attempts to reuse a stream that is part of an existing data channel,
the addition MUST fail. the addition <bcp14>MUST</bcp14> fail.
In addition to choosing a stream, the application SHOULD also determine In addition to choosing a stream, the application <bcp14>SHOULD</bcp14> also det
the options to use for sending messages. ermine
The application MUST ensure in an application-specific manner that the options to be used for sending messages.
The application <bcp14>MUST</bcp14> ensure in an application-specific manner tha
t
the application at the peer will also know the selected stream to the application at the peer will also know the selected stream to
be used, and the options for sending data from that side.</t> be used, as well as the options for sending data from that side.</t>
</section> </section>
<section numbered="true" toc="default">
<section title='Transferring User Data on a Data Channel'> <name>Transferring User Data on a Data Channel</name>
<t>All data sent on a data channel in both directions MUST be sent over the <t>All data sent on a data channel in both directions <bcp14>MUST</bcp14
> be sent over the
underlying stream using the reliability defined when the data channel was underlying stream using the reliability defined when the data channel was
opened unless the options are changed, or per-message options are specified opened, unless the options are changed or per-message options are specified
by a higher level.</t> by a higher level.</t>
<t>The message-orientation of SCTP is used to preserve the message boundaries <t>The message orientation of SCTP is used to preserve the message bound
of user messages. Therefore, senders MUST NOT put more than one application aries
of user messages. Therefore, senders <bcp14>MUST NOT</bcp14> put more than one a
pplication
message into an SCTP user message. Unless the deprecated PPID-based message into an SCTP user message. Unless the deprecated PPID-based
fragmentation and reassembly is used, the sender MUST include exactly one fragmentation and reassembly is used, the sender <bcp14>MUST</bcp14> include exa ctly one
application message in each SCTP user message.</t> application message in each SCTP user message.</t>
<t>The SCTP Payload Protocol Identifiers (PPIDs) are used to signal the <t>The SCTP Payload Protocol Identifiers (PPIDs) are used to signal the
interpretation of the "Payload data". The following PPIDs MUST be used interpretation of the "payload data". The following PPIDs <bcp14>MUST</bcp14> be
(see <xref target='sec-IANA'/>): used
<list style="hanging"> (see <xref target="sec-IANA" format="default"/>):
<t hangText='WebRTC String:'> </t>
to identify a non-empty JavaScript string encoded in UTF-8.</t> <dl newline="false" spacing="normal">
<t hangText='WebRTC String Empty:'> <dt>WebRTC String:</dt>
to identify an empty JavaScript string encoded in UTF-8.</t> <dd>
<t hangText='WebRTC Binary:'> to identify a non-empty JavaScript string encoded in UTF-8.</dd>
to identify a non-empty JavaScript binary data <dt>WebRTC String Empty:</dt>
(ArrayBuffer, ArrayBufferView or Blob).</t> <dd>
<t hangText='WebRTC Binary Empty:'> to identify an empty JavaScript string encoded in UTF-8.</dd>
to identify an empty JavaScript binary data <dt>WebRTC Binary:</dt>
(ArrayBuffer, ArrayBufferView or Blob).</t> <dd>
</list></t> to identify non-empty JavaScript binary data
<t>SCTP does not support the sending of empty user messages. Therefore, if an (ArrayBuffer, ArrayBufferView, or Blob).</dd>
<dt>WebRTC Binary Empty:</dt>
<dd>
to identify empty JavaScript binary data
(ArrayBuffer, ArrayBufferView, or Blob).</dd>
</dl>
<t>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 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 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 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.</t> <bcp14>MUST</bcp14> ignore the SCTP user message and process it as an empty mess
<t>The usage of the PPIDs "WebRTC String Partial" and "WebRTC Binary Partial" age.</t>
<t>The usage of the PPIDs "WebRTC String Partial" and "WebRTC Binary Par
tial"
is deprecated. They were used for a PPID-based fragmentation and reassembly is deprecated. They were used for a PPID-based fragmentation and reassembly
of user messages belonging to reliable and ordered data channels.</t> of user messages belonging to reliable and ordered data channels.</t>
<t>If a message with an unsupported PPID is received or some error condition <t>If a message with an unsupported PPID is received or some error condi tion
related to the received message is detected by the receiver related to the received message is detected by the receiver
(for example, illegal ordering), the receiver SHOULD close the corresponding (for example, illegal ordering), the receiver <bcp14>SHOULD</bcp14> close the co rresponding
data channel. This implies in particular that extensions using additional data channel. This implies in particular that extensions using additional
PPIDs can't be used without prior negotiation.</t> PPIDs can't be used without prior negotiation.</t>
<t>The SCTP base protocol specified in <xref target='RFC4960'/> does not <t>The SCTP base protocol specified in <xref target="RFC4960" format="de
support the interleaving of user messages. Therefore sending a large user fault"/> does not
support the interleaving of user messages. Therefore, sending a large user
message can monopolize the SCTP association. message can monopolize the SCTP association.
To overcome this limitation, <xref target='I-D.ietf-tsvwg-sctp-ndata'/> To overcome this limitation, <xref target="RFC8260" format="default"/>
defines an extension to support message interleaving, which SHOULD be used. defines an extension to support message interleaving, which <bcp14>SHOULD</bcp14
> be used.
As long as message interleaving is not supported, the sender As long as message interleaving is not supported, the sender
SHOULD limit the maximum message size to 16 KB to avoid monopolization.</t> <bcp14>SHOULD</bcp14> limit the maximum message size to 16 KB to avoid monopoliz
<t>It is recommended that the message size be kept within certain size bounds ation.</t>
as applications will not be able to support arbitrarily-large single <t>It is recommended that the message size be kept within certain size b
messages. This limit has to be negotiated, for example by using ounds,
<xref target='I-D.ietf-mmusic-sctp-sdp'/>.</t> as applications will not be able to support arbitrarily large single
<t>The sender SHOULD disable the Nagle algorithm (see <xref target='RFC1122'/>) messages. This limit has to be negotiated, for example, by using
<xref target="RFC8841" format="default"/>.</t>
<t>The sender <bcp14>SHOULD</bcp14> disable the Nagle algorithm (see <xr
ef target="RFC1122" format="default"/>)
to minimize the latency.</t> to minimize the latency.</t>
</section> </section>
<section numbered="true" toc="default">
<section title='Closing a Data Channel'> <name>Closing a Data Channel</name>
<t>Closing of a data channel MUST be signaled by resetting the corresponding <t>Closing of a data channel <bcp14>MUST</bcp14> be signaled by resettin
outgoing streams <xref target='RFC6525'/>. This means that if one side g the corresponding
outgoing streams <xref target="RFC6525" format="default"/>. This means that if o
ne side
decides to close the data channel, it resets the corresponding outgoing stream. 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 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 close d. corresponding outgoing stream. Once this is completed, the data channel is close d.
Resetting a stream sets the Stream Sequence Numbers (SSNs) of the stream back to Resetting a stream sets the Stream Sequence Numbers (SSNs) of the stream back to
'zero' with a corresponding notification to the application layer 'zero' with a corresponding notification to the application layer
that the reset has been performed. Streams are available for reuse after a reset that the reset has been performed. Streams are available for reuse after a reset
has been performed.</t> has been performed.</t>
<t><xref target='RFC6525'/> also guarantees that all the messages are delivered <t><xref target="RFC6525" format="default"/> also guarantees that all th e messages are delivered
(or abandoned) before the stream is reset.</t> (or abandoned) before the stream is reset.</t>
</section> </section>
</section> </section>
<section anchor="sec-security" numbered="true" toc="default">
<section title='Security Considerations' <name>Security Considerations</name>
anchor='sec-security'> <t>This document does not add any additional considerations to the ones gi
<t>This document does not add any additional considerations to the ones given in ven in
<xref target='I-D.ietf-rtcweb-security'/> and <xref target="RFC8826" format="default"/> and
<xref target='I-D.ietf-rtcweb-security-arch'/>.</t> <xref target="RFC8827" format="default"/>.</t>
<t>It should be noted that a receiver must be prepared that the sender tries <t>It should be noted that a receiver must be prepared for a sender that t
to send arbitrary large messages.</t> ries
</section> to send arbitrarily large messages.</t>
</section>
<section title='IANA Considerations' <section anchor="sec-IANA" numbered="true" toc="default">
anchor='sec-IANA'> <name>IANA Considerations</name>
<t>[NOTE to RFC-Editor: <t>This document uses six already registered SCTP Payload Protocol
<list>
<t>"RFCXXXX" is to be replaced by the RFC number you assign this document.</t>
</list>
]</t>
<t>This document uses six already registered SCTP Payload Protocol
Identifiers (PPIDs): Identifiers (PPIDs):
"DOMString Last", "DOMString Last",
"Binary Data Partial", "Binary Data Partial",
"Binary Data Last", "Binary Data Last",
"DOMString Partial", "DOMString Partial",
"WebRTC String Empty", and "WebRTC String Empty", and
"WebRTC Binary Empty". "WebRTC Binary Empty".
<xref target='RFC4960'/> creates the registry "SCTP Payload Protocol Identifiers " <xref target="RFC4960" format="default"/> creates the "SCTP Payload Protocol Ide ntifiers" registry
from which these identifiers were assigned. from which these identifiers were assigned.
IANA is requested to update the reference of these six assignments to point IANA has updated the reference of these six assignments to point
to this document and change the names of the first four PPIDs. to this document and changed the names of the first four PPIDs.
The corresponding dates should be kept.</t> The corresponding dates remain unchanged.</t>
<t>Therefore these six assignments should be updated to read:</t> <t>The six assignments have been updated to read:</t>
<texttable> <table align="center">
<ttcol align='left'>Value</ttcol> <thead>
<ttcol align='left'>SCTP PPID</ttcol> <tr>
<ttcol align='left'>Reference</ttcol> <th align="left">Value</th>
<ttcol align='left'>Date</ttcol> <th align="left">SCTP PPID</th>
<c>WebRTC String</c> <c>51</c> <c>[RFCXXXX]</c> <c>2013-09- <th align="left">Reference</th>
20</c> <th align="left">Date</th>
<c>WebRTC Binary Partial (Deprecated)</c> <c>52</c> <c>[RFCXXXX]</c> <c>2013-09- </tr>
20</c> </thead>
<c>WebRTC Binary</c> <c>53</c> <c>[RFCXXXX]</c> <c>2013-09- <tbody>
20</c> <tr>
<c>WebRTC String Partial (Deprecated)</c> <c>54</c> <c>[RFCXXXX]</c> <c>2013-09- <td align="left">WebRTC String</td>
20</c> <td align="left">51</td>
<c>WebRTC String Empty</c> <c>56</c> <c>[RFCXXXX]</c> <c>2014-08- <td align="left">RFC 8831</td>
22</c> <td align="left">2013-09-20</td>
<c>WebRTC Binary Empty</c> <c>57</c> <c>[RFCXXXX]</c> <c>2014-08- </tr>
22</c> <tr>
</texttable> <td align="left">WebRTC Binary Partial (deprecated)</td>
</section> <td align="left">52</td>
<td align="left">RFC 8831</td>
<td align="left">2013-09-20</td>
</tr>
<tr>
<td align="left">WebRTC Binary</td>
<td align="left">53</td>
<td align="left">RFC 8831</td>
<td align="left">2013-09-20</td>
</tr>
<tr>
<td align="left">WebRTC String Partial (deprecated)</td>
<td align="left">54</td>
<td align="left">RFC 8831</td>
<td align="left">2013-09-20</td>
</tr>
<tr>
<td align="left">WebRTC String Empty</td>
<td align="left">56</td>
<td align="left">RFC 8831</td>
<td align="left">2014-08-22</td>
</tr>
<tr>
<td align="left">WebRTC Binary Empty</td>
<td align="left">57</td>
<td align="left">RFC 8831</td>
<td align="left">2014-08-22</td>
</tr>
</tbody>
</table>
</section>
</middle>
<back>
<references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3758.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4347.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4820.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4821.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4960.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5061.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8445.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6347.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6525.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8260.xml"/>
<!--draft-ietf-rtcweb-data-protocol: 8832 -->
<reference anchor="RFC8832" target="https://www.rfc-editor.org/info/rfc8832">
<front>
<title>WebRTC Data Channel Establishment Protocol</title>
<author initials='R.' surname='Jesup' fullname='Randell Jesup'>
<organization/>
</author>
<author initials='S.' surname='Loreto' fullname='Salvatore Loreto'>
<organization/>
</author>
<author initials='M' surname='Tüxen' fullname='Michael Tüxen'>
<organization/>
</author>
<date month='October' year='2020'/>
</front>
<seriesInfo name="RFC" value="8832"/>
<seriesInfo name="DOI" value="10.17487/RFC8832"/>
</reference>
<section title='Acknowledgments'> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<t>Many thanks for comments, ideas, and text from FC.8261.xml"/>
Harald Alvestrand,
Richard Barnes,
Adam Bergkvist,
Alissa Cooper,
Benoit Claise,
Spencer Dawkins,
Gunnar Hellstrom,
Christer Holmberg,
Cullen Jennings,
Paul Kyzivat,
Eric Rescorla,
Adam Roach,
Irene Ruengeler,
Randall Stewart,
Martin Stiemerling,
Justin Uberti,
and Magnus Westerlund.</t>
</section>
</middle>
<back> <!--draft-ietf-rtcweb-security: RFC 8826 -->
<references title='Normative References'> <reference anchor="RFC8826" target="https://www.rfc-editor.org/info/rfc8826">
<?rfc include='reference.RFC.2119' ?> <front>
<?rfc include='reference.RFC.3758'?> <title>Security Considerations for WebRTC</title>
<?rfc include='reference.RFC.4347'?> <author initials='E.' surname='Rescorla' fullname='Eric Rescorla'>
<?rfc include='reference.RFC.4820'?> <organization/>
<?rfc include='reference.RFC.4821'?> </author>
<?rfc include='reference.RFC.4960'?> <date month='October' year='2020'/>
<?rfc include='reference.RFC.5061'?> </front>
<?rfc include='reference.RFC.5245'?> <seriesInfo name="RFC" value="8826"/>
<?rfc include='reference.RFC.6347'?> <seriesInfo name="DOI" value="10.17487/RFC8826"/>
<?rfc include='reference.RFC.6525'?> </reference>
<?rfc include='reference.I-D.ietf-tsvwg-sctp-ndata'?>
<?rfc include='reference.I-D.ietf-rtcweb-data-protocol'?> <!--draft-ietf-rtcweb-security-arch: 8827 -->
<?rfc include='reference.I-D.ietf-tsvwg-sctp-dtls-encaps'?> <reference anchor="RFC8827" target="https://www.rfc-editor.org/info/rfc8827">
<?rfc include='reference.I-D.ietf-rtcweb-security'?> <front>
<?rfc include='reference.I-D.ietf-rtcweb-security-arch'?> <title>WebRTC Security Architecture</title>
<?rfc include='reference.I-D.ietf-rtcweb-jsep'?> <author initials='E.' surname='Rescorla' fullname='Eric Rescorla'>
<?rfc include='reference.I-D.ietf-tsvwg-sctp-prpolicies'?> <organization/>
<?rfc include='reference.I-D.ietf-mmusic-sctp-sdp'?> </author>
</references> <date month='October' year='2020'/>
<references title='Informative References'> </front>
<?rfc include='reference.RFC.1122'?> <seriesInfo name="RFC" value="8827"/>
<?rfc include='reference.RFC.5764'?> <seriesInfo name="DOI" value="10.17487/RFC8827"/>
<?rfc include='reference.RFC.6083'?> </reference>
<?rfc include='reference.RFC.6951'?>
</references> <!--draft-ietf-rtcweb-jsep: 8829 -->
</back> <reference anchor="RFC8829" target="https://www.rfc-editor.org/info/rfc8829">
<front>
<title>JavaScript Session Establishment Protocol (JSEP)</title>
<author initials='J.' surname='Uberti' fullname='Justin Uberti'>
<organization/>
</author>
<author initials="C." surname="Jennings" fullname="Cullen Jennings">
<organization/>
</author>
<author initials="E." surname="Rescorla" fullname="Eric Rescorla"
role="editor">
<organization/>
</author>
<date month='October' year='2020'/>
</front>
<seriesInfo name="RFC" value="8829"/>
<seriesInfo name="DOI" value="10.17487/RFC8829"/>
</reference>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7496.xml"/>
<!-- draft-ietf-mmusic-sctp-sdp: 8841 -->
<reference anchor="RFC8841" target="https://www.rfc-editor.org/info/rfc8841">
<front>
<title>Session Description Protocol (SDP) Offer/Answer Procedures for
Stream Control Transmission Protocol (SCTP) over Datagram Transport Layer
Security (DTLS) Transport</title>
<author initials="C." surname="Holmberg" fullname="Christer Holmberg">
<organization />
</author>
<author initials="R." surname="Shpount" fullname="Roman Shpount">
<organization />
</author>
<author initials="S." surname="Loreto" fullname="Salvatore Loreto">
<organization />
</author>
<author initials="G." surname="Camarillo" fullname="Gonzalo Camarillo">
<organization />
</author>
<date month="October" year="2020" />
</front>
<seriesInfo name="RFC" value="8841" />
<seriesInfo name="DOI" value="10.17487/RFC8841"/>
</reference>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.1122.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5389.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5764.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6083.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6951.xml"/>
</references>
</references>
<section numbered="false" toc="default">
<name>Acknowledgements</name>
<t>Many thanks for comments, ideas, and text from <contact
fullname="Harald Alvestrand"/>, <contact fullname="Richard Barnes"/>,
<contact fullname="Adam Bergkvist"/>, <contact fullname="Alissa Cooper"/>,
<contact fullname="Benoit Claise"/>, <contact fullname="Spencer
Dawkins"/>, <contact fullname="Gunnar Hellström"/>, <contact
fullname="Christer Holmberg"/>, <contact fullname="Cullen Jennings"/>,
<contact fullname="Paul Kyzivat"/>, <contact fullname="Eric Rescorla"/>,
<contact fullname="Adam Roach"/>, <contact fullname="Irene Rüngeler"/>,
<contact fullname="Randall Stewart"/>, <contact fullname="Martin
Stiemerling"/>, <contact fullname="Justin Uberti"/>, and <contact
fullname="Magnus Westerlund"/>.</t>
</section>
</back>
</rfc> </rfc>
 End of changes. 77 change blocks. 
486 lines changed or deleted 691 lines changed or added

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