WebRTC Data Channels
Extracted elements (30)
Because DTLS is typically implemented in user application space, the SCTP stack must also be a user application space stack rather than a kernel implementation.
The SCTP-over-DTLS-over-UDP stack was chosen over alternatives (e.g., DTLS over SCTP per RFC 6083) for three reasons: it supports arbitrarily large user messages, it shares the DTLS connection with SRTP media channels of the PeerConnection, and it provides privacy for SCTP control information.
The SCTP PPID is used to multiplex DCEP, UTF-8 data, and binary data over a single SCTP association, but is intentionally not exposed via the JavaScript API, keeping the multiplexing mechanism internal to the protocol stack.
WebRTC data channels do not support SCTP multihoming. The DTLS layer presents a connection-oriented, single-homed abstraction, so the SCTP layer acts as if running on a single-homed host even though the underlying IP may be multihomed.
Extensions that use additional SCTP PPIDs beyond those defined here cannot be used without prior negotiation between peers. If a message with an unsupported PPID is received, the receiver SHOULD close the corresponding data channel.
The PPIDs 'WebRTC Binary Partial' (52) and 'WebRTC String Partial' (54) are deprecated. They were used for PPID-based fragmentation and reassembly of user messages on reliable and ordered channels; that approach has been superseded.
Closing a data channel MUST be signaled by resetting the corresponding outgoing SCTP streams per RFC 6525. When the peer sees an incoming stream reset, it also resets its corresponding outgoing stream, completing the close.
Data channel priorities MUST be interpreted as weighted-fair-queuing scheduling priorities per RFC 8260. Recommended values are 128 (below normal), 256 (normal), 512 (high), or 1024 (extra high).
If an application attempts to reuse a stream identifier that is already part of an existing data channel (during out-of-band negotiation), the addition MUST fail.
SCTP as specified in RFC 4960 MUST be used in combination with the partial reliability extension defined in RFC 3758. This provides multiple unidirectional streams, ordered and unordered delivery, and reliable and partially reliable transport.
SCTP MUST support performing Path MTU discovery without relying on ICMP or ICMPv6 as specified in RFC 4821, using probing messages defined in RFC 4820, because incoming ICMP/ICMPv6 messages cannot be associated with an SCTP association in this stack.
Senders MUST NOT put more than one application message into an SCTP user message; unless deprecated PPID-based fragmentation is used, each SCTP user message MUST contain exactly one application message.
Support for message interleaving as defined in RFC 8260 SHOULD be used. Until it is supported, the sender SHOULD limit maximum message size to 16 KB to avoid monopolization of the SCTP association.
The DTLS encapsulation of SCTP packets as described in RFC 8261 MUST be used. This provides confidentiality, integrity, and source authentication of the complete SCTP packet.
The dynamic address reconfiguration extension defined in RFC 5061 MUST be used to signal support for the stream reset extension defined in RFC 6525. Other features of RFC 5061 are OPTIONAL.
The initial Path MTU at the IP layer SHOULD NOT exceed 1200 bytes for IPv4 and 1280 bytes for IPv6.
The number of SCTP streams negotiated during association setup SHOULD be 65535, which is the maximum number that can be negotiated at setup time.
The partial reliability extension (RFC 3758) MUST be supported, and the limited retransmission policy (RFC 7496) MUST also be supported. Zero retransmissions combined with unordered delivery provides a UDP-like per-message service.
The PPIDs WebRTC String (51), WebRTC String Empty (56), WebRTC Binary (53), and WebRTC Binary Empty (57) MUST be used to signal message type. Empty messages must be sent as a one-zero-byte SCTP user message with the Empty PPID, and receivers MUST ignore the byte and treat it as an empty message.
The sender SHOULD disable the Nagle algorithm (RFC 1122) to minimize latency on data channels.
The stream reconfiguration extension defined in RFC 6525 MUST be supported; it is used for closing data channels by resetting SCTP streams.
When an ICE/UDP address change occurs, SCTP SHOULD be notified and SHOULD retest the Path MTU and reset the congestion state (congestion window and slow-start threshold) to initial values.
A data channel is realized as a pair of one incoming and one outgoing SCTP stream sharing the same SCTP stream identifier, providing bidirectional communication. Each channel has properties for reliability, ordering, priority (2-byte unsigned integer), optional label, and optional protocol.
During out-of-band data channel negotiation, stream identifiers are assigned based on DTLS role: the DTLS client picks even stream identifiers and the DTLS server picks odd stream identifiers.
The WebRTC data channel stack is SCTP over DTLS over ICE/UDP. SCTP provides data transport; DTLS provides confidentiality, authentication, and integrity; ICE/UDP provides NAT traversal. All can share a single UDP port with SRTP media.
RFC 8831 updates six entries in the IANA 'SCTP Payload Protocol Identifiers' registry (originally created by RFC 4960): WebRTC String (51), WebRTC Binary Partial/deprecated (52), WebRTC Binary (53), WebRTC String Partial/deprecated (54), WebRTC String Empty (56), and WebRTC Binary Empty (57).
Security considerations for WebRTC data channels are fully covered by RFC 8826 (Security Considerations for WebRTC) and RFC 8827 (WebRTC Security Architecture); this document adds no additional considerations. Implementations must be prepared for senders attempting to send arbitrarily large messages.
Data channel close sequence: (1) closing side resets its outgoing SCTP stream (RFC 6525); (2) peer detects incoming stream reset and resets its corresponding outgoing stream; (3) both resets complete and the channel is closed. Stream Sequence Numbers reset to zero and streams become available for reuse.
Because SCTP does not support empty user messages, an empty JavaScript string or binary value is encoded as a one-zero-byte SCTP user message carrying the appropriate Empty PPID (56 or 57). Receivers identify and discard the padding byte.
SCTP Payload Protocol Identifier (PPID) is a per-message field passed by the upper layer: WebRTC String=51, WebRTC Binary (Partial, deprecated)=52, WebRTC Binary=53, WebRTC String (Partial, deprecated)=54, WebRTC String Empty=56, WebRTC Binary Empty=57.