RFC 8831

WebRTC Data Channels

📅 published January 2021, from ietf

RFC 8831: WebRTC Data Channels 🎀

Okay bestie, this is RFC 8831, and it's called WebRTC Data Channels 🦋. It's a Standards Track document from the IETF, so it's the real deal and not an experiment 💅. It came out in January 2021 with ISSN 2070-1721 ✨. The authors are R. Jesup from Mozilla, S. Loreto from Ericsson, and M. Tüxen from Münster Univ. of Appl. Sciences 🫶. The title block doesn't list anything it obsoletes or updates, so there's no drama there 🙈.

Abstract ✨

So WebRTC is the framework that lets two browsers have direct, interactive, rich calls with audio, video, and data 💖. This doc zooms in on the non-media data side of things. It gives you the big-picture tour of how SCTP (Stream Control Transmission Protocol) works as a generic transport, so browsers can swap generic data peer to peer 🦋.

Status of This Memo 📜

This is an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force (IETF) 🌸. It represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). If you want more info on Internet Standards, check out Section 2 of RFC 7841.

Info about the current status of this document, any errata, and how to send feedback lives at https://www.rfc-editor.org/info/rfc8831 🔗.

Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the date of publication 📚. Please read these carefully, because they describe your rights and restrictions for this document. Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License 💜.

Table of Contents 🧚

1.  Introduction
2.  Conventions
3.  Use Cases
  3.1.  Use Cases for Unreliable Data Channels
  3.2.  Use Cases for Reliable Data Channels
4.  Requirements
5.  SCTP over DTLS over UDP Considerations
6.  The Usage of SCTP for Data Channels
  6.1.  SCTP Protocol Considerations
  6.2.  SCTP Association Management
  6.3.  SCTP Streams
  6.4.  Data Channel Definition
  6.5.  Opening a Data Channel
  6.6.  Transferring User Data on a Data Channel
  6.7.  Closing a Data Channel
7.  Security Considerations
8.  IANA Considerations
9.  References
  9.1.  Normative References
  9.2.  Informative References
Acknowledgements
Authors' Addresses

1. Introduction ✨

In WebRTC, a conversation is made of two kinds of stuff: media (like audio and video) and non-media data 🎀. Media rides on SRTP (Secure Real-time Transport Protocol), and this doc doesn't go any further into that. Non-media data is handled by SCTP [RFC4960], which gets encapsulated in DTLS. DTLS 1.0 is defined in [RFC4347]. The current latest version, DTLS 1.2, is defined in [RFC6347]. And an upcoming version, DTLS 1.3, is defined in [TLS-DTLS13] 🔥.

                               +----------+
                               |   SCTP   |
                               +----------+
                               |   DTLS   |
                               +----------+
                               | ICE/UDP  |
                               +----------+

                       Figure 1: Basic Stack Diagram

So the stack goes SCTP wrapped in DTLS (see [RFC8261]), and that gets wrapped over ICE/UDP (see [RFC8445]) 🦋. Put together, that's a NAT traversal solution that also gives you confidentiality, source authentication, and integrity-protected transfers 🔐✨. This data transport service runs in parallel with the SRTP media transports, and eventually all of them can share one single UDP port number 💅.

Now let's talk about SCTP itself 🧚. SCTP, as specified in [RFC4960], comes with the partial reliability extension (PR-SCTP) defined in [RFC3758] and the extra policies defined in [RFC7496]. It gives you multiple streams natively, with reliable delivery modes and the relevant partially reliable ones for user messages 🌈. The reconfiguration extension defined in [RFC6525] lets you increase the number of streams during the lifetime of an SCTP association, and it also lets individual SCTP streams get reset 🔄. Then [RFC8260] lets large messages get interleaved so one big message can't hog everything 🙅‍♀️, and it adds support for prioritizing SCTP streams 👑.

Here's the roadmap for the rest of the doc 🗺️: Sections 3 and 4 cover use cases and requirements for both unreliable and reliable peer-to-peer data channels. Section 5 talks about SCTP over DTLS over UDP. Section 6 specifies how SCTP should be used by the WebRTC protocol framework to transport non-media data between web browsers 💖.

2. Conventions 🫶

Here's the important bit. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174], but only when they appear in all capitals, just like shown here 👀.

