RFC 6525

Stream Control Transmission Protocol (SCTP) Stream Reconfiguration 🦋

📜 RFC 6525, from the Internet Engineering Task Force (IETF), is a Standards Track document, so it's an official spec. It was written by R. Stewart (Adara Networks), M. Tuexen (Muenster Univ. of Appl. Sciences), and P. Lei (Cisco Systems, Inc.), and it's dated February 2012. Its ISSN is 2070-1721. The title block doesn't list any RFCs it obsoletes or updates. 💅

Abstract

okay so, a LOT of apps that run on SCTP want to be able to "reset" a stream 🌸 The whole goal is to set a stream's numbering sequence back to 'zero' and tell the app layer that the reset happened. 🫶 Why does anyone care? Apps want to reuse a stream for a different purpose but still use the sequence numbers to keep track of message flows. Without this feature, reusing an old stream means your message numbers come out higher than you expected, unless there's a protocol mechanism to "reset the streams back to zero." 😭 This doc also covers resetting the transmission sequence numbers, adding new streams, and resetting all the stream sequence numbers too. It's giving full toolkit ✨

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 has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.

Information about the current status of this document, any errata, and how to give feedback on it can be found at http://www.rfc-editor.org/info/rfc6525. 🔥

Copyright Notice

Copyright (c) 2012 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 🌈

Table of Contents 🧚

1. Introduction ....................................................3
2. Conventions .....................................................4
3. New Chunk Type ..................................................4
   3.1. RE-CONFIG Chunk ............................................5
4. New Parameter Types .............................................6
   4.1. Outgoing SSN Reset Request Parameter .......................7
   4.2. Incoming SSN Reset Request Parameter .......................8
   4.3. SSN/TSN Reset Request Parameter ............................9
   4.4. Re-configuration Response Parameter .......................10
   4.5. Add Outgoing Streams Request Parameter ....................12
   4.6. Add Incoming Streams Request Parameter ....................13
5. Procedures .....................................................14
   5.1. Sender-Side Procedures ....................................14
        5.1.1. Sender-Side Procedures for the RE-CONFIG Chunk .....14
        5.1.2. Sender-Side Procedures for the Outgoing SSN
               Reset Request Parameter ............................15
        5.1.3. Sender-Side Procedures for the Incoming SSN
               Reset Request Parameter ............................16
        5.1.4. Sender-Side Procedures for the SSN/TSN
               Reset Request Parameter ............................17
        5.1.5. Sender-Side Procedures for the Add Outgoing
               Streams Request Parameter ..........................17
        5.1.6. Sender-Side Procedures for the Add Incoming
               Streams Request Parameter ..........................17
        5.1.7. Sender-Side Procedures for the
               Re-configuration Response Parameter ................18

   5.2. Receiver-Side Procedures ..................................18
        5.2.1. Receiver-Side Procedures for the RE-CONFIG Chunk ...18
        5.2.2. Receiver-Side Procedures for the Outgoing
               SSN Reset Request Parameter ........................19
        5.2.3. Receiver-Side Procedures for the Incoming
               SSN Reset Request Parameter ........................20
        5.2.4. Receiver-Side Procedures for the SSN/TSN
               Reset Request Parameter ............................21
        5.2.5. Receiver-Side Procedures for the Add
               Outgoing Streams Request Parameter .................21
        5.2.6. Receiver-Side Procedures for the Add
               Incoming Streams Request Parameter .................22
        5.2.7. Receiver-Side Procedures for the
               Re-configuration Response Parameter ................22
6. Sockets API Considerations .....................................23
   6.1. Events ....................................................23
        6.1.1. Stream Reset Event .................................24
        6.1.2. Association Reset Event ............................25
        6.1.3. Stream Change Event ................................26
   6.2. Event Subscription ........................................27
   6.3. Socket Options ............................................27
        6.3.1. Enable/Disable Stream Reset
               (SCTP_ENABLE_STREAM_RESET) .........................28
        6.3.2. Reset Incoming and/or Outgoing Streams
               (SCTP_RESET_STREAMS) ...............................29
        6.3.3. Reset SSN/TSN (SCTP_RESET_ASSOC) ...................29
        6.3.4. Add Incoming and/or Outgoing Streams
               (SCTP_ADD_STREAMS) .................................30
7. Security Considerations ........................................30
8. IANA Considerations ............................................31
   8.1. A New Chunk Type ..........................................31
   8.2. Six New Chunk Parameter Types .............................31
9. Acknowledgments ................................................31
10. References ....................................................32
    10.1. Normative References .....................................32
    10.2. Informative References ...................................32
Appendix A. Examples of the Reconfiguration Procedures ............33

1. Introduction ✨

Lots of apps that use SCTP as defined in [RFC4960] want to "reset" a stream 💖 Resetting a stream means setting its Stream Sequence Numbers (SSNs) back to 'zero' and letting the application layer know the reset happened. Apps want to "reuse" streams for different purposes but still use the SSN so they can track message flows. Without this feature, a reused stream would give you message numbers that are higher than expected, unless there's a protocol mechanism to "reset the streams back to zero." This document also covers resetting the Transmission Sequence Numbers (TSNs), adding more streams, and resetting all SSNs. 🌸

The sockets API for SCTP defined in [RFC6458] exposes the sequence numbers SCTP uses for user message transfer, so app writers can actually use resetting them. Heads up though: the matching sequence number for TCP isn't exposed through the TCP sockets API. 🙈

2. Conventions 💜

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

3. New Chunk Type 🎀

This section defines the new chunk type that gets used to reconfigure streams. Table 1 shows the new chunk type:

          +------------+------------------------------------+
          | Chunk Type | Chunk Name                         |
          +------------+------------------------------------+
          | 130        | Re-configuration Chunk (RE-CONFIG) |
          +------------+------------------------------------+

                                Table 1

It's worth noting that the RE-CONFIG chunk's format requires that the receiver ignore the chunk if it doesn't understand it and keep processing all the chunks that follow. This works through the upper bits of the chunk type, as described in Section 3.2 of [RFC4960]. 🦋

All transported integer numbers are in "network byte order", a.k.a. Big Endian. 🍓

3.1. RE-CONFIG Chunk 🌈

This document adds one new chunk type to SCTP, and the chunk has the following format:

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 130    |  Chunk Flags  |      Chunk Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\                                                               \
/                  Re-configuration Parameter                   /
\                                                               \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\                                                               \
/             Re-configuration Parameter (optional)             /
\                                                               \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Here's what each field does:

• Chunk Type: 1 byte (unsigned integer). This field holds the IANA-defined chunk type for the RE-CONFIG chunk. The value of this field is 130. 🍒
• Chunk Flags: 1 byte (unsigned integer). The sender sets this field to 0, and the receiver ignores it. 🫧
• Chunk Length: 2 bytes (unsigned integer). This field holds the length of the chunk in bytes, including the Chunk Type, Chunk Flags, and Chunk Length. 📏
• Re-configuration Parameter: This field holds a Re-configuration Request Parameter or a Re-configuration Response Parameter. 💌

Note that each RE-CONFIG chunk holds at least one parameter and at most two parameters. Only these combinations are allowed:

1. Outgoing SSN Reset Request Parameter.
2. Incoming SSN Reset Request Parameter.
3. Outgoing SSN Reset Request Parameter, Incoming SSN Reset Request Parameter.
4. SSN/TSN Reset Request Parameter.
5. Add Outgoing Streams Request Parameter.
6. Add Incoming Streams Request Parameter.
7. Add Outgoing Streams Request Parameter, Add Incoming Streams Request Parameter.
8. Re-configuration Response Parameter.
9. Re-configuration Response Parameter, Outgoing SSN Reset Request Parameter.
10. Re-configuration Response Parameter, Re-configuration Response Parameter.

🚨 If a sender transmits an unsupported combination, the receiver SHOULD send an ERROR chunk with a Protocol Violation cause, as defined in Section 3.3.10.13 of [RFC4960]).

4. New Parameter Types ✨

okay bestie, this section is where we meet the new parameter types that live inside the RE-CONFIG chunk 🎀 Table 2 has the whole lineup:

+----------------+----------------------------------------+
| Parameter Type | Parameter Name                         |
+----------------+----------------------------------------+
| 13             | Outgoing SSN Reset Request Parameter   |
| 14             | Incoming SSN Reset Request Parameter   |
| 15             | SSN/TSN Reset Request Parameter        |
| 16             | Re-configuration Response Parameter    |
| 17             | Add Outgoing Streams Request Parameter |
| 18             | Add Incoming Streams Request Parameter |
+----------------+----------------------------------------+

                                  Table 2

ngl this next bit is important 👀 the parameter format says that if a receiver doesn't recognize a parameter type, it has to stop processing that parameter AND any other parameters after it in the chunk 🛑 This is done with the upper bits of the parameter type, which you can read about in Section 3.2.1 of [RFC4960] 🧚

All transported integer numbers are in "network byte order", a.k.a. Big Endian 🍓

4.1. Outgoing SSN Reset Request Parameter

this parameter is the sender asking for a reset of some or all of its outgoing streams 💅

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Parameter Type = 13       | Parameter Length = 16 + 2 * N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Re-configuration Request Sequence Number            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Re-configuration Response Sequence Number           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                Sender's Last Assigned TSN                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Stream Number 1 (optional)   |    Stream Number 2 (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/                            ......                             /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Stream Number N-1 (optional) |    Stream Number N (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Parameter Type: 2 bytes (unsigned integer). This field holds the IANA-defined parameter type for the Outgoing SSN Reset Request Parameter. The value of this field is 13.

Parameter Length: 2 bytes (unsigned integer). This field holds the length in bytes of the parameter. The value MUST be 16 + 2 * N, where N is the number of stream numbers listed.

Re-configuration Request Sequence Number: 4 bytes (unsigned integer). This field is used to identify the request. It's a monotonically increasing number that starts at the same value as the initial TSN. It goes up by 1 whenever a new Re-configuration Request Parameter is sent. 📈

Re-configuration Response Sequence Number: 4 bytes (unsigned integer). When this Outgoing SSN Reset Request Parameter is sent in response to an Incoming SSN Reset Request Parameter, this parameter is also an implicit response to the incoming request 🫶 In that case, this field holds the Re-configuration Request Sequence Number of the incoming request. In other cases, it holds the next expected Re-configuration Request Sequence Number minus 1.

Sender's Last Assigned TSN: 4 bytes (unsigned integer). This value holds the next TSN minus 1. In other words, it's the last TSN that this sender assigned 🎯

Stream Number 1..N: 2 bytes (unsigned integer). This field is optional. If it's included, it's used to point at the specific streams that are to be reset. If no streams are listed, then all streams are to be reset 👑

This parameter can appear in a RE-CONFIG chunk. This parameter MUST NOT appear in any other chunk type. 🙅‍♀️

4.2. Incoming SSN Reset Request Parameter

