draft-ietf-rtcweb-data-protocol-09.txt		rfc8832.txt
	Network Working Group R. Jesup		Internet Engineering Task Force (IETF) R. Jesup
	Internet-Draft Mozilla		Request for Comments: 8832 Mozilla
	Intended status: Standards Track S. Loreto		Category: Standards Track S. Loreto
	Expires: July 8, 2015 Ericsson		ISSN: 2070-1721 Ericsson
	M. Tuexen		M. Tüxen
	Muenster Univ. of Appl. Sciences		Münster Univ. of Appl. Sciences
	January 4, 2015		January 2021
	WebRTC Data Channel Establishment Protocol		WebRTC Data Channel Establishment Protocol
	draft-ietf-rtcweb-data-protocol-09.txt
	Abstract		Abstract
	The WebRTC framework specifies protocol support for direct		The WebRTC framework specifies protocol support for direct
	interactive rich communication using audio, video, and data between		interactive rich communication using audio, video, and data between
	two peers' web-browsers. This document specifies a simple protocol		two peers' web browsers. This document specifies a simple protocol
	for establishing symmetric Data Channels between the peers. It uses		for establishing symmetric data channels between the peers. It uses
	a two way handshake and allows sending of user data without waiting		a two-way handshake and allows sending of user data without waiting
	for the handshake to complete.		for the handshake to complete.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This is an Internet Standards Track document.
	provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		This document is a product of the Internet Engineering Task Force
	and may be updated, replaced, or obsoleted by other documents at any		(IETF). It represents the consensus of the IETF community. It has
	time. It is inappropriate to use Internet-Drafts as reference		received public review and has been approved for publication by the
	material or to cite them other than as "work in progress."		Internet Engineering Steering Group (IESG). Further information on
			Internet Standards is available in Section 2 of RFC 7841.
	This Internet-Draft will expire on July 8, 2015.		Information about the current status of this document, any errata,
			and how to provide feedback on it may be obtained at
			https://www.rfc-editor.org/info/rfc8832.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 IETF Trust and the persons identified as the		Copyright (c) 2021 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction
	2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 2		2. Conventions
	3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		3. Terminology
	4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3		4. Protocol Overview
	5. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 4		5. Message Formats
	5.1. DATA_CHANNEL_OPEN Message . . . . . . . . . . . . . . . . 4		5.1. DATA_CHANNEL_OPEN Message
	5.2. DATA_CHANNEL_ACK Message . . . . . . . . . . . . . . . . 7		5.2. DATA_CHANNEL_ACK Message
	6. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 7		6. Procedures
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 8		7. Security Considerations
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9		8. IANA Considerations
	8.1. SCTP Payload Protocol Identifier . . . . . . . . . . . . 9		8.1. SCTP Payload Protocol Identifier
	8.2. New Standalone Registry for the DCEP . . . . . . . . . . 9		8.2. New Standalone Registry for DCEP
	8.2.1. New Message Type Registry . . . . . . . . . . . . . . 9		8.2.1. New Message Type Registry
	8.2.2. New Channel Type Registry . . . . . . . . . . . . . . 10		8.2.2. New Channel Type Registry
	9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11		9. References
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11		9.1. Normative References
	10.1. Normative References . . . . . . . . . . . . . . . . . . 11		9.2. Informative References
	10.2. Informational References . . . . . . . . . . . . . . . . 12		Acknowledgements
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12		Authors' Addresses
	1. Introduction		1. Introduction
	The Data Channel Establishment Protocol (DCEP) is designed to		The Data Channel Establishment Protocol (DCEP) is designed to
	provide, in the WebRTC Data Channel context		provide, in the WebRTC data channel context [RFC8831], a simple in-
	[I-D.ietf-rtcweb-data-channel], a simple in-band method to open		band method for opening symmetric data channels. As discussed in
	symmetric Data Channels. As discussed in		[RFC8831], the protocol uses the Stream Control Transmission Protocol
	[I-D.ietf-rtcweb-data-channel], the protocol uses the Stream Control		(SCTP) [RFC4960] encapsulated in Datagram Transport Layer Security
	Transmission Protocol (SCTP) [RFC4960] encapsulated in the Datagram		(DTLS) (described in [RFC8261]). This allows DCEP to benefit from
	Transport Layer Security (DTLS) as described in		the already standardized transport and security features of SCTP and
	[I-D.ietf-tsvwg-sctp-dtls-encaps] to benefit from their already		DTLS. DTLS 1.0 is defined in [RFC4347]; the present latest version,
	standardized transport and security features. DTLS 1.0 is defined in		DTLS 1.2, is defined in [RFC6347]; and an upcoming version, DTLS 1.3,
	[RFC4347] and the present latest version, DTLS 1.2, is defined in		is defined in [TLS-DTLS13].
	[RFC6347].
	2. Conventions		2. Conventions
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	document are to be interpreted as described in [RFC2119].		"OPTIONAL" in this document are to be interpreted as described in
			BCP?14 [RFC2119] [RFC8174] when, and only when, they appear in all
			capitals, as shown here.
	3. Terminology		3. Terminology
	This document uses the following terms:		This document uses the following terms:
	Association: An SCTP association.		Association: An SCTP association.
	Stream: A unidirectional stream of an SCTP association. It is		Stream: A unidirectional stream of an SCTP association. It is
	uniquely identified by an SCTP stream identifier (0-65534). Note:		uniquely identified by an SCTP stream identifier (0-65534). Note:
	the SCTP stream identifier 65535 is reserved due to SCTP INIT and		The SCTP stream identifier 65535 is reserved due to SCTP INIT and
	INIT-ACK chunks only allowing a maximum of 65535 Streams to be		INIT-ACK chunks only allowing a maximum of 65535 streams to be
	negotiated (0-65534).		negotiated (0-65534).
	Stream Identifier: The SCTP stream identifier uniquely identifying a		Stream Identifier: The SCTP stream identifier uniquely identifying a
	Stream.		stream.
	Data Channel: Two Streams with the same Stream Identifier, one in		Data Channel: Two streams with the same stream identifier, one in
	each direction, which are managed together.		each direction, which are managed together.
	4. Protocol Overview		4. Protocol Overview
	The Data Channel Establishment Protocol is a simple, low-overhead way		The Data Channel Establishment Protocol is a simple, low-overhead way
	to establish bidirectional Data Channels over an SCTP association		to establish bidirectional data channels over an SCTP association
	with a consistent set of properties.		with a consistent set of properties.
	The set of consistent properties includes:		The set of consistent properties includes:
	o reliable or unreliable message transmission. In case of		* reliable or unreliable message transmission. In case of
	unreliable transmissions, the same level of unreliability is used.		unreliable transmissions, the same level of unreliability is used.
	o in-order or out-of-order message delivery.		* in-order or out-of-order message delivery.
	o the priority of the Data Channel.		* the priority of the data channel.
	o an optional label for the Data Channel.		* an optional label for the data channel.
	o an optional protocol for the Data Channel.		* an optional protocol for the data channel.
	o the Streams.		* the streams.
	This protocol uses a two way handshake to open a Data Channel. The		This protocol uses a two-way handshake to open a data channel. The
	handshake pairs one incoming and one outgoing Stream, both having the		handshake pairs one incoming and one outgoing stream, both having the
	same Stream Identifier, into a single bidirectional Data Channel.		same stream identifier, into a single bidirectional data channel.
	The peer that initiates opening a Data Channel selects a Stream		The peer that initiates opening a data channel selects a stream
	Identifier for which the corresponding incoming and outgoing Streams		identifier for which the corresponding incoming and outgoing streams
	are unused and sends a DATA_CHANNEL_OPEN message on the outgoing		are unused and sends a DATA_CHANNEL_OPEN message on the outgoing
	Stream. The peer responds with a DATA_CHANNEL_ACK message on its		stream. The peer responds with a DATA_CHANNEL_ACK message on its
	corresponding outgoing Stream. Then the Data Channel is open. Data		corresponding outgoing stream. Then the data channel is open. DCEP
	Channel Establishment Protocol messages are sent on the same Stream		messages are sent on the same stream as the user messages belonging
	as the user messages belonging to the Data Channel. The		to the data channel. The demultiplexing is based on the SCTP Payload
	demultiplexing is based on the SCTP payload protocol identifier		Protocol Identifier (PPID), since DCEP uses a specific PPID.
	(PPID), since the Data Channel Establishment Protocol uses a specific
	PPID.
	Note: The opening side MAY send user messages before the		| Note: The opening side MAY send user messages before the
	DATA_CHANNEL_ACK is received.		| DATA_CHANNEL_ACK is received.
	To avoid collisions where both sides try to open a Data Channel with		To avoid collisions where both sides try to open a data channel with
	the same Stream Identifiers, each side MUST use Streams with either		the same stream identifiers, each side MUST use streams with either
	even or odd Stream Identifiers when sending a DATA_CHANNEL_OPEN		even or odd stream identifiers when sending a DATA_CHANNEL_OPEN
	message. When using SCTP over DTLS		message. When using SCTP over DTLS [RFC8261], the method used to
	[I-D.ietf-tsvwg-sctp-dtls-encaps], the method used to determine which		determine which side uses odd or even is based on the underlying DTLS
	side uses odd or even is based on the underlying DTLS connection		connection role: the side acting as the DTLS client MUST use streams
	role: the side acting as the DTLS client MUST use Streams with even		with even stream identifiers; the side acting as the DTLS server MUST
	Stream Identifiers, the side acting as the DTLS server MUST use		use streams with odd stream identifiers.
	Streams with odd Stream Identifiers.
	Note: There is no attempt to ensure uniqueness for the label; if both		| Note: There is no attempt to ensure uniqueness for the label;
	sides open a Data Channel labeled "x" at the same time, there will be		| if both sides open a data channel labeled "x" at the same time,
	two Data Channels labeled "x" - one on an even Stream pair, one on an		| there will be two data channels labeled "x" -- one on an even
	odd pair.		| stream pair, one on an odd pair.
	The protocol field is to ease cross-application interoperation		The purpose of the protocol field is to ease cross-application
	("federation") by identifying the user data being passed with an		interoperation ("federation") by identifying the user data being
	IANA-registered string ('WebSocket Subprotocol Name Registry' defined		passed by means of an IANA-registered string from the "WebSocket
	in [RFC6455]), and may be useful for homogeneous applications which		Subprotocol Name Registry" defined in [RFC6455]. The field may be
	may create more than one type of Data Channel. Please note that		useful for homogeneous applications that may create more than one
	there is also no attempt to ensure uniqueness for the protocol field.		type of data channel. Note that there is no attempt to ensure
			uniqueness for the protocol field.
	5. Message Formats		5. Message Formats
	Every Data Channel Establishment Protocol message starts with a one		Every DCEP message starts with a one-byte field called "Message Type"
	byte field called "Message Type" which indicates the type of the		that indicates the type of the message. The corresponding values are
	message. The corresponding values are managed by IANA (see		managed by IANA (see Section 8.2.1).
	Section 8.2.1).
	5.1. DATA_CHANNEL_OPEN Message		5.1. DATA_CHANNEL_OPEN Message
	This message is sent initially on the Stream used for user messages		This message is initially sent using the data channel on the stream
	using the Data Channel.		used for user messages.
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Message Type | Channel Type | Priority |		| Message Type | Channel Type | Priority |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Reliability Parameter |		| Reliability Parameter |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Label Length | Protocol Length |		| Label Length | Protocol Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\ /		\ /
	| Label |		| Label |
	/ \		/ \
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\ /		\ /
	| Protocol |		| Protocol |
	/ \		/ \
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Message Type: 1 byte (unsigned integer)		Message Type: 1 byte (unsigned integer)
	This field holds the IANA defined message type for the		This field holds the IANA-defined message type for the
	DATA_CHANNEL_OPEN message. The value of this field is 0x03 as		DATA_CHANNEL_OPEN message. The value of this field is 0x03, as
	specified in Section 8.2.1.		specified in Section 8.2.1.
	Channel Type: 1 byte (unsigned integer)		Channel Type: 1 byte (unsigned integer)
	This field specifies the type of the Data Channel to be opened and		This field specifies the type of data channel to be opened. The
	the values are managed by IANA (see Section 8.2.2):		values are managed by IANA (see Section 8.2.2):
	DATA_CHANNEL_RELIABLE (0x00): The Data Channel provides a		DATA_CHANNEL_RELIABLE (0x00): The data channel provides a
	reliable in-order bi-directional communication.		reliable in-order bidirectional communication.
	DATA_CHANNEL_RELIABLE_UNORDERED (0x80): The Data Channel provides		DATA_CHANNEL_RELIABLE_UNORDERED (0x80): The data channel provides
	a reliable unordered bi-directional communication.		a reliable unordered bidirectional communication.
	DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT (0x01): The Data Channel		DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT (0x01): The data channel
	provides a partially-reliable in-order bi-directional		provides a partially reliable in-order bidirectional
	communication. User messages will not be retransmitted more		communication. User messages will not be retransmitted more
	times than specified in the Reliability Parameter.		times than specified in the Reliability Parameter.
	DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT_UNORDERED (0x81): The Data		DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT_UNORDERED (0x81): The data
	Channel provides a partial reliable unordered bi-directional		channel provides a partially reliable unordered bidirectional
	communication. User messages will not be retransmitted more		communication. User messages will not be retransmitted more
	times than specified in the Reliability Parameter.		times than specified in the Reliability Parameter.
	DATA_CHANNEL_PARTIAL_RELIABLE_TIMED (0x02): The Data Channel		DATA_CHANNEL_PARTIAL_RELIABLE_TIMED (0x02): The data channel
	provides a partial reliable in-order bi-directional		provides a partially reliable in-order bidirectional
	communication. User messages might not be transmitted or		communication. User messages might not be transmitted or
	retransmitted after a specified life-time given in milli-		retransmitted after a specified lifetime given in milliseconds
	seconds in the Reliability Parameter. This life-time starts		in the Reliability Parameter. This lifetime starts when
	when providing the user message to the protocol stack.		providing the user message to the protocol stack.
	DATA_CHANNEL_PARTIAL_RELIABLE_TIMED_UNORDERED (0x82): The Data		DATA_CHANNEL_PARTIAL_RELIABLE_TIMED_UNORDERED (0x82): The data
	Channel provides a partial reliable unordered bi-directional		channel provides a partially reliable unordered bidirectional
	communication. User messages might not be transmitted or		communication. User messages might not be transmitted or
	retransmitted after a specified life-time given in milli-		retransmitted after a specified lifetime given in milliseconds
	seconds in the Reliability Parameter. This life-time starts		in the Reliability Parameter. This lifetime starts when
	when providing the user message to the protocol stack.		providing the user message to the protocol stack.
	Priority: 2 bytes (unsigned integer)		Priority: 2 bytes (unsigned integer)
	The priority of the Data Channel as described in		The priority of the data channel, as described in [RFC8831].
	[I-D.ietf-rtcweb-data-channel].
	Reliability Parameter: 4 bytes (unsigned integer)		Reliability Parameter: 4 bytes (unsigned integer)
	For reliable Data Channels this field MUST be set to 0 on the		For reliable data channels, this field MUST be set to 0 on the
	sending side and MUST be ignored on the receiving side. If a		sending side and MUST be ignored on the receiving side. If a
	partial reliable Data Channel with limited number of		partially reliable data channel with a limited number of
	retransmissions is used, this field specifies the number of		retransmissions is used, this field specifies the number of
	retransmissions. If a partial reliable Data Channel with limited		retransmissions. If a partially reliable data channel with a
	lifetime is used, this field specifies the maximum lifetime in		limited lifetime is used, this field specifies the maximum
	milliseconds. The following table summarizes this:		lifetime in milliseconds. The following table summarizes this:
	+------------------------------------------------+------------------+		+================================================+=============+
	| Channel Type | Reliability |		| Channel Type | Reliability |
	| | Parameter |		| | Parameter |
	+------------------------------------------------+------------------+		+================================================+=============+
	| DATA_CHANNEL_RELIABLE | Ignored |		| DATA_CHANNEL_RELIABLE | Ignored |
	| DATA_CHANNEL_RELIABLE_UNORDERED | Ignored |		+------------------------------------------------+-------------+
	| DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT | Number of RTX |		| DATA_CHANNEL_RELIABLE_UNORDERED | Ignored |
	| DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT_UNORDERED | Number of RTX |		+------------------------------------------------+-------------+
	| DATA_CHANNEL_PARTIAL_RELIABLE_TIMED | Lifetime in ms |		| DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT | Number of |
	| DATA_CHANNEL_PARTIAL_RELIABLE_TIMED_UNORDERED | Lifetime in ms |		| | RTX |
	+------------------------------------------------+------------------+		+------------------------------------------------+-------------+
			| DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT_UNORDERED | Number of |
			| | RTX |
			+------------------------------------------------+-------------+
			| DATA_CHANNEL_PARTIAL_RELIABLE_TIMED | Lifetime in |
			| | ms |
			+------------------------------------------------+-------------+
			| DATA_CHANNEL_PARTIAL_RELIABLE_TIMED_UNORDERED | Lifetime in |
			| | ms |
			+------------------------------------------------+-------------+
			Table 1
	Label Length: 2 bytes (unsigned integer)		Label Length: 2 bytes (unsigned integer)
	The length of the label field in bytes.		The length of the label field in bytes.
	Protocol Length: 2 bytes (unsigned integer)		Protocol Length: 2 bytes (unsigned integer)
	The length of the protocol field in bytes.		The length of the protocol field in bytes.
	Label: Variable Length (sequence of characters)		Label: Variable Length (sequence of characters)
	The name of the Data Channel as a UTF-8 encoded string as		The name of the data channel as a UTF-8-encoded string, as
	specified in [RFC3629]. This may be an empty string.		specified in [RFC3629]. This may be an empty string.
	Protocol: Variable Length (sequence of characters)		Protocol: Variable Length (sequence of characters)
	If this is an empty string the protocol is unspecified. If it is		If this is an empty string, the protocol is unspecified. If it is
	a non-empty string, it specifies a protocol registered in the		a non-empty string, it specifies a protocol registered in the
	'WebSocket Subprotocol Name Registry' created in [RFC6455]. This		"WebSocket Subprotocol Name Registry" created in [RFC6455]. This
	string is UTF-8 encoded as specified in [RFC3629].		string is UTF-8 encoded, as specified in [RFC3629].
	5.2. DATA_CHANNEL_ACK Message		5.2. DATA_CHANNEL_ACK Message
	This message is sent in response to a DATA_CHANNEL_OPEN_RESPONSE		This message is sent in response to a DATA_CHANNEL_OPEN_RESPONSE
	message on the stream used for user messages using the Data Channel.		message. It is sent on the stream used for user messages using the
	Reception of this message tells the opener that the Data Channel		data channel. Reception of this message tells the opener that the
	setup handshake is complete.		data channel setup handshake is complete.
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Message Type |		| Message Type |
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	Message Type: 1 byte (unsigned integer)		Message Type: 1 byte (unsigned integer)
	This field holds the IANA defined message type for the		This field holds the IANA-defined message type for the
	DATA_CHANNEL_ACK message. The value of this field is 0x02 as		DATA_CHANNEL_ACK message. The value of this field is 0x02, as
	specified in Section 8.2.1.		specified in Section 8.2.1.
	6. Procedures		6. Procedures
	All Data Channel Establishment Protocol messages MUST be sent using		All DCEP messages MUST be sent using ordered delivery and reliable
	ordered delivery and reliable transmission. They MUST be sent on the		transmission. They MUST be sent on the same outgoing stream as the
	same outgoing Stream as the user messages belonging to the		user messages belonging to the corresponding data channel.
	corresponding Data Channel. Multiplexing and demultiplexing is done		Multiplexing and demultiplexing is done by using the SCTP PPID.
	by using the SCTP payload protocol identifier (PPID). Therefore Data		Therefore, a DCEP message MUST be sent with the assigned PPID for the
	Channel Establishment Protocol message MUST be sent with the assigned		Data Channel Establishment Protocol (see Section 8.1). Other
	PPID for the Data Channel Establishment Protocol (see Section 8.1).		messages MUST NOT be sent using this PPID.
	Other messages MUST NOT be sent using this PPID.
	The peer that initiates opening a Data Channel selects a Stream		The peer that initiates opening a data channel selects a stream
	Identifier for which the corresponding incoming and outgoing Streams		identifier for which the corresponding incoming and outgoing streams
	are unused. If the side is the DTLS client, it MUST choose an even		are unused. If the side is acting as the DTLS client, it MUST choose
	Stream Identifier, if the side is the DTLS server, it MUST choose an		an even stream identifier; if the side is acting as the DTLS server,
	odd one. It fills in the parameters of the DATA_CHANNEL_OPEN message		it MUST choose an odd one. The initiating peer fills in the
	and sends it on the chosen Stream.		parameters of the DATA_CHANNEL_OPEN message and sends it on the
			chosen stream.
	If a DATA_CHANNEL_OPEN message is received on an unused Stream, the		If a DATA_CHANNEL_OPEN message is received on an unused stream, the
	Stream Identifier corresponds to the role of the peer and all		stream identifier corresponds to the role of the peer, and all
	parameters in the DATA_CHANNEL_OPEN message are valid, then a		parameters in the DATA_CHANNEL_OPEN message are valid, then a
	corresponding DATA_CHANNEL_ACK message is sent on the Stream with the		corresponding DATA_CHANNEL_ACK message is sent on the stream with the
	same Stream Identifier as the one the DATA_CHANNEL_OPEN message was		same stream identifier as the one the DATA_CHANNEL_OPEN message was
	received on.		received on.
	If the DATA_CHANNEL_OPEN message doesn't satisfy the conditions		If the DATA_CHANNEL_OPEN message doesn't satisfy the conditions
	above, for instance if a DATA_CHANNEL_OPEN message is received on an		above, the receiver MUST close the corresponding data channel using
	already used Stream or there are any problems with parameters within		the procedure described in [RFC8831] and MUST NOT send a
	the DATA_CHANNEL_OPEN message, the odd/even rule is violated or the		DATA_CHANNEL_ACK message in response to the received message. This
	DATA_CHANNEL_OPEN message itself is not well-formed, the receiver		might occur if, for example, a DATA_CHANNEL_OPEN message is received
	MUST close the corresponding Data Channel using the procedure		on an already used stream, there are problems with parameters within
	described in [I-D.ietf-rtcweb-data-channel] and MUST NOT send a		the DATA_CHANNEL_OPEN message, the odd/even rule is violated, or the
	DATA_CHANNEL_ACK message in response to the received message.		DATA_CHANNEL_OPEN message itself is not well formed. Therefore,
	Therefore, receiving an SCTP stream reset request for a Stream on		receiving an SCTP stream-reset request for a stream on which no
	which no DATA_CHANNEL_ACK message has been received indicates to the		DATA_CHANNEL_ACK message has been received indicates to the sender of
	sender of the corresponding DATA_CHANNEL_OPEN message the failure of		the corresponding DATA_CHANNEL_OPEN message the failure of the data
	the Data Channel setup procedure. After also successfully resetting		channel setup procedure. After also successfully resetting the
	the corresponding outgoing Stream, which concludes the Data Channel		corresponding outgoing stream, which concludes the data channel
	closing initiated by the peer, a new DATA_CHANNEL_OPEN message can be		closing initiated by the peer, a new DATA_CHANNEL_OPEN message can be
	sent on the Stream.		sent on the stream.
	After the DATA_CHANNEL_OPEN message has been sent, the sender of the		After the DATA_CHANNEL_OPEN message has been sent, the sender of that
	DATA_CHANNEL_OPEN MAY start sending messages containing user data		message MAY start sending messages containing user data without
	without waiting for the reception of the corresponding		waiting for the reception of the corresponding DATA_CHANNEL_ACK
	DATA_CHANNEL_ACK message. However, before the DATA_CHANNEL_ACK		message. However, before the DATA_CHANNEL_ACK message or any other
	message or any other message has been received on a Data Channel, all		message has been received on a data channel, all other messages
	other messages containing user data and belonging to this Data		containing user data and belonging to this data channel MUST be sent
	Channel MUST be sent ordered, no matter whether the Data Channel is		ordered, no matter whether the data channel is ordered or not. After
	ordered or not. After the DATA_CHANNEL_ACK or any other message has		the DATA_CHANNEL_ACK or any other message has been received on the
	been received on the Data Channel, messages containing user data MUST		data channel, messages containing user data MUST be sent ordered on
	be sent ordered on ordered Data Channels and MUST be sent unordered		ordered data channels and MUST be sent unordered on unordered data
	on unordered Data Channels. Therefore receiving a message containing		channels. Therefore, receiving a message containing user data on an
	user data on an unused Stream indicates an error. The corresponding		unused stream indicates an error. In that case, the corresponding
	Data Channel MUST be closed as described in		data channel MUST be closed, as described in [RFC8831].
	[I-D.ietf-rtcweb-data-channel].
	7. Security Considerations		7. Security Considerations
	The DATA_CHANNEL_OPEN messages contains two variable length fields:		The DATA_CHANNEL_OPEN message contains two variable-length fields:
	the protocol and the label. A receiver must be prepared to receive		the protocol and the label. A receiver must be prepared to receive
	DATA_CHANNEL_OPEN messages where these field have the maximum length		DATA_CHANNEL_OPEN messages where these fields have the maximum length
	of 65535 bytes. Error cases like the use of inconsistent lengths		of 65535 bytes. Error cases such as using inconsistent lengths of
	fields, unknown parameter values or violation the odd/even rule must		fields, using unknown parameter values, or violating the odd/even
	also be handled by closing the corresponding Data Channel. An end-		rule must also be handled by closing the corresponding data channel.
	point must also be prepared that the peer open the maximum number of		An end point must also be prepared for the peer to open the maximum
	Data Channels.		number of data channels.
	This protocol does not provide privacy, integrity or authentication.		This protocol does not provide privacy, integrity, or authentication.
	It needs to be used as part of a protocol suite that contains all		It needs to be used as part of a protocol suite that contains all
	these things. Such a protocol suite is specified in		these things. Such a protocol suite is specified in [RFC8261].
	[I-D.ietf-tsvwg-sctp-dtls-encaps].
	For general considerations see [I-D.ietf-rtcweb-security] and		For general considerations, see [RFC8826] and [RFC8827].
	[I-D.ietf-rtcweb-security-arch].
	8. IANA Considerations		8. IANA Considerations
	[NOTE to RFC-Editor:		IANA has updated the reference of an already existing SCTP PPID
			assignment (Section 8.1) and created a new standalone registry with
	"RFCXXXX" is to be replaced by the RFC number you assign this		its own URL for DCEP (Section 8.2) containing two new registration
	document.		tables (Sections 8.2.1 and 8.2.2).
	]
	IANA is asked to update the reference of an already existing SCTP
	PPID assignment (Section 8.1) and to create a new standalone registry
	with its own URL for the DCEP (Section 8.2) containing two new
	registration tables (Section 8.2.1 and Section 8.2.2).
	8.1. SCTP Payload Protocol Identifier		8.1. SCTP Payload Protocol Identifier
	This document uses one already registered SCTP Payload Protocol		This document uses an SCTP Payload Protocol Identifier (PPID)
	Identifier (PPID) named "WebRTC Control". [RFC4960] creates the		previously registered as "WebRTC Control". [RFC4960] created the
	registry "SCTP Payload Protocol Identifiers" from which this		"SCTP Payload Protocol Identifiers" registry, in which this
	identifier was assigned. IANA is requested to update the reference		identifier was assigned. IANA has updated the PPID name from "WebRTC
	of this assignment to point to this document and to update the name.		Control" to "WebRTC DCEP" and has updated the reference to point to
	The corresponding date should be kept.		this document. The corresponding date has been kept.
	Therefore this assignment should be updated to read:		Therefore, this assignment now appears as follows:
	+-------------+-----------+-----------+------------+		+=============+===========+===========+============+
	| Value | SCTP PPID | Reference | Date |		| Value | SCTP PPID | Reference | Date |
	+-------------+-----------+-----------+------------+		+=============+===========+===========+============+
	| WebRTC DCEP | 50 | [RFCXXXX] | 2013-09-20 |		| WebRTC DCEP | 50 | RFC 8832 | 2013-09-20 |
	+-------------+-----------+-----------+------------+		+-------------+-----------+-----------+------------+
	8.2. New Standalone Registry for the DCEP		Table 2
	IANA is requested to create a new standalone registry (aka a webpage)		8.2. New Standalone Registry for DCEP
	with its own URL for the Data Channel Establishment Protocol (DCEP).
	The title should be "Data Channel Establishment Protocol (DCEP)		IANA has created the "Data Channel Establishment Protocol (DCEP)
	Parameters". It will contain the two tables as described in		Parameters" registry. It contains the two tables provided in
	Section 8.2.1 and Section 8.2.2.		Sections 8.2.1 and 8.2.2.
	8.2.1. New Message Type Registry		8.2.1. New Message Type Registry
	IANA is requested to create a new registration table "Message Type		IANA has created the "Message Types" registry for DCEP to manage the
	Registry" for the Data Channel Establishment Protocol (DCEP) to		one-byte "Message Type" field in DCEP messages (see Section 5). This
	manage the one byte "Message Type" field in DCEP messages (see		registration table is a subregistry of the registry described in
	Section 5). This registration table should be part of the registry		Section 8.2.
	described in Section 8.2.
	The assignment of new message types is done through an RFC required		The assignment of new message types is done through an RFC Required
	action, as defined in [RFC5226]. Documentation of the new message		action, as defined in [RFC8126]. Documentation of new message types
	type MUST contain the following information:		MUST contain the following information:
	1. A name for the new message type;		1. A name for the new message type.
	2. A detailed procedural description of the use of messages with the		2. A detailed procedural description of how each message type is
	new type within the operation of the Data Channel Establishment		used with within DCEP.
	Protocol.
	Initially the following values need to be registered:		The following are the initial registrations:
	+-------------------+-----------+-----------+		+===================+===========+===========+
	| Name | Type | Reference |		| Name | Type | Reference |
			+===================+===========+===========+
			| Reserved | 0x00 | RFC 8832 |
			+-------------------+-----------+-----------+
			| Reserved | 0x01 | RFC 8832 |
			+-------------------+-----------+-----------+
			| DATA_CHANNEL_ACK | 0x02 | RFC 8832 |
			+-------------------+-----------+-----------+
			| DATA_CHANNEL_OPEN | 0x03 | RFC 8832 |
	+-------------------+-----------+-----------+		+-------------------+-----------+-----------+
	| Reserved | 0x00 | [RFCXXXX] |
	| Reserved | 0x01 | [RFCXXXX] |
	| DATA_CHANNEL_ACK | 0x02 | [RFCXXXX] |
	| DATA_CHANNEL_OPEN | 0x03 | [RFCXXXX] |
	| Unassigned | 0x04-0xfe | |		| Unassigned | 0x04-0xfe | |
	| Reserved | 0xff | [RFCXXXX] |		+-------------------+-----------+-----------+
			| Reserved | 0xff | RFC 8832 |
	+-------------------+-----------+-----------+		+-------------------+-----------+-----------+
	Please note that the values 0x00 and 0x01 are reserved to avoid		Table 3
	interoperability problems, since they have been used in earlier
	versions of the document. The value 0xff has been reserved for		Note that values 0x00 and 0x01 are reserved to avoid interoperability
	future extensibility. The range of possible values is from 0x00 to		problems, since they have been used in draft versions of the
	0xff.		document. The value 0xff has been reserved for future extensibility.
			The range of possible values is from 0x00 to 0xff.
	8.2.2. New Channel Type Registry		8.2.2. New Channel Type Registry
	IANA is requested to create a new registration table "Channel Type		IANA has created the "Channel Types" registry for DCEP to manage the
	Registry" for the Data Channel Establishment Protocol to manage the		one-byte "Channel Type" field in DATA_CHANNEL_OPEN messages (see
	one byte "Channel Type" field in DATA_CHANNEL_OPEN messages (see		Section 5.1). This registration table is a subregistry within the
	Section 5.1). This registration table should be part of the registry		registry described in Section 8.2.
	described in Section 8.2.
	The assignment of new message types is done through an RFC required		The assignment of new message types is done through an RFC Required
	action, as defined in [RFC5226]. Documentation of the new Channel		action, as defined in [RFC8126]. Documentation of new Channel Types
	Type MUST contain the following information:		MUST contain the following information:
	1. A name for the new Channel Type;		1. A name for the new Channel Type.
	2. A detailed procedural description of the user message handling		2. A detailed procedural description of the user message handling
	for Data Channels using this new Channel Type.		for data channels using this new Channel Type.
	Please note that if new Channel Types support ordered and unordered		If new Channel Types support ordered and unordered message delivery,
	message delivery, the high order bit MUST be used to indicate whether		the high-order bit MUST be used to indicate whether or not the
	the message delivery is unordered or not.		message delivery is unordered.
	Initially the following values need to be registered:		The following are the initial registrations:
	+------------------------------------------------+------+-----------+		+================================================+======+===========+
	| Name | Type | Reference |		| Name | Type | Reference |
			+================================================+======+===========+
			| DATA_CHANNEL_RELIABLE | 0x00 | RFC 8832 |
			+------------------------------------------------+------+-----------+
			| DATA_CHANNEL_RELIABLE_UNORDERED | 0x80 | RFC 8832 |
			+------------------------------------------------+------+-----------+
			| DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT | 0x01 | RFC 8832 |
			+------------------------------------------------+------+-----------+
			| DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT_UNORDERED | 0x81 | RFC 8832 |
			+------------------------------------------------+------+-----------+
			| DATA_CHANNEL_PARTIAL_RELIABLE_TIMED | 0x02 | RFC 8832 |
			+------------------------------------------------+------+-----------+
			| DATA_CHANNEL_PARTIAL_RELIABLE_TIMED_UNORDERED | 0x82 | RFC 8832 |
			+------------------------------------------------+------+-----------+
			| Reserved | 0x7f | RFC 8832 |
			+------------------------------------------------+------+-----------+
			| Reserved | 0xff | RFC 8832 |
	+------------------------------------------------+------+-----------+		+------------------------------------------------+------+-----------+
	| DATA_CHANNEL_RELIABLE | 0x00 | [RFCXXXX] |
	| DATA_CHANNEL_RELIABLE_UNORDERED | 0x80 | [RFCXXXX] |
	| DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT | 0x01 | [RFCXXXX] |
	| DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT_UNORDERED | 0x81 | [RFCXXXX] |
	| DATA_CHANNEL_PARTIAL_RELIABLE_TIMED | 0x02 | [RFCXXXX] |
	| DATA_CHANNEL_PARTIAL_RELIABLE_TIMED_UNORDERED | 0x82 | [RFCXXXX] |
	| Reserved | 0x7f | [RFCXXXX] |
	| Reserved | 0xff | [RFCXXXX] |
	| Unassigned | rest | |		| Unassigned | rest | |
	+------------------------------------------------+------+-----------+		+------------------------------------------------+------+-----------+
	Please note that the values 0x7f and 0xff have been reserved for		Table 4
	future extensibility. The range of possible values is from 0x00 to
	0xff.
	9. Acknowledgments
	The authors wish to thank Harald Alvestrand, Richard Barnes, Adam		Values 0x7f and 0xff have been reserved for future extensibility.
	Bergkvist, Spencer Dawkins, Barry Dingle, Stefan Haekansson, Cullen		The range of possible values is from 0x00 to 0xff.
	Jennings, Paul Kyzivat, Doug Leonard, Alexey Melnikov, Pete Resnick,
	Irene Ruengeler, Randall Stewart, Peter Thatcher, Martin Thompson,
	Justin Uberti, and many others for their invaluable comments.
	10. References		9. References
	10.1. Normative References		9.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119,
			DOI 10.17487/RFC2119, March 1997,
			<https://www.rfc-editor.org/info/rfc2119>.
			[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
			2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
			May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO		[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
	10646", STD 63, RFC 3629, November 2003.		10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
			2003, <https://www.rfc-editor.org/info/rfc3629>.
	[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer		[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol",
	Security", RFC 4347, April 2006.		RFC 4960, DOI 10.17487/RFC4960, September 2007,
			<https://www.rfc-editor.org/info/rfc4960>.
	[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC		[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
	4960, September 2007.		Writing an IANA Considerations Section in RFCs", BCP 26,
			RFC 8126, DOI 10.17487/RFC8126, June 2017,
			<https://www.rfc-editor.org/info/rfc8126>.
	[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an		[RFC8261] Tuexen, M., Stewart, R., Jesup, R., and S. Loreto,
	IANA Considerations Section in RFCs", BCP 26, RFC 5226,		"Datagram Transport Layer Security (DTLS) Encapsulation of
	May 2008.		SCTP Packets", RFC 8261, DOI 10.17487/RFC8261, November
			2017, <https://www.rfc-editor.org/info/rfc8261>.
			[RFC8831] Jesup, R., Loreto, S., and M. Tüxen, "WebRTC Data
			Channels", RFC 8831, DOI 10.17487/RFC8831, January 2021,
			<https://www.rfc-editor.org/info/rfc8831>.
			9.2. Informative References
			[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
			Security", RFC 4347, DOI 10.17487/RFC4347, April 2006,
			<https://www.rfc-editor.org/info/rfc4347>.
	[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer		[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
	Security Version 1.2", RFC 6347, January 2012.		Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
			January 2012, <https://www.rfc-editor.org/info/rfc6347>.
	[I-D.ietf-tsvwg-sctp-dtls-encaps]		[RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol",
	Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, "DTLS		RFC 6455, DOI 10.17487/RFC6455, December 2011,
	Encapsulation of SCTP Packets", draft-ietf-tsvwg-sctp-		<https://www.rfc-editor.org/info/rfc6455>.
	dtls-encaps-07 (work in progress), December 2014.
	[I-D.ietf-rtcweb-data-channel]		[RFC8826] Rescorla, E., "Security Considerations for WebRTC",
	Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data		RFC 8826, DOI 10.17487/RFC8826, January 2021,
	Channels", draft-ietf-rtcweb-data-channel-12 (work in		<https://www.rfc-editor.org/info/rfc8826>.
	progress), September 2014.
	10.2. Informational References		[RFC8827] Rescorla, E., "WebRTC Security Architecture", RFC 8827,
			DOI 10.17487/RFC8827, January 2021,
			<https://www.rfc-editor.org/info/rfc8827>.
	[RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC		[TLS-DTLS13]
	6455, December 2011.		Rescorla, E., Tschofenig, H., and N. Modadugu, "The
			Datagram Transport Layer Security (DTLS) Protocol Version
			1.3", Work in Progress, Internet-Draft, draft-ietf-tls-
			dtls13-39, 2 November 2020,
			<https://tools.ietf.org/html/draft-ietf-tls-dtls13-39>.
	[I-D.ietf-rtcweb-security]		Acknowledgements
	Rescorla, E., "Security Considerations for WebRTC", draft-
	ietf-rtcweb-security-07 (work in progress), July 2014.
	[I-D.ietf-rtcweb-security-arch]		The authors wish to thank Harald Alvestrand, Richard Barnes, Adam
	Rescorla, E., "WebRTC Security Architecture", draft-ietf-		Bergkvist, Spencer Dawkins, Barry Dingle, Stefan Håkansson, Cullen
	rtcweb-security-arch-10 (work in progress), July 2014.		Jennings, Paul Kyzivat, Doug Leonard, Alexey Melnikov, Pete Resnick,
			Irene Rüngeler, Randall Stewart, Peter Thatcher, Martin Thomson,
			Justin Uberti, and many others for their invaluable comments.
	Authors' Addresses		Authors' Addresses
	Randell Jesup		Randell Jesup
	Mozilla		Mozilla
	US		United States of America
	Email: randell-ietf@jesup.org		Email: randell-ietf@jesup.org
	Salvatore Loreto		Salvatore Loreto
	Ericsson		Ericsson
	Hirsalantie 11		Hirsalantie 11
	Jorvas 02420		FI-02420 Jorvas
	FI		Finland
	Email: salvatore.loreto@ericsson.com		Email: salvatore.loreto@ericsson.com
	Michael Tuexen
	Muenster University of Applied Sciences		Michael Tüxen
			Münster University of Applied Sciences
	Stegerwaldstrasse 39		Stegerwaldstrasse 39
	Steinfurt 48565		48565 Steinfurt
	DE		Germany
	Email: tuexen@fh-muenster.de		Email: tuexen@fh-muenster.de
End of changes. 107 change blocks.
	332 lines changed or deleted		357 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/