3. Use Cases 🦋

This section is all about use cases specific to data channels. Please note that this section is informational only.

3.1. Use Cases for Unreliable Data Channels 🎮

U-C 1: Picture a real-time game where position and object state info gets sent over one or more unreliable data channels. Heads up: at any moment there may not be any SRTP media channels, or all of them may be inactive, and there may also be reliable data channels in use.

U-C 2: Giving a user non-critical info about why a state changed during a video chat or conference, like someone's mute state 🔇.

3.2. Use Cases for Reliable Data Channels 💜

U-C 3: A real-time game where critical state information needs to get transferred, like control information 🕹️. That kind of game may have no SRTP media channels at all, or they may be inactive at any given time, or they may only get added because of in-game actions.

U-C 4: Non-real-time file transfers between people chatting 📁. This may involve a large number of files moving sequentially or in parallel, like when you share a folder of images or a directory of files 🖼️.

U-C 5: Real-time text chat during an audio and/or video call, whether it's with one person or with multiple people in a conference 💬.

U-C 6: Renegotiating the configuration of the PeerConnection 🔧.

U-C 7: Proxy browsing, where a browser uses data channels of a PeerConnection to send and receive HTTP/HTTPS requests and data. For example, that could be used to get around local Internet filtering or monitoring 🕵️‍♀️.

4. Requirements 🍓

This section lists the requirements for Peer-to-Peer (P2P) data channels between two browsers. Please note that this section is informational only.

Req. 1: Multiple simultaneous data channels must be supported. There may be zero or more SRTP media streams running alongside the data channels in the same PeerConnection, and the number and state (active/inactive) of those SRTP media streams may change at any time 🌊.

Req. 2: Both reliable and unreliable data channels must be supported 💖.

Req. 3: Data channels of a PeerConnection must be congestion controlled, either individually, as a class, or together with the SRTP media streams of the PeerConnection 🚦. This makes sure that data channels don't cause congestion problems for those SRTP media streams, and that the WebRTC PeerConnection doesn't cause excessive problems when it runs in parallel with TCP connections 🧁.

Req. 4: The application should be able to provide guidance on the relative priority of each data channel, both relative to each other and relative to the SRTP media streams. This will interact with the congestion control algorithms 👑.

Req. 5: Data channels must be secured, which allows for confidentiality, integrity, and source authentication 🔐. See [RFC8826] and [RFC8827] for detailed info.

Req. 6: Data channels must provide message fragmentation support, so IP-layer fragmentation can be avoided no matter how large a message the JavaScript application passes in to be sent 📦. It also must make sure that large data channel transfers don't unduly delay traffic on other data channels 🙏.

Req. 7: The data channel transport protocol must not encode local IP addresses inside its protocol fields. Doing so reveals potentially private information, and it leads to failure if the address is depended upon 🙈.

Req. 8: The data channel transport protocol should support unbounded-length "messages" (i.e., a virtual socket stream) at the application layer, for things like image-file-transfer. Implementations might enforce a reasonable message size limit 🖼️.

Req. 9: The data channel transport protocol should avoid IP fragmentation 🧩. It must support Path MTU (PMTU) discovery, and it must not rely on ICMP or ICMPv6 being generated or being passed back, especially for PMTU discovery 🛰️.

Req. 10: It must be possible to implement the protocol stack in the user application space 🧚.

5. SCTP over DTLS over UDP Considerations ✨

okay bestie, this section is where SCTP gets its WebRTC glow-up 💅 Here are the features that matter most in the WebRTC context 🦋

  • Usage of TCP-friendly congestion control. 🌸
  • modifiable congestion control for integration with the SRTP media stream congestion control. 💜
  • Support of multiple unidirectional streams, each providing its own notion of ordered message delivery. 🧚
  • Support of ordered and out-of-order message delivery. ✨
  • Support of arbitrarily large user messages by providing fragmentation and reassembly. 🔥
  • Support of PMTU discovery. 🌈
  • Support of reliable or partially reliable message transport. 👑

The WebRTC data channel mechanism does not support SCTP multihoming 🙈 So SCTP just acts like it's running on a single-homed host, because that's the abstraction the DTLS layer gives it. DTLS is a connection-oriented, unreliable datagram service, so that's the vibe it's working with 🎀

