rfc8831xml2.original.xml		rfc8831.xml
	<?xml version='1.0'?>		<?xml version='1.0' encoding='utf-8'?>
	<?rfc symrefs='yes'?>		<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" conse
	<!DOCTYPE rfc SYSTEM 'rfc2629.dtd'>		nsus="true" docName="draft-ietf-rtcweb-data-channel-13" indexInclude="true" ipr=
	<?rfc toc='yes' ?>		"trust200902" number="8831" prepTime="2021-01-16T21:17:59" scripts="Common,Latin
	<?rfc compact='yes' ?>		" sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="3" tocInclude="
	<?rfc subcompact='no' ?>		true" xml:lang="en">
	<?rfc sortrefs='no' ?>		<link href="https://datatracker.ietf.org/doc/draft-ietf-rtcweb-data-channel-13
	<?rfc strict='yes' ?>		" rel="prev"/>
			<link href="https://dx.doi.org/10.17487/rfc8831" rel="alternate"/>
	<rfc category='std'		<link href="urn:issn:2070-1721" rel="alternate"/>
	ipr='trust200902'		<front>
	docName='draft-ietf-rtcweb-data-channel-13.txt'>		<title>WebRTC Data Channels</title>
	<front>		<seriesInfo name="RFC" value="8831" stream="IETF"/>
	<title>WebRTC Data Channels</title>		<author initials="R." surname="Jesup" fullname="Randell Jesup">
			<organization showOnFrontPage="true">Mozilla</organization>
	<author initials='R.' surname='Jesup' fullname='Randell Jesup'>		<address>
	<organization>Mozilla</organization>		<postal>
	<address>		<street/>
	<postal>		<code/>
	<street></street>		<city/>
	<code></code>		<country>United States of America</country>
	<city></city>		</postal>
	<country>US</country>		<email>randell-ietf@jesup.org</email>
	</postal>		</address>
	<email>randell-ietf@jesup.org</email>		</author>
	</address>		<author initials="S." surname="Loreto" fullname="Salvatore Loreto">
	</author>		<organization showOnFrontPage="true">Ericsson</organization>
			<address>
	<author initials='S.' surname='Loreto' fullname='Salvatore Loreto'>		<postal>
	<organization>Ericsson</organization>		<street>Hirsalantie 11</street>
	<address>		<code>02420</code>
	<postal>		<city>Jorvas</city>
	<street>Hirsalantie 11</street>		<country>Finland</country>
	<code>02420</code>		</postal>
	<city>Jorvas</city>		<email>salvatore.loreto@ericsson.com</email>
	<country>FI</country>		</address>
	</postal>		</author>
	<email>salvatore.loreto@ericsson.com</email>		<author initials="M." surname="Tüxen" fullname="Michael Tüxen">
	</address>		<organization abbrev="Münster Univ. of Appl. Sciences" showOnFrontPage="tr
	</author>		ue">Münster University of Applied Sciences</organization>
			<address>
	<author initials='M.' surname='Tuexen' fullname='Michael Tuexen'>		<postal>
	<organization abbrev='Muenster Univ. of Appl. Sciences'>		<street>Stegerwaldstrasse 39</street>
	Muenster University of Applied Sciences</organization>		<code>48565</code>
	<address>		<city> Steinfurt</city>
	<postal>		<country>Germany</country>
	<street>Stegerwaldstrasse 39</street>		</postal>
	<code>48565</code>		<email>tuexen@fh-muenster.de</email>
	<city> Steinfurt</city>		</address>
	<country>DE</country>		</author>
	</postal>		<date month="01" year="2021"/>
	<email>tuexen@fh-muenster.de</email>		<abstract pn="section-abstract">
	</address>		<t indent="0" pn="section-abstract-1">The WebRTC framework specifies proto
	</author>		col support for direct, interactive,
			rich communication using audio, video, and data between two peers' web browsers.
	<date />
	<area>RAI</area>
	<abstract>
	<t>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		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>		<boilerplate>
			<section anchor="status-of-memo" numbered="false" removeInRFC="false" toc=
	<middle>		"exclude" pn="section-boilerplate.1">
	<section title='Introduction'>		<name slugifiedName="name-status-of-this-memo">Status of This Memo</name
	<t>In the WebRTC framework, communication between the parties consists of media		>
	(for example audio and video) and non-media data.		<t indent="0" pn="section-boilerplate.1-1">
	Media is sent using SRTP, and is not specified further here.		This is an Internet Standards Track document.
	Non-media data is handled by using SCTP <xref target='RFC4960'/> encapsulated		</t>
	in DTLS. DTLS 1.0 is defined in <xref target='RFC4347'/> and the present		<t indent="0" pn="section-boilerplate.1-2">
	latest version, DTLS 1.2, is defined in <xref target='RFC6347'/>.</t>		This document is a product of the Internet Engineering Task Force
			(IETF). It represents the consensus of the IETF community. It has
	<figure title='Basic stack diagram'		received public review and has been approved for publication by
	anchor='fig-stack'>		the Internet Engineering Steering Group (IESG). Further
	<artwork align='center'>		information on Internet Standards is available in Section 2 of
			RFC 7841.
			</t>
			<t indent="0" pn="section-boilerplate.1-3">
			Information about the current status of this document, any
			errata, and how to provide feedback on it may be obtained at
			<eref target="https://www.rfc-editor.org/info/rfc8831" brackets="non
			e"/>.
			</t>
			</section>
			<section anchor="copyright" numbered="false" removeInRFC="false" toc="excl
			ude" pn="section-boilerplate.2">
			<name slugifiedName="name-copyright-notice">Copyright Notice</name>
			<t indent="0" pn="section-boilerplate.2-1">
			Copyright (c) 2021 IETF Trust and the persons identified as the
			document authors. All rights reserved.
			</t>
			<t indent="0" pn="section-boilerplate.2-2">
			This document is subject to BCP 78 and the IETF Trust's Legal
			Provisions Relating to IETF Documents
			(<eref target="https://trustee.ietf.org/license-info" brackets="none
			"/>) 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.
			</t>
			</section>
			</boilerplate>
			<toc>
			<section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" p
			n="section-toc.1">
			<name slugifiedName="name-table-of-contents">Table of Contents</name>
			<ul bare="true" empty="true" indent="2" spacing="compact" pn="section-to
			c.1-1">
			<li pn="section-toc.1-1.1">
			<t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref der
			ivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref
			derivedContent="" format="title" sectionFormat="of" target="name-introduction">
			Introduction</xref></t>
			</li>
			<li pn="section-toc.1-1.2">
			<t indent="0" keepWithNext="true" pn="section-toc.1-1.2.1"><xref der
			ivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref
			derivedContent="" format="title" sectionFormat="of" target="name-conventions">C
			onventions</xref></t>
			</li>
			<li pn="section-toc.1-1.3">
			<t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" form
			at="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" f
			ormat="title" sectionFormat="of" target="name-use-cases">Use Cases</xref></t>
			<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
			n-toc.1-1.3.2">
			<li pn="section-toc.1-1.3.2.1">
			<t indent="0" keepWithNext="true" pn="section-toc.1-1.3.2.1.1"><
			xref derivedContent="3.1" format="counter" sectionFormat="of" target="section-3.
			1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-us
			e-cases-for-unreliable-da">Use Cases for Unreliable Data Channels</xref></t>
			</li>
			<li pn="section-toc.1-1.3.2.2">
			<t indent="0" pn="section-toc.1-1.3.2.2.1"><xref derivedContent=
			"3.2" format="counter" sectionFormat="of" target="section-3.2"/>.  <xref derived
			Content="" format="title" sectionFormat="of" target="name-use-cases-for-reliable
			-data">Use Cases for Reliable Data Channels</xref></t>
			</li>
			</ul>
			</li>
			<li pn="section-toc.1-1.4">
			<t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" form
			at="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" f
			ormat="title" sectionFormat="of" target="name-requirements">Requirements</xref><
			/t>
			</li>
			<li pn="section-toc.1-1.5">
			<t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" form
			at="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" f
			ormat="title" sectionFormat="of" target="name-sctp-over-dtls-over-udp-con">SCTP
			over DTLS over UDP Considerations</xref></t>
			</li>
			<li pn="section-toc.1-1.6">
			<t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" form
			at="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" f
			ormat="title" sectionFormat="of" target="name-the-usage-of-sctp-for-data-">The U
			sage of SCTP for Data Channels</xref></t>
			<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
			n-toc.1-1.6.2">
			<li pn="section-toc.1-1.6.2.1">
			<t indent="0" pn="section-toc.1-1.6.2.1.1"><xref derivedContent=
			"6.1" format="counter" sectionFormat="of" target="section-6.1"/>.  <xref derived
			Content="" format="title" sectionFormat="of" target="name-sctp-protocol-consider
			ation">SCTP Protocol Considerations</xref></t>
			</li>
			<li pn="section-toc.1-1.6.2.2">
			<t indent="0" pn="section-toc.1-1.6.2.2.1"><xref derivedContent=
			"6.2" format="counter" sectionFormat="of" target="section-6.2"/>.  <xref derived
			Content="" format="title" sectionFormat="of" target="name-sctp-association-manag
			ement">SCTP Association Management</xref></t>
			</li>
			<li pn="section-toc.1-1.6.2.3">
			<t indent="0" pn="section-toc.1-1.6.2.3.1"><xref derivedContent=
			"6.3" format="counter" sectionFormat="of" target="section-6.3"/>.  <xref derived
			Content="" format="title" sectionFormat="of" target="name-sctp-streams">SCTP Str
			eams</xref></t>
			</li>
			<li pn="section-toc.1-1.6.2.4">
			<t indent="0" pn="section-toc.1-1.6.2.4.1"><xref derivedContent=
			"6.4" format="counter" sectionFormat="of" target="section-6.4"/>.  <xref derived
			Content="" format="title" sectionFormat="of" target="name-data-channel-definitio
			n">Data Channel Definition</xref></t>
			</li>
			<li pn="section-toc.1-1.6.2.5">
			<t indent="0" pn="section-toc.1-1.6.2.5.1"><xref derivedContent=
			"6.5" format="counter" sectionFormat="of" target="section-6.5"/>.  <xref derived
			Content="" format="title" sectionFormat="of" target="name-opening-a-data-channel
			">Opening a Data Channel</xref></t>
			</li>
			<li pn="section-toc.1-1.6.2.6">
			<t indent="0" pn="section-toc.1-1.6.2.6.1"><xref derivedContent=
			"6.6" format="counter" sectionFormat="of" target="section-6.6"/>.  <xref derived
			Content="" format="title" sectionFormat="of" target="name-transferring-user-data
			-on-a">Transferring User Data on a Data Channel</xref></t>
			</li>
			<li pn="section-toc.1-1.6.2.7">
			<t indent="0" pn="section-toc.1-1.6.2.7.1"><xref derivedContent=
			"6.7" format="counter" sectionFormat="of" target="section-6.7"/>.  <xref derived
			Content="" format="title" sectionFormat="of" target="name-closing-a-data-channel
			">Closing a Data Channel</xref></t>
			</li>
			</ul>
			</li>
			<li pn="section-toc.1-1.7">
			<t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" form
			at="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" f
			ormat="title" sectionFormat="of" target="name-security-considerations">Security
			Considerations</xref></t>
			</li>
			<li pn="section-toc.1-1.8">
			<t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" form
			at="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" f
			ormat="title" sectionFormat="of" target="name-iana-considerations">IANA Consider
			ations</xref></t>
			</li>
			<li pn="section-toc.1-1.9">
			<t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9" form
			at="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" f
			ormat="title" sectionFormat="of" target="name-references">References</xref></t>
			<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
			n-toc.1-1.9.2">
			<li pn="section-toc.1-1.9.2.1">
			<t indent="0" pn="section-toc.1-1.9.2.1.1"><xref derivedContent=
			"9.1" format="counter" sectionFormat="of" target="section-9.1"/>.  <xref derived
			Content="" format="title" sectionFormat="of" target="name-normative-references">
			Normative References</xref></t>
			</li>
			<li pn="section-toc.1-1.9.2.2">
			<t indent="0" pn="section-toc.1-1.9.2.2.1"><xref derivedContent=
			"9.2" format="counter" sectionFormat="of" target="section-9.2"/>.  <xref derived
			Content="" format="title" sectionFormat="of" target="name-informative-references
			">Informative References</xref></t>
			</li>
			</ul>
			</li>
			<li pn="section-toc.1-1.10">
			<t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="" form
			at="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="
			" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgeme
			nts</xref></t>
			</li>
			<li pn="section-toc.1-1.11">
			<t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="" form
			at="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="
			" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Add
			resses</xref></t>
			</li>
			</ul>
			</section>
			</toc>
			</front>
			<middle>
			<section numbered="true" toc="include" removeInRFC="false" pn="section-1">
			<name slugifiedName="name-introduction">Introduction</name>
			<t indent="0" pn="section-1-1">In the WebRTC framework, communication betw
			een 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 (SCT
			P) <xref target="RFC4960" format="default" sectionFormat="of" derivedContent="RF
			C4960"/> encapsulated
			in DTLS. DTLS 1.0 is defined in <xref target="RFC4347" format="default" sectionF
			ormat="of" derivedContent="RFC4347"/>; the present
			latest version, DTLS 1.2, is defined in <xref target="RFC6347" format="default"
			sectionFormat="of" derivedContent="RFC6347"/>; and
			an upcoming version, DTLS 1.3, is defined in <xref target="I-D.ietf-tls-dtls13"
			format="default" sectionFormat="of" derivedContent="TLS-DTLS13"/>.</t>
			<figure anchor="fig-stack" align="left" suppress-title="false" pn="figure-
			1">
			<name slugifiedName="name-basic-stack-diagram">Basic Stack Diagram</name
			>
			<artwork align="center" name="" type="" alt="" pn="section-1-2.1">
	+----------+		+----------+
	| SCTP |		| SCTP |
	+----------+		+----------+
	| DTLS |		| DTLS |
	+----------+		+----------+
	| ICE/UDP |		| ICE/UDP |
	+----------+		+----------+</artwork>
	</artwork>		</figure>
	</figure>		<t indent="0" pn="section-1-3">The encapsulation of SCTP over DTLS
	<t>The encapsulation of SCTP over DTLS		(see <xref target="RFC8261" format="default" sectionFormat="of" derivedContent="
	(see <xref target='I-D.ietf-tsvwg-sctp-dtls-encaps'/>) over ICE/UDP		RFC8261"/>) over ICE/UDP
	(see <xref target='RFC5245'/>) provides a NAT traversal		(see <xref target="RFC8445" format="default" sectionFormat="of" derivedContent="
			RFC8445"/>) 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 indent="0" pn="section-1-4">SCTP, as specified in <xref target="RFC4960
	extension defined in <xref target='RFC3758'/> and the additional policies		" format="default" sectionFormat="of" derivedContent="RFC4960"/> with the partia
	defined in <xref target='I-D.ietf-tsvwg-sctp-prpolicies'/>		l reliability
			extension (PR-SCTP) defined in <xref target="RFC3758" format="default" sectionFo
			rmat="of" derivedContent="RFC3758"/> and the additional policies
			defined in <xref target="RFC7496" format="default" sectionFormat="of" derivedCon
			tent="RFC7496"/>,
	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" sectionFormat="of" derivedContent="RFC6525"/>
	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" sectionFormat="of" derivedContent=
	prioritizing of SCTP streams.</t>		"RFC8260"/> allows the interleave of large messages 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 indent="0" pn="section-1-5">The remainder of this document is organized
	<xref target='sec-p-a-2'/> discusses SCTP over DTLS over UDP;		as follows:
	<xref target='sec-sctp-usage'/> provides the specification of how SCTP should be		Sections <xref target="sec-use-cases" format="counter" sectionFormat="of" derive
			dContent="3"/> and <xref target="sec-req" format="counter" sectionFormat="of" de
			rivedContent="4"/> provide use cases
			and requirements for both unreliable and reliable peer-to-peer data channels;
			<xref target="sec-p-a-2" format="default" sectionFormat="of" derivedContent="Sec
			tion 5"/> discusses SCTP over DTLS over UDP; and
			<xref target="sec-sctp-usage" format="default" sectionFormat="of" derivedContent
			="Section 6"/> 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="include" removeInRFC="false" pn="section-2">
	<section title='Conventions'>		<name slugifiedName="name-conventions">Conventions</name>
	<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		<t indent="0" pn="section-2-1">The key words "<bcp14>MUST</bcp14>", "<bcp1
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"		4>MUST NOT</bcp14>",
	in this document are to be interpreted as described in		"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
	<xref target='RFC2119'/>.</t>		"<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
	</section>		"<bcp14>SHOULD NOT</bcp14>",
			"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
	<section title='Use Cases'		"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
	anchor='sec-use-cases'>		are to be interpreted as described in BCP 14
	<t>This section defines use cases specific to data channels.		<xref target="RFC2119" format="default" sectionFormat="of" derivedContent
			="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedC
			ontent="RFC8174"/> when, and only
			when, they appear in all capitals, as shown here.</t>
			</section>
			<section anchor="sec-use-cases" numbered="true" toc="include" removeInRFC="f
			alse" pn="section-3">
			<name slugifiedName="name-use-cases">Use Cases</name>
			<t indent="0" pn="section-3-1">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="include" r
	<section title='Use Cases for Unreliable Data Channels'		emoveInRFC="false" pn="section-3.1">
	anchor='sec-use-cases-unreliable'>		<name slugifiedName="name-use-cases-for-unreliable-da">Use Cases for Unr
	<t><list style='format U-C %d:' counter='UseCases'>		eliable Data Channels</name>
	<t>A real-time game where position and object state information is		<ol group="UseCases" spacing="normal" type="U-C %d:" indent="8" start="1
			" pn="section-3.1-1">
			<li pn="section-3.1-1.1" derivedCounter="U-C 1:">A real-time game wher
			e position and object state information are
	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 pn="section-3.1-1.2" derivedCounter="U-C 2:">Providing non-critica
	</list></t>		l information to a user about the reason for 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="include" rem
	<t><list style='format U-C %d:' counter='UseCases'>		oveInRFC="false" pn="section-3.2">
	<t> A real-time game where critical state information needs to be		<name slugifiedName="name-use-cases-for-reliable-data">Use Cases for Rel
			iable Data Channels</name>
			<ol group="UseCases" spacing="normal" type="U-C %d:" indent="8" start="3
			" pn="section-3.2-1">
			<li pn="section-3.2-1.1" derivedCounter="U-C 3:"> A real-time game whe
			re 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 pn="section-3.2-1.2" derivedCounter="U-C 4:">Non-real-time file tr
			ansfers 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 pn="section-3.2-1.3" derivedCounter="U-C 5:">Real-time text chat d
	or with multiple people in a conference.</t>		uring an audio and/or video call with an individual
	<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 pn="section-3.2-1.4" derivedCounter="U-C 6:">Renegotiation of the
	to send and receive HTTP/HTTPS requests and data, for example to avoid local		configuration of the PeerConnection.</li>
	Internet filtering or monitoring.</t>		<li pn="section-3.2-1.5" derivedCounter="U-C 7:">Proxy browsing, where
	</list></t>		a browser uses data channels of a PeerConnection
	</section>		to send and receive HTTP/HTTPS requests and data, for example, to avoid local
	</section>		Internet filtering or monitoring.</li>
			</ol>
	<section title='Requirements'		</section>
	anchor='sec-req'>		</section>
	<t>This section lists the requirements for P2P data channels between		<section anchor="sec-req" numbered="true" toc="include" removeInRFC="false"
			pn="section-4">
			<name slugifiedName="name-requirements">Requirements</name>
			<t indent="0" pn="section-4-1">This section lists the requirements for Pee
			r-to-Peer (P2P) data channels 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" start="1" pn="section-4-2
	<t>Multiple simultaneous data channels must be supported.		">
	Note that there may be 0 or more SRTP media streams in parallel with the data		<li pn="section-4-2.1" derivedCounter="Req. 1:">Multiple simultaneous da
			ta 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)		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 pn="section-4-2.2" derivedCounter="Req. 2:">Both reliable and unreli
	<t>Data channels of a PeerConnection must be congestion controlled;		able data channels must be supported.</li>
			<li pn="section-4-2.3" derivedCounter="Req. 3:">Data channels of a PeerC
			onnection 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 pn="section-4-2.4" derivedCounter="Req. 4:">The application should b
	relative priority of each data channel relative to each other,		e able to provide guidance as to the
			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 pn="section-4-2.5" derivedCounter="Req. 5:">Data channels must be se
	integrity and source authentication.		cured, which allows for confidentiality,
	See <xref target='I-D.ietf-rtcweb-security'/> and		integrity, and source authentication.
	<xref target='I-D.ietf-rtcweb-security-arch'/> for detailed info.</t>		See <xref target="RFC8826" format="default" sectionFormat="of" derivedContent="R
	<!--<t>Consent and NAT traversal mechanism: These are handled by the		FC8826"/> and
	PeerConnection's ICE <xref target='RFC5245'/> connectivity checks and		<xref target="RFC8827" format="default" sectionFormat="of" derivedContent="RFC88
	optional TURN servers.</t>-->		27"/> for detailed information.</li>
	<t>Data channels must provide message fragmentation support such that		<li pn="section-4-2.6" derivedCounter="Req. 6:">Data channels must provi
			de 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 pn="section-4-2.7" derivedCounter="Req. 7:">The data channel transpo
	inside its protocol fields; doing so reveals potentially private information,		rt protocol must not encode local IP addresses
	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 pn="section-4-2.8" derivedCounter="Req. 8:">The data channel transpo
	(i.e., a virtual socket stream) at the application layer, for such things as		rt protocol should support unbounded-length "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 pn="section-4-2.9" derivedCounter="Req. 9:">The data channel transpo
	being generated or being passed back, especially for PMTU discovery.</t>		rt protocol should avoid IP fragmentation. It
	<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 pn="section-4-2.10" derivedCounter="Req. 10:">It must be possible to
	</section>		implement the protocol stack in the user application 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="include" removeInRFC="false
	<t>The important features of SCTP in the WebRTC context are:		" pn="section-5">
	<list style='symbols'>		<name slugifiedName="name-sctp-over-dtls-over-udp-con">SCTP over DTLS over
	<t>Usage of a TCP-friendly congestion control.</t>		UDP Considerations</name>
	<t>The congestion control is modifiable for integration with the		<t indent="0" pn="section-5-1">The important features of SCTP in the WebRT
	SRTP media stream congestion control.</t>		C context are the following:
	<t>Support of multiple unidirectional streams, each providing its own		</t>
	notion of ordered message delivery.</t>		<ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5-2
	<t>Support of ordered and out-of-order message delivery.</t>		">
	<t>Supporting arbitrary large user messages by providing fragmentation		<li pn="section-5-2.1">Usage of TCP-friendly congestion control.</li>
	and reassembly.</t>		<li pn="section-5-2.2">modifiable congestion control for integration wit
	<t>Support of PMTU-discovery.</t>		h the
	<t>Support of reliable or partially reliable message transport.</t>		SRTP media stream congestion control.</li>
	</list></t>		<li pn="section-5-2.3">Support of multiple unidirectional streams, each
	<t>The WebRTC Data Channel mechanism does not support SCTP multihoming.		providing its own
			notion of ordered message delivery.</li>
			<li pn="section-5-2.4">Support of ordered and out-of-order message deliv
			ery.</li>
			<li pn="section-5-2.5">Support of arbitrarily large user messages by pro
			viding fragmentation
			and reassembly.</li>
			<li pn="section-5-2.6">Support of PMTU discovery.</li>
			<li pn="section-5-2.7">Support of reliable or partially reliable message
			transport.</li>
			</ul>
			<t indent="0" pn="section-5-3">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 indent="0" pn="section-5-4">The encapsulation of SCTP over DTLS defined
	<xref target='I-D.ietf-tsvwg-sctp-dtls-encaps'/> provides confidentiality,		in
	source authenticated, and integrity protected transfers.		<xref target="RFC8261" format="default" sectionFormat="of" derivedContent="RFC82
	Using DTLS over UDP in combination with ICE enables middlebox traversal		61"/> provides confidentiality,
	in IPv4 and IPv6 based networks.		source authentication, and integrity-protected transfers.
	SCTP as specified in <xref target='RFC4960'/> MUST be used in		Using DTLS over UDP in combination with Interactive Connectivity Establishment
	combination with the extension defined in <xref target='RFC3758'/> and		(ICE) <xref target="RFC8445" format="default" sectionFormat="of" derivedContent=
			"RFC8445"/> enables middlebox traversal
			in IPv4- and IPv6-based networks.
			SCTP as specified in <xref target="RFC4960" format="default" sectionFormat="of"
			derivedContent="RFC4960"/> <bcp14>MUST</bcp14> be used in
			combination with the extension defined in <xref target="RFC3758" format="default
			" sectionFormat="of" derivedContent="RFC3758"/> 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" bare="false" empty="false" indent="3" pn="section-5-5
	<t>Ordered and unordered delivery of user messages.</t>		">
	<t>Reliable and partial-reliable transport of user messages.</t>		<li pn="section-5-5.1">Support of multiple unidirectional streams.</li>
	</list></t>		<li pn="section-5-5.2">Ordered and unordered delivery of user messages.<
	<t>Each SCTP user message contains a Payload Protocol Identifier (PPID)		/li>
			<li pn="section-5-5.3">Reliable and partially reliable transport of user
			messages.</li>
			</ul>
			<t indent="0" pn="section-5-6">Each SCTP user message contains a Payload P
			rotocol 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" sectionFormat="of" derivedContent="RFC88
	Please note that the PPID is not accessible via the Javascript API.</t>		32"/>.
	<!--		Please note that the PPID is not accessible via the JavaScript API.</t>
	<t>Moreover SCTP provides the possibility to transport different "protocols"		<t indent="0" pn="section-5-7">The encapsulation of SCTP over DTLS, togeth
	over multiple streams and associations using the PPID		er with the SCTP features listed
	(Payload Protocol Identifier).		above, satisfies all the requirements listed in <xref target="sec-req" format="d
	An application can set a different PPID with each send call.		efault" sectionFormat="of" derivedContent="Section 4"/>.</t>
	This allows the receiving application to look at this information		<t indent="0" pn="section-5-8">The layering of protocols for WebRTC is sho
	(as well as the stream id/seq) on receiving to know what type of protocol		wn in <xref target="fig-sctp-layering" format="default" sectionFormat="of" deriv
	the data payload has.</t>		edContent="Figure 2"/>.</t>
	<t>The encapsulation of SCTP over DTLS, together with the SCTP features listed		<figure anchor="fig-sctp-layering" align="left" suppress-title="false" pn=
	above satisfies all the requirements listed in <xref target='sec-req'/>.</t>		"figure-2">
	<!--		<name slugifiedName="name-webrtc-protocol-layers">WebRTC Protocol Layers
	<t>There are SCTP implementations for most Operating Systems in wide use:</t>		</name>
	<t>		<artwork align="center" name="" type="" alt="" pn="section-5-9.1">
	<list style='empty'>
	<t>Linux (mainline kernel 2.6.36)</t>
	<t>FreeBSD (release kernel 8.2)</t>
	<t>Mac OS X</t>
	<t>Windows (SctpDrv4)</t>
	<t>Solaris (OpenSolaris 2009.06)</t>
	<t>and a user-land SCTP implementation (based on the FreeBSD implementation).</t
	>
	</list>
	</t>
	<section title='User Space versus Kernel Implementation'
	anchor='sec-sctp-1'>
	<t>Even though kernel implementations of SCTP are already available for most
	platforms (see <xref target='sec-p-a-2'/> ), there are compelling reasons for
	using an SCTP stack that works well in user land.</t>
	<t>The main reason is deployability.</t>
	<t>Web browsers supporting WebRTC are expected to run on a wide range of old
	and new operating systems. They support operating systems 10 years old or more,
	they run on mobile and desktop operating systems,
	and they are highly portable to new operating systems.
	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.
	This creates a need to implement as much functionality as possible
	inside the application instead of relying on the operating system.</t>
	<t>As a user-land implementation of SCTP is available, this meets
	requirement 12.</t>
	</section>
	<t>The layering of protocols for WebRTC is shown in the following
	<xref target='fig-sctp-layering'/>.</t>
	<figure title='WebRTC protocol layers'
	anchor='fig-sctp-layering'>
	<artwork align='center'>
	+------+------+------+		+------+------+------+
	| 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 indent="0" pn="section-5-10">This stack (especially in contrast to DTLS
	<t>This stack (especially in contrast to DTLS over SCTP <xref target='RFC6083'/>		over SCTP <xref target="RFC6083" format="default" sectionFormat="of" derivedCon
	in combination with SCTP over UDP <xref target='RFC6951'/>)		tent="RFC6083"/> and
	has been chosen because it		in combination with SCTP over UDP <xref target="RFC6951" format="default" sectio
	<list style='symbols'>		nFormat="of" derivedContent="RFC6951"/>)
	<t>supports the transmission of arbitrary large user messages.</t>		has been chosen for the following reasons:
	<t>shares the DTLS connection with the SRTP media channels of the PeerConnection		</t>
	.</t>		<ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5-1
	<t>provides privacy for the SCTP control information.</t>		1">
	</list></t>		<li pn="section-5-11.1">supports the transmission of arbitrarily large u
	<t>Considering the protocol stack of <xref target='fig-sctp-layering'/> the		ser messages;</li>
	usage of DTLS 1.0 over UDP is specified in <xref target='RFC4347'/> and		<li pn="section-5-11.2">shares the DTLS connection with the SRTP media c
	the usage of DTLS 1.2 over UDP in specified in <xref target='RFC6347'/>,		hannels of the
	while the usage of SCTP on top of DTLS is specified in		PeerConnection; and</li>
	<xref target='I-D.ietf-tsvwg-sctp-dtls-encaps'/>.		<li pn="section-5-11.3">provides privacy for the SCTP control informatio
	Please note that the demultiplexing STUN vs. SRTP vs. DTLS is done		n.</li>
	as described in Section 5.1.2 of <xref target='RFC5764'/> and SCTP		</ul>
			<t indent="0" pn="section-5-12">Referring to the protocol stack shown in <
			xref target="fig-sctp-layering" format="default" sectionFormat="of" derivedConte
			nt="Figure 2"/>:</t>
			<ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5-1
			3">
			<li pn="section-5-13.1">the usage of DTLS 1.0 over UDP is specified in <
			xref target="RFC4347" format="default" sectionFormat="of" derivedContent="RFC434
			7"/>;</li>
			<li pn="section-5-13.2">the usage of DTLS 1.2 over UDP in specified in <
			xref target="RFC6347" format="default" sectionFormat="of" derivedContent="RFC634
			7"/>;</li>
			<li pn="section-5-13.3">the usage of DTLS 1.3 over UDP is specified in a
			n upcoming document
			<xref target="I-D.ietf-tls-dtls13" format="default" sectionFormat="of" derivedCo
			ntent="TLS-DTLS13"/>; and</li>
			<li pn="section-5-13.4">the usage of SCTP on top of DTLS is specified in
			<xref target="RFC8261" format="default" sectionFormat="of" derivedContent="RFC82
			61"/>.</li>
			</ul>
			<t indent="0" pn="section-5-14">Please note that the demultiplexing Sessio
			n Traversal Utilities for NAT (STUN)
			<xref target="RFC5389" format="default" sectionFormat="of" derivedContent="RFC53
			89"/> vs. SRTP vs. DTLS is done
			as described in <xref target="RFC5764" sectionFormat="of" section="5.1.2" format
			="default" derivedLink="https://rfc-editor.org/rfc/rfc5764#section-5.1.2" derive
			dContent="RFC5764"/>, 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 indent="0" pn="section-5-15">Since DTLS is typically implemented in use r 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 indent="0" pn="section-5-16">The ICE/UDP layer can handle IP address ch anges during a session without
	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" sectionFormat="of" derivedContent="RFC49
	slow start threshold to its initial values.</t>		60"/>, this means setting the congestion window and
	<t>Incoming ICMP or ICMPv6 messages can't be processed by		slow-start threshold to its initial values.</t>
			<t indent="0" pn="section-5-17">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" sectionFormat="of" derivedContent="RFC4821"/>
	and 1280 for IPv6.</t>		by using probing messages specified in <xref target="RFC4820" format="default" s
	<t>In general, the lower layer interface of an SCTP implementation should be		ectionFormat="of" derivedContent="RFC4820"/>.
	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 indent="0" pn="section-5-18">In general, the lower-layer interface of a
			n SCTP implementation should be
			adapted to address the differences between IPv4 and IPv6 (being connectionless)
			or DTLS (being connection oriented).</t>
			<t indent="0" pn="section-5-19">When the protocol stack shown in <xref tar
			get="fig-sctp-layering" format="default" sectionFormat="of" derivedContent="Figu
			re 2"/> 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 indent="0" pn="section-5-20">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 indent="0" pn="section-5-21">SCTP uses the same port number concept as
	Therefore an SCTP association uses two port numbers, one at each SCTP		TCP and UDP.
	end-point.</t>		Therefore, an SCTP association uses two port numbers, one at each SCTP
	</section>		endpoint.</t>
			</section>
	<section title='The Usage of SCTP for Data Channels'		<section anchor="sec-sctp-usage" numbered="true" toc="include" removeInRFC="
	anchor='sec-sctp-usage'>		false" pn="section-6">
			<name slugifiedName="name-the-usage-of-sctp-for-data-">The Usage of SCTP f
	<section title='SCTP Protocol Considerations'>		or Data Channels</name>
	<t>The DTLS encapsulation of SCTP packets as described in		<section numbered="true" toc="include" removeInRFC="false" pn="section-6.1
	<xref target='I-D.ietf-tsvwg-sctp-dtls-encaps'/> MUST be used.</t>		">
	<t>This SCTP stack and its upper layer MUST support the usage of multiple		<name slugifiedName="name-sctp-protocol-consideration">SCTP Protocol Con
			siderations</name>
			<t indent="0" pn="section-6.1-1">The DTLS encapsulation of SCTP packets
			as described in
			<xref target="RFC8261" format="default" sectionFormat="of" derivedContent="RFC82
			61"/> <bcp14>MUST</bcp14> be used.</t>
			<t indent="0" pn="section-6.1-2">This SCTP stack and its upper layer <bc
			p14>MUST</bcp14> support the usage 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 indent="0" pn="section-6.1-3">The following SCTP protocol extensions
	<list style='symbols'>		are required:
	<t>The stream reconfiguration extension defined in <xref target='RFC6525'/>		</t>
	MUST be supported. It is used for closing channels.</t>		<ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6
	<t>The dynamic address reconfiguration extension defined in		.1-4">
	<xref target='RFC5061'/> MUST be used to signal the support of the		<li pn="section-6.1-4.1">The stream reconfiguration extension defined
	stream reset extension defined in <xref target='RFC6525'/>.		in <xref target="RFC6525" format="default" sectionFormat="of" derivedContent="RF
	Other features of <xref target='RFC5061'/> are OPTIONAL.</t>		C6525"/>
	<t>The partial reliability extension defined in <xref target='RFC3758'/> MUST		<bcp14>MUST</bcp14> be supported. It is used for closing channels.</
			li>
			<li pn="section-6.1-4.2">The dynamic address reconfiguration extension
			defined in
			<xref target="RFC5061" format="default" sectionFormat="of" derivedContent="RF
			C5061"/> <bcp14>MUST</bcp14> be used to signal the support of the
			stream reset extension defined in <xref target="RFC6525" format="default" sec
			tionFormat="of" derivedContent="RFC6525"/>.
			Other features of <xref target="RFC5061" format="default" sectionFormat="of"
			derivedContent="RFC5061"/> are <bcp14>OPTIONAL</bcp14>.</li>
			<li pn="section-6.1-4.3">The partial reliability extension defined in
			<xref target="RFC3758" format="default" sectionFormat="of" derivedContent="RFC37
			58"/> <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" sectionFormat="of" derivedContent=
	<xref target='I-D.ietf-tsvwg-sctp-prpolicies'/> MUST be supported.		"RFC3758"/>, the limited retransmission policy defined in
	Limiting the number of retransmissions to zero combined with unordered		<xref target="RFC7496" format="default" sectionFormat="of" derivedContent="RF
	delivery provides a UDP-like service where each user message is sent		C7496"/> <bcp14>MUST</bcp14> be supported.
	exactly once and delivered in the order received.</t>		Limiting the number of retransmissions to zero, combined with unordered
	</list></t>		delivery, provides a UDP-like service where each user message is sent
	<t>The support for message interleaving as defined in		exactly once and delivered in the order received.</li>
	<xref target='I-D.ietf-tsvwg-sctp-ndata'/> SHOULD be used.</t>		</ul>
	</section>		<t indent="0" pn="section-6.1-5">The support for message interleaving as
			defined in
	<section title='SCTP Association Management'		<xref target="RFC8260" format="default" sectionFormat="of" derivedContent="RFC82
	anchor='sec-sctp-management'>		60"/> <bcp14>SHOULD</bcp14> be used.</t>
	<t>In the WebRTC context, the SCTP association will be set up when the		</section>
			<section anchor="sec-sctp-management" numbered="true" toc="include" remove
			InRFC="false" pn="section-6.2">
			<name slugifiedName="name-sctp-association-management">SCTP Association
			Management</name>
			<t indent="0" pn="section-6.2-1">In the WebRTC context, the SCTP associa
			tion 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" sectionFormat="of" derivedContent="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		shared via BUNDLE or equivalent with DTLS connections used to key the
	SRTP media streams.</t>		SRTP media streams.</t>
	<!-- FIXME: Bundle Issue. -->		<t indent="0" pn="section-6.2-2">The number of streams negotiated during
	<t>The number of streams negotiated during SCTP association setup SHOULD		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 indent="0" pn="section-6.2-3">SCTP supports two ways of terminating a
	<t>SCTP supports two ways of terminating an SCTP association.		n SCTP association.
	A graceful one, using a procedure which ensures that no messages are lost		The first method is a graceful one, where a procedure that ensures no messages
	during the shutdown of the association.		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		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 indent="0" pn="section-6.2-4">Each SCTP endpoint continuously supervi ses the reachability of its peer 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 indent="0" pn="section-6.2-5">If an SCTP association is closed in a g raceful way, all of its data channels
	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="include" removeInRFC="false" pn="section-6.3
	<section title='SCTP Streams'>		">
	<t>SCTP defines a stream as a unidirectional logical channel existing within		<name slugifiedName="name-sctp-streams">SCTP Streams</name>
			<t indent="0" pn="section-6.3-1">SCTP defines a stream as a unidirection
			al logical channel existing within
	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="include" removeInRFC="false" pn="section-6.4
	<section title='Data Channel Definition'>		">
	<t>Data channels are defined such that their accompanying application-level API		<name slugifiedName="name-data-channel-definition">Data Channel Definiti
			on</name>
			<t indent="0" pn="section-6.4-1">Data channels are defined such that the
			ir accompanying application-level 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 indent="0" pn="section-6.4-2">The realization of a data channel is a pair of one incoming stream and
	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 indent="0" pn="section-6.4-3">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" bare="false" empty="false" indent="3" pn="section-6
			.4-4">
			<li pn="section-6.4-4.1">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 pn="section-6.4-4.2">in-order or out-of-order message delivery for
	Please note that in SCTP this is a property of an SCTP user message and not		message sent:
	of an SCTP stream.</t>		Note that, in SCTP, this is a property of an SCTP user message and not
	<t>A priority, which is a 2 byte unsigned integer.		of an SCTP stream.</li>
	These priorities MUST be interpreted as weighted-fair-queuing scheduling		<li pn="section-6.4-4.3">a priority, which is a 2-byte unsigned intege
			r:
			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" sectionFormat
	For use in WebRTC, the values used SHOULD be one of 128 ("below normal"),		="of" derivedContent="RFC8260"/>.
	256 ("normal"), 512 ("high") or 1024 ("extra high").</t>		For use in WebRTC, the values used <bcp14>SHOULD</bcp14> be one of 128 ("below n
	<t>an optional label.</t>		ormal"),
	<t>an optional protocol.</t>		256 ("normal"), 512 ("high"), or 1024 ("extra high").</li>
	</list></t>		<li pn="section-6.4-4.4">an optional label.</li>
	<t>Please note that for a data channel being negotiated with the protocol		<li pn="section-6.4-4.5">an optional protocol.</li>
	specified in <xref target='I-D.ietf-rtcweb-data-protocol'/> all of the above		</ul>
			<t indent="0" pn="section-6.4-5">Note that for a data channel being nego
			tiated with the protocol
			specified in <xref target="RFC8832" format="default" sectionFormat="of" derivedC
			ontent="RFC8832"/>, 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="include" removeInRFC="false" pn="section-6.5
	<section title='Opening a Data Channel'>		">
	<t>Data channels can be opened by using negotiation within the SCTP association,		<name slugifiedName="name-opening-a-data-channel">Opening a Data Channel
	called in-band negotiation, or out-of-band negotiation.		</name>
	Out-of-band negotiation is defined as any method which results in an agreement		<t indent="0" pn="section-6.5-1">Data channels can be opened by using ne
			gotiation 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.		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 indent="0" pn="section-6.5-2">A simple protocol for in-band negotiati
	<t>A simple protocol for in-band negotiation is specified in		on is specified in
	<xref target='I-D.ietf-rtcweb-data-protocol'/>.</t>		<xref target="RFC8832" format="default" sectionFormat="of" derivedContent="RFC88
	<t>When one side wants to open a channel using out-of-band negotiation, it		32"/>.</t>
			<t indent="0" pn="section-6.5-3">When one side wants to open a channel u
			sing out-of-band negotiation, 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="include" removeInRFC="false" pn="section-6.6
	<section title='Transferring User Data on a Data Channel'>		">
	<t>All data sent on a data channel in both directions MUST be sent over the		<name slugifiedName="name-transferring-user-data-on-a">Transferring User
			Data on a Data Channel</name>
			<t indent="0" pn="section-6.6-1">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 indent="0" pn="section-6.6-2">The message orientation of SCTP is used
	of user messages. Therefore, senders MUST NOT put more than one application		to preserve the message boundaries
			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 indent="0" pn="section-6.6-3">The SCTP Payload Protocol Identifiers (
	interpretation of the "Payload data". The following PPIDs MUST be used		PPIDs) are used to signal the
	(see <xref target='sec-IANA'/>):		interpretation of the "payload data". The following PPIDs <bcp14>MUST</bcp14> be
	<list style="hanging">		used
	<t hangText='WebRTC String:'>		(see <xref target="sec-IANA" format="default" sectionFormat="of" derivedContent=
	to identify a non-empty JavaScript string encoded in UTF-8.</t>		"Section 8"/>):
	<t hangText='WebRTC String Empty:'>		</t>
	to identify an empty JavaScript string encoded in UTF-8.</t>		<dl newline="false" spacing="normal" indent="3" pn="section-6.6-4">
	<t hangText='WebRTC Binary:'>		<dt pn="section-6.6-4.1">WebRTC String:</dt>
	to identify a non-empty JavaScript binary data		<dd pn="section-6.6-4.2">
	(ArrayBuffer, ArrayBufferView or Blob).</t>		to identify a non-empty JavaScript string encoded in UTF-8.</dd>
	<t hangText='WebRTC Binary Empty:'>		<dt pn="section-6.6-4.3">WebRTC String Empty:</dt>
	to identify an empty JavaScript binary data		<dd pn="section-6.6-4.4">
	(ArrayBuffer, ArrayBufferView or Blob).</t>		to identify an empty JavaScript string encoded in UTF-8.</dd>
	</list></t>		<dt pn="section-6.6-4.5">WebRTC Binary:</dt>
	<t>SCTP does not support the sending of empty user messages. Therefore, if an		<dd pn="section-6.6-4.6">
			to identify non-empty JavaScript binary data
			(ArrayBuffer, ArrayBufferView, or Blob).</dd>
			<dt pn="section-6.6-4.7">WebRTC Binary Empty:</dt>
			<dd pn="section-6.6-4.8">
			to identify empty JavaScript binary data
			(ArrayBuffer, ArrayBufferView, or Blob).</dd>
			</dl>
			<t indent="0" pn="section-6.6-5">SCTP does not support the sending of em
			pty 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 indent="0" pn="section-6.6-6">The usage of the PPIDs "WebRTC String P
			artial" and "WebRTC Binary Partial"
	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 indent="0" pn="section-6.6-7">If a message with an unsupported PPID i s received or some error condition
	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 indent="0" pn="section-6.6-8">The SCTP base protocol specified in <xr
	support the interleaving of user messages. Therefore sending a large user		ef target="RFC4960" format="default" sectionFormat="of" derivedContent="RFC4960"
			/> 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" sectionForm
	defines an extension to support message interleaving, which SHOULD be used.		at="of" derivedContent="RFC8260"/>
			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 indent="0" pn="section-6.6-9">It is recommended that the message size
	messages. This limit has to be negotiated, for example by using		be kept within certain size bounds,
	<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" sectionFormat="of" derivedContent="RFC88
			41"/>.</t>
			<t indent="0" pn="section-6.6-10">The sender <bcp14>SHOULD</bcp14> disab
			le the Nagle algorithm (see <xref target="RFC1122" format="default" sectionForma
			t="of" derivedContent="RFC1122"/>)
	to minimize the latency.</t>		to minimize the latency.</t>
	</section>		</section>
			<section numbered="true" toc="include" removeInRFC="false" pn="section-6.7
	<section title='Closing a Data Channel'>		">
	<t>Closing of a data channel MUST be signaled by resetting the corresponding		<name slugifiedName="name-closing-a-data-channel">Closing a Data Channel
	outgoing streams <xref target='RFC6525'/>. This means that if one side		</name>
			<t indent="0" pn="section-6.7-1">Closing of a data channel <bcp14>MUST</
			bcp14> be signaled by resetting the corresponding
			outgoing streams <xref target="RFC6525" format="default" sectionFormat="of" deri
			vedContent="RFC6525"/>. This means that if one 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 indent="0" pn="section-6.7-2"><xref target="RFC6525" format="default" sectionFormat="of" derivedContent="RFC6525"/> also guarantees that all the mess ages 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="include" removeInRFC="fa
	<section title='Security Considerations'		lse" pn="section-7">
	anchor='sec-security'>		<name slugifiedName="name-security-considerations">Security Considerations
	<t>This document does not add any additional considerations to the ones given in		</name>
	<xref target='I-D.ietf-rtcweb-security'/> and		<t indent="0" pn="section-7-1">This document does not add any additional c
	<xref target='I-D.ietf-rtcweb-security-arch'/>.</t>		onsiderations to the ones given in
	<t>It should be noted that a receiver must be prepared that the sender tries		<xref target="RFC8826" format="default" sectionFormat="of" derivedContent="RFC88
	to send arbitrary large messages.</t>		26"/> and
	</section>		<xref target="RFC8827" format="default" sectionFormat="of" derivedContent="RFC88
			27"/>.</t>
	<section title='IANA Considerations'		<t indent="0" pn="section-7-2">It should be noted that a receiver must be
	anchor='sec-IANA'>		prepared for a sender that tries
	<t>[NOTE to RFC-Editor:		to send arbitrarily large messages.</t>
	<list>		</section>
	<t>"RFCXXXX" is to be replaced by the RFC number you assign this document.</t>		<section anchor="sec-IANA" numbered="true" toc="include" removeInRFC="false"
	</list>		pn="section-8">
	]</t>		<name slugifiedName="name-iana-considerations">IANA Considerations</name>
	<t>This document uses six already registered SCTP Payload Protocol		<t indent="0" pn="section-8-1">This document uses six already registered S
			CTP 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" sectionFormat="of" derivedContent="RFC49 60"/> creates the "SCTP Payload Protocol Identifiers" 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 indent="0" pn="section-8-2">The six assignments have been updated to re
	<texttable>		ad:</t>
	<ttcol align='left'>Value</ttcol>		<table align="center" pn="table-1">
	<ttcol align='left'>SCTP PPID</ttcol>		<thead>
	<ttcol align='left'>Reference</ttcol>		<tr>
	<ttcol align='left'>Date</ttcol>		<th align="left" colspan="1" rowspan="1">Value</th>
	<c>WebRTC String</c> <c>51</c> <c>[RFCXXXX]</c> <c>2013-09-		<th align="left" colspan="1" rowspan="1">SCTP PPID</th>
	20</c>		<th align="left" colspan="1" rowspan="1">Reference</th>
	<c>WebRTC Binary Partial (Deprecated)</c> <c>52</c> <c>[RFCXXXX]</c> <c>2013-09-		<th align="left" colspan="1" rowspan="1">Date</th>
	20</c>		</tr>
	<c>WebRTC Binary</c> <c>53</c> <c>[RFCXXXX]</c> <c>2013-09-		</thead>
	20</c>		<tbody>
	<c>WebRTC String Partial (Deprecated)</c> <c>54</c> <c>[RFCXXXX]</c> <c>2013-09-		<tr>
	20</c>		<td align="left" colspan="1" rowspan="1">WebRTC String</td>
	<c>WebRTC String Empty</c> <c>56</c> <c>[RFCXXXX]</c> <c>2014-08-		<td align="left" colspan="1" rowspan="1">51</td>
	22</c>		<td align="left" colspan="1" rowspan="1">RFC 8831</td>
	<c>WebRTC Binary Empty</c> <c>57</c> <c>[RFCXXXX]</c> <c>2014-08-		<td align="left" colspan="1" rowspan="1">2013-09-20</td>
	22</c>		</tr>
	</texttable>		<tr>
	</section>		<td align="left" colspan="1" rowspan="1">WebRTC Binary Partial (depr
			ecated)</td>
	<section title='Acknowledgments'>		<td align="left" colspan="1" rowspan="1">52</td>
	<t>Many thanks for comments, ideas, and text from		<td align="left" colspan="1" rowspan="1">RFC 8831</td>
	Harald Alvestrand,		<td align="left" colspan="1" rowspan="1">2013-09-20</td>
	Richard Barnes,		</tr>
	Adam Bergkvist,		<tr>
	Alissa Cooper,		<td align="left" colspan="1" rowspan="1">WebRTC Binary</td>
	Benoit Claise,		<td align="left" colspan="1" rowspan="1">53</td>
	Spencer Dawkins,		<td align="left" colspan="1" rowspan="1">RFC 8831</td>
	Gunnar Hellstrom,		<td align="left" colspan="1" rowspan="1">2013-09-20</td>
	Christer Holmberg,		</tr>
	Cullen Jennings,		<tr>
	Paul Kyzivat,		<td align="left" colspan="1" rowspan="1">WebRTC String Partial (depr
	Eric Rescorla,		ecated)</td>
	Adam Roach,		<td align="left" colspan="1" rowspan="1">54</td>
	Irene Ruengeler,		<td align="left" colspan="1" rowspan="1">RFC 8831</td>
	Randall Stewart,		<td align="left" colspan="1" rowspan="1">2013-09-20</td>
	Martin Stiemerling,		</tr>
	Justin Uberti,		<tr>
	and Magnus Westerlund.</t>		<td align="left" colspan="1" rowspan="1">WebRTC String Empty</td>
	</section>		<td align="left" colspan="1" rowspan="1">56</td>
	</middle>		<td align="left" colspan="1" rowspan="1">RFC 8831</td>
			<td align="left" colspan="1" rowspan="1">2014-08-22</td>
			</tr>
			<tr>
			<td align="left" colspan="1" rowspan="1">WebRTC Binary Empty</td>
			<td align="left" colspan="1" rowspan="1">57</td>
			<td align="left" colspan="1" rowspan="1">RFC 8831</td>
			<td align="left" colspan="1" rowspan="1">2014-08-22</td>
			</tr>
			</tbody>
			</table>
			</section>
			</middle>
			<back>
			<displayreference target="I-D.ietf-tls-dtls13" to="TLS-DTLS13"/>
			<references pn="section-9">
			<name slugifiedName="name-references">References</name>
			<references pn="section-9.1">
			<name slugifiedName="name-normative-references">Normative References</na
			me>
			<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2
			119" quoteTitle="true" derivedAnchor="RFC2119">
			<front>
			<title>Key words for use in RFCs to Indicate Requirement Levels</tit
			le>
			<author initials="S." surname="Bradner" fullname="S. Bradner">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="1997" month="March"/>
			<abstract>
			<t indent="0">In many standards track documents several words are
			used to signify the requirements in the specification. These words are often ca
			pitalized. This document defines these words as they should be interpreted in IE
			TF documents. This document specifies an Internet Best Current Practices for th
			e Internet Community, and requests discussion and suggestions for improvements.<
			/t>
			</abstract>
			</front>
			<seriesInfo name="BCP" value="14"/>
			<seriesInfo name="RFC" value="2119"/>
			<seriesInfo name="DOI" value="10.17487/RFC2119"/>
			</reference>
			<reference anchor="RFC3758" target="https://www.rfc-editor.org/info/rfc3
			758" quoteTitle="true" derivedAnchor="RFC3758">
			<front>
			<title>Stream Control Transmission Protocol (SCTP) Partial Reliabili
			ty Extension</title>
			<author initials="R." surname="Stewart" fullname="R. Stewart">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="M." surname="Ramalho" fullname="M. Ramalho">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="Q." surname="Xie" fullname="Q. Xie">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="M." surname="Tuexen" fullname="M. Tuexen">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="P." surname="Conrad" fullname="P. Conrad">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2004" month="May"/>
			<abstract>
			<t indent="0">This memo describes an extension to the Stream Contr
			ol Transmission Protocol (SCTP) that allows an SCTP endpoint to signal to its pe
			er that it should move the cumulative ack point forward. When both sides of an
			SCTP association support this extension, it can be used by an SCTP implementatio
			n to provide partially reliable data transmission service to an upper layer prot
			ocol. This memo describes the protocol extensions, which consist of a new param
			eter for INIT and INIT ACK, and a new FORWARD TSN chunk type, and provides one e
			xample of a partially reliable service that can be provided to the upper layer v
			ia this mechanism. [STANDARDS-TRACK]</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="3758"/>
			<seriesInfo name="DOI" value="10.17487/RFC3758"/>
			</reference>
			<reference anchor="RFC4820" target="https://www.rfc-editor.org/info/rfc4
			820" quoteTitle="true" derivedAnchor="RFC4820">
			<front>
			<title>Padding Chunk and Parameter for the Stream Control Transmissi
			on Protocol (SCTP)</title>
			<author initials="M." surname="Tuexen" fullname="M. Tuexen">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="R." surname="Stewart" fullname="R. Stewart">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="P." surname="Lei" fullname="P. Lei">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2007" month="March"/>
			<abstract>
			<t indent="0">This document defines a padding chunk and a padding
			parameter and describes the required receiver side procedures. The padding chun
			k is used to pad a Stream Control Transmission Protocol (SCTP) packet to an arbi
			trary size. The padding parameter is used to pad an SCTP INIT chunk to an arbit
			rary size. [STANDARDS-TRACK]</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="4820"/>
			<seriesInfo name="DOI" value="10.17487/RFC4820"/>
			</reference>
			<reference anchor="RFC4821" target="https://www.rfc-editor.org/info/rfc4
			821" quoteTitle="true" derivedAnchor="RFC4821">
			<front>
			<title>Packetization Layer Path MTU Discovery</title>
			<author initials="M." surname="Mathis" fullname="M. Mathis">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="J." surname="Heffner" fullname="J. Heffner">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2007" month="March"/>
			<abstract>
			<t indent="0">This document describes a robust method for Path MTU
			Discovery (PMTUD) that relies on TCP or some other Packetization Layer to probe
			an Internet path with progressively larger packets. This method is described a
			s an extension to RFC 1191 and RFC 1981, which specify ICMP-based Path MTU Disco
			very for IP versions 4 and 6, respectively. [STANDARDS-TRACK]</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="4821"/>
			<seriesInfo name="DOI" value="10.17487/RFC4821"/>
			</reference>
			<reference anchor="RFC4960" target="https://www.rfc-editor.org/info/rfc4
			960" quoteTitle="true" derivedAnchor="RFC4960">
			<front>
			<title>Stream Control Transmission Protocol</title>
			<author initials="R." surname="Stewart" fullname="R. Stewart" role="
			editor">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2007" month="September"/>
			<abstract>
			<t indent="0">This document obsoletes RFC 2960 and RFC 3309. It d
			escribes the Stream Control Transmission Protocol (SCTP). SCTP is designed to t
			ransport Public Switched Telephone Network (PSTN) signaling messages over IP net
			works, but is capable of broader applications.</t>
			<t indent="0">SCTP is a reliable transport protocol operating on t
			op of a connectionless packet network such as IP. It offers the following servi
			ces to its users:</t>
			<t indent="0">-- acknowledged error-free non-duplicated transfer
			of user data,</t>
			<t indent="0">-- data fragmentation to conform to discovered path
			MTU size,</t>
			<t indent="0">-- sequenced delivery of user messages within multi
			ple streams, with an option for order-of-arrival delivery of individual user mes
			sages,</t>
			<t indent="0">-- optional bundling of multiple user messages into
			a single SCTP packet, and</t>
			<t indent="0">-- network-level fault tolerance through supporting
			of multi-homing at either or both ends of an association.</t>
			<t indent="0"> The design of SCTP includes appropriate congestion
			avoidance behavior and resistance to flooding and masquerade attacks. [STANDARD
			S-TRACK]</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="4960"/>
			<seriesInfo name="DOI" value="10.17487/RFC4960"/>
			</reference>
			<reference anchor="RFC5061" target="https://www.rfc-editor.org/info/rfc5
			061" quoteTitle="true" derivedAnchor="RFC5061">
			<front>
			<title>Stream Control Transmission Protocol (SCTP) Dynamic Address R
			econfiguration</title>
			<author initials="R." surname="Stewart" fullname="R. Stewart">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="Q." surname="Xie" fullname="Q. Xie">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="M." surname="Tuexen" fullname="M. Tuexen">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="S." surname="Maruyama" fullname="S. Maruyama">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="M." surname="Kozuka" fullname="M. Kozuka">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2007" month="September"/>
			<abstract>
			<t indent="0">A local host may have multiple points of attachment
			to the Internet, giving it a degree of fault tolerance from hardware failures.
			Stream Control Transmission Protocol (SCTP) (RFC 4960) was developed to take ful
			l advantage of such a multi-homed host to provide a fast failover and associatio
			n survivability in the face of such hardware failures. This document describes a
			n extension to SCTP that will allow an SCTP stack to dynamically add an IP addre
			ss to an SCTP association, dynamically delete an IP address from an SCTP associa
			tion, and to request to set the primary address the peer will use when sending t
			o an endpoint. [STANDARDS-TRACK]</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="5061"/>
			<seriesInfo name="DOI" value="10.17487/RFC5061"/>
			</reference>
			<reference anchor="RFC6525" target="https://www.rfc-editor.org/info/rfc6
			525" quoteTitle="true" derivedAnchor="RFC6525">
			<front>
			<title>Stream Control Transmission Protocol (SCTP) Stream Reconfigur
			ation</title>
			<author initials="R." surname="Stewart" fullname="R. Stewart">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="M." surname="Tuexen" fullname="M. Tuexen">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="P." surname="Lei" fullname="P. Lei">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2012" month="February"/>
			<abstract>
			<t indent="0">Many applications that use the Stream Control Transm
			ission Protocol (SCTP) want the ability to "reset" a stream. The intention of r
			esetting a stream is to set the numbering sequence of the stream back to 'zero'
			with a corresponding notification to the application layer that the reset has be
			en performed. Applications requiring this feature want it so that they can "reu
			se" streams for different purposes but still utilize the stream sequence number
			so that the application can track the message flows. Thus, without this feature
			, a new use of an old stream would result in message numbers greater than expect
			ed, unless there is a protocol mechanism to "reset the streams back to zero". T
			his document also includes methods for resetting the transmission sequence numbe
			rs, adding additional streams, and resetting all stream sequence numbers. [STAN
			DARDS-TRACK]</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="6525"/>
			<seriesInfo name="DOI" value="10.17487/RFC6525"/>
			</reference>
			<reference anchor="RFC7496" target="https://www.rfc-editor.org/info/rfc7
			496" quoteTitle="true" derivedAnchor="RFC7496">
			<front>
			<title>Additional Policies for the Partially Reliable Stream Control
			Transmission Protocol Extension</title>
			<author initials="M." surname="Tuexen" fullname="M. Tuexen">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="R." surname="Seggelmann" fullname="R. Seggelmann">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="R." surname="Stewart" fullname="R. Stewart">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="S." surname="Loreto" fullname="S. Loreto">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2015" month="April"/>
			<abstract>
			<t indent="0">This document defines two additional policies for th
			e Partially Reliable Stream Control Transmission Protocol (PR-SCTP) extension. T
			hese policies allow limitation of the number of retransmissions and prioritizati
			on of user messages for more efficient usage of the send buffer.</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="7496"/>
			<seriesInfo name="DOI" value="10.17487/RFC7496"/>
			</reference>
			<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8
			174" quoteTitle="true" derivedAnchor="RFC8174">
			<front>
			<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
			tle>
			<author initials="B." surname="Leiba" fullname="B. Leiba">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2017" month="May"/>
			<abstract>
			<t indent="0">RFC 2119 specifies common key words that may be used
			in protocol specifications. This document aims to reduce the ambiguity by cla
			rifying that only UPPERCASE usage of the key words have the defined special mea
			nings.</t>
			</abstract>
			</front>
			<seriesInfo name="BCP" value="14"/>
			<seriesInfo name="RFC" value="8174"/>
			<seriesInfo name="DOI" value="10.17487/RFC8174"/>
			</reference>
			<reference anchor="RFC8260" target="https://www.rfc-editor.org/info/rfc8
			260" quoteTitle="true" derivedAnchor="RFC8260">
			<front>
			<title>Stream Schedulers and User Message Interleaving for the Strea
			m Control Transmission Protocol</title>
			<author initials="R." surname="Stewart" fullname="R. Stewart">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="M." surname="Tuexen" fullname="M. Tuexen">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="S." surname="Loreto" fullname="S. Loreto">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="R." surname="Seggelmann" fullname="R. Seggelmann">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2017" month="November"/>
			<abstract>
			<t indent="0">The Stream Control Transmission Protocol (SCTP) is a
			message-oriented transport protocol supporting arbitrarily large user messages.
			This document adds a new chunk to SCTP for carrying payload data. This allows
			a sender to interleave different user messages that would otherwise result in h
			ead-of-line blocking at the sender. The interleaving of user messages is requir
			ed for WebRTC data channels.</t>
			<t indent="0">Whenever an SCTP sender is allowed to send user data
			, it may choose from multiple outgoing SCTP streams. Multiple ways for performi
			ng this selection, called stream schedulers, are defined in this document. A st
			ream scheduler can choose to either implement, or not implement, user message in
			terleaving.</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="8260"/>
			<seriesInfo name="DOI" value="10.17487/RFC8260"/>
			</reference>
			<reference anchor="RFC8261" target="https://www.rfc-editor.org/info/rfc8
			261" quoteTitle="true" derivedAnchor="RFC8261">
			<front>
			<title>Datagram Transport Layer Security (DTLS) Encapsulation of SCT
			P Packets</title>
			<author initials="M." surname="Tuexen" fullname="M. Tuexen">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="R." surname="Stewart" fullname="R. Stewart">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="R." surname="Jesup" fullname="R. Jesup">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="S." surname="Loreto" fullname="S. Loreto">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2017" month="November"/>
			<abstract>
			<t indent="0">The Stream Control Transmission Protocol (SCTP) is a
			transport protocol originally defined to run on top of the network protocols IP
			v4 or IPv6. This document specifies how SCTP can be used on top of the Datagram
			Transport Layer Security (DTLS) protocol. Using the encapsulation method descr
			ibed in this document, SCTP is unaware of the protocols being used below DTLS; h
			ence, explicit IP addresses cannot be used in the SCTP control chunks. As a con
			sequence, the SCTP associations carried over DTLS can only be single-homed.</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="8261"/>
			<seriesInfo name="DOI" value="10.17487/RFC8261"/>
			</reference>
			<reference anchor="RFC8445" target="https://www.rfc-editor.org/info/rfc8
			445" quoteTitle="true" derivedAnchor="RFC8445">
			<front>
			<title>Interactive Connectivity Establishment (ICE): A Protocol for
			Network Address Translator (NAT) Traversal</title>
			<author initials="A." surname="Keranen" fullname="A. Keranen">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="C." surname="Holmberg" fullname="C. Holmberg">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="J." surname="Rosenberg" fullname="J. Rosenberg">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2018" month="July"/>
			<abstract>
			<t indent="0">This document describes a protocol for Network Addre
			ss Translator (NAT) traversal for UDP-based communication. This protocol is cal
			led Interactive Connectivity Establishment (ICE). ICE makes use of the Session
			Traversal Utilities for NAT (STUN) protocol and its extension, Traversal Using R
			elay NAT (TURN).</t>
			<t indent="0">This document obsoletes RFC 5245.</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="8445"/>
			<seriesInfo name="DOI" value="10.17487/RFC8445"/>
			</reference>
			<reference anchor="RFC8826" target="https://www.rfc-editor.org/info/rfc8
			826" quoteTitle="true" derivedAnchor="RFC8826">
			<front>
			<title>Security Considerations for WebRTC</title>
			<author initials="E." surname="Rescorla" fullname="Eric Rescorla">
			<organization showOnFrontPage="true"/>
			</author>
			<date month="January" year="2021"/>
			</front>
			<seriesInfo name="RFC" value="8826"/>
			<seriesInfo name="DOI" value="10.17487/RFC8826"/>
			</reference>
			<reference anchor="RFC8827" target="https://www.rfc-editor.org/info/rfc8
			827" quoteTitle="true" derivedAnchor="RFC8827">
			<front>
			<title>WebRTC Security Architecture</title>
			<author initials="E." surname="Rescorla" fullname="Eric Rescorla">
			<organization showOnFrontPage="true"/>
			</author>
			<date month="January" year="2021"/>
			</front>
			<seriesInfo name="RFC" value="8827"/>
			<seriesInfo name="DOI" value="10.17487/RFC8827"/>
			</reference>
			<reference anchor="RFC8829" target="https://www.rfc-editor.org/info/rfc8
			829" quoteTitle="true" derivedAnchor="RFC8829">
			<front>
			<title>JavaScript Session Establishment Protocol (JSEP)</title>
			<author initials="J." surname="Uberti" fullname="Justin Uberti">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="C." surname="Jennings" fullname="Cullen Jennings">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="E." surname="Rescorla" fullname="Eric Rescorla" ro
			le="editor">
			<organization showOnFrontPage="true"/>
			</author>
			<date month="January" year="2021"/>
			</front>
			<seriesInfo name="RFC" value="8829"/>
			<seriesInfo name="DOI" value="10.17487/RFC8829"/>
			</reference>
			<reference anchor="RFC8832" target="https://www.rfc-editor.org/info/rfc8
			832" quoteTitle="true" derivedAnchor="RFC8832">
			<front>
			<title>WebRTC Data Channel Establishment Protocol</title>
			<author initials="R." surname="Jesup" fullname="Randell Jesup">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="S." surname="Loreto" fullname="Salvatore Loreto">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="M" surname="Tüxen" fullname="Michael Tüxen">
			<organization showOnFrontPage="true"/>
			</author>
			<date month="January" year="2021"/>
			</front>
			<seriesInfo name="RFC" value="8832"/>
			<seriesInfo name="DOI" value="10.17487/RFC8832"/>
			</reference>
			<reference anchor="RFC8841" target="https://www.rfc-editor.org/info/rfc8
			841" quoteTitle="true" derivedAnchor="RFC8841">
			<front>
			<title>Session Description Protocol (SDP) Offer/Answer Procedures fo
			r Stream Control Transmission Protocol (SCTP) over Datagram Transport Layer Secu
			rity (DTLS) Transport</title>
			<author initials="C." surname="Holmberg" fullname="Christer Holmberg
			">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="R." surname="Shpount" fullname="Roman Shpount">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="S." surname="Loreto" fullname="Salvatore Loreto">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="G." surname="Camarillo" fullname="Gonzalo Camarill
			o">
			<organization showOnFrontPage="true"/>
			</author>
			<date month="January" year="2021"/>
			</front>
			<seriesInfo name="RFC" value="8841"/>
			<seriesInfo name="DOI" value="10.17487/RFC8841"/>
			</reference>
			</references>
			<references pn="section-9.2">
			<name slugifiedName="name-informative-references">Informative References
			</name>
			<reference anchor="RFC1122" target="https://www.rfc-editor.org/info/rfc1
			122" quoteTitle="true" derivedAnchor="RFC1122">
			<front>
			<title>Requirements for Internet Hosts - Communication Layers</title
			>
			<author initials="R." surname="Braden" fullname="R. Braden" role="ed
			itor">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="1989" month="October"/>
			<abstract>
			<t indent="0">This RFC is an official specification for the Intern
			et community. It incorporates by reference, amends, corrects, and supplements t
			he primary protocol standards documents relating to hosts. [STANDARDS-TRACK]</t
			>
			</abstract>
			</front>
			<seriesInfo name="STD" value="3"/>
			<seriesInfo name="RFC" value="1122"/>
			<seriesInfo name="DOI" value="10.17487/RFC1122"/>
			</reference>
			<reference anchor="RFC4347" target="https://www.rfc-editor.org/info/rfc4
			347" quoteTitle="true" derivedAnchor="RFC4347">
			<front>
			<title>Datagram Transport Layer Security</title>
			<author initials="E." surname="Rescorla" fullname="E. Rescorla">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="N." surname="Modadugu" fullname="N. Modadugu">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2006" month="April"/>
			<abstract>
			<t indent="0">This document specifies Version 1.0 of the Datagram
			Transport Layer Security (DTLS) protocol. The DTLS protocol provides communicat
			ions privacy for datagram protocols. The protocol allows client/server applicat
			ions to communicate in a way that is designed to prevent eavesdropping, tamperin
			g, or message forgery. The DTLS protocol is based on the Transport Layer Securi
			ty (TLS) protocol and provides equivalent security guarantees. Datagram semanti
			cs of the underlying transport are preserved by the DTLS protocol. [STANDARDS-T
			RACK]</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="4347"/>
			<seriesInfo name="DOI" value="10.17487/RFC4347"/>
			</reference>
			<reference anchor="RFC5389" target="https://www.rfc-editor.org/info/rfc5
			389" quoteTitle="true" derivedAnchor="RFC5389">
			<front>
			<title>Session Traversal Utilities for NAT (STUN)</title>
			<author initials="J." surname="Rosenberg" fullname="J. Rosenberg">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="R." surname="Mahy" fullname="R. Mahy">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="P." surname="Matthews" fullname="P. Matthews">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="D." surname="Wing" fullname="D. Wing">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2008" month="October"/>
			<abstract>
			<t indent="0">Session Traversal Utilities for NAT (STUN) is a prot
			ocol that serves as a tool for other protocols in dealing with Network Address T
			ranslator (NAT) traversal. It can be used by an endpoint to determine the IP ad
			dress and port allocated to it by a NAT. It can also be used to check connectiv
			ity between two endpoints, and as a keep-alive protocol to maintain NAT bindings
			. STUN works with many existing NATs, and does not require any special behavior
			from them.</t>
			<t indent="0">STUN is not a NAT traversal solution by itself. Rat
			her, it is a tool to be used in the context of a NAT traversal solution. This i
			s an important change from the previous version of this specification (RFC 3489)
			, which presented STUN as a complete solution.</t>
			<t indent="0">This document obsoletes RFC 3489. [STANDARDS-TRACK]
			</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="5389"/>
			<seriesInfo name="DOI" value="10.17487/RFC5389"/>
			</reference>
			<reference anchor="RFC5764" target="https://www.rfc-editor.org/info/rfc5
			764" quoteTitle="true" derivedAnchor="RFC5764">
			<front>
			<title>Datagram Transport Layer Security (DTLS) Extension to Establi
			sh Keys for the Secure Real-time Transport Protocol (SRTP)</title>
			<author initials="D." surname="McGrew" fullname="D. McGrew">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="E." surname="Rescorla" fullname="E. Rescorla">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2010" month="May"/>
			<abstract>
			<t indent="0">This document describes a Datagram Transport Layer S
			ecurity (DTLS) extension to establish keys for Secure RTP (SRTP) and Secure RTP
			Control Protocol (SRTCP) flows. DTLS keying happens on the media path, independ
			ent of any out-of-band signalling channel present. [STANDARDS-TRACK]</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="5764"/>
			<seriesInfo name="DOI" value="10.17487/RFC5764"/>
			</reference>
			<reference anchor="RFC6083" target="https://www.rfc-editor.org/info/rfc6
			083" quoteTitle="true" derivedAnchor="RFC6083">
			<front>
			<title>Datagram Transport Layer Security (DTLS) for Stream Control T
			ransmission Protocol (SCTP)</title>
			<author initials="M." surname="Tuexen" fullname="M. Tuexen">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="R." surname="Seggelmann" fullname="R. Seggelmann">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="E." surname="Rescorla" fullname="E. Rescorla">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2011" month="January"/>
			<abstract>
			<t indent="0">This document describes the usage of the Datagram Tr
			ansport Layer Security (DTLS) protocol over the Stream Control Transmission Prot
			ocol (SCTP).</t>
			<t indent="0">DTLS over SCTP provides communications privacy for a
			pplications that use SCTP as their transport protocol and allows client/server a
			pplications to communicate in a way that is designed to prevent eavesdropping an
			d detect tampering or message forgery.</t>
			<t indent="0">Applications using DTLS over SCTP can use almost all
			transport features provided by SCTP and its extensions. [STANDARDS-TRACK]</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="6083"/>
			<seriesInfo name="DOI" value="10.17487/RFC6083"/>
			</reference>
			<reference anchor="RFC6347" target="https://www.rfc-editor.org/info/rfc6
			347" quoteTitle="true" derivedAnchor="RFC6347">
			<front>
			<title>Datagram Transport Layer Security Version 1.2</title>
			<author initials="E." surname="Rescorla" fullname="E. Rescorla">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="N." surname="Modadugu" fullname="N. Modadugu">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2012" month="January"/>
			<abstract>
			<t indent="0">This document specifies version 1.2 of the Datagram
			Transport Layer Security (DTLS) protocol. The DTLS protocol provides communicat
			ions privacy for datagram protocols. The protocol allows client/server applicat
			ions to communicate in a way that is designed to prevent eavesdropping, tamperin
			g, or message forgery. The DTLS protocol is based on the Transport Layer Securi
			ty (TLS) protocol and provides equivalent security guarantees. Datagram semanti
			cs of the underlying transport are preserved by the DTLS protocol. This documen
			t updates DTLS 1.0 to work with TLS version 1.2. [STANDARDS-TRACK]</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="6347"/>
			<seriesInfo name="DOI" value="10.17487/RFC6347"/>
			</reference>
			<reference anchor="RFC6951" target="https://www.rfc-editor.org/info/rfc6
			951" quoteTitle="true" derivedAnchor="RFC6951">
			<front>
			<title>UDP Encapsulation of Stream Control Transmission Protocol (SC
			TP) Packets for End-Host to End-Host Communication</title>
			<author initials="M." surname="Tuexen" fullname="M. Tuexen">
			<organization showOnFrontPage="true"/>
			</author>
			<author initials="R." surname="Stewart" fullname="R. Stewart">
			<organization showOnFrontPage="true"/>
			</author>
			<date year="2013" month="May"/>
			<abstract>
			<t indent="0">This document describes a simple method of encapsula
			ting Stream Control Transmission Protocol (SCTP) packets into UDP packets and it
			s limitations. This allows the usage of SCTP in networks with legacy NATs that
			do not support SCTP. It can also be used to implement SCTP on hosts without dir
			ectly accessing the IP layer, for example, implementing it as part of the applic
			ation without requiring special privileges.</t>
			<t indent="0">Please note that this document only describes the fu
			nctionality required within an SCTP stack to add on UDP encapsulation, providing
			only those mechanisms for two end-hosts to communicate with each other over UDP
			ports. In particular, it does not provide mechanisms to determine whether UDP
			encapsulation is being used by the peer, nor the mechanisms for determining whic
			h remote UDP port number can be used. These functions are out of scope for this
			document.</t>
			<t indent="0">This document covers only end-hosts and not tunnelin
			g (egress or ingress) endpoints.</t>
			</abstract>
			</front>
			<seriesInfo name="RFC" value="6951"/>
			<seriesInfo name="DOI" value="10.17487/RFC6951"/>
			</reference>
			<reference anchor="I-D.ietf-tls-dtls13" quoteTitle="true" target="https:
			//tools.ietf.org/html/draft-ietf-tls-dtls13-39" derivedAnchor="TLS-DTLS13">
			<front>
			<title>The Datagram Transport Layer Security (DTLS) Protocol Version
			1.3</title>
			<author initials="E." surname="Rescorla" fullname="Eric Rescorla">
			<organization showOnFrontPage="true">RTFM, Inc.</organization>
			</author>
			<author initials="H." surname="Tschofenig" fullname="Hannes Tschofen
			ig">
			<organization showOnFrontPage="true">Arm Limited</organization>
			</author>
			<author initials="N." surname="Modadugu" fullname="Nagendra Modadugu
			">
			<organization showOnFrontPage="true">Google, Inc.</organization>
			</author>
			<date month="November" day="2" year="2020"/>
			<abstract>
			<t indent="0"> This document specifies Version 1.3 of the Datagr
			am Transport Layer
			Security (DTLS) protocol. DTLS 1.3 allows client/server applications
			to communicate over the Internet in a way that is designed to prevent
			eavesdropping, tampering, and message forgery.
	<back>		The DTLS 1.3 protocol is intentionally based on the Transport Layer
	<references title='Normative References'>		Security (TLS) 1.3 protocol and provides equivalent security
	<?rfc include='reference.RFC.2119' ?>		guarantees with the exception of order protection/non-replayability.
	<?rfc include='reference.RFC.3758'?>		Datagram semantics of the underlying transport are preserved by the
	<?rfc include='reference.RFC.4347'?>		DTLS protocol.
	<?rfc include='reference.RFC.4820'?>
	<?rfc include='reference.RFC.4821'?>
	<?rfc include='reference.RFC.4960'?>
	<?rfc include='reference.RFC.5061'?>
	<?rfc include='reference.RFC.5245'?>
	<?rfc include='reference.RFC.6347'?>
	<?rfc include='reference.RFC.6525'?>
	<?rfc include='reference.I-D.ietf-tsvwg-sctp-ndata'?>
	<?rfc include='reference.I-D.ietf-rtcweb-data-protocol'?>
	<?rfc include='reference.I-D.ietf-tsvwg-sctp-dtls-encaps'?>
	<?rfc include='reference.I-D.ietf-rtcweb-security'?>
	<?rfc include='reference.I-D.ietf-rtcweb-security-arch'?>
	<?rfc include='reference.I-D.ietf-rtcweb-jsep'?>
	<?rfc include='reference.I-D.ietf-tsvwg-sctp-prpolicies'?>
	<?rfc include='reference.I-D.ietf-mmusic-sctp-sdp'?>
	</references>
	<references title='Informative References'>
	<?rfc include='reference.RFC.1122'?>
	<?rfc include='reference.RFC.5764'?>
	<?rfc include='reference.RFC.6083'?>
	<?rfc include='reference.RFC.6951'?>
	</references>
	</back>
			</t>
			</abstract>
			</front>
			<seriesInfo name="Internet-Draft" value="draft-ietf-tls-dtls13-39"/>
			<format type="TXT" target="https://www.ietf.org/internet-drafts/draft-
			ietf-tls-dtls13-39.txt"/>
			<refcontent>Work in Progress</refcontent>
			</reference>
			</references>
			</references>
			<section numbered="false" toc="include" removeInRFC="false" pn="section-appe
			ndix.a">
			<name slugifiedName="name-acknowledgements">Acknowledgements</name>
			<t indent="0" pn="section-appendix.a-1">Many thanks for comments, ideas, a
			nd 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 Dawk
			ins"/>, <contact fullname="Gunnar Hellström"/>, <contact fullname="Christer Holm
			berg"/>, <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 Sti
			emerling"/>, <contact fullname="Justin Uberti"/>, and <contact fullname="Magnus
			Westerlund"/>.</t>
			</section>
			<section anchor="authors-addresses" numbered="false" removeInRFC="false" toc
			="include" pn="section-appendix.b">
			<name slugifiedName="name-authors-addresses">Authors' Addresses</name>
			<author initials="R." surname="Jesup" fullname="Randell Jesup">
			<organization showOnFrontPage="true">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 showOnFrontPage="true">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" showOnFrontPage="
			true">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>
			</section>
			</back>
	</rfc>		</rfc>
End of changes. 69 change blocks.
	533 lines changed or deleted		1595 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/