rfc8831v2.txt		rfc8831.txt
	Internet Engineering Task Force (IETF) R. Jesup		Internet Engineering Task Force (IETF) R. Jesup
	Request for Comments: 8831 Mozilla		Request for Comments: 8831 Mozilla
	Category: Standards Track S. Loreto		Category: Standards Track S. Loreto
	ISSN: 2070-1721 Ericsson		ISSN: 2070-1721 Ericsson
	M. Tüxen		M. Tüxen
	Münster Univ. of Appl. Sciences		Münster Univ. of Appl. Sciences
	November 2020		January 2021
	WebRTC Data Channels		WebRTC Data Channels
	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 the non-media data		two peers' web browsers. This document specifies the non-media data
	transport aspects of the WebRTC framework. It provides an		transport aspects of the WebRTC framework. It provides an
	architectural overview of how the Stream Control Transmission		architectural overview of how the Stream Control Transmission
	skipping to change at line 39 ¶		skipping to change at line 39 ¶
	received public review and has been approved for publication by the		received public review and has been approved for publication by the
	Internet Engineering Steering Group (IESG). Further information on		Internet Engineering Steering Group (IESG). Further information on
	Internet Standards is available in Section 2 of RFC 7841.		Internet Standards is available in Section 2 of RFC 7841.
	Information about the current status of this document, any errata,		Information about the current status of this document, any errata,
	and how to provide feedback on it may be obtained at		and how to provide feedback on it may be obtained at
	https://www.rfc-editor.org/info/rfc8831.		https://www.rfc-editor.org/info/rfc8831.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 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
	(https://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
	skipping to change at line 84 ¶		skipping to change at line 84 ¶
	Acknowledgements		Acknowledgements
	Authors' Addresses		Authors' Addresses
	1. Introduction		1. Introduction
	In the WebRTC framework, communication between the parties consists		In the WebRTC framework, communication between the parties consists
	of media (for example, audio and video) and non-media data. Media is		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		sent using the Secure Real-time Transport Protocol (SRTP) and is not
	specified further here. Non-media data is handled by using the		specified further here. Non-media data is handled by using the
	Stream Control Transmission Protocol (SCTP) [RFC4960] encapsulated in		Stream Control Transmission Protocol (SCTP) [RFC4960] encapsulated in
	DTLS. DTLS 1.0 is defined in [RFC4347], and the present latest		DTLS. DTLS 1.0 is defined in [RFC4347]; the present latest version,
	version, DTLS 1.2, is defined in [RFC6347].		DTLS 1.2, is defined in [RFC6347]; and an upcoming version, DTLS 1.3,
			is defined in [TLS-DTLS13].
	+----------+		+----------+
	| SCTP |		| SCTP |
	+----------+		+----------+
	| DTLS |		| DTLS |
	+----------+		+----------+
	| ICE/UDP |		| ICE/UDP |
	+----------+		+----------+
	Figure 1: Basic Stack Diagram		Figure 1: Basic Stack Diagram
	skipping to change at line 276 ¶		skipping to change at line 277 ¶
	* Reliable and partially reliable transport of user messages.		* Reliable and partially reliable transport of user messages.
	Each SCTP user message contains a Payload Protocol Identifier (PPID)		Each SCTP user message contains a Payload Protocol Identifier (PPID)
	that is passed to SCTP by its upper layer on the sending side and		that is passed to SCTP by its upper layer on the sending side and
	provided to its upper layer on the receiving side. The PPID can be		provided to its upper layer on the receiving side. The PPID can be
	used to multiplex/demultiplex multiple upper layers over a single		used to multiplex/demultiplex multiple upper layers over a single
	SCTP association. In the WebRTC context, the PPID is used to		SCTP association. In the WebRTC context, the PPID is used to
	distinguish between UTF-8 encoded user data, binary-encoded user		distinguish between UTF-8 encoded user data, binary-encoded user
	data, and the Data Channel Establishment Protocol (DCEP) defined in		data, and the Data Channel Establishment Protocol (DCEP) defined in
	[RFC8832]. Please note that the PPID is not accessible via the		[RFC8832]. Please note that the PPID is not accessible via the
	Javascript API.		JavaScript API.
	The encapsulation of SCTP over DTLS, together with the SCTP features		The encapsulation of SCTP over DTLS, together with the SCTP features
	listed above, satisfies all the requirements listed in Section 4.		listed above, satisfies all the requirements listed in Section 4.
	The layering of protocols for WebRTC is shown in Figure 2.		The layering of protocols for WebRTC is shown in Figure 2.
	+------+------+------+		+------+------+------+
	| DCEP | UTF-8|Binary|		| DCEP | UTF-8|Binary|
	| | Data | Data |		| | Data | Data |
	+------+------+------+		+------+------+------+
	skipping to change at line 309 ¶		skipping to change at line 310 ¶
	combination with SCTP over UDP [RFC6951]) has been chosen for the		combination with SCTP over UDP [RFC6951]) has been chosen for the
	following reasons:		following reasons:
	* supports the transmission of arbitrarily large user messages;		* supports the transmission of arbitrarily large user messages;
	* shares the DTLS connection with the SRTP media channels of the		* shares the DTLS connection with the SRTP media channels of the
	PeerConnection; and		PeerConnection; and
	* provides privacy for the SCTP control information.		* provides privacy for the SCTP control information.
	In the protocol stack of Figure 2, the usage of DTLS 1.0 over UDP is		Referring to the protocol stack shown in Figure 2:
	specified in [RFC4347] and the usage of DTLS 1.2 over UDP in
	specified in [RFC6347], while the usage of SCTP on top of DTLS is		* the usage of DTLS 1.0 over UDP is specified in [RFC4347];
	specified in [RFC8261]. Please note that the demultiplexing Session
	Traversal Utilities for NAT (STUN) [RFC5389] vs. SRTP vs. DTLS is		* the usage of DTLS 1.2 over UDP in specified in [RFC6347];
	done as described in Section 5.1.2 of [RFC5764], and SCTP is the only
	payload of DTLS.		* the usage of DTLS 1.3 over UDP is specified in an upcoming
			document [TLS-DTLS13]; and
			* the usage of SCTP on top of DTLS is specified in [RFC8261].
			Please note that the demultiplexing Session Traversal Utilities for
			NAT (STUN) [RFC5389] vs. SRTP vs. DTLS is done as described in
			Section 5.1.2 of [RFC5764], and SCTP is the only payload of DTLS.
	Since DTLS is typically implemented in user application space, the		Since DTLS is typically implemented in user application space, the
	SCTP stack also needs to be a user application space stack.		SCTP stack also needs to be a user application space stack.
	The ICE/UDP layer can handle IP address changes during a session		The ICE/UDP layer can handle IP address changes during a session
	without needing interaction with the DTLS and SCTP layers. However,		without needing interaction with the DTLS and SCTP layers. However,
	SCTP SHOULD be notified when an address change has happened. In this		SCTP SHOULD be notified when an address change has happened. In this
	case, SCTP SHOULD retest the Path MTU and reset the congestion state		case, SCTP SHOULD retest the Path MTU and reset the congestion state
	to the initial state. In the case of window-based congestion control		to the initial state. In the case of window-based congestion control
	like the one specified in [RFC4960], this means setting the		like the one specified in [RFC4960], this means setting the
	skipping to change at line 340 ¶		skipping to change at line 348 ¶
	association. Therefore, SCTP MUST support performing Path MTU		association. Therefore, SCTP MUST support performing Path MTU
	discovery without relying on ICMP or ICMPv6 as specified in [RFC4821]		discovery without relying on ICMP or ICMPv6 as specified in [RFC4821]
	by using probing messages specified in [RFC4820]. The initial Path		by using probing messages specified in [RFC4820]. The initial Path
	MTU at the IP layer SHOULD NOT exceed 1200 bytes for IPv4 and 1280		MTU at the IP layer SHOULD NOT exceed 1200 bytes for IPv4 and 1280
	bytes for IPv6.		bytes for IPv6.
	In general, the lower-layer interface of an SCTP implementation		In general, the lower-layer interface of an SCTP implementation
	should be adapted to address the differences between IPv4 and IPv6		should be adapted to address the differences between IPv4 and IPv6
	(being connectionless) or DTLS (being connection oriented).		(being connectionless) or DTLS (being connection oriented).
	When the protocol stack of Figure 2 is used, DTLS protects the		When the protocol stack shown in Figure 2 is used, DTLS protects the
	complete SCTP packet, so it provides confidentiality, integrity, and		complete SCTP packet, so it provides confidentiality, integrity, and
	source authentication of the complete SCTP packet.		source authentication of the complete SCTP packet.
	SCTP provides congestion control on a per-association basis. This		SCTP provides congestion control on a per-association basis. This
	means that all SCTP streams within a single SCTP association share		means that all SCTP streams within a single SCTP association share
	the same congestion window. Traffic not being sent over SCTP is not		the same congestion window. Traffic not being sent over SCTP is not
	covered by SCTP congestion control. Using a congestion control		covered by SCTP congestion control. Using a congestion control
	different from the standard one might improve the impact on the		different from the standard one might improve the impact on the
	parallel SRTP media streams.		parallel SRTP media streams.
	skipping to change at line 625 ¶		skipping to change at line 633 ¶
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P.		[RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P.
	Conrad, "Stream Control Transmission Protocol (SCTP)		Conrad, "Stream Control Transmission Protocol (SCTP)
	Partial Reliability Extension", RFC 3758,		Partial Reliability Extension", RFC 3758,
	DOI 10.17487/RFC3758, May 2004,		DOI 10.17487/RFC3758, May 2004,
	<https://www.rfc-editor.org/info/rfc3758>.		<https://www.rfc-editor.org/info/rfc3758>.
	[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>.
	[RFC4820] Tuexen, M., Stewart, R., and P. Lei, "Padding Chunk and		[RFC4820] Tuexen, M., Stewart, R., and P. Lei, "Padding Chunk and
	Parameter for the Stream Control Transmission Protocol		Parameter for the Stream Control Transmission Protocol
	(SCTP)", RFC 4820, DOI 10.17487/RFC4820, March 2007,		(SCTP)", RFC 4820, DOI 10.17487/RFC4820, March 2007,
	<https://www.rfc-editor.org/info/rfc4820>.		<https://www.rfc-editor.org/info/rfc4820>.
	[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU		[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
	Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007,		Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007,
	<https://www.rfc-editor.org/info/rfc4821>.		<https://www.rfc-editor.org/info/rfc4821>.
	[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol",		[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol",
	RFC 4960, DOI 10.17487/RFC4960, September 2007,		RFC 4960, DOI 10.17487/RFC4960, September 2007,
	<https://www.rfc-editor.org/info/rfc4960>.		<https://www.rfc-editor.org/info/rfc4960>.
	[RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M.		[RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M.
	Kozuka, "Stream Control Transmission Protocol (SCTP)		Kozuka, "Stream Control Transmission Protocol (SCTP)
	Dynamic Address Reconfiguration", RFC 5061,		Dynamic Address Reconfiguration", RFC 5061,
	DOI 10.17487/RFC5061, September 2007,		DOI 10.17487/RFC5061, September 2007,
	<https://www.rfc-editor.org/info/rfc5061>.		<https://www.rfc-editor.org/info/rfc5061>.
	[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
	Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
	January 2012, <https://www.rfc-editor.org/info/rfc6347>.
	[RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control		[RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control
	Transmission Protocol (SCTP) Stream Reconfiguration",		Transmission Protocol (SCTP) Stream Reconfiguration",
	RFC 6525, DOI 10.17487/RFC6525, February 2012,		RFC 6525, DOI 10.17487/RFC6525, February 2012,
	<https://www.rfc-editor.org/info/rfc6525>.		<https://www.rfc-editor.org/info/rfc6525>.
	[RFC7496] Tuexen, M., Seggelmann, R., Stewart, R., and S. Loreto,		[RFC7496] Tuexen, M., Seggelmann, R., Stewart, R., and S. Loreto,
	"Additional Policies for the Partially Reliable Stream		"Additional Policies for the Partially Reliable Stream
	Control Transmission Protocol Extension", RFC 7496,		Control Transmission Protocol Extension", RFC 7496,
	DOI 10.17487/RFC7496, April 2015,		DOI 10.17487/RFC7496, April 2015,
	<https://www.rfc-editor.org/info/rfc7496>.		<https://www.rfc-editor.org/info/rfc7496>.
	skipping to change at line 685 ¶		skipping to change at line 685 ¶
	SCTP Packets", RFC 8261, DOI 10.17487/RFC8261, November		SCTP Packets", RFC 8261, DOI 10.17487/RFC8261, November
	2017, <https://www.rfc-editor.org/info/rfc8261>.		2017, <https://www.rfc-editor.org/info/rfc8261>.
	[RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive		[RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive
	Connectivity Establishment (ICE): A Protocol for Network		Connectivity Establishment (ICE): A Protocol for Network
	Address Translator (NAT) Traversal", RFC 8445,		Address Translator (NAT) Traversal", RFC 8445,
	DOI 10.17487/RFC8445, July 2018,		DOI 10.17487/RFC8445, July 2018,
	<https://www.rfc-editor.org/info/rfc8445>.		<https://www.rfc-editor.org/info/rfc8445>.
	[RFC8826] Rescorla, E., "Security Considerations for WebRTC",		[RFC8826] Rescorla, E., "Security Considerations for WebRTC",
	RFC 8826, DOI 10.17487/RFC8826, November 2020,		RFC 8826, DOI 10.17487/RFC8826, January 2021,
	<https://www.rfc-editor.org/info/rfc8826>.		<https://www.rfc-editor.org/info/rfc8826>.
	[RFC8827] Rescorla, E., "WebRTC Security Architecture", RFC 8827,		[RFC8827] Rescorla, E., "WebRTC Security Architecture", RFC 8827,
	DOI 10.17487/RFC8827, November 2020,		DOI 10.17487/RFC8827, January 2021,
	<https://www.rfc-editor.org/info/rfc8827>.		<https://www.rfc-editor.org/info/rfc8827>.
	[RFC8829] Uberti, J., Jennings, C., and E. Rescorla, Ed.,		[RFC8829] Uberti, J., Jennings, C., and E. Rescorla, Ed.,
	"JavaScript Session Establishment Protocol (JSEP)",		"JavaScript Session Establishment Protocol (JSEP)",
	RFC 8829, DOI 10.17487/RFC8829, November 2020,		RFC 8829, DOI 10.17487/RFC8829, January 2021,
	<https://www.rfc-editor.org/info/rfc8829>.		<https://www.rfc-editor.org/info/rfc8829>.
	[RFC8832] Jesup, R., Loreto, S., and M. Tüxen, "WebRTC Data Channel		[RFC8832] Jesup, R., Loreto, S., and M. Tüxen, "WebRTC Data Channel
	Establishment Protocol", RFC 8832, DOI 10.17487/RFC8832,		Establishment Protocol", RFC 8832, DOI 10.17487/RFC8832,
	November 2020, <https://www.rfc-editor.org/info/rfc8832>.		January 2021, <https://www.rfc-editor.org/info/rfc8832>.
	[RFC8841] Holmberg, C., Shpount, R., Loreto, S., and G. Camarillo,		[RFC8841] Holmberg, C., Shpount, R., Loreto, S., and G. Camarillo,
	"Session Description Protocol (SDP) Offer/Answer		"Session Description Protocol (SDP) Offer/Answer
	Procedures for Stream Control Transmission Protocol (SCTP)		Procedures for Stream Control Transmission Protocol (SCTP)
	over Datagram Transport Layer Security (DTLS) Transport",		over Datagram Transport Layer Security (DTLS) Transport",
	RFC 8841, DOI 10.17487/RFC8841, November 2020,		RFC 8841, DOI 10.17487/RFC8841, January 2021,
	<https://www.rfc-editor.org/info/rfc8841>.		<https://www.rfc-editor.org/info/rfc8841>.
	9.2. Informative References		9.2. Informative References
	[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -		[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
	Communication Layers", STD 3, RFC 1122,		Communication Layers", STD 3, RFC 1122,
	DOI 10.17487/RFC1122, October 1989,		DOI 10.17487/RFC1122, October 1989,
	<https://www.rfc-editor.org/info/rfc1122>.		<https://www.rfc-editor.org/info/rfc1122>.
			[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
			Security", RFC 4347, DOI 10.17487/RFC4347, April 2006,
			<https://www.rfc-editor.org/info/rfc4347>.
	[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,		[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
	"Session Traversal Utilities for NAT (STUN)", RFC 5389,		"Session Traversal Utilities for NAT (STUN)", RFC 5389,
	DOI 10.17487/RFC5389, October 2008,		DOI 10.17487/RFC5389, October 2008,
	<https://www.rfc-editor.org/info/rfc5389>.		<https://www.rfc-editor.org/info/rfc5389>.
	[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer		[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer
	Security (DTLS) Extension to Establish Keys for the Secure		Security (DTLS) Extension to Establish Keys for the Secure
	Real-time Transport Protocol (SRTP)", RFC 5764,		Real-time Transport Protocol (SRTP)", RFC 5764,
	DOI 10.17487/RFC5764, May 2010,		DOI 10.17487/RFC5764, May 2010,
	<https://www.rfc-editor.org/info/rfc5764>.		<https://www.rfc-editor.org/info/rfc5764>.
	[RFC6083] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram		[RFC6083] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram
	Transport Layer Security (DTLS) for Stream Control		Transport Layer Security (DTLS) for Stream Control
	Transmission Protocol (SCTP)", RFC 6083,		Transmission Protocol (SCTP)", RFC 6083,
	DOI 10.17487/RFC6083, January 2011,		DOI 10.17487/RFC6083, January 2011,
	<https://www.rfc-editor.org/info/rfc6083>.		<https://www.rfc-editor.org/info/rfc6083>.
			[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
			Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
			January 2012, <https://www.rfc-editor.org/info/rfc6347>.
	[RFC6951] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream		[RFC6951] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream
	Control Transmission Protocol (SCTP) Packets for End-Host		Control Transmission Protocol (SCTP) Packets for End-Host
	to End-Host Communication", RFC 6951,		to End-Host Communication", RFC 6951,
	DOI 10.17487/RFC6951, May 2013,		DOI 10.17487/RFC6951, May 2013,
	<https://www.rfc-editor.org/info/rfc6951>.		<https://www.rfc-editor.org/info/rfc6951>.
			[TLS-DTLS13]
			Rescorla, E., Tschofenig, H., and N. Modadugu, "The
			Datagram Transport Layer Security (DTLS) Protocol Version
			1.3", Work in Progress, Internet-Draft, draft-ietf-tls-
			dtls13-39, 2 November 2020,
			<https://tools.ietf.org/html/draft-ietf-tls-dtls13-39>.
	Acknowledgements		Acknowledgements
	Many thanks for comments, ideas, and text from Harald Alvestrand,		Many thanks for comments, ideas, and text from Harald Alvestrand,
	Richard Barnes, Adam Bergkvist, Alissa Cooper, Benoit Claise, Spencer		Richard Barnes, Adam Bergkvist, Alissa Cooper, Benoit Claise, Spencer
	Dawkins, Gunnar Hellström, Christer Holmberg, Cullen Jennings, Paul		Dawkins, Gunnar Hellström, Christer Holmberg, Cullen Jennings, Paul
	Kyzivat, Eric Rescorla, Adam Roach, Irene Rüngeler, Randall Stewart,		Kyzivat, Eric Rescorla, Adam Roach, Irene Rüngeler, Randall Stewart,
	Martin Stiemerling, Justin Uberti, and Magnus Westerlund.		Martin Stiemerling, Justin Uberti, and Magnus Westerlund.
	Authors' Addresses		Authors' Addresses
End of changes. 16 change blocks.
	26 lines changed or deleted		41 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/