The encapsulation of SCTP over DTLS defined in [RFC8261] gives you confidentiality, source authentication, and integrity-protected transfers 🔒💖 Running DTLS over UDP together with Interactive Connectivity Establishment (ICE) [RFC8445] lets things get through middleboxes in both IPv4- and IPv6-based networks, which is so iconic 🦋 SCTP as specified in [RFC4960] MUST be used together with the extension defined in [RFC3758], and it gives you these features for moving non-media data between browsers 💅

  • Support of multiple unidirectional streams. 🌸
  • Ordered and unordered delivery of user messages. ✨
  • Reliable and partially reliable transport of user messages. 🫶

Every SCTP user message carries a Payload Protocol Identifier (PPID) 🧚 The upper layer hands it to SCTP on the sending side, and the receiving side gets it back from SCTP. The PPID can be used to multiplex and demultiplex multiple upper layers over a single SCTP association, which is giving multitasking 💜 In WebRTC, the PPID tells apart UTF-8 encoded user data, binary-encoded user data, and the Data Channel Establishment Protocol (DCEP) defined in [RFC8832] 🎀 Heads up: the PPID is not accessible via the JavaScript API 🙈

Put the SCTP-over-DTLS encapsulation together with the SCTP features above, and it satisfies all the requirements listed in Section 4 🏆

The layering of protocols for WebRTC looks like this, as shown in Figure 2 🌈

                             +------+------+------+
                             | DCEP | UTF-8|Binary|
                             |      | Data | Data |
                             +------+------+------+
                             |        SCTP        |
                   +----------------------------------+
                   | STUN | SRTP |        DTLS        |
                   +----------------------------------+
                   |                ICE               |
                   +----------------------------------+
                   | UDP1 | UDP2 | UDP3 | ...         |
                   +----------------------------------+

                      Figure 2: WebRTC Protocol Layers

This stack is chosen over DTLS over SCTP [RFC6083] and over SCTP over UDP [RFC6951], and it's especially bold compared to those 😎 Here's why:

  • supports the transmission of arbitrarily large user messages; 🔥
  • shares the DTLS connection with the SRTP media channels of the PeerConnection; and 💞
  • provides privacy for the SCTP control information. 🔐

Now for the protocol stack in Figure 2, here's the receipts 🧾

  • the usage of DTLS 1.0 over UDP is specified in [RFC4347]; 🌸
  • the usage of DTLS 1.2 over UDP is specified in [RFC6347]; 💜
  • 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 demultiplexing STUN [RFC5389], SRTP, and DTLS is done as described in Section 5.1.2 of [RFC5764], and SCTP is the only payload of DTLS 🧚 Since DTLS usually lives in user application space, the SCTP stack needs to be a user application space stack too 💅

The ICE/UDP layer can handle IP address changes during a session without needing to bother the DTLS and SCTP layers, which is so smooth 🌊 However, SCTP SHOULD be notified when an address change has happened 🔔 In that case, SCTP SHOULD retest the Path MTU and reset the congestion state to the initial state 🔄 For window-based congestion control like the one specified in [RFC4960], this means setting the congestion window and slow-start threshold back to their initial values 🫶

Incoming ICMP or ICMPv6 messages can't be processed by the SCTP layer, since there's no way to identify the corresponding association 😭 So SCTP MUST support performing Path MTU discovery without relying on ICMP or ICMPv6, as specified in [RFC4821], by using the probing messages specified in [RFC4820] 💪 The initial Path MTU at the IP layer SHOULD NOT exceed 1200 bytes for IPv4 and 1280 bytes for IPv6 📏

In general, the lower-layer interface of an SCTP implementation should be adapted to deal with the differences between IPv4 and IPv6 (being connectionless) or DTLS (being connection oriented) 🧩

When the protocol stack in Figure 2 is used, DTLS protects the complete SCTP packet, so you get confidentiality, integrity, and source authentication for the whole packet 🔐💖

SCTP provides congestion control on a per-association basis 🌈 That means all SCTP streams inside a single SCTP association share the same congestion window 🪟 Traffic not sent over SCTP isn't covered by SCTP congestion control. Using a congestion control different from the standard one might improve the impact on the parallel SRTP media streams 🎶