this one is the sender asking the peer to reset some or all of its outgoing streams 🔁

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Parameter Type = 14       |  Parameter Length = 8 + 2 * N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Re-configuration Request Sequence Number             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Stream Number 1 (optional)   |    Stream Number 2 (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/                            ......                             /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Stream Number N-1 (optional) |    Stream Number N (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Parameter Type: 2 bytes (unsigned integer). This field holds the IANA-defined parameter type for the Incoming SSN Reset Request Parameter. The value of this field is 14.

Parameter Length: 2 bytes (unsigned integer). This field holds the length in bytes of the parameter. The value MUST be 8 + 2 * N.

Re-configuration Request Sequence Number: 4 bytes (unsigned integer). This field is used to identify the request. It's a monotonically increasing number that starts at the same value as the initial TSN. It goes up by 1 whenever a new Re-configuration Request Parameter is sent. 📈

Stream Number 1..N: 2 bytes (unsigned integer). This field is optional. If it's included, it's used to point at the specific streams that are to be reset. If no streams are listed, then all streams are to be reset 👑

This parameter can appear in a RE-CONFIG chunk. This parameter MUST NOT appear in any other chunk type. 🙅‍♀️

4.3. SSN/TSN Reset Request Parameter

this parameter is the sender asking for a reset of the TSN and SSN numbering across all incoming and outgoing streams, so it's a big one 💥

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Parameter Type = 15       |      Parameter Length = 8     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Re-configuration Request Sequence Number              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Parameter Type: 2 bytes (unsigned integer). This field holds the IANA-defined parameter type for the SSN/TSN Reset Request Parameter. The value of this field is 15.

Parameter Length: 2 bytes (unsigned integer). This field holds the length in bytes of the parameter. The value MUST be 8.

Re-configuration Request Sequence Number: 4 bytes (unsigned integer). This field is used to identify the request. It's a monotonically increasing number that starts at the same value as the initial TSN. It goes up by 1 whenever a new Re-configuration Request Parameter is sent. 📈

This parameter can appear in a RE-CONFIG chunk. This parameter MUST NOT appear in any other chunk type. 🙅‍♀️

4.4. Re-configuration Response Parameter

this is the reply 💌 the receiver of a Re-configuration Request Parameter uses this one to respond to the request.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Parameter Type = 16       |      Parameter Length         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Re-configuration Response Sequence Number             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            Result                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   Sender's Next TSN (optional)                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                  Receiver's Next TSN (optional)               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Parameter Type: 2 bytes (unsigned integer). This field holds the IANA-defined parameter type for the Re-configuration Response Parameter. The value of this field is 16.

Parameter Type Length: 2 bytes (unsigned integer). This field holds the length in bytes of the parameter. The value MUST be 12 if the optional fields are not present, and 20 otherwise.

Re-configuration Response Sequence Number: 4 bytes (unsigned integer). This value is copied from the request parameter. The receiver of the Re-configuration Response Parameter uses it to tie the response back to the request 🧵

Result: 4 bytes (unsigned integer). This value describes the result of the processing of the request. It's encoded as shown in Table 3 📋

+--------+-------------------------------------+
| Result | Description                         |
+--------+-------------------------------------+
| 0      | Success - Nothing to do             |
| 1      | Success - Performed                 |
| 2      | Denied                              |
| 3      | Error - Wrong SSN                   |
| 4      | Error - Request already in progress |
| 5      | Error - Bad Sequence Number         |
| 6      | In progress                         |
+--------+-------------------------------------+

                                  Table 3

Sender's Next TSN: 4 bytes (unsigned integer). This field holds the TSN that the sender of the response will use to send the next DATA chunk. The field is only applicable in responses to SSN/TSN reset requests.

Receiver's Next TSN: 4 bytes (unsigned integer). This field holds the TSN that the receiver of the response MUST use to send the next DATA chunk. The field is only applicable in responses to SSN/TSN reset requests.

Either both optional fields (Sender's Next TSN and Receiver's Next TSN) MUST be present, or no field. 🫧

This parameter can appear in a RE-CONFIG chunk. This parameter MUST NOT appear in any other chunk type. 🙅‍♀️

4.5. Add Outgoing Streams Request Parameter ✨

okay so this one is how the sender asks for more outgoing streams to be added to the association, which means more incoming streams on the receiver's side 🌊 it's giving "I need more lanes, please and thank you" 💅

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Parameter Type = 17       |      Parameter Length = 12    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Re-configuration Request Sequence Number             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Number of new streams    |         Reserved              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Parameter Type (2 bytes, unsigned integer) 🎀 This is the IANA-defined type for the Add Outgoing Streams Request Parameter, and it's 17 🔢

Parameter Length (2 bytes, unsigned integer) 📏 This tells you how many bytes the whole parameter is, and the value MUST be 12. no wiggle room bestie 🙈

Re-configuration Request Sequence Number (4 bytes, unsigned integer) 🔁 This is how the request gets identified. It's a monotonically increasing number, starting at the same value as the initial TSN, and it goes up by 1 every time a brand new Re-configuration Request Parameter gets sent. very organized, very iconic 🧚

Number of new streams (2 bytes, unsigned integer) 🌸 This is how many extra outgoing streams the sender wants added. The new streams come in order and they're consecutive, so if the association has 4 outgoing streams (0-3) and you ask for 3 more, you get 4, 5, and 6. literally a lil queue of streams 🦋

Reserved (2 bytes, unsigned integer) 🫧 This field is reserved. The sender SHOULD set it to 0, and the receiver SHOULD ignore it. (the receiver is supposed to ignore it, so no drama there 💜)

This parameter MAY show up in a RE-CONFIG chunk. It MUST NOT show up in any other chunk type. ngl that's a strict guest list 💅

---

4.6. Add Incoming Streams Request Parameter 🌈

this one is kind of the mirror image: the sender asks the peer to add more outgoing streams, which are the sender's incoming streams 🪞 main character energy, but make it symmetrical 🫶

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Parameter Type = 18       |      Parameter Length = 12    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Re-configuration Request Sequence Number             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Number of new streams    |         Reserved              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Parameter Type (2 bytes, unsigned integer) 🎀 This is the IANA-defined type for the Add Incoming Streams Request Parameter, and the value is 18 🔢

Parameter Length (2 bytes, unsigned integer) 📏 The length in bytes of the parameter, and the value MUST be 12. lock it in 🔒

Re-configuration Request Sequence Number (4 bytes, unsigned integer) 🔁 It identifies the request. It's a monotonically increasing number that starts at the same value as the initial TSN and goes up by 1 each time a new Re-configuration Request Parameter is sent. same energy as before, consistent queen behaviour 👑

Number of new streams (2 bytes, unsigned integer) 🌸 This is how many extra incoming streams the sender wants added to the association. They're added in order and they're consecutive. same example as above: 4 outgoing streams (0-3) plus 3 more gives you 4, 5, and 6 🦋

Reserved (2 bytes, unsigned integer) 🫧 Reserved. The sender SHOULD set it to 0, and the receiver SHOULD ignore it. 💖

This parameter MAY show up in a RE-CONFIG chunk. It MUST NOT show up in any other chunk type. bouncer vibes again 🚪

---

5. Procedures 🧠

okay this section is the rulebook for both the sender and the receiver of a RE-CONFIG chunk 📖 there are examples of the re-configuration scenarios in Appendix A, so go peek there if you want to see it in action 👀

one big thing to remember 🚨: SCTP streams are uni-directional, and there's no link between outgoing and incoming streams. because of that, the procedures are built so the incoming side always resets its SSN first, before the outgoing side. that also means the re-configuration request always has to come from the outgoing side 📤 so if an endpoint wants its incoming streams reset, it basically has to ask the peer to start an outgoing reset. once that request gets acknowledged, the peer is the one actually in charge of the reset 🫡 it's giving "you drive, I'll navigate" 🚗

---

5.1. Sender-Side Procedures 💌

this part covers everything the sender does when it sends RE-CONFIG chunks. a RE-CONFIG chunk is made of one or two Type-Length-Value (TLV) parameters 🎁

5.1.1. Sender-Side Procedures for the RE-CONFIG Chunk 🎀

this extension uses the Supported Extensions Parameter from [RFC5061] to negotiate support. so basically the handshake is how everyone agrees that re-config is a vibe 🤝

An SCTP endpoint that supports this extension MUST include the chunk type of the RE-CONFIG chunk in the Supported Extensions Parameter, in either the INIT or the INIT-ACK. 🪪 Before the sender sends a RE-CONFIG chunk, it MUST make sure the peer has advertised support for the re-configuration extension. If the chunk type of the RE-CONFIG chunk isn't in the supported extension's list of chunks, then the sender MUST NOT send any re-configuration request to the peer. Any request from the application for that service SHOULD get an appropriate error saying the peer SCTP stack doesn't support the re-configuration extension 🙅‍♀️ (rude, but honest)

At any given time, there MUST NOT be more than one request in flight. 🚫 So if the Re-configuration Timer is running and the RE-CONFIG chunk has at least one request parameter, the chunk MUST be buffered. no double booking, bestie 📅

After packaging the RE-CONFIG chunk and sending it, the sender MUST start the Re-configuration Timer if the chunk contains at least one request parameter. If it has no request parameters, the Re-configuration Timer MUST NOT be started. ⏱️ This timer MUST use the same value as SCTP's data transmission timer (the retransmission timeout (RTO) timer), and it MUST use exponential backoff, doubling the value at every expiration 📈 If the timer expires, the sender MUST double the value (yes, again), MUST retransmit the RE-CONFIG chunk, increment the appropriate error counts for both the association and the destination, and do threshold management. That might end with the association getting destroyed if the SCTP retransmission thresholds get exceeded 💀 scary, but that's how it goes.

5.1.2. Sender-Side Procedures for the Outgoing SSN Reset Request Parameter 📤

when an SCTP sender wants to reset the SSNs of some or all of its outgoing streams, it can send an Outgoing SSN Reset Request Parameter, as long as the Re-configuration Timer isn't running. These steps must be followed:

A1: The sender MUST stop assigning new SSNs to new user data coming from the upper layer for the affected streams, and queue that data instead. 🛑 why? Because nobody knows yet whether the receiver will accept or deny the request. And if a request gets lost, that could cause an out-of-sequence error in a stream the receiver isn't ready to handle 😬

A2: The sender MUST assign the next re-configuration request sequence number and MUST put it in the Re-configuration Request Sequence Number field of the Outgoing SSN Reset Request Parameter. After that, the next re-configuration request sequence number MUST be incremented by 1. 🔢

A3: The Sender's Last Assigned TSN MUST be set to the next TSN the sender assigns, minus 1. 🧮

A4: This one has a lot going on, so buckle up 🎢

• If this Outgoing SSN Reset Request Parameter is sent in response to an Incoming SSN Reset Request Parameter, the stream numbers MUST be copied from the Incoming SSN Reset Request Parameter into the Outgoing SSN Reset Request Parameter. The Re-configuration Response Sequence Number of the Outgoing SSN Reset Request Parameter MUST be the Re-configuration Request Sequence Number of the Incoming SSN Reset Request Parameter.
• If this Outgoing SSN Reset Request Parameter is sent at the request of the upper layer and the sender wants all outgoing streams reset, stream numbers SHOULD NOT be put into the Outgoing SSN Reset Request Parameter.
• If the sender only wants some outgoing streams reset, those stream numbers MUST be placed in the Outgoing SSN Reset Request Parameter.
• The Re-configuration Response Sequence Number is the next expected Re-configuration Request Sequence Number of the peer, minus 1. 🧠

A5: The Outgoing SSN Reset Request Parameter MUST be put into a RE-CONFIG Chunk. It MAY be put together with either an Incoming SSN Reset Request Parameter or a Re-configuration Response Parameter, but not both. It MUST NOT be put together with any other parameter, as described in Section 3.1. 🧩 strict roommates only 🏠

A6: The RE-CONFIG chunk MUST be sent following the rules in Section 5.1.1. 📬 (go back and re-read it if you forgot 😌)

5.1.3. Sender-Side Procedures for the Incoming SSN Reset Request Parameter 📥

when an SCTP sender wants to reset the SSNs of some or all of its incoming streams, it can send an Incoming SSN Reset Request Parameter, as long as the Re-configuration Timer isn't running. These steps must be followed:

B1: The sender MUST assign the next re-configuration request sequence number and MUST put it in the Re-configuration Request Sequence Number field of the Incoming SSN Reset Request Parameter. After assigning it, the next re-configuration request sequence number MUST be incremented by 1. 🔁

B2: If the sender wants all incoming streams reset, stream numbers SHOULD NOT be put into the Incoming SSN Reset Request Parameter. If the sender only wants some incoming streams reset, those stream numbers MUST be filled in the Incoming SSN Reset Request Parameter. 🎯

B3: The Incoming SSN Reset Request Parameter MUST be put into a RE-CONFIG Chunk. It MAY be put together with an Outgoing SSN Reset Request Parameter, but it MUST NOT be put together with any other parameter. 🧩

B4: The RE-CONFIG chunk MUST be sent following the rules in Section 5.1.1. 📬

when the sender sends an Incoming SSN Reset Request, there's a chance the peer has just reset the same streams, or is in the middle of resetting them, through an Outgoing SSN Reset Request. that collision scenario is covered in Section 5.2.3. 💥 plot twist, but we've got it handled 🫶

5.1.4. Sender-Side Procedures for the SSN/TSN Reset Request Parameter ✨

okay so when an SCTP sender wants to reset the SSNs and TSNs, it can send an SSN/TSN Reset Request Parameter, but only if the Re-configuration Timer is not running 🙈. the following steps must be followed:

C1: the sender MUST assign the next re-configuration request sequence number and put it into the Re-configuration Request Sequence Number field of the SSN/TSN Reset Request Parameter 🎀. after assigning it, the next re-configuration request sequence number MUST be incremented by 1 💅.

C2: the sender has either no outstanding TSNs or considers all outstanding TSNs abandoned 🫶. the sender MUST queue any user data, suspending any new transmissions and TSN assignment until the reset procedure is finished by the peer either acknowledging or denying the request 😭.

C3: the SSN/TSN Reset Request Parameter MUST be put into a RE-CONFIG chunk. there MUST NOT be any other parameter in this chunk 🚫.

C4: the RE-CONFIG chunk MUST be sent following the rules given in Section 5.1.1 🦋.

only one SSN/TSN Reset Request SHOULD be sent within 30 seconds, which is considered a maximum segment lifetime (the IP MSL) ⏳. that's the vibe, bestie 💜.

---

5.1.5. Sender-Side Procedures for the Add Outgoing Streams Request Parameter 🌈

when an SCTP sender wants to increase the number of outbound streams it can send to, it may add an Add Outgoing Streams Request Parameter to the RE-CONFIG chunk 🧚. upon sending the request, the sender MUST await a positive acknowledgment (Success) before using any additional stream added by this request ✨. note that new streams are added adjacent to the previous streams with no gaps 👑. so if a request is made to add 2 streams to an association that already has 5 (0-4), then the new streams, upon successful completion, are streams 5 and 6 🍓. a new stream MUST use SSN 0 for its first ordered message 💖.

---

5.1.6. Sender-Side Procedures for the Add Incoming Streams Request Parameter 🦋

when an SCTP sender wants to increase the number of inbound streams the peer is able to send to, it may add an Add Incoming Streams Request Parameter to the RE-CONFIG chunk 🌸. note that new streams are added adjacent to the previous streams with no gaps 🎀. this means that if a request is made to add 2 streams to an association that already has 5 (0-4), then the new streams, upon successful completion, are streams 5 and 6 ✨. a new stream MUST use SSN 0 for its first ordered message 💅.

---

5.1.7. Sender-Side Procedures for the Re-configuration Response Parameter 🫶

when an implementation receives a reset request parameter, it must respond with a Re-configuration Response Parameter in the following manner 💌:

D1: the Re-configuration Request Sequence number of the incoming request MUST be copied to the Re-configuration Response Sequence Number field of the Re-configuration Response Parameter 🔥.

D2: the result of the processing of the incoming request according to Table 3 MUST be placed in the Result field of the Re-configuration Response Parameter 📋.

D3: if the incoming request is an SSN/TSN reset request, the Sender's Next TSN field MUST be filled with the next TSN the sender of this Re-configuration Response Parameter will assign 🧁. for other requests, the Sender's Next TSN field, which is optional, MUST NOT be used 🙅‍♀️.

D4: if the incoming request is an SSN/TSN reset request, the Receiver's Next TSN field MUST be filled with a TSN such that the sender of the Re-configuration Response Parameter can be sure it can discard received DATA chunks with smaller TSNs 🗑️. the value SHOULD be the smallest TSN not acknowledged by the receiver of the request plus 2^31 🔢. for other requests, the Receiver's Next TSN field, which is optional, MUST NOT be used 🙅‍♀️.

---

5.2. Receiver-Side Procedures 👂

5.2.1. Receiver-Side Procedures for the RE-CONFIG Chunk 📥

upon reception of a RE-CONFIG chunk, each parameter within it SHOULD be processed 🧐. if multiple parameters have to be returned, they MUST be put into one RE_CONFIG chunk 📦. if the received RE-CONFIG chunk contains at least one request parameter, a selective acknowledgment (SACK) chunk SHOULD be sent back and MAY be bundled with the RE-CONFIG chunk 🤝. if the received RE-CONFIG chunk contains at least one request and, based on the analysis of the Re-configuration Request Sequence Numbers, this is the last received RE-CONFIG chunk (i.e., a retransmission), the same RE-CONFIG chunk MUST to be sent back in response, as it was earlier 🔁.

the decision to deny a re-configuration request is an administrative decision and may be user configurable even after the association has formed 🎛️. if for whatever reason the endpoint does not wish to process a received request parameter, it MUST send a corresponding response parameter as described in Section 5.1.7, with an appropriate Result field 🙃.

Implementation Note: it is recommended that a SACK be bundled with any re-configuration response so that any retransmission processing that needs to occur can be expedited 🚀. a SACK chunk is not required for this feature to work, but it will in effect help minimize the delay in completing a re-configuration operation in the face of any data loss 🌧️.

5.2.2. Receiver-Side Procedures for the Outgoing SSN Reset Request Parameter 📤

in the case that the endpoint is willing to perform a stream reset, the following steps must be followed 🪄:

E1: if the Re-configuration Timer is running for the Re-configuration Request Sequence Number indicated in the Re-configuration Response Sequence Number field, the Re-configuration Request Sequence Number MUST be marked as acknowledged ✅. if all Re-configuration Request Sequence Numbers for which the Re-configuration Timer is running are acknowledged, the Re-configuration Timer MUST be stopped ⏹️.

E2: if the Sender's Last Assigned TSN is greater than the cumulative acknowledgment point, then the endpoint MUST enter "deferred reset processing" 🧊. in this mode, any data arriving with a TSN larger than the Sender's Last Assigned TSN for the affected stream(s) MUST be queued locally and held until the cumulative acknowledgment point reaches the Sender's Last Assigned TSN 🫙. when the cumulative acknowledgment point reaches the last assigned TSN, then proceed to the next step 👣. if the endpoint enters "deferred reset processing", it MUST put a Re-configuration Response Parameter into a RE-CONFIG chunk indicating "In progress" and MUST send the RE-CONFIG chunk ⏳.

E3: if no stream numbers are listed in the parameter, then all incoming streams MUST be reset to 0 as the next expected SSN 🧼. if specific stream numbers are listed, then only these specific streams MUST be reset to 0, and all other non-listed SSNs remain unchanged 🎯.

E4: any queued TSNs (queued at step E2) MUST now be released and processed normally 🎉.

E5: a Re-configuration Response Parameter MUST be put into a RE-CONFIG chunk indicating successful processing 🥳.

E6: the RE-CONFIG chunk MUST be sent after the incoming RE-CONFIG chunk is processed completely 📨.

5.2.3. Receiver-Side Procedures for the Incoming SSN Reset Request Parameter 📥🔄

in the case that the endpoint is willing to perform a stream reset, the following steps must be followed 💫:

F1: an Outgoing SSN Reset Request Parameter MUST be put into a RE-CONFIG chunk according to Section 5.1.2 🧩.

F2: the RE-CONFIG chunk MUST be sent after the incoming RE-CONFIG chunk is processed completely 📬.

when a peer endpoint requests an Incoming SSN Reset Request, it is possible that the local endpoint has just sent an Outgoing SSN Reset Request on the same association and has not yet received a response 😬. in such a case, the local endpoint MUST do the following:

• if the Outgoing SSN Reset Request Parameter that was just sent completely overlaps the received Incoming SSN Reset Request Parameter, respond to the peer with an acknowledgment indicating that there was "Nothing to do" 🙃.
• otherwise, process the Incoming SSN Reset Request Parameter normally, responding to the peer with an acknowledgment. note that this case includes the situation where some of the streams requested overlap with the Outgoing SSN Reset Request that was just sent 🫠. even in such a situation, the Incoming SSN Reset MUST be processed normally, even though this means that (if the endpoint elects to do the stream reset) streams that are already at SSN 0 will be reset a subsequent time 🔂.

it is also possible that the Incoming request will arrive after the Outgoing SSN Reset Request just completed 🏁. in such a case, all of the streams being requested will be already set to 0 🧸. if so, the local endpoint SHOULD send back a Re-configuration Response with the success code "Nothing to do" 🙌.

note that in either race condition, the local endpoint could optionally also perform the reset 🤷‍♀️. this would result in streams that are already at sequence 0 being reset again to 0, which would cause no harm to the application but will add an extra message to the network 📡.

5.2.4. Receiver-Side Procedures for the SSN/TSN Reset Request Parameter 🧼

in the case that the endpoint is willing to perform an SSN/TSN reset, the following steps must be followed 🛠️:

G1: compute an appropriate value for the Receiver's Next TSN, the TSN that the peer should use to send the next DATA chunk 🔮. the value SHOULD be the smallest TSN not acknowledged by the receiver of the request plus 2^31 🔢.

G2: compute an appropriate value for the local endpoint's next TSN, i.e., the next TSN assigned by the receiver of the SSN/TSN reset chunk 🧠. the value SHOULD be the highest TSN sent by the receiver of the request plus 1 ➕.

G3: the same processing as though a SACK chunk with no gap report and a cumulative TSN ACK of the Sender's Next TSN minus 1 were received MUST be performed 🧾.

G4: the same processing as though a FWD-TSN chunk (as defined in [RFC3758]) with all streams affected and a new cumulative TSN ACK of the Receiver's Next TSN minus 1 were received MUST be performed 🔁.

G5: the next expected and outgoing SSNs MUST be reset to 0 for all incoming and outgoing streams 🔄.

G6: a Re-configuration Response Parameter MUST be put into a RE-CONFIG chunk indicating successful processing 🥰.

G7: the RE-CONFIG chunk MUST be sent after the incoming RE-CONFIG chunk is processed completely 💌.

5.2.5. Receiver-Side Procedures for the Add Outgoing Streams Request Parameter 🌟

when an SCTP endpoint receives a re-configuration request adding additional streams, it MUST send a response parameter either acknowledging or denying the request 🙋‍♀️. if the response is successful, the receiver MUST add the requested number of inbound streams to the association, initializing the next expected SSN to 0 🏗️. the SCTP endpoint SHOULD deny the request if the number of streams exceeds a limit that should be configurable by the application 🚧. bestie, that's the whole receiver side of stream adds 💖✨.

5.2.6. Receiver-Side Procedures for the Add Incoming Streams Request Parameter ✨

okay so when an SCTP endpoint gets a re-configuration request that adds more incoming streams, it MUST either send back a response parameter denying the request OR send a matching Add Outgoing Streams Request Parameter, following the rules in Section 5.1.5. 💅 The endpoint SHOULD deny the request if the number of streams goes over a limit that the application should be able to configure. 🎀

5.2.7. Receiver-Side Procedures for the Re-configuration Response Parameter 🦋

when a Re-configuration Response Parameter shows up, these steps have to happen, in this order 👑

H1: If the Re-configuration Timer is running for the Re-configuration Request Sequence Number indicated in the Re-configuration Response Sequence Number field, the Re-configuration Request Sequence Number MUST be marked as acknowledged. If all Re-configuration Request Sequence Numbers for which the Re-configuration Timer is running are acknowledged, the Re-configuration Timer MUST be stopped. If the timer was not running for the Re-configuration Request Sequence Number, the processing of the Re-configuration Response Parameter is complete.

H2: If the Result field indicates "In progress", the timer for the Re-configuration Request Sequence Number is started again. If the timer runs out, the RE-CONFIG chunk MUST be retransmitted but the corresponding error counters MUST NOT be incremented.

H3: If the Result field does not indicate successful processing, the processing of this response is complete.

H4: If the request was an Outgoing SSN Reset Request, the affected streams MUST now be reset and all queued data should now be processed. The assigning of SSNs is allowed again.

H5: If the request was an SSN/TSN Reset Request, new data MUST be sent from the Receiver's Next TSN, beginning with SSN 0 for all outgoing streams. All incoming streams MUST be reset to 0 as the next expected SSN. The peer will send DATA chunks starting with the Sender's Next TSN.

H6: If the request was to add outgoing streams, the endpoint MUST add the additional streams to the association. Note that an implementation may allocate the memory at the time of the request, but it MUST NOT use the streams until the peer has responded with a positive acknowledgment.

---

6. Sockets API Considerations 🔌

This section describes how the sockets API defined in [RFC6458] needs to be extended to make the features of SCTP re-configuration available to the application.

heads up bestie: this section is informational only 🫶

6.1. Events 🎉

When the SCTP_ASSOC_CHANGE notification is delivered and both peers support the extension described in this document, SCTP_ASSOC_SUPPORTS_RE_CONFIG should be listed in the sac_info field.

the union sctp_notification {} gets three new fields, sn_strreset_event, sn_assocreset_event, and sn_strchange_event. it's giving union glow-up ✨

union sctp_notification {
  struct sctp_tlv {
    uint16_t sn_type; /* Notification type. */
    uint16_t sn_flags;
    uint32_t sn_length;
  } sn_header;
  ...
  struct sctp_stream_reset_event sn_strreset_event;
  struct sctp_assoc_reset_event sn_assocreset_event;
  struct sctp_stream_change_event sn_strchange_event;
  ...
}

the matching sn_type values are in Table 4 🌈

+--------------------------+----------------------------------------+
| sn_type                  | valid field in union sctp_notification |
+--------------------------+----------------------------------------+
| SCTP_STREAM_RESET_EVENT  | sn_strreset_event                      |
| SCTP_ASSOC_RESET_EVENT   | sn_assocreset_event                    |
| SCTP_STREAM_CHANGE_EVENT | sn_strchange_event                     |
+--------------------------+----------------------------------------+

                              Table 4

these events get delivered when an incoming request was processed successfully, or when the processing of an outgoing request has finished 💖

6.1.1. Stream Reset Event 💖

here's the structure the event comes in 💅

struct sctp_stream_reset_event {
  uint16_t strreset_type;
  uint16_t strreset_flags;
  uint32_t strreset_length;
  sctp_assoc_t strreset_assoc_id;
  uint16_t strreset_stream_list[];
};

• strreset_type: This field should be SCTP_STREAM_RESET_EVENT.
• strreset_flags: This field is formed from the bitwise OR of one or more of the following currently defined flags:
  • SCTP_STREAM_RESET_INCOMING_SSN: The stream identifiers given in strreset_stream_list[] refer to incoming streams of the endpoint.
  • SCTP_STREAM_RESET_OUTGOING_SSN: The stream identifiers given in strreset_stream_list[] refer to outgoing streams of the endpoint.
  • SCTP_STREAM_RESET_DENIED: The corresponding request was denied by the peer.
  • SCTP_STREAM_RESET_FAILED: The corresponding request failed.

At least one of SCTP_STREAM_RESET_INCOMING_SSN and SCTP_STREAM_RESET_OUTGOING_SSN is set. SCTP_STREAM_RESET_DENIED and SCTP_STREAM_RESET_FAILED are mutually exclusive. If the request was successful, none of these are set.

• strreset_length: This field is the total length in bytes of the delivered event, including the header.
• strreset_assoc_id: This association id field holds the identifier for the association. All notifications for a given association have the same association identifier. For one-to-one style sockets, this field is ignored.
• strreset_stream_list: This is the list of stream identifiers to which this event refers. An empty list identifies all streams as being reset. Depending on strreset_flags, the identifiers refer to incoming or outgoing streams, or both.

6.1.2. Association Reset Event 🌸

the association reset event looks like this 🦋

struct sctp_assoc_reset_event {
  uint16_t assocreset_type;
  uint16_t assocreset_flags;
  uint32_t assocreset_length;
  sctp_assoc_t assocreset_assoc_id;
  uint32_t assocreset_local_tsn;
  uint32_t assocreset_remote_tsn;
};

• assocreset_type: This field should be SCTP_ASSOC_RESET_EVENT.
• assocreset_flags: This field is formed from the bitwise OR of one or more of the following currently defined flags:
  • SCTP_ASSOC_RESET_DENIED: The corresponding outgoing request was denied by the peer.
  • SCTP_ASSOC_RESET_FAILED: The corresponding outgoing request failed.

SCTP_ASSOC_RESET_DENIED and SCTP_ASSOC_RESET_FAILED are mutually exclusive. If the request was successful, none of these are set.

• assocreset_length: This field is the total length in bytes of the delivered event, including the header.
• assocreset_assoc_id: This association id field holds the identifier for the association. All notifications for a given association have the same association identifier. For one-to-one style sockets, this field is ignored.
• assocreset_local_tsn: This field is the next TSN used by the endpoint.
• assocreset_remote_tsn: This field is the next TSN used by the peer.

6.1.3. Stream Change Event 🧚

and last but not least, the stream change event 🎀

struct sctp_stream_change_event {
  uint16_t strchange_type;
  uint16_t strchange_flags;
  uint32_t strchange_length;
  sctp_assoc_t strchange_assoc_id;
  uint16_t strchange_instrms;
  uint16_t strchange_outstrms;
};

• strchange_type: This field should be SCTP_STREAM_CHANGE_EVENT.
• strchange_flags: This field is formed from the bitwise OR of one or more of the following currently defined flags:
  • SCTP_STREAM_CHANGE_DENIED: The corresponding request was denied by the peer.
  • SCTP_STREAM_CHANGE_FAILED: The corresponding request failed.

SCTP_STREAM_CHANGE_DENIED and SCTP_STREAM_CHANGE_FAILED are mutually exclusive. If the request was successful, none of these are set.

• strchange_length: This field is the total length in bytes of the delivered event, including the header.
• strchange_assoc_id: This association id field holds the identifier for the association. All notifications for a given association have the same association identifier. For one-to-one style sockets, this field is ignored.
• strchange_instrms: The number of streams that the peer is allowed to use outbound.
• strchange_outstrms: The number of streams that the endpoint is allowed to use outbound.

6.2. Event Subscription 💜

subscribing to events as described in [RFC6458] is done with a setsockopt() call using the SCTP_EVENT socket option. this option takes the structure below, which specifies the association, the event type (using the same value found in the event type field), and an on/off boolean 🫶

struct sctp_event {
  sctp_assoc_t se_assoc_id;
  uint16_t     se_type;
  uint8_t      se_on;
};

the user fills in the se_type field with the same value found in the strreset_type field, i.e., SCTP_STREAM_RESET_EVENT. they also fill in the se_assoc_id field with either the association to set this event on (this field is ignored for one-to-one style sockets) or one of the reserved constant values defined in [RFC6458]. finally, the se_on field gets set with a 1 to enable the event or a 0 to disable it 💅

6.3. Socket Options 🍓

Table 5 shows the new socket options that make the re-configuration features accessible to the user. they all use IPPROTO_SCTP as their level 🌸

if a call to setsockopt() is used to issue a re-configuration request while the Re-configuration timer is running, setsockopt() will return -1, and error is set to EALREADY. yikes, don't spam it while the timer is running 😭

+--------------------------+---------------------------+-----+-----+
| option name              | data type                 | get | set |
+--------------------------+---------------------------+-----+-----+
| SCTP_ENABLE_STREAM_RESET | struct sctp_assoc_value   |  X  |  X  |
| SCTP_RESET_STREAMS       | struct sctp_reset_streams |     |  X  |
| SCTP_RESET_ASSOC         | sctp_assoc_t              |     |  X  |
| SCTP_ADD_STREAMS         | struct sctp_add_streams   |     |  X  |
+--------------------------+---------------------------+-----+-----+

                              Table 5

Okay bestie, picking up right where we left off with the socket options 💅

6.3.1. Enable/Disable Stream Reset (SCTP_ENABLE_STREAM_RESET) 🎀

okay so this option is the gatekeeper 🚪 it lets a user decide whether the SCTP implementation actually processes or straight up denies incoming STREAM_RESET chunks. no cap, the default is to deny all incoming requests 🙅‍♀️

to set or get this option, the user fills in this struct:

struct sctp_assoc_value {
  sctp_assoc_t assoc_id;
  uint32_t assoc_value;
};

assoc_id: this one gets ignored for one-to-one style sockets 💖 but for one-to-many style sockets, it tells you which association you're doing the thing to.

assoc_value: this is built by bitwise OR-ing one or more of the flags below together 🌈

• SCTP_ENABLE_RESET_STREAM_REQ: process received Incoming/Outgoing SSN Reset Requests if this flag is set, deny them if not 🫶
• SCTP_ENABLE_RESET_ASSOC_REQ: process received SSN/TSN Reset Requests if this flag is set, deny them if not ✨
• SCTP_ENABLE_CHANGE_ASSOC_REQ: process received Add Outgoing Streams Requests if this flag is set, deny them if not 🦋

the default value is !(SCTP_ENABLE_RESET_STREAM_REQ|SCTP_ENABLE_RESET_ASSOC_REQ|SCTP_ENABLE_CHANGE_ASSOC_REQ) 👑

one more thing 👀 using this option has zero impact on subscribing to any related events. those are totally separate, periodt 💅

6.3.2. Reset Incoming and/or Outgoing Streams (SCTP_RESET_STREAMS) 🌸

this option lets the user request a reset of incoming and/or outgoing streams. it's giving reset energy 🔄

to set or get this option, the user fills in this struct:

struct sctp_reset_streams {
  sctp_assoc_t srs_assoc_id;
  uint16_t srs_flags;
  uint16_t srs_number_streams;
  uint16_t srs_stream_list[];
};

srs_assoc_id: ignored for one-to-one style sockets 🧚 for one-to-many style sockets, it picks the association being acted upon.

srs_flags: this says which class of streams gets reset 💜 it's built from the bitwise OR of one or more of these:

• SCTP_STREAM_RESET_INCOMING
• SCTP_STREAM_RESET_OUTGOING

srs_number_streams: the number of elements in srs_stream_list. if it's zero, the operation hits all streams 🌈

srs_stream_list: a list of stream identifiers the operation is performed on. it holds srs_number_streams elements. if it's empty, the operation is performed on all streams 💫 depending on srs_flags, those identifiers refer to incoming streams, outgoing streams, or both 🙈

6.3.3. Reset SSN/TSN (SCTP_RESET_ASSOC) 🦋

this option lets a user request a reset of the SSN/TSN ✨

to set this option, the user provides an option_value of type sctp_assoc_t 💖

on one-to-one style sockets, the option_value is ignored 🙃 for one-to-many style sockets, the option_value is the association identifier of the association the action is performed upon 🫶

6.3.4. Add Incoming and/or Outgoing Streams (SCTP_ADD_STREAMS) 🍓

this option lets a user request adding some incoming and/or outgoing streams 🌟

to set this option, the user fills in this struct:

struct sctp_add_streams {
  sctp_assoc_t sas_assoc_id;
  uint16_t sas_instrms;
  uint16_t sas_outstrms;
};

sas_assoc_id: ignored for one-to-one style sockets 🧚 for one-to-many style sockets, it indicates which association the user is acting upon.

sas_instrms: the number of incoming streams to add 📥

sas_outstrms: the number of outgoing streams to add 📤

an endpoint can limit the number of incoming and outgoing streams by using the sinit_max_instreams field in the struct sctp_initmsg{} when issuing an SCTP_INIT socket option, as defined in [RFC6458] 🔒 an incoming request asking for more streams than allowed will be denied 🚫

---

7. Security Considerations 🔐

okay, this section is SERIOUS bestie 😤 the SCTP sockets API as described in [RFC6458] exposes the sequence numbers of received DATA chunks to the application. an application might expect them to be monotonically increasing. when using the re-configuration extension, this might no longer be true 😱 so applications MUST enable this extension explicitly before it is used. on top of that, applications MUST subscribe explicitly to notifications related to the re-configuration extension before receiving them 🚨

SCTP associations are protected against blind attackers by using verification tags. this is still valid when using the re-configuration extension 🛡️ so this extension does not add any additional security risk to SCTP in relation to blind attackers 💅

when both the SSN and TSN are reset, the maximum segment lifetime is used to avoid TSN wrap-around ⏳

---

8. IANA Considerations 📋

this document (RFC 6525) is the reference for all registrations described in this section. the changes are described below 💌

8.1. A New Chunk Type 🦋

a chunk type has been assigned by IANA. the values given in Table 1 have been used. IANA has assigned this value from the pool of chunks with the upper two bits set to '10' ✨

this has added a line in the "Chunk Types" registry for SCTP:

Chunk Types

ID Value    Chunk Type                                     Reference
-----       ----------                                     ---------
130         Re-configuration Chunk (RE-CONFIG)             [RFC6525]

the registration table as defined in [RFC6096] for the chunk flags of this chunk type is empty 🫧

8.2. Six New Chunk Parameter Types 🌈

six chunk parameter types have been assigned by IANA. it the values given in Table 2 have been used. IANA has assigned these values from the pool of parameters with the upper two bits set to '00' 💜

six additional lines in the "Chunk Parameter Types" registry for SCTP have been added:

Chunk Parameter Types

ID Value  Chunk Parameter Type                             Reference
--------  ------------------------------------------------ ---------
13        Outgoing SSN Reset Request Parameter             [RFC6525]
14        Incoming SSN Reset Request Parameter             [RFC6525]
15        SSN/TSN Reset Request Parameter                  [RFC6525]
16        Re-configuration Response Parameter              [RFC6525]
17        Add Outgoing Streams Request Parameter           [RFC6525]
18        Add Incoming Streams Request Parameter           [RFC6525]

---

9. Acknowledgments 🫶

the authors wish to thank Paul Aitken, Gorry Fairhurst, Tom Petch, Kacheong Poon, Irene Ruengeler, Robin Seggelmann, Gavin Shearer, and Vlad Yasevich for their invaluable comments 💖 the real MVPs 👑

---

10. References 📚

10.1. Normative References 🔗

• [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
• [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. Conrad, "Stream Control Transmission Protocol (SCTP) Partial Reliability Extension", RFC 3758, May 2004.
• [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, September 2007.
• [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. Kozuka, "Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration", RFC 5061, September 2007.
• [RFC6096] Tuexen, M. and R. Stewart, "Stream Control Transmission Protocol (SCTP) Chunk Flags Registration", RFC 6096, January 2011.

10.2. Informative References 🌸

• [RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V. Yasevich, "Sockets API Extensions for the Stream Control Transmission Protocol (SCTP)", RFC 6458, December 2011.

---

Appendix A. Examples of the Reconfiguration Procedures 🧸

please note that this appendix is informational only ℹ️ the following message flows between Endpoints E-A and E-Z illustrate the described procedures. time progresses in the downward direction ⬇️

the following example illustrates E-A resetting streams 1 and 2 for just its outgoing streams 📤

E-A                                         E-Z
----------[RE-CONFIG(OUT-REQ:X/1,2)]---------->
<-------------[RE-CONFIG(RESP:X)]--------------

the following example illustrates E-A resetting streams 1 and 2 for just its incoming streams 📥

E-A                                         E-Z
-----------[RE-CONFIG(IN-REQ:X/1,2)]---------->
<--------[RE-CONFIG(OUT-REQ:Y,X/1,2)]----------
-------------[RE-CONFIG(RESP:Y)]-------------->

the following example illustrates E-A resetting all streams in both directions 🔁

E-A                                         E-Z
-----[RE-CONFIG(OUT-REQ:X,Y-1|IN-REQ:X+1)]---->
<------[RE-CONFIG(RESP:X|OUT-REQ:Y,X+1)]-------
-------------[RE-CONFIG(RESP:Y)]-------------->

the following example illustrates E-A requesting that the streams and TSNs be reset. at completion, E-A has the new sending TSN (selected by the peer) of B, and E-Z has the new sending TSN of A (also selected by the peer) 🌙

E-A                                         E-Z
------------[RE-CONFIG(TSN-REQ:X)]------------>
<-----[RE-CONFIG(RESP:X/S-TSN=A, R-TSN=B)]-----

the following example illustrates E-A requesting the addition of 3 outgoing streams ➕

E-A                                         E-Z
--------[RE-CONFIG(ADD_OUT_STRMS:X/3)]-------->
<-------------[RE-CONFIG(RESP:X)]--------------

the following example illustrates E-A requesting the addition of 3 incoming streams ➕

E-A                                         E-Z
---------[RE-CONFIG(ADD_IN_STRMS:X/3)]-------->
<----[RE-CONFIG(ADD_OUT_STRMS-REQ:Y,X/3)]------
-------------[RE-CONFIG(RESP:Y)]-------------->

---

Authors' Addresses 🏡

Randall R. Stewart Adara Networks Chapin, SC 29036 USA

EMail: randall@lakerest.net

Michael Tuexen Muenster University of Applied Sciences Stegerwaldstr. 39 48565 Steinfurt DE

EMail: tuexen@fh-muenster.de

Peter Lei Cisco Systems, Inc. 9501 Technology Blvd. West Office Center Rosemont, IL 60018 USA

EMail: peterlei@cisco.com