SCTP uses the same port number concept as TCP and UDP, so an SCTP association uses two port numbers, one at each SCTP endpoint 🔢✨

6. The Usage of SCTP for Data Channels 🎀

6.1. SCTP Protocol Considerations 💅

The DTLS encapsulation of SCTP packets, as described in [RFC8261], MUST be used 🔒

This SCTP stack and its upper layer MUST support the usage of multiple SCTP streams 🌸 A user message can be sent ordered or unordered, and with partial or full reliability 🦋

The following SCTP protocol extensions are required 📋

  • The stream reconfiguration extension defined in [RFC6525] MUST be supported. It's used for closing channels. 🚪
  • The dynamic address reconfiguration extension defined in [RFC5061] MUST be used to signal the support of the stream reset extension defined in [RFC6525]. Other features of [RFC5061] are OPTIONAL. 🔁
  • The partial reliability extension defined in [RFC3758] MUST be supported. On top of the timed reliability PR-SCTP policy defined in [RFC3758], the limited retransmission policy defined in [RFC7496] MUST be supported too. Limiting the number of retransmissions to zero, combined with unordered delivery, gives you a UDP-like service where each user message is sent exactly once and delivered in the order received 🚀

The support for message interleaving as defined in [RFC8260] SHOULD be used 🎶

6.2. SCTP Association Management 🤝

In WebRTC, the SCTP association gets set up once the two endpoints of the PeerConnection agree to open it. That agreement is negotiated through the JavaScript Session Establishment Protocol (JSEP), which is usually an exchange of the Session Description Protocol (SDP) [RFC8829] 💬 It uses the DTLS connection selected via ICE, and this is typically shared via BUNDLE or an equivalent with the DTLS connections used to key the SRTP media streams 🧃

The number of streams negotiated during SCTP association setup SHOULD be 65535, which is the maximum number of streams that can be negotiated during association setup 🔢👑

SCTP supports two ways of ending an SCTP association 🚦 The first is graceful, where a procedure makes sure no messages are lost during shutdown. The second is non-graceful, where one side can just abort the association 💥

Each SCTP endpoint keeps an eye on its peer's reachability by monitoring the number of retransmissions of user messages and test messages 👀 If there are excessive retransmissions, the association gets terminated in a non-graceful way 😬

If an SCTP association closes gracefully, all of its data channels close too 🌙 With a non-graceful teardown, all data channels also close, but an error indication SHOULD be provided if possible ⚠️

6.3. SCTP Streams 🌊

SCTP defines a stream as a unidirectional logical channel that exists within an SCTP association to another SCTP endpoint 🛤️ Streams give you the notion of in-sequence delivery and let you multiplex 🧶 Each user message is sent on a particular stream, either ordered or unordered. Ordering is only preserved for ordered messages sent on the same stream 📜

6.4. Data Channel Definition 🎀

Data channels are defined so their application-level API can closely mirror the WebSockets API 🪞 That means bidirectional streams of data plus a textual field called 'label' that identifies what the data channel is for 🏷️

A data channel is realized as a pair of one incoming stream and one outgoing SCTP stream that have the same SCTP stream identifier 🧵 How these identifiers get selected is protocol and implementation dependent 🤷‍♀️ This is what allows bidirectional communication 🔁

Each data channel also has these properties in each direction 💜

  • reliable or unreliable message transmission: In case of unreliable transmissions, the same level of unreliability is used. Note that, in SCTP, this is a property of an SCTP user message and not of an SCTP stream. 🎲
  • in-order or out-of-order message delivery for message sent: Note that, in SCTP, this is a property of an SCTP user message and not of an SCTP stream. 📬
  • a priority, which is a 2-byte unsigned integer: These priorities MUST be interpreted as weighted-fair-queuing scheduling priorities per the definition of the corresponding stream scheduler supporting interleaving in [RFC8260]. For use in WebRTC, the values used SHOULD be one of 128 ("below normal"), 256 ("normal"), 512 ("high"), or 1024 ("extra high"). 🥇
  • an optional label. 🏷️
  • an optional protocol. 📎

Note that for a data channel negotiated with the protocol specified in [RFC8832], all of the above properties are the same in both directions 🫶💖

6.5. Opening a Data Channel 🎀

okay so bestie, data channels can get opened in two ways 💖 either in-band (negotiated inside the SCTP association itself) or out-of-band 🦋. out-of-band negotiation is basically any method that gets both sides to agree on a channel's parameters AND actually create it ✨. the details of that are out of scope for this doc, so don't come for me on that one 🙈. the big rule is that the apps using data channels need to use the same negotiation method consistently on BOTH endpoints 🫶

a simple protocol for in-band negotiation is specified in [RFC8832] 🧚

okay now for out-of-band 💅. when one side wants to open a channel this way, it picks a stream 🌸. unless something else is defined or negotiated, the streams get picked based on the DTLS role: the client picks the even stream identifiers and the server picks the odd ones 👑. BUT the application is responsible for avoiding collisions with existing streams 😭. if it tries to reuse a stream that's already part of an existing data channel, the addition MUST fail 💀. on top of picking a stream, the application SHOULD also figure out the options it'll use for sending messages ✨. and the application MUST make sure, in an application-specific way, that the app on the peer side ALSO knows which stream is being used AND what the sending options are from this side 🫶🔥

6.6. Transferring User Data on a Data Channel 🦋

all data sent on a data channel, in both directions, MUST be sent over the underlying stream using the reliability that was defined when the channel got opened 💜. the only exception is if the options get changed or a higher level specifies per-message options 🍓

SCTP is message-oriented, which is how it keeps message boundaries of user messages intact 🌈. so senders MUST NOT put more than one application message into a single SCTP user message 🙅‍♀️. unless the deprecated PPID-based fragmentation and reassembly is being used, the sender MUST include exactly one application message in each SCTP user message 💅

the SCTP Payload Protocol Identifiers (PPIDs) are how we signal how to interpret the "payload data" ✨. the following PPIDs MUST be used (see Section 8) 🎀:

  • WebRTC String: identifies a non-empty JavaScript string encoded in UTF-8 💖
  • WebRTC String Empty: identifies an empty JavaScript string encoded in UTF-8 🌸
  • WebRTC Binary: identifies non-empty JavaScript binary data (ArrayBuffer, ArrayBufferView, or Blob) 🦋
  • WebRTC Binary Empty: identifies empty JavaScript binary data (ArrayBuffer, ArrayBufferView, or Blob) 🧚

okay the empty situation is a bit funny 😭. SCTP doesn't support sending empty user messages at all, so if you need to send an empty message, you use the matching empty PPID (WebRTC String Empty or WebRTC Binary Empty) and send an SCTP user message that's one zero byte long 🫶. when the receiver gets an SCTP user message with one of these PPIDs, it MUST ignore that SCTP user message and process it as an empty message 💅✨

the "WebRTC String Partial" and "WebRTC Binary Partial" PPIDs are deprecated now 🥀. they used to do PPID-based fragmentation and reassembly for user messages on reliable and ordered data channels 🕰️

if a receiver gets a message with a PPID it doesn't support, OR it spots some error related to the message (like illegal ordering, for example) 🚨, the receiver SHOULD close the corresponding data channel 💀. the big takeaway here is that extensions using extra PPIDs can't be used without negotiating them first 🙅‍♀️

the base SCTP protocol in [RFC4960] doesn't support interleaving user messages 😬. that means sending a big user message can totally monopolize the SCTP association 🐘. to fix that, [RFC8260] defines an extension that adds message interleaving, and it SHOULD be used 🌟. until message interleaving is supported, the sender SHOULD limit the maximum message size to 16 KB so nothing gets monopolized 🛡️

it's recommended to keep message size within certain bounds, because applications won't be able to handle arbitrarily large single messages 🙈. this limit has to be negotiated, for example by using [RFC8841] 🤝

the sender SHOULD disable the Nagle algorithm (see [RFC1122]) to keep latency low ⚡

6.7. Closing a Data Channel 🌙

closing a data channel MUST be signaled by resetting the corresponding outgoing streams [RFC6525] 💌. so if one side decides to close the channel, it resets its corresponding outgoing stream 🥺. when the peer sees that an incoming stream got reset, it resets its corresponding outgoing stream too 🪞. once that's all done, the data channel is closed ✅. resetting a stream sets the Stream Sequence Numbers (SSNs) of the stream back to 'zero', with a notification going up to the application layer that the reset happened 🔁. streams are available for reuse after a reset has been performed 🫧

[RFC6525] also guarantees that all the messages are delivered (or abandoned) before the stream gets reset 📦

  1. Security Considerations 🔒

okay this section is lowkey serious, bestie 🚨. this document doesn't add any extra considerations on top of the ones given in [RFC8826] and [RFC8827] 📚

but here's the thing: a receiver MUST be prepared for a sender that tries to send arbitrarily large messages 😱💀. like, be ready for it, no excuses 🛑

  1. IANA Considerations 📋

this document uses six already registered SCTP Payload Protocol Identifiers (PPIDs): "DOMString Last", "Binary Data Partial", "Binary Data Last", "DOMString Partial", "WebRTC String Empty", and "WebRTC Binary Empty" 🎟️. [RFC4960] created the "SCTP Payload Protocol Identifiers" registry that these were assigned from 🗂️. IANA has updated the reference of these six assignments to point to this document, and changed the names of the first four PPIDs 🔄. the dates stay the same 📅

the six assignments have been updated to read:

+======================+===========+===========+============+
| Value                | SCTP PPID | Reference | Date       |
+======================+===========+===========+============+
| WebRTC String        | 51        | RFC 8831  | 2013-09-20 |
+----------------------+-----------+-----------+------------+
| WebRTC Binary        | 52        | RFC 8831  | 2013-09-20 |
| Partial (deprecated) |           |           |            |
+----------------------+-----------+-----------+------------+
| WebRTC Binary        | 53        | RFC 8831  | 2013-09-20 |
+----------------------+-----------+-----------+------------+
| WebRTC String        | 54        | RFC 8831  | 2013-09-20 |
| Partial (deprecated) |           |           |            |
+----------------------+-----------+-----------+------------+
| WebRTC String Empty  | 56        | RFC 8831  | 2014-08-22 |
+----------------------+-----------+-----------+------------+
| WebRTC Binary Empty  | 57        | RFC 8831  | 2014-08-22 |
+----------------------+-----------+-----------+------------+

Table 1 ✨

  1. References 📚

9.1. Normative References 🌟

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119,
           DOI 10.17487/RFC2119, March 1997,
           <https://www.rfc-editor.org/info/rfc2119>.

[RFC3758]  Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P.
           Conrad, "Stream Control Transmission Protocol (SCTP)
           Partial Reliability Extension", RFC 3758,
           DOI 10.17487/RFC3758, May 2004,
           <https://www.rfc-editor.org/info/rfc3758>.

[RFC4820]  Tuexen, M., Stewart, R., and P. Lei, "Padding Chunk and
           Parameter for the Stream Control Transmission Protocol
           (SCTP)", RFC 4820, DOI 10.17487/RFC4820, March 2007,
           <https://www.rfc-editor.org/info/rfc4820>.

[RFC4821]  Mathis, M. and J. Heffner, "Packetization Layer Path MTU
           Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007,
           <https://www.rfc-editor.org/info/rfc4821>.

[RFC4960]  Stewart, R., Ed., "Stream Control Transmission Protocol",
           RFC 4960, DOI 10.17487/RFC4960, September 2007,
           <https://www.rfc-editor.org/info/rfc4960>.

[RFC5061]  Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M.
           Kozuka, "Stream Control Transmission Protocol (SCTP)
           Dynamic Address Reconfiguration", RFC 5061,
           DOI 10.17487/RFC5061, September 2007,
           <https://www.rfc-editor.org/info/rfc5061>.

[RFC6525]  Stewart, R., Tuexen, M., and P. Lei, "Stream Control
           Transmission Protocol (SCTP) Stream Reconfiguration",
           RFC 6525, DOI 10.17487/RFC6525, February 2012,
           <https://www.rfc-editor.org/info/rfc6525>.

[RFC7496]  Tuexen, M., Seggelmann, R., Stewart, R., and S. Loreto,
           "Additional Policies for the Partially Reliable Stream
           Control Transmission Protocol Extension", RFC 7496,
           DOI 10.17487/RFC7496, April 2015,
           <https://www.rfc-editor.org/info/rfc7496>.

[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>.

[RFC8260]  Stewart, R., Tuexen, M., Loreto, S., and R. Seggelmann,
           "Stream Schedulers and User Message Interleaving for the
           Stream Control Transmission Protocol", RFC 8260,
           DOI 10.17487/RFC8260, November 2017,
           <https://www.rfc-editor.org/info/rfc8260>.

[RFC8261]  Tuexen, M., Stewart, R., Jesup, R., and S. Loreto,
           "Datagram Transport Layer Security (DTLS) Encapsulation of
           SCTP Packets", RFC 8261, DOI 10.17487/RFC8261, November
           2017, <https://www.rfc-editor.org/info/rfc8261>.

[RFC8445]  Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive
           Connectivity Establishment (ICE): A Protocol for Network
           Address Translator (NAT) Traversal", RFC 8445,
           DOI 10.17487/RFC8445, July 2018,
           <https://www.rfc-editor.org/info/rfc8445>.

[RFC8826]  Rescorla, E., "Security Considerations for WebRTC",
           RFC 8826, DOI 10.17487/RFC8826, January 2021,
           <https://www.rfc-editor.org/info/rfc8826>.

[RFC8827]  Rescorla, E., "WebRTC Security Architecture", RFC 8827,
           DOI 10.17487/RFC8827, January 2021,
           <https://www.rfc-editor.org/info/rfc8827>.

[RFC8829]  Uberti, J., Jennings, C., and E. Rescorla, Ed.,
           "JavaScript Session Establishment Protocol (JSEP)",
           RFC 8829, DOI 10.17487/RFC8829, January 2021,
           <https://www.rfc-editor.org/info/rfc8829>.

[RFC8832]  Jesup, R., Loreto, S., and M. Tüxen, "WebRTC Data Channel
           Establishment Protocol", RFC 8832, DOI 10.17487/RFC8832,
           January 2021, <https://www.rfc-editor.org/info/rfc8832>.

[RFC8841]  Holmberg, C., Shpount, R., Loreto, S., and G. Camarillo,
           "Session Description Protocol (SDP) Offer/Answer
           Procedures for Stream Control Transmission Protocol (SCTP)
           over Datagram Transport Layer Security (DTLS) Transport",
           RFC 8841, DOI 10.17487/RFC8841, January 2021,
           <https://www.rfc-editor.org/info/rfc8841>.

9.2. Informative References

okay bestie, this is the "if you want the backstory" list 📚✨ these aren't required to implement the spec, but they're the RFCs and drafts it leans on for context, so here they are, complete 💅

[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989, <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, "Session Traversal Utilities for NAT (STUN)", RFC 5389, DOI 10.17487/RFC5389, October 2008, <https://www.rfc-editor.org/info/rfc5389>.

[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)", RFC 5764, DOI 10.17487/RFC5764, May 2010, <https://www.rfc-editor.org/info/rfc5764>.

[RFC6083] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram Transport Layer Security (DTLS) for Stream Control Transmission Protocol (SCTP)", RFC 6083, DOI 10.17487/RFC6083, January 2011, <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 Control Transmission Protocol (SCTP) Packets for End-Host to End-Host Communication", RFC 6951, DOI 10.17487/RFC6951, May 2013, <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 🫶

huge thank-yous to everyone who sent comments, ideas, and text 💖 you're all absolute legends:

Harald Alvestrand, Richard Barnes, Adam Bergkvist, Alissa Cooper, Benoit Claise, Spencer Dawkins, Gunnar Hellström, Christer Holmberg, Cullen Jennings, Paul Kyzivat, Eric Rescorla, Adam Roach, Irene Rüngeler, Randall Stewart, Martin Stiemerling, Justin Uberti, and Magnus Westerlund.

Authors' Addresses 🦋

the people who wrote this thing 🎀

Randell Jesup
Mozilla
United States of America

Email: randell-ietf@jesup.org


Salvatore Loreto
Ericsson
Hirsalantie 11
FI-02420 Jorvas
Finland

Email: salvatore.loreto@ericsson.com


Michael Tüxen
Münster University of Applied Sciences
Stegerwaldstrasse 39
48565  Steinfurt
Germany

Email: tuexen@fh-muenster.de
📦 where this page comes from