idnits 2.17.1 draft-ietf-tsvwg-rfc4960-bis-19.txt: -(4): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(5): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(6875): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 10 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document obsoletes RFC6096, but the abstract doesn't seem to directly say this. It does mention RFC6096 though, so this could be OK. -- The draft header indicates that this document obsoletes RFC4460, but the abstract doesn't seem to directly say this. It does mention RFC4460 though, so this could be OK. -- The draft header indicates that this document obsoletes RFC8540, but the abstract doesn't seem to directly say this. It does mention RFC8540 though, so this could be OK. -- The draft header indicates that this document obsoletes RFC7053, but the abstract doesn't seem to directly say this. It does mention RFC7053 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (5 February 2022) is 782 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'ASSOCIATE' is mentioned on line 2580, but not defined == Missing Reference: 'SHUTDOWN' is mentioned on line 2610, but not defined == Missing Reference: 'ABORT' is mentioned on line 2573, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU.V42.1994' -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 2960 (Obsoleted by RFC 4960) -- Obsolete informational reference (is this intentional?): RFC 4460 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 6096 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 7053 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 8540 (Obsoleted by RFC 9260) Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. R. Stewart 3 Internet-Draft Netflix, Inc. 4 Obsoletes: 4460, 4960, 6096, 7053, 8540 (if M. Tüxen 5 approved) Münster Univ. of Appl. Sciences 6 Intended status: Standards Track K. E. E. Nielsen 7 Expires: 9 August 2022 Kamstrup A/S 8 5 February 2022 10 Stream Control Transmission Protocol 11 draft-ietf-tsvwg-rfc4960-bis-19 13 Abstract 15 This document obsoletes RFC 4960, if approved. It describes the 16 Stream Control Transmission Protocol (SCTP) and incorporates the 17 specification of the chunk flags registry from RFC 6096 and the 18 specification of the I bit of DATA chunks from RFC 7053. Therefore, 19 RFC 6096 and RFC 7053 are also obsoleted by this document, if 20 approved. In addition to that, the Errata documents RFC 4460 and RFC 21 8540 are also obsoleted by this document, if approved. 23 SCTP was originally designed to transport Public Switched Telephone 24 Network (PSTN) signaling messages over IP networks. It is also 25 suited to be used for other applications, for example WebRTC. 27 SCTP is a reliable transport protocol operating on top of a 28 connectionless packet network such as IP. It offers the following 29 services to its users: 31 * acknowledged error-free non-duplicated transfer of user data, 33 * data fragmentation to conform to discovered path maximum 34 transmission unit (PMTU) size, 36 * sequenced delivery of user messages within multiple streams, with 37 an option for order-of-arrival delivery of individual user 38 messages, 40 * optional bundling of multiple user messages into a single SCTP 41 packet, and 43 * network-level fault tolerance through supporting of multi-homing 44 at either or both ends of an association. 46 The design of SCTP includes appropriate congestion avoidance behavior 47 and resistance to flooding and masquerade attacks. 49 Status of This Memo 51 This Internet-Draft is submitted in full conformance with the 52 provisions of BCP 78 and BCP 79. 54 Internet-Drafts are working documents of the Internet Engineering 55 Task Force (IETF). Note that other groups may also distribute 56 working documents as Internet-Drafts. The list of current Internet- 57 Drafts is at https://datatracker.ietf.org/drafts/current/. 59 Internet-Drafts are draft documents valid for a maximum of six months 60 and may be updated, replaced, or obsoleted by other documents at any 61 time. It is inappropriate to use Internet-Drafts as reference 62 material or to cite them other than as "work in progress." 64 This Internet-Draft will expire on 9 August 2022. 66 Copyright Notice 68 Copyright (c) 2022 IETF Trust and the persons identified as the 69 document authors. All rights reserved. 71 This document is subject to BCP 78 and the IETF Trust's Legal 72 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 73 license-info) in effect on the date of publication of this document. 74 Please review these documents carefully, as they describe your rights 75 and restrictions with respect to this document. Code Components 76 extracted from this document must include Revised BSD License text as 77 described in Section 4.e of the Trust Legal Provisions and are 78 provided without warranty as described in the Revised BSD License. 80 This document may contain material from IETF Documents or IETF 81 Contributions published or made publicly available before November 82 10, 2008. The person(s) controlling the copyright in some of this 83 material may not have granted the IETF Trust the right to allow 84 modifications of such material outside the IETF Standards Process. 85 Without obtaining an adequate license from the person(s) controlling 86 the copyright in such materials, this document may not be modified 87 outside the IETF Standards Process, and derivative works of it may 88 not be created outside the IETF Standards Process, except to format 89 it for publication as an RFC or to translate it into languages other 90 than English. 92 Table of Contents 94 1. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 6 95 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6 96 2.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 7 97 2.2. Architectural View of SCTP . . . . . . . . . . . . . . . 7 98 2.3. Key Terms . . . . . . . . . . . . . . . . . . . . . . . . 8 99 2.4. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 12 100 2.5. Functional View of SCTP . . . . . . . . . . . . . . . . . 13 101 2.5.1. Association Startup and Takedown . . . . . . . . . . 13 102 2.5.2. Sequenced Delivery within Streams . . . . . . . . . . 14 103 2.5.3. User Data Fragmentation . . . . . . . . . . . . . . . 15 104 2.5.4. Acknowledgement and Congestion Avoidance . . . . . . 15 105 2.5.5. Chunk Bundling . . . . . . . . . . . . . . . . . . . 15 106 2.5.6. Packet Validation . . . . . . . . . . . . . . . . . . 16 107 2.5.7. Path Management . . . . . . . . . . . . . . . . . . . 16 108 2.6. Serial Number Arithmetic . . . . . . . . . . . . . . . . 17 109 2.7. Changes from RFC 4960 . . . . . . . . . . . . . . . . . . 17 110 3. SCTP Packet Format . . . . . . . . . . . . . . . . . . . . . 18 111 3.1. SCTP Common Header Field Descriptions . . . . . . . . . . 19 112 3.2. Chunk Field Descriptions . . . . . . . . . . . . . . . . 20 113 3.2.1. Optional/Variable-Length Parameter Format . . . . . . 23 114 3.2.2. Reporting of Unrecognized Parameters . . . . . . . . 25 115 3.3. SCTP Chunk Definitions . . . . . . . . . . . . . . . . . 25 116 3.3.1. Payload Data (DATA) (0) . . . . . . . . . . . . . . . 25 117 3.3.2. Initiation (INIT) (1) . . . . . . . . . . . . . . . . 28 118 3.3.2.1. Optional or Variable-Length Parameters in INIT 119 chunks . . . . . . . . . . . . . . . . . . . . . . 32 120 3.3.3. Initiation Acknowledgement (INIT ACK) (2) . . . . . . 35 121 3.3.3.1. Optional or Variable-Length Parameters in INIT ACK 122 chunks . . . . . . . . . . . . . . . . . . . . . . 39 123 3.3.4. Selective Acknowledgement (SACK) (3) . . . . . . . . 40 124 3.3.5. Heartbeat Request (HEARTBEAT) (4) . . . . . . . . . . 43 125 3.3.6. Heartbeat Acknowledgement (HEARTBEAT ACK) (5) . . . . 44 126 3.3.7. Abort Association (ABORT) (6) . . . . . . . . . . . . 45 127 3.3.8. Shutdown Association (SHUTDOWN) (7) . . . . . . . . . 46 128 3.3.9. Shutdown Acknowledgement (SHUTDOWN ACK) (8) . . . . . 47 129 3.3.10. Operation Error (ERROR) (9) . . . . . . . . . . . . . 47 130 3.3.10.1. Invalid Stream Identifier (1) . . . . . . . . . 49 131 3.3.10.2. Missing Mandatory Parameter (2) . . . . . . . . 50 132 3.3.10.3. Stale Cookie Error (3) . . . . . . . . . . . . . 50 133 3.3.10.4. Out of Resource (4) . . . . . . . . . . . . . . 51 134 3.3.10.5. Unresolvable Address (5) . . . . . . . . . . . . 51 135 3.3.10.6. Unrecognized Chunk Type (6) . . . . . . . . . . 52 136 3.3.10.7. Invalid Mandatory Parameter (7) . . . . . . . . 52 137 3.3.10.8. Unrecognized Parameters (8) . . . . . . . . . . 52 138 3.3.10.9. No User Data (9) . . . . . . . . . . . . . . . . 53 139 3.3.10.10. Cookie Received While Shutting Down (10) . . . . 53 140 3.3.10.11. Restart of an Association with New Addresses 141 (11) . . . . . . . . . . . . . . . . . . . . . . . 54 142 3.3.10.12. User-Initiated Abort (12) . . . . . . . . . . . 54 143 3.3.10.13. Protocol Violation (13) . . . . . . . . . . . . 54 145 3.3.11. Cookie Echo (COOKIE ECHO) (10) . . . . . . . . . . . 55 146 3.3.12. Cookie Acknowledgement (COOKIE ACK) (11) . . . . . . 56 147 3.3.13. Shutdown Complete (SHUTDOWN COMPLETE) (14) . . . . . 56 148 4. SCTP Association State Diagram . . . . . . . . . . . . . . . 57 149 5. Association Initialization . . . . . . . . . . . . . . . . . 60 150 5.1. Normal Establishment of an Association . . . . . . . . . 60 151 5.1.1. Handle Stream Parameters . . . . . . . . . . . . . . 62 152 5.1.2. Handle Address Parameters . . . . . . . . . . . . . . 63 153 5.1.3. Generating State Cookie . . . . . . . . . . . . . . . 64 154 5.1.4. State Cookie Processing . . . . . . . . . . . . . . . 65 155 5.1.5. State Cookie Authentication . . . . . . . . . . . . . 65 156 5.1.6. An Example of Normal Association Establishment . . . 66 157 5.2. Handle Duplicate or Unexpected INIT, INIT ACK, COOKIE ECHO, 158 and COOKIE ACK Chunks . . . . . . . . . . . . . . . . . . 68 159 5.2.1. INIT Chunk Received in COOKIE-WAIT or COOKIE-ECHOED 160 State (Item B) . . . . . . . . . . . . . . . . . . . 68 161 5.2.2. Unexpected INIT Chunk in States Other than CLOSED, 162 COOKIE-ECHOED, COOKIE-WAIT, and SHUTDOWN-ACK-SENT . . 69 163 5.2.3. Unexpected INIT ACK Chunk . . . . . . . . . . . . . . 70 164 5.2.4. Handle a COOKIE ECHO Chunk when a TCB Exists . . . . 70 165 5.2.4.1. An Example of a Association Restart . . . . . . . 73 166 5.2.5. Handle Duplicate COOKIE ACK Chunk . . . . . . . . . . 74 167 5.2.6. Handle Stale Cookie Error . . . . . . . . . . . . . . 74 168 5.3. Other Initialization Issues . . . . . . . . . . . . . . . 74 169 5.3.1. Selection of Tag Value . . . . . . . . . . . . . . . 75 170 5.4. Path Verification . . . . . . . . . . . . . . . . . . . . 75 171 6. User Data Transfer . . . . . . . . . . . . . . . . . . . . . 76 172 6.1. Transmission of DATA Chunks . . . . . . . . . . . . . . . 78 173 6.2. Acknowledgement on Reception of DATA Chunks . . . . . . . 81 174 6.2.1. Processing a Received SACK Chunk . . . . . . . . . . 84 175 6.3. Management of Retransmission Timer . . . . . . . . . . . 86 176 6.3.1. RTO Calculation . . . . . . . . . . . . . . . . . . . 86 177 6.3.2. Retransmission Timer Rules . . . . . . . . . . . . . 88 178 6.3.3. Handle T3-rtx Expiration . . . . . . . . . . . . . . 89 179 6.4. Multi-Homed SCTP Endpoints . . . . . . . . . . . . . . . 90 180 6.4.1. Failover from an Inactive Destination Address . . . . 91 181 6.5. Stream Identifier and Stream Sequence Number . . . . . . 92 182 6.6. Ordered and Unordered Delivery . . . . . . . . . . . . . 92 183 6.7. Report Gaps in Received DATA TSNs . . . . . . . . . . . . 93 184 6.8. CRC32c Checksum Calculation . . . . . . . . . . . . . . . 94 185 6.9. Fragmentation and Reassembly . . . . . . . . . . . . . . 95 186 6.10. Bundling . . . . . . . . . . . . . . . . . . . . . . . . 96 187 7. Congestion Control . . . . . . . . . . . . . . . . . . . . . 97 188 7.1. SCTP Differences from TCP Congestion Control . . . . . . 98 189 7.2. SCTP Slow-Start and Congestion Avoidance . . . . . . . . 99 190 7.2.1. Slow-Start . . . . . . . . . . . . . . . . . . . . . 100 191 7.2.2. Congestion Avoidance . . . . . . . . . . . . . . . . 101 192 7.2.3. Congestion Control . . . . . . . . . . . . . . . . . 102 193 7.2.4. Fast Retransmit on Gap Reports . . . . . . . . . . . 102 194 7.2.5. Reinitialization . . . . . . . . . . . . . . . . . . 104 195 7.2.5.1. Change of Differentiated Services Code Points . . 104 196 7.2.5.2. Change of Routes . . . . . . . . . . . . . . . . 104 197 7.3. PMTU Discovery . . . . . . . . . . . . . . . . . . . . . 104 198 8. Fault Management . . . . . . . . . . . . . . . . . . . . . . 105 199 8.1. Endpoint Failure Detection . . . . . . . . . . . . . . . 105 200 8.2. Path Failure Detection . . . . . . . . . . . . . . . . . 105 201 8.3. Path Heartbeat . . . . . . . . . . . . . . . . . . . . . 106 202 8.4. Handle "Out of the Blue" Packets . . . . . . . . . . . . 109 203 8.5. Verification Tag . . . . . . . . . . . . . . . . . . . . 110 204 8.5.1. Exceptions in Verification Tag Rules . . . . . . . . 110 205 9. Termination of Association . . . . . . . . . . . . . . . . . 111 206 9.1. Abort of an Association . . . . . . . . . . . . . . . . . 112 207 9.2. Shutdown of an Association . . . . . . . . . . . . . . . 112 208 10. ICMP Handling . . . . . . . . . . . . . . . . . . . . . . . . 115 209 11. Interface with Upper Layer . . . . . . . . . . . . . . . . . 116 210 11.1. ULP-to-SCTP . . . . . . . . . . . . . . . . . . . . . . 117 211 11.1.1. Initialize . . . . . . . . . . . . . . . . . . . . . 117 212 11.1.2. Associate . . . . . . . . . . . . . . . . . . . . . 118 213 11.1.3. Shutdown . . . . . . . . . . . . . . . . . . . . . . 119 214 11.1.4. Abort . . . . . . . . . . . . . . . . . . . . . . . 119 215 11.1.5. Send . . . . . . . . . . . . . . . . . . . . . . . . 119 216 11.1.6. Set Primary . . . . . . . . . . . . . . . . . . . . 121 217 11.1.7. Receive . . . . . . . . . . . . . . . . . . . . . . 121 218 11.1.8. Status . . . . . . . . . . . . . . . . . . . . . . . 122 219 11.1.9. Change Heartbeat . . . . . . . . . . . . . . . . . . 123 220 11.1.10. Request Heartbeat . . . . . . . . . . . . . . . . . 124 221 11.1.11. Get SRTT Report . . . . . . . . . . . . . . . . . . 124 222 11.1.12. Set Failure Threshold . . . . . . . . . . . . . . . 125 223 11.1.13. Set Protocol Parameters . . . . . . . . . . . . . . 125 224 11.1.14. Receive Unsent Message . . . . . . . . . . . . . . . 125 225 11.1.15. Receive Unacknowledged Message . . . . . . . . . . . 126 226 11.1.16. Destroy SCTP Instance . . . . . . . . . . . . . . . 127 227 11.2. SCTP-to-ULP . . . . . . . . . . . . . . . . . . . . . . 127 228 11.2.1. DATA ARRIVE Notification . . . . . . . . . . . . . . 127 229 11.2.2. SEND FAILURE Notification . . . . . . . . . . . . . 128 230 11.2.3. NETWORK STATUS CHANGE Notification . . . . . . . . . 128 231 11.2.4. COMMUNICATION UP Notification . . . . . . . . . . . 128 232 11.2.5. COMMUNICATION LOST Notification . . . . . . . . . . 129 233 11.2.6. COMMUNICATION ERROR Notification . . . . . . . . . . 130 234 11.2.7. RESTART Notification . . . . . . . . . . . . . . . . 130 235 11.2.8. SHUTDOWN COMPLETE Notification . . . . . . . . . . . 130 236 12. Security Considerations . . . . . . . . . . . . . . . . . . . 130 237 12.1. Security Objectives . . . . . . . . . . . . . . . . . . 130 238 12.2. SCTP Responses to Potential Threats . . . . . . . . . . 131 239 12.2.1. Countering Insider Attacks . . . . . . . . . . . . . 131 240 12.2.2. Protecting against Data Corruption in the Network . 131 241 12.2.3. Protecting Confidentiality . . . . . . . . . . . . . 131 242 12.2.4. Protecting against Blind Denial-of-Service 243 Attacks . . . . . . . . . . . . . . . . . . . . . . . 132 244 12.2.4.1. Flooding . . . . . . . . . . . . . . . . . . . . 132 245 12.2.4.2. Blind Masquerade . . . . . . . . . . . . . . . . 133 246 12.2.4.3. Improper Monopolization of Services . . . . . . 134 247 12.3. SCTP Interactions with Firewalls . . . . . . . . . . . . 134 248 12.4. Protection of Non-SCTP-Capable Hosts . . . . . . . . . . 134 249 13. Network Management Considerations . . . . . . . . . . . . . . 135 250 14. Recommended Transmission Control Block (TCB) Parameters . . . 135 251 14.1. Parameters Necessary for the SCTP Instance . . . . . . . 135 252 14.2. Parameters Necessary per Association (i.e., the TCB) . . 136 253 14.3. Per Transport Address Data . . . . . . . . . . . . . . . 138 254 14.4. General Parameters Needed . . . . . . . . . . . . . . . 139 255 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 139 256 15.1. IETF-Defined Chunk Extension . . . . . . . . . . . . . . 143 257 15.2. IETF Chunk Flags Registration . . . . . . . . . . . . . 144 258 15.3. IETF-Defined Chunk Parameter Extension . . . . . . . . . 144 259 15.4. IETF-Defined Additional Error Causes . . . . . . . . . . 144 260 15.5. Payload Protocol Identifiers . . . . . . . . . . . . . . 145 261 15.6. Port Numbers Registry . . . . . . . . . . . . . . . . . 145 262 16. Suggested SCTP Protocol Parameter Values . . . . . . . . . . 145 263 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 146 264 18. Normative References . . . . . . . . . . . . . . . . . . . . 147 265 19. Informative References . . . . . . . . . . . . . . . . . . . 149 266 Appendix A. CRC32c Checksum Calculation . . . . . . . . . . . . 152 267 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 159 269 1. Conventions 271 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 272 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 273 "OPTIONAL" in this document are to be interpreted as described in BCP 274 14 [RFC2119] [RFC8174] when, and only when, they appear in all 275 capitals, as shown here. 277 2. Introduction 279 This section explains the reasoning behind the development of the 280 Stream Control Transmission Protocol (SCTP), the services it offers, 281 and the basic concepts needed to understand the detailed description 282 of the protocol. 284 This document obsoletes [RFC4960], if approved. In addition to that, 285 it incorporates the specification of the chunk flags registry from 286 [RFC6096] and the specification of the I bit of DATA chunks from 287 [RFC7053]. Therefore, [RFC6096] and [RFC7053] are also obsoleted by 288 this document, if approved. 290 2.1. Motivation 292 TCP [RFC0793] has performed immense service as the primary means of 293 reliable data transfer in IP networks. However, an increasing number 294 of recent applications have found TCP too limiting, and have 295 incorporated their own reliable data transfer protocol on top of UDP 296 [RFC0768]. The limitations that users have wished to bypass include 297 the following: 299 * TCP provides both reliable data transfer and strict order-of- 300 transmission delivery of data. Some applications need reliable 301 transfer without sequence maintenance, while others would be 302 satisfied with partial ordering of the data. In both of these 303 cases, the head-of-line blocking offered by TCP causes unnecessary 304 delay. 306 * The stream-oriented nature of TCP is often an inconvenience. 307 Applications add their own record marking to delineate their 308 messages, and make explicit use of the push facility to ensure 309 that a complete message is transferred in a reasonable time. 311 * The limited scope of TCP sockets complicates the task of providing 312 highly-available data transfer capability using multi-homed hosts. 314 * TCP is relatively vulnerable to denial-of-service attacks, such as 315 SYN attacks. 317 Transport of PSTN signaling across the IP network is an application 318 for which all of these limitations of TCP are relevant. While this 319 application directly motivated the development of SCTP, other 320 applications might find SCTP a good match to their requirements. One 321 example of this is the use of datachannels in the WebRTC 322 infrastructure. 324 2.2. Architectural View of SCTP 326 SCTP is viewed as a layer between the SCTP user application ("SCTP 327 user" for short) and a connectionless packet network service such as 328 IP. The remainder of this document assumes SCTP runs on top of IP. 329 The basic service offered by SCTP is the reliable transfer of user 330 messages between peer SCTP users. It performs this service within 331 the context of an association between two SCTP endpoints. Section 11 332 of this document sketches the API that exists at the boundary between 333 the SCTP and the SCTP upper layers. 335 SCTP is connection-oriented in nature, but the SCTP association is a 336 broader concept than the TCP connection. SCTP provides the means for 337 each SCTP endpoint (Section 2.3) to provide the other endpoint 338 (during association startup) with a list of transport addresses 339 (i.e., multiple IP addresses in combination with an SCTP port) 340 through which that endpoint can be reached and from which it will 341 originate SCTP packets. The association spans transfers over all of 342 the possible source/destination combinations that can be generated 343 from each endpoint's lists. 345 _____________ _____________ 346 | SCTP User | | SCTP User | 347 | Application | | Application | 348 |-------------| |-------------| 349 | SCTP | | SCTP | 350 | Transport | | Transport | 351 | Service | | Service | 352 |-------------| |-------------| 353 | |One or more ---- One or more| | 354 | IP Network |IP address \/ IP address| IP Network | 355 | Service |appearances /\ appearances| Service | 356 |_____________| ---- |_____________| 358 SCTP Node A |<-------- Network transport ------->| SCTP Node B 360 Figure 1: An SCTP Association 362 In addition to encapsulating SCTP packets in IPv4 or IPv6, it is also 363 possible to encapsulate SCTP packets in UDP as specified in [RFC6951] 364 or encapsulate them in DTLS as specified in [RFC8261]. 366 2.3. Key Terms 368 Some of the language used to describe SCTP has been introduced in the 369 previous sections. This section provides a consolidated list of the 370 key terms and their definitions. 372 Active Destination Transport Address: A transport address on a peer 373 endpoint that a transmitting endpoint considers available for 374 receiving user messages. 376 Association Maximum DATA Chunk Size (AMDCS): The smallest Path 377 Maximum DATA Chunk Size (PMDCS) of all destination addresses. 379 Bundling Of Chunks: An optional multiplexing operation, whereby more 380 than one chunk can be carried in the same SCTP packet. 382 Bundling Of User Messages: An optional multiplexing operation, 383 whereby more than one user message can be carried in the same SCTP 384 packet. Each user message occupies its own DATA chunk. 386 Chunk: A unit of information within an SCTP packet, consisting of a 387 chunk header and chunk-specific content. 389 Congestion Window (cwnd): An SCTP variable that limits outstanding 390 data, in number of bytes, that a sender can send to a particular 391 destination transport address before receiving an acknowledgement. 393 Control Chunk: A chunk not being used for transmitting user data, 394 i.e. every chunk which is not a DATA chunk. 396 Cumulative TSN Ack Point: The Transmission Sequence Number (TSN) of 397 the last DATA chunk acknowledged via the Cumulative TSN Ack field 398 of a SACK chunk. 400 Flightsize: The number of bytes of outstanding data to a particular 401 destination transport address at any given time. 403 Idle Destination Address: An address that has not had user messages 404 sent to it within some length of time, normally the 'HB.interval' 405 or greater. 407 Inactive Destination Transport Address: An address that is 408 considered inactive due to errors and unavailable to transport 409 user messages. 411 Message (or User Message): Data submitted to SCTP by the Upper Layer 412 Protocol (ULP). 414 Network Byte Order: Most significant byte first, a.k.a., big endian. 416 Ordered Message: A user message that is delivered in order with 417 respect to all previous user messages sent within the stream on 418 which the message was sent. 420 Outstanding Data (or Data Outstanding or Data In Flight): The total 421 size of the DATA chunks associated with outstanding TSNs. A 422 retransmitted DATA chunk is counted once in outstanding data. A 423 DATA chunk that is classified as lost but that has not yet been 424 retransmitted is not in outstanding data. 426 Outstanding TSN (at an SCTP Endpoint): A TSN (and the associated 427 DATA chunk) that has been sent by the endpoint but for which it 428 has not yet received an acknowledgement. 430 Out Of The Blue (OOTB) Packet: A correctly formed packet, for which 431 the receiver can not identify the association it belongs to. See 432 Section 8.4. 434 Path: The route taken by the SCTP packets sent by one SCTP endpoint 435 to a specific destination transport address of its peer SCTP 436 endpoint. Sending to different destination transport addresses 437 does not necessarily guarantee getting separate paths. Within 438 this specification, a path is identified by the destination 439 transport address, since the routing is assumed to be stable. 440 This includes in particular the source address being selected when 441 sending packets to the destination address. 443 Path Maximum DATA Chunk Size (PMDCS): The maximum size (including 444 the DATA chunk header) of a DATA chunk which fits into an SCTP 445 packet not exceeding the PMTU of a particular destination address. 447 Path Maximum Transmission Unit (PMTU): The maximum size (including 448 the SCTP common header and all chunks including their paddings) of 449 an SCTP packet which can be sent to a particular destination 450 address without using IP level fragmentation. 452 Primary Path: The primary path is the destination and source address 453 that will be put into a packet outbound to the peer endpoint by 454 default. The definition includes the source address since an 455 implementation MAY wish to specify both destination and source 456 address to better control the return path taken by reply chunks 457 and on which interface the packet is transmitted when the data 458 sender is multi-homed. 460 Receiver Window (rwnd): An SCTP variable a data sender uses to store 461 the most recently calculated receiver window of its peer, in 462 number of bytes. This gives the sender an indication of the space 463 available in the receiver's inbound buffer. 465 SCTP Association: A protocol relationship between SCTP endpoints, 466 composed of the two SCTP endpoints and protocol state information 467 including Verification Tags and the currently active set of 468 Transmission Sequence Numbers (TSNs), etc. An association can be 469 uniquely identified by the transport addresses used by the 470 endpoints in the association. Two SCTP endpoints MUST NOT have 471 more than one SCTP association between them at any given time. 473 SCTP Endpoint: The logical sender/receiver of SCTP packets. On a 474 multi-homed host, an SCTP endpoint is represented to its peers as 475 a combination of a set of eligible destination transport addresses 476 to which SCTP packets can be sent and a set of eligible source 477 transport addresses from which SCTP packets can be received. All 478 transport addresses used by an SCTP endpoint MUST use the same 479 port number, but can use multiple IP addresses. A transport 480 address used by an SCTP endpoint MUST NOT be used by another SCTP 481 endpoint. In other words, a transport address is unique to an 482 SCTP endpoint. 484 SCTP Packet (or Packet): The unit of data delivery across the 485 interface between SCTP and the connectionless packet network 486 (e.g., IP). An SCTP packet includes the common SCTP header, 487 possible SCTP control chunks, and user data encapsulated within 488 SCTP DATA chunks. 490 SCTP User Application (or SCTP User): The logical higher-layer 491 application entity which uses the services of SCTP, also called 492 the Upper-Layer Protocol (ULP). 494 Slow-Start Threshold (ssthresh): An SCTP variable. This is the 495 threshold that the endpoint will use to determine whether to 496 perform slow start or congestion avoidance on a particular 497 destination transport address. Ssthresh is in number of bytes. 499 State Cookie: A container of all information needed to establish an 500 association. 502 Stream: A unidirectional logical channel established from one to 503 another associated SCTP endpoint, within which all user messages 504 are delivered in sequence except for those submitted to the 505 unordered delivery service. 507 Note: The relationship between stream numbers in opposite 508 directions is strictly a matter of how the applications use them. 509 It is the responsibility of the SCTP user to create and manage 510 these correlations if they are so desired. 512 Stream Sequence Number: A 16-bit sequence number used internally by 513 SCTP to ensure sequenced delivery of the user messages within a 514 given stream. One Stream Sequence Number is attached to each 515 ordered user message. 517 Tie-Tags: Two 32-bit random numbers that together make a 64-bit 518 nonce. These tags are used within a State Cookie and TCB so that 519 a newly restarting association can be linked to the original 520 association within the endpoint that did not restart and yet not 521 reveal the true Verification Tags of an existing association. 523 Transmission Control Block (TCB): An internal data structure created 524 by an SCTP endpoint for each of its existing SCTP associations to 525 other SCTP endpoints. TCB contains all the status and operational 526 information for the endpoint to maintain and manage the 527 corresponding association. 529 Transmission Sequence Number (TSN): A 32-bit sequence number used 530 internally by SCTP. One TSN is attached to each chunk containing 531 user data to permit the receiving SCTP endpoint to acknowledge its 532 receipt and detect duplicate deliveries. 534 Transport Address: A transport address is traditionally defined by a 535 network-layer address, a transport-layer protocol, and a 536 transport-layer port number. In the case of SCTP running over IP, 537 a transport address is defined by the combination of an IP address 538 and an SCTP port number (where SCTP is the transport protocol). 540 Unordered Message: Unordered messages are "unordered" with respect 541 to any other message; this includes both other unordered messages 542 as well as other ordered messages. An unordered message might be 543 delivered prior to or later than ordered messages sent on the same 544 stream. 546 User Message: The unit of data delivery across the interface between 547 SCTP and its user. 549 Verification Tag: A 32-bit unsigned integer that is randomly 550 generated. The Verification Tag provides a key that allows a 551 receiver to verify that the SCTP packet belongs to the current 552 association and is not an old or stale packet from a previous 553 association. 555 2.4. Abbreviations 557 MAC Message Authentication Code [RFC2104] 558 RTO Retransmission Timeout 559 RTT Round-Trip Time 560 RTTVAR Round-Trip Time Variation 561 SCTP Stream Control Transmission Protocol 562 SRTT Smoothed RTT 563 TCB Transmission Control Block 564 TLV Type-Length-Value coding format 565 TSN Transmission Sequence Number 566 ULP Upper-Layer Protocol 568 2.5. Functional View of SCTP 570 The SCTP transport service can be decomposed into a number of 571 functions. These are depicted in Figure 2 and explained in the 572 remainder of this section. 574 SCTP User Application 576 ----------------------------------------------------- 577 _____________ ____________________ 578 | | | Sequenced Delivery | 579 | Association | | within Streams | 580 | | |____________________| 581 | Startup | 582 | | ____________________________ 583 | and | | User Data Fragmentation | 584 | | |____________________________| 585 | Takedown | 586 | | ____________________________ 587 | | | Acknowledgement | 588 | | | and | 589 | | | Congestion Avoidance | 590 | | |____________________________| 591 | | 592 | | ____________________________ 593 | | | Chunk Bundling | 594 | | |____________________________| 595 | | 596 | | ________________________________ 597 | | | Packet Validation | 598 | | |________________________________| 599 | | 600 | | ________________________________ 601 | | | Path Management | 602 |_____________| |________________________________| 604 Figure 2: Functional View of the SCTP Transport Service 606 2.5.1. Association Startup and Takedown 608 An association is initiated by a request from the SCTP user (see the 609 description of the ASSOCIATE (or SEND) primitive in Section 11). 611 A cookie mechanism, similar to one described by Karn and Simpson in 612 [RFC2522], is employed during the initialization to provide 613 protection against synchronization attacks. The cookie mechanism 614 uses a four-way handshake, the last two legs of which are allowed to 615 carry user data for fast setup. The startup sequence is described in 616 Section 5 of this document. 618 SCTP provides for graceful close (i.e., shutdown) of an active 619 association on request from the SCTP user. See the description of 620 the SHUTDOWN primitive in Section 11. SCTP also allows ungraceful 621 close (i.e., abort), either on request from the user (ABORT 622 primitive) or as a result of an error condition detected within the 623 SCTP layer. Section 9 describes both the graceful and the ungraceful 624 close procedures. 626 SCTP does not support a half-open state (like TCP) wherein one side 627 continues sending data while the other end is closed. When either 628 endpoint performs a shutdown, the association on each peer will stop 629 accepting new data from its user and only deliver data in queue at 630 the time of the graceful close (see Section 9). 632 2.5.2. Sequenced Delivery within Streams 634 The term "stream" is used in SCTP to refer to a sequence of user 635 messages that are to be delivered to the upper-layer protocol in 636 order with respect to other messages within the same stream. This is 637 in contrast to its usage in TCP, where it refers to a sequence of 638 bytes (in this document, a byte is assumed to be 8 bits). 640 The SCTP user can specify at association startup time the number of 641 streams to be supported by the association. This number is 642 negotiated with the remote end (see Section 5.1.1). User messages 643 are associated with stream numbers (SEND, RECEIVE primitives, 644 Section 11). Internally, SCTP assigns a Stream Sequence Number to 645 each message passed to it by the SCTP user. On the receiving side, 646 SCTP ensures that messages are delivered to the SCTP user in sequence 647 within a given stream. However, while one stream might be blocked 648 waiting for the next in-sequence user message, delivery from other 649 streams might proceed. 651 SCTP provides a mechanism for bypassing the sequenced delivery 652 service. User messages sent using this mechanism are delivered to 653 the SCTP user as soon as they are received. 655 2.5.3. User Data Fragmentation 657 When needed, SCTP fragments user messages to ensure that the size of 658 the SCTP packet passed to the lower layer does not exceed the PMTU. 659 Once a user message has been fragmented, this fragmentation cannot be 660 changed anymore. On receipt, fragments are reassembled into complete 661 messages before being passed to the SCTP user. 663 2.5.4. Acknowledgement and Congestion Avoidance 665 SCTP assigns a Transmission Sequence Number (TSN) to each user data 666 fragment or unfragmented message. The TSN is independent of any 667 Stream Sequence Number assigned at the stream level. The receiving 668 end acknowledges all TSNs received, even if there are gaps in the 669 sequence. If a user data fragment or unfragmented message needs to 670 be retransmitted, the TSN assigned to it is used. In this way, 671 reliable delivery is kept functionally separate from sequenced stream 672 delivery. 674 The acknowledgement and congestion avoidance function is responsible 675 for packet retransmission when timely acknowledgement has not been 676 received. Packet retransmission is conditioned by congestion 677 avoidance procedures similar to those used for TCP. See Section 6 678 and Section 7 for a detailed description of the protocol procedures 679 associated with this function. 681 2.5.5. Chunk Bundling 683 As described in Section 3, the SCTP packet as delivered to the lower 684 layer consists of a common header followed by one or more chunks. 685 Each chunk contains either user data or SCTP control information. An 686 SCTP implementation supporting bundling on the sender side might 687 delay the sending of user messages to allow the corresponding DATA 688 chunks to be bundled. 690 The SCTP user has the option to request that an SCTP implementation 691 does not delay the sending of a user message just for this purpose. 692 However, even if the SCTP user has chosen this option, the SCTP 693 implementation might delay the sending due to other reasons, for 694 example due to congestion control or flow control, and might also 695 bundle multiple DATA chunks, if possible. 697 2.5.6. Packet Validation 699 A mandatory Verification Tag field and a 32-bit checksum field (see 700 Appendix A for a description of the CRC32c checksum) are included in 701 the SCTP common header. The Verification Tag value is chosen by each 702 end of the association during association startup. Packets received 703 without the expected Verification Tag value are discarded, as a 704 protection against blind masquerade attacks and against stale SCTP 705 packets from a previous association. The CRC32c checksum is set by 706 the sender of each SCTP packet to provide additional protection 707 against data corruption in the network. The receiver of an SCTP 708 packet with an invalid CRC32c checksum silently discards the packet. 710 2.5.7. Path Management 712 The sending SCTP user is able to manipulate the set of transport 713 addresses used as destinations for SCTP packets through the 714 primitives described in Section 11. The SCTP path management 715 function monitors reachability through heartbeats when other packet 716 traffic is inadequate to provide this information and advises the 717 SCTP user when reachability of any transport address of the peer 718 endpoint changes. The path management function chooses the 719 destination transport address for each outgoing SCTP packet based on 720 the SCTP user's instructions and the currently perceived reachability 721 status of the eligible destination set. The path management function 722 is also responsible for reporting the eligible set of local transport 723 addresses to the peer endpoint during association startup, and for 724 reporting the transport addresses returned from the peer endpoint to 725 the SCTP user. 727 At association startup, a primary path is defined for each SCTP 728 endpoint, and is used for normal sending of SCTP packets. 730 On the receiving end, the path management is responsible for 731 verifying the existence of a valid SCTP association to which the 732 inbound SCTP packet belongs before passing it for further processing. 734 Note: Path Management and Packet Validation are done at the same 735 time, so although described separately above, in reality they cannot 736 be performed as separate items. 738 2.6. Serial Number Arithmetic 740 It is essential to remember that the actual Transmission Sequence 741 Number space is finite, though very large. This space ranges from 0 742 to 2^32 - 1. Since the space is finite, all arithmetic dealing with 743 Transmission Sequence Numbers MUST be performed modulo 2^32. This 744 unsigned arithmetic preserves the relationship of sequence numbers as 745 they cycle from 2^32 - 1 to 0 again. There are some subtleties to 746 computer modulo arithmetic, so great care has to be taken in 747 programming the comparison of such values. When referring to TSNs, 748 the symbol "<=" means "less than or equal" (modulo 2^32). 750 Comparisons and arithmetic on TSNs in this document SHOULD use Serial 751 Number Arithmetic as defined in [RFC1982] where SERIAL_BITS = 32. 753 An endpoint SHOULD NOT transmit a DATA chunk with a TSN that is more 754 than 2^31 - 1 above the beginning TSN of its current send window. 755 Doing so will cause problems in comparing TSNs. 757 Transmission Sequence Numbers wrap around when they reach 2^32 - 1. 758 That is, the next TSN a DATA chunk MUST use after transmitting TSN = 759 2^32 - 1 is TSN = 0. 761 Any arithmetic done on Stream Sequence Numbers SHOULD use Serial 762 Number Arithmetic as defined in [RFC1982] where SERIAL_BITS = 16. 763 All other arithmetic and comparisons in this document use normal 764 arithmetic. 766 2.7. Changes from RFC 4960 768 SCTP was originally defined in [RFC4960], which this document 769 obsoletes, if approved. Readers interested in the details of the 770 various changes that this document incorporates are asked to consult 771 [RFC8540]. 773 In addition to these and further editorial changes, the following 774 changes have been incorporated in this document: 776 * Update references. 778 * Improve the language related to requirements levels. 780 * Allow the ASSOCIATE primitive to take multiple remote addresses; 781 also refer to the Socket API specification. 783 * Refer to the PLPMTUD specification for path MTU discovery. 785 * Move the description of ICMP handling from an Appendix to the main 786 text. 788 * Remove the Appendix describing ECN handling from the document. 790 * Describe the packet size handling more precisely by introducing 791 PMTU, PMDCS and AMDCS. 793 * Add the definition of control chunk. 795 * Improve the description of the handling of INIT and INIT ACK 796 chunks with invalid mandatory parameters. 798 * Allow using L > 1 for Appropriate Byte Counting (ABC) during slow 799 start. 801 * Explicitly describe the reinitialization of the congestion 802 controller on route changes. 804 * Improve the terminology to make clear that this specification does 805 not describe a full mesh architecture. 807 * Improve the description of sequence number generation 808 (Transmission Sequence Number and Stream Sequence Number). 810 * Improve the description of reneging. 812 * Don't require the change of the cumulative TSN ACK anymore for 813 increasing the congestion window. This improves the consistency 814 with the handling in congestion avoidance. 816 * Improve the description of the State Cookie. 818 * Fix the API for retrieving messages in case of association 819 failures. 821 3. SCTP Packet Format 823 An SCTP packet is composed of a common header and chunks. A chunk 824 contains either control information or user data. 826 The SCTP packet format is shown below: 828 0 1 2 3 829 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 830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 831 | Common Header | 832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 833 | Chunk #1 | 834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 835 | ... | 836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 837 | Chunk #n | 838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 840 INIT, INIT ACK and SHUTDOWN COMPLETE chunks MUST NOT be bundled with 841 any other chunk into an SCTP packet. All other chunks MAY be bundled 842 to form an SCTP packet that does not exceed the PMTU. See 843 Section 6.10 for more details on chunk bundling. 845 If a user data message does not fit into one SCTP packet it can be 846 fragmented into multiple chunks using the procedure defined in 847 Section 6.9. 849 All integer fields in an SCTP packet MUST be transmitted in network 850 byte order, unless otherwise stated. 852 3.1. SCTP Common Header Field Descriptions 854 0 1 2 3 855 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 856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 857 | Source Port Number | Destination Port Number | 858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 859 | Verification Tag | 860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 861 | Checksum | 862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 864 Source Port Number: 16 bits (unsigned integer) 865 This is the SCTP sender's port number. It can be used by the 866 receiver in combination with the source IP address, the SCTP 867 destination port, and possibly the destination IP address to 868 identify the association to which this packet belongs. The source 869 port number 0 MUST NOT be used. 871 Destination Port Number: 16 bits (unsigned integer) 872 This is the SCTP port number to which this packet is destined. 873 The receiving host will use this port number to de-multiplex the 874 SCTP packet to the correct receiving endpoint/application. The 875 destination port number 0 MUST NOT be used. 877 Verification Tag: 32 bits (unsigned integer) 878 The receiver of an SCTP packet uses the Verification Tag to 879 validate the sender of this packet. On transmit, the value of the 880 Verification Tag MUST be set to the value of the Initiate Tag 881 received from the peer endpoint during the association 882 initialization, with the following exceptions: 884 * A packet containing an INIT chunk MUST have a zero Verification 885 Tag. 887 * A packet containing a SHUTDOWN COMPLETE chunk with the T bit 888 set MUST have the Verification Tag copied from the packet with 889 the SHUTDOWN ACK chunk. 891 * A packet containing an ABORT chunk MAY have the verification 892 tag copied from the packet that caused the ABORT chunk to be 893 sent. For details see Section 8.4 and Section 8.5. 895 Checksum: 32 bits (unsigned integer) 896 This field contains the checksum of the SCTP packet. Its 897 calculation is discussed in Section 6.8. SCTP uses the CRC32c 898 algorithm as described in Appendix A for calculating the checksum. 900 3.2. Chunk Field Descriptions 902 The figure below illustrates the field format for the chunks to be 903 transmitted in the SCTP packet. Each chunk is formatted with a Chunk 904 Type field, a chunk-specific Flag field, a Chunk Length field, and a 905 Value field. 907 0 1 2 3 908 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 909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 910 | Chunk Type | Chunk Flags | Chunk Length | 911 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 912 \ \ 913 / Chunk Value / 914 \ \ 915 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 917 Chunk Type: 8 bits (unsigned integer) 918 This field identifies the type of information contained in the 919 Chunk Value field. It takes a value from 0 to 254. The value of 920 255 is reserved for future use as an extension field. 922 The values of Chunk Types are defined as follows: 924 +==========+===========================================+ 925 | ID Value | Chunk Type | 926 +==========+===========================================+ 927 | 0 | Payload Data (DATA) | 928 +----------+-------------------------------------------+ 929 | 1 | Initiation (INIT) | 930 +----------+-------------------------------------------+ 931 | 2 | Initiation Acknowledgement (INIT ACK) | 932 +----------+-------------------------------------------+ 933 | 3 | Selective Acknowledgement (SACK) | 934 +----------+-------------------------------------------+ 935 | 4 | Heartbeat Request (HEARTBEAT) | 936 +----------+-------------------------------------------+ 937 | 5 | Heartbeat Acknowledgement (HEARTBEAT ACK) | 938 +----------+-------------------------------------------+ 939 | 6 | Abort (ABORT) | 940 +----------+-------------------------------------------+ 941 | 7 | Shutdown (SHUTDOWN) | 942 +----------+-------------------------------------------+ 943 | 8 | Shutdown Acknowledgement (SHUTDOWN ACK) | 944 +----------+-------------------------------------------+ 945 | 9 | Operation Error (ERROR) | 946 +----------+-------------------------------------------+ 947 | 10 | State Cookie (COOKIE ECHO) | 948 +----------+-------------------------------------------+ 949 | 11 | Cookie Acknowledgement (COOKIE ACK) | 950 +----------+-------------------------------------------+ 951 | 12 | Reserved for Explicit Congestion | 952 | | Notification Echo (ECNE) | 953 +----------+-------------------------------------------+ 954 | 13 | Reserved for Congestion Window Reduced | 955 | | (CWR) | 956 +----------+-------------------------------------------+ 957 | 14 | Shutdown Complete (SHUTDOWN COMPLETE) | 958 +----------+-------------------------------------------+ 959 | 15 to 62 | available | 960 +----------+-------------------------------------------+ 961 | 63 | reserved for IETF-defined Chunk | 962 | | Extensions | 963 +----------+-------------------------------------------+ 964 | 64 to | available | 965 | 126 | | 966 +----------+-------------------------------------------+ 967 | 127 | reserved for IETF-defined Chunk | 968 | | Extensions | 969 +----------+-------------------------------------------+ 970 | 128 to | available | 971 | 190 | | 972 +----------+-------------------------------------------+ 973 | 191 | reserved for IETF-defined Chunk | 974 | | Extensions | 975 +----------+-------------------------------------------+ 976 | 192 to | available | 977 | 254 | | 978 +----------+-------------------------------------------+ 979 | 255 | reserved for IETF-defined Chunk | 980 | | Extensions | 981 +----------+-------------------------------------------+ 983 Table 1: Chunk Types 985 Note: The ECNE and CWR chunk types are reserved for future use of 986 Explicit Congestion Notification (ECN). 988 Chunk Types are encoded such that the highest-order 2 bits specify 989 the action that is taken if the processing endpoint does not 990 recognize the Chunk Type. 992 +----+--------------------------------------------------+ 993 | 00 | Stop processing this SCTP packet; discard the | 994 | | unrecognized chunk and all further chunks. | 995 +----+--------------------------------------------------+ 996 | 01 | Stop processing this SCTP packet, discard the | 997 | | unrecognized chunk and all further chunks, and | 998 | | report the unrecognized chunk in an ERROR chunk | 999 | | using the 'Unrecognized Chunk Type' error cause. | 1000 +----+--------------------------------------------------+ 1001 | 10 | Skip this chunk and continue processing. | 1002 +----+--------------------------------------------------+ 1003 | 11 | Skip this chunk and continue processing, but | 1004 | | report it in an ERROR chunk using the | 1005 | | 'Unrecognized Chunk Type' error cause. | 1006 +----+--------------------------------------------------+ 1008 Table 2: Processing of Unknown Chunks 1010 Chunk Flags: 8 bits 1011 The usage of these bits depends on the Chunk type as given by the 1012 Chunk Type field. Unless otherwise specified, they are set to 0 1013 on transmit and are ignored on receipt. 1015 Chunk Length: 16 bits (unsigned integer) 1016 This value represents the size of the chunk in bytes, including 1017 the Chunk Type, Chunk Flags, Chunk Length, and Chunk Value fields. 1018 Therefore, if the Chunk Value field is zero-length, the Length 1019 field will be set to 4. The Chunk Length field does not count any 1020 chunk padding. However, it does include any padding of variable- 1021 length parameters other than the last parameter in the chunk. 1023 Note: A robust implementation is expected to accept the chunk 1024 whether or not the final padding has been included in the Chunk 1025 Length. 1027 Chunk Value: variable length 1028 The Chunk Value field contains the actual information to be 1029 transferred in the chunk. The usage and format of this field is 1030 dependent on the Chunk Type. 1032 The total length of a chunk (including Type, Length, and Value 1033 fields) MUST be a multiple of 4 bytes. If the length of the chunk is 1034 not a multiple of 4 bytes, the sender MUST pad the chunk with all 1035 zero bytes, and this padding is not included in the Chunk Length 1036 field. The sender MUST NOT pad with more than 3 bytes. The receiver 1037 MUST ignore the padding bytes. 1039 SCTP-defined chunks are described in detail in Section 3.3. The 1040 guidelines for IETF-defined chunk extensions can be found in 1041 Section 15.1 of this document. 1043 3.2.1. Optional/Variable-Length Parameter Format 1045 Chunk values of SCTP control chunks consist of a chunk-type-specific 1046 header of required fields, followed by zero or more parameters. The 1047 optional and variable-length parameters contained in a chunk are 1048 defined in a Type-Length-Value format as shown below. 1050 0 1 2 3 1051 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 1052 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1053 | Parameter Type | Parameter Length | 1054 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1055 \ \ 1056 / Parameter Value / 1057 \ \ 1058 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1060 Parameter Type: 16 bits (unsigned integer) 1061 The Type field is a 16-bit identifier of the type of parameter. 1062 It takes a value of 0 to 65534. 1064 The value of 65535 is reserved for IETF-defined extensions. 1065 Values other than those defined in specific SCTP chunk 1066 descriptions are reserved for use by IETF. 1068 Parameter Length: 16 bits (unsigned integer) 1069 The Parameter Length field contains the size of the parameter in 1070 bytes, including the Parameter Type, Parameter Length, and 1071 Parameter Value fields. Thus, a parameter with a zero-length 1072 Parameter Value field would have a Parameter Length field of 4. 1073 The Parameter Length does not include any padding bytes. 1075 Parameter Value: variable length 1076 The Parameter Value field contains the actual information to be 1077 transferred in the parameter. 1079 The total length of a parameter (including Parameter Type, Parameter 1080 Length, and Parameter Value fields) MUST be a multiple of 4 bytes. 1081 If the length of the parameter is not a multiple of 4 bytes, the 1082 sender pads the parameter at the end (i.e., after the Parameter Value 1083 field) with all zero bytes. The length of the padding is not 1084 included in the Parameter Length field. A sender MUST NOT pad with 1085 more than 3 bytes. The receiver MUST ignore the padding bytes. 1087 The Parameter Types are encoded such that the highest-order 2 bits 1088 specify the action that is taken if the processing endpoint does not 1089 recognize the Parameter Type. 1091 +----+-------------------------------------------------------+ 1092 | 00 | Stop processing this parameter; do not process any | 1093 | | further parameters within this chunk. | 1094 +----+-------------------------------------------------------+ 1095 | 01 | Stop processing this parameter, do not process any | 1096 | | further parameters within this chunk, and report the | 1097 | | unrecognized parameter as described in Section 3.2.2. | 1098 +----+-------------------------------------------------------+ 1099 | 10 | Skip this parameter and continue processing. | 1100 +----+-------------------------------------------------------+ 1101 | 11 | Skip this parameter and continue processing but | 1102 | | report the unrecognized parameter as described in | 1103 | | Section 3.2.2. | 1104 +----+-------------------------------------------------------+ 1106 Table 3: Processing of Unknown Parameters 1108 Please note that, when an INIT or INIT ACK chunk is received, in all 1109 four cases, an INIT ACK or COOKIE ECHO chunk is sent in response, 1110 respectively. In the 00 or 01 case, the processing of the parameters 1111 after the unknown parameter is canceled, but no processing already 1112 done is rolled back. 1114 The actual SCTP parameters are defined in the specific SCTP chunk 1115 sections. The rules for IETF-defined parameter extensions are 1116 defined in Section 15.3. Parameter types MUST be unique across all 1117 chunks. For example, the parameter type '5' is used to represent an 1118 IPv4 address (see Section 3.3.2.1). The value '5' then is reserved 1119 across all chunks to represent an IPv4 address and MUST NOT be reused 1120 with a different meaning in any other chunk. 1122 3.2.2. Reporting of Unrecognized Parameters 1124 If the receiver of an INIT chunk detects unrecognized parameters and 1125 has to report them according to Section 3.2.1, it MUST put the 1126 "Unrecognized Parameter" parameter(s) in the INIT ACK chunk sent in 1127 response to the INIT chunk. Note that if the receiver of the INIT 1128 chunk is not going to establish an association (e.g., due to lack of 1129 resources), an "Unrecognized Parameter" error cause would not be 1130 included with any ABORT chunk being sent to the sender of the INIT 1131 chunk. 1133 If the receiver of any other chunk (e.g., INIT ACK) detects 1134 unrecognized parameters and has to report them according to 1135 Section 3.2.1, it SHOULD bundle the ERROR chunk containing the 1136 "Unrecognized Parameters" error cause with the chunk sent in response 1137 (e.g., COOKIE ECHO). If the receiver of an INIT ACK chunk cannot 1138 bundle the COOKIE ECHO chunk with the ERROR chunk, the ERROR chunk 1139 MAY be sent separately but not before the COOKIE ACK chunk has been 1140 received. 1142 Any time a COOKIE ECHO chunk is sent in a packet, it MUST be the 1143 first chunk. 1145 3.3. SCTP Chunk Definitions 1147 This section defines the format of the different SCTP chunk types. 1149 3.3.1. Payload Data (DATA) (0) 1151 The following format MUST be used for the DATA chunk: 1153 0 1 2 3 1154 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 1155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1156 | Type = 0 | Res |I|U|B|E| Length | 1157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1158 | TSN | 1159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1160 | Stream Identifier S | Stream Sequence Number n | 1161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1162 | Payload Protocol Identifier | 1163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1164 \ \ 1165 / User Data (seq n of Stream S) / 1166 \ \ 1167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1169 Res: 4 bits 1170 All set to 0 on transmit and ignored on receipt. 1172 I bit: 1 bit 1173 The (I)mmediate bit MAY be set by the sender whenever the sender 1174 of a DATA chunk can benefit from the corresponding SACK chunk 1175 being sent back without delay. See Section 4 of [RFC7053] for a 1176 discussion of the benefits. 1178 U bit: 1 bit 1179 The (U)nordered bit, if set to 1, indicates that this is an 1180 unordered DATA chunk, and there is no Stream Sequence Number 1181 assigned to this DATA chunk. Therefore, the receiver MUST ignore 1182 the Stream Sequence Number field. 1184 After reassembly (if necessary), unordered DATA chunks MUST be 1185 dispatched to the upper layer by the receiver without any attempt 1186 to reorder. 1188 If an unordered user message is fragmented, each fragment of the 1189 message MUST have its U bit set to 1. 1191 B bit: 1 bit 1192 The (B)eginning fragment bit, if set, indicates the first fragment 1193 of a user message. 1195 E bit: 1 bit 1196 The (E)nding fragment bit, if set, indicates the last fragment of 1197 a user message. 1199 Length: 16 bits (unsigned integer) 1200 This field indicates the length of the DATA chunk in bytes from 1201 the beginning of the type field to the end of the User Data field 1202 excluding any padding. A DATA chunk with one byte of user data 1203 will have Length set to 17 (indicating 17 bytes). 1205 A DATA chunk with a User Data field of length L will have the 1206 Length field set to (16 + L) (indicating 16 + L bytes) where L 1207 MUST be greater than 0. 1209 TSN: 32 bits (unsigned integer) 1210 This value represents the TSN for this DATA chunk. The valid 1211 range of TSN is from 0 to 4294967295 (2^32 - 1). TSN wraps back 1212 to 0 after reaching 4294967295. 1214 Stream Identifier S: 16 bits (unsigned integer) 1215 Identifies the stream to which the following user data belongs. 1217 Stream Sequence Number n: 16 bits (unsigned integer) 1218 This value represents the Stream Sequence Number of the following 1219 user data within the stream S. Valid range is 0 to 65535. 1221 When a user message is fragmented by SCTP for transport, the same 1222 Stream Sequence Number MUST be carried in each of the fragments of 1223 the message. 1225 Payload Protocol Identifier: 32 bits (unsigned integer) 1226 This value represents an application (or upper layer) specified 1227 protocol identifier. This value is passed to SCTP by its upper 1228 layer and sent to its peer. This identifier is not used by SCTP 1229 but can be used by certain network entities, as well as by the 1230 peer application, to identify the type of information being 1231 carried in this DATA chunk. This field MUST be sent even in 1232 fragmented DATA chunks (to make sure it is available for agents in 1233 the middle of the network). Note that this field is not touched 1234 by an SCTP implementation; The upper layer is responsible for the 1235 host to network byte order conversion of this field. 1237 The value 0 indicates that no application identifier is specified 1238 by the upper layer for this payload data. 1240 User Data: variable length 1241 This is the payload user data. The implementation MUST pad the 1242 end of the data to a 4-byte boundary with all-zero bytes. Any 1243 padding MUST NOT be included in the Length field. A sender MUST 1244 never add more than 3 bytes of padding. 1246 An unfragmented user message MUST have both the B and E bits set to 1247 1. Setting both B and E bits to 0 indicates a middle fragment of a 1248 multi-fragment user message, as summarized in the following table: 1250 +---+---+-------------------------------------------+ 1251 | B | E | Description | 1252 +---+---+-------------------------------------------+ 1253 | 1 | 0 | First piece of a fragmented user message | 1254 +---+---+-------------------------------------------+ 1255 | 0 | 0 | Middle piece of a fragmented user message | 1256 +---+---+-------------------------------------------+ 1257 | 0 | 1 | Last piece of a fragmented user message | 1258 +---+---+-------------------------------------------+ 1259 | 1 | 1 | Unfragmented message | 1260 +---+---+-------------------------------------------+ 1262 Table 4: Fragment Description Flags 1264 When a user message is fragmented into multiple chunks, the TSNs are 1265 used by the receiver to reassemble the message. This means that the 1266 TSNs for each fragment of a fragmented user message MUST be strictly 1267 sequential. 1269 The TSNs of DATA chunks sent SHOULD be strictly sequential. 1271 Note: The extension described in [RFC8260] can be used to mitigate 1272 the head of line blocking when transferring large user messages. 1274 3.3.2. Initiation (INIT) (1) 1276 This chunk is used to initiate an SCTP association between two 1277 endpoints. The format of the INIT chunk is shown below: 1279 0 1 2 3 1280 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 1281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1282 | Type = 1 | Chunk Flags | Chunk Length | 1283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1284 | Initiate Tag | 1285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1286 | Advertised Receiver Window Credit (a_rwnd) | 1287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1288 | Number of Outbound Streams | Number of Inbound Streams | 1289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1290 | Initial TSN | 1291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1292 \ \ 1293 / Optional/Variable-Length Parameters / 1294 \ \ 1295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1297 The following parameters are specified for the INIT chunk. Unless 1298 otherwise noted, each parameter MUST only be included once in the 1299 INIT chunk. 1301 +-----------------------------------+-----------+ 1302 | Fixed Length Parameter | Status | 1303 +-----------------------------------+-----------+ 1304 | Initiate Tag | Mandatory | 1305 +-----------------------------------+-----------+ 1306 | Advertised Receiver Window Credit | Mandatory | 1307 +-----------------------------------+-----------+ 1308 | Number of Outbound Streams | Mandatory | 1309 +-----------------------------------+-----------+ 1310 | Number of Inbound Streams | Mandatory | 1311 +-----------------------------------+-----------+ 1312 | Initial TSN | Mandatory | 1313 +-----------------------------------+-----------+ 1315 Table 5: Fixed Length Parameters of INIT Chunks 1317 +-----------------------------------+------------+----------------+ 1318 | Variable Length Parameter | Status | Type Value | 1319 +-----------------------------------+------------+----------------+ 1320 | IPv4 Address (Note 1) | Optional | 5 | 1321 +-----------------------------------+------------+----------------+ 1322 | IPv6 Address (Note 1) | Optional | 6 | 1323 +-----------------------------------+------------+----------------+ 1324 | Cookie Preservative | Optional | 9 | 1325 +-----------------------------------+------------+----------------+ 1326 | Reserved for ECN Capable (Note 2) | Optional | 32768 (0x8000) | 1327 +-----------------------------------+------------+----------------+ 1328 | Host Name Address (Note 3) | Deprecated | 11 | 1329 +-----------------------------------+------------+----------------+ 1330 | Supported Address Types (Note 4) | Optional | 12 | 1331 +-----------------------------------+------------+----------------+ 1333 Table 6: Variable Length Parameters of INIT Chunks 1335 Note 1: The INIT chunks can contain multiple addresses that can be 1336 IPv4 and/or IPv6 in any combination. 1338 Note 2: The ECN Capable field is reserved for future use of Explicit 1339 Congestion Notification. 1341 Note 3: An INIT chunk MUST NOT contain the Host Name Address 1342 parameter. The receiver of an INIT chunk containing a Host Name 1343 Address parameter MUST send an ABORT chunk and MAY include an 1344 "Unresolvable Address" error cause. 1346 Note 4: This parameter, when present, specifies all the address types 1347 the sending endpoint can support. The absence of this parameter 1348 indicates that the sending endpoint can support any address type. 1350 If an INIT chunk is received with all mandatory parameters that are 1351 specified for the INIT chunk, then the receiver SHOULD process the 1352 INIT chunk and send back an INIT ACK. The receiver of the INIT chunk 1353 MAY bundle an ERROR chunk with the COOKIE ACK chunk later. However, 1354 restrictive implementations MAY send back an ABORT chunk in response 1355 to the INIT chunk. 1357 The Chunk Flags field in INIT chunks is reserved, and all bits in it 1358 SHOULD be set to 0 by the sender and ignored by the receiver. 1360 Initiate Tag: 32 bits (unsigned integer) 1361 The receiver of the INIT chunk (the responding end) records the 1362 value of the Initiate Tag parameter. This value MUST be placed 1363 into the Verification Tag field of every SCTP packet that the 1364 receiver of the INIT chunk transmits within this association. 1366 The Initiate Tag is allowed to have any value except 0. See 1367 Section 5.3.1 for more on the selection of the tag value. 1369 If the value of the Initiate Tag in a received INIT chunk is found 1370 to be 0, the receiver MUST silently discard the packet. 1372 Advertised Receiver Window Credit (a_rwnd): 32 bits (unsigned 1373 integer) 1374 This value represents the dedicated buffer space, in number of 1375 bytes, the sender of the INIT chunk has reserved in association 1376 with this window. 1378 The Advertised Receiver Window Credit MUST NOT be smaller than 1379 1500. 1381 A receiver of an INIT chunk with the a_rwnd value set to a value 1382 smaller than 1500 MUST discard the packet, SHOULD send a packet in 1383 response containing an ABORT chunk and using the Initiate Tag as 1384 the Verification Tag, and MUST NOT change the state of any 1385 existing association. 1387 During the life of the association, this buffer space SHOULD NOT 1388 be reduced (i.e., dedicated buffers ought not to be taken away 1389 from this association); however, an endpoint MAY change the value 1390 of a_rwnd it sends in SACK chunks. 1392 Number of Outbound Streams (OS): 16 bits (unsigned integer) 1393 Defines the number of outbound streams the sender of this INIT 1394 chunk wishes to create in this association. The value of 0 MUST 1395 NOT be used. 1397 A receiver of an INIT chunk with the OS value set to 0 MUST 1398 discard the packet, SHOULD send a packet in response containing an 1399 ABORT chunk and using the Initiate Tag as the Verification Tag, 1400 and MUST NOT change the state of any existing association. 1402 Number of Inbound Streams (MIS): 16 bits (unsigned integer) 1403 Defines the maximum number of streams the sender of this INIT 1404 chunk allows the peer end to create in this association. The 1405 value 0 MUST NOT be used. 1407 Note: There is no negotiation of the actual number of streams but 1408 instead the two endpoints will use the min(requested, offered). 1409 See Section 5.1.1 for details. 1411 A receiver of an INIT chunk with the MIS value set to 0 MUST 1412 discard the packet, SHOULD send a packet in response containing an 1413 ABORT chunk and using the Initiate Tag as the Verification Tag, 1414 and MUST NOT change the state of any existing association. 1416 Initial TSN (I-TSN): 32 bits (unsigned integer) 1417 Defines the initial TSN that the sender of the INIT chunk will 1418 use. The valid range is from 0 to 4294967295 and the Initial TSN 1419 SHOULD be set to a random value in that range. The methods 1420 described in [RFC4086] can be used for the Initial TSN 1421 randomization. 1423 3.3.2.1. Optional or Variable-Length Parameters in INIT chunks 1425 The following parameters follow the Type-Length-Value format as 1426 defined in Section 3.2.1. Any Type-Length-Value fields MUST be 1427 placed after the fixed-length fields. (The fixed-length fields are 1428 defined in the previous section.) 1430 3.3.2.1.1. IPv4 Address (5) 1432 0 1 2 3 1433 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 1434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1435 | Type = 5 | Length = 8 | 1436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1437 | IPv4 Address | 1438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1440 IPv4 Address: 32 bits (unsigned integer) 1441 Contains an IPv4 address of the sending endpoint. It is binary 1442 encoded. 1444 3.3.2.1.2. IPv6 Address (6) 1446 0 1 2 3 1447 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 1448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1449 | Type = 6 | Length = 20 | 1450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1451 | | 1452 | IPv6 Address | 1453 | | 1454 | | 1455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1457 IPv6 Address: 128 bits (unsigned integer) 1458 Contains an IPv6 [RFC8200] address of the sending endpoint. It is 1459 binary encoded. 1461 A sender MUST NOT use an IPv4-mapped IPv6 address [RFC4291], but 1462 SHOULD instead use an IPv4 Address parameter for an IPv4 address. 1464 Combined with the Source Port Number in the SCTP common header, the 1465 value passed in an IPv4 or IPv6 Address parameter indicates a 1466 transport address the sender of the INIT chunk will support for the 1467 association being initiated. That is, during the life time of this 1468 association, this IP address can appear in the source address field 1469 of an IP datagram sent from the sender of the INIT chunk, and can be 1470 used as a destination address of an IP datagram sent from the 1471 receiver of the INIT chunk. 1473 More than one IP Address parameter can be included in an INIT chunk 1474 when the sender of the INIT chunk is multi-homed. Moreover, a multi- 1475 homed endpoint might have access to different types of network; thus, 1476 more than one address type can be present in one INIT chunk, i.e., 1477 IPv4 and IPv6 addresses are allowed in the same INIT chunk. 1479 If the INIT chunk contains at least one IP Address parameter, then 1480 the source address of the IP datagram containing the INIT chunk and 1481 any additional address(es) provided within the INIT can be used as 1482 destinations by the endpoint receiving the INIT chunk. If the INIT 1483 chunk does not contain any IP Address parameters, the endpoint 1484 receiving the INIT chunk MUST use the source address associated with 1485 the received IP datagram as its sole destination address for the 1486 association. 1488 Note that not using any IP Address parameters in the INIT and INIT 1489 ACK chunk is a way to make an association more likely to work in 1490 combination with Network Address Translation (NAT). 1492 3.3.2.1.3. Cookie Preservative (9) 1494 The sender of the INIT chunk uses this parameter to suggest to the 1495 receiver of the INIT chunk a longer life-span for the State Cookie. 1497 0 1 2 3 1498 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 1499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1500 | Type = 9 | Length = 8 | 1501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1502 | Suggested Cookie Life-Span Increment (msec.) | 1503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1505 Suggested Cookie Life-Span Increment: 32 bits (unsigned integer) 1506 This parameter indicates to the receiver how much increment in 1507 milliseconds the sender wishes the receiver to add to its default 1508 cookie life-span. 1510 This optional parameter MAY be added to the INIT chunk by the 1511 sender when it reattempts establishing an association with a peer 1512 to which its previous attempt of establishing the association 1513 failed due to a stale cookie operation error. The receiver MAY 1514 choose to ignore the suggested cookie life-span increase for its 1515 own security reasons. 1517 3.3.2.1.4. Host Name Address (11) 1519 The sender of an INIT chunk or INIT ACK chunk MUST NOT include this 1520 parameter. The usage of the Host Name Address parameter is 1521 deprecated. The receiver of an INIT chunk or an INIT ACK containing 1522 a Host Name Address parameter MUST send an ABORT chunk and MAY 1523 include an "Unresolvable Address" error cause. 1525 0 1 2 3 1526 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 1527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1528 | Type = 11 | Length | 1529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1530 / Host Name / 1531 \ \ 1532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1534 Host Name: variable length 1535 This field contains a host name in "host name syntax" per 1536 Section 2.1 of [RFC1123]. The method for resolving the host name 1537 is out of scope of SCTP. 1539 At least one null terminator is included in the Host Name string 1540 and MUST be included in the length. 1542 3.3.2.1.5. Supported Address Types (12) 1544 The sender of INIT chunk uses this parameter to list all the address 1545 types it can support. 1547 0 1 2 3 1548 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 1549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1550 | Type = 12 | Length | 1551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1552 | Address Type #1 | Address Type #2 | 1553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1554 | ...... | 1555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+ 1557 Address Type: 16 bits (unsigned integer) 1558 This is filled with the type value of the corresponding address 1559 TLV (e.g., 5 for indicating IPv4, 6 for indicating IPv6). The 1560 value indicating the Host Name Address parameter MUST NOT be used 1561 when sending this parameter and MUST be ignored when receiving 1562 this parameter. 1564 3.3.3. Initiation Acknowledgement (INIT ACK) (2) 1566 The INIT ACK chunk is used to acknowledge the initiation of an SCTP 1567 association. The format of the INIT ACK chunk is shown below: 1569 0 1 2 3 1570 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 1571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1572 | Type = 2 | Chunk Flags | Chunk Length | 1573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1574 | Initiate Tag | 1575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1576 | Advertised Receiver Window Credit | 1577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1578 | Number of Outbound Streams | Number of Inbound Streams | 1579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1580 | Initial TSN | 1581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1582 \ \ 1583 / Optional/Variable-Length Parameters / 1584 \ \ 1585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1587 The parameter part of INIT ACK is formatted similarly to the INIT 1588 chunk. The following parameters are specified for the INIT ACK 1589 chunk: 1591 +-----------------------------------+-----------+ 1592 | Fixed Length Parameter | Status | 1593 +-----------------------------------+-----------+ 1594 | Initiate Tag | Mandatory | 1595 +-----------------------------------+-----------+ 1596 | Advertised Receiver Window Credit | Mandatory | 1597 +-----------------------------------+-----------+ 1598 | Number of Outbound Streams | Mandatory | 1599 +-----------------------------------+-----------+ 1600 | Number of Inbound Streams | Mandatory | 1601 +-----------------------------------+-----------+ 1602 | Initial TSN | Mandatory | 1603 +-----------------------------------+-----------+ 1605 Table 7: Fixed Length Parameters of INIT ACK 1606 Chunks 1608 It uses two extra variable parameters: The State Cookie and the 1609 Unrecognized Parameter: 1611 +-----------------------------------+------------+----------------+ 1612 | Variable Length Parameter | Status | Type Value | 1613 +-----------------------------------+------------+----------------+ 1614 | State Cookie | Mandatory | 7 | 1615 +-----------------------------------+------------+----------------+ 1616 | IPv4 Address (Note 1) | Optional | 5 | 1617 +-----------------------------------+------------+----------------+ 1618 | IPv6 Address (Note 1) | Optional | 6 | 1619 +-----------------------------------+------------+----------------+ 1620 | Unrecognized Parameter | Optional | 8 | 1621 +-----------------------------------+------------+----------------+ 1622 | Reserved for ECN Capable (Note 2) | Optional | 32768 (0x8000) | 1623 +-----------------------------------+------------+----------------+ 1624 | Host Name Address (Note 3) | Deprecated | 11 | 1625 +-----------------------------------+------------+----------------+ 1627 Table 8: Variable Length Parameters of INIT ACK Chunks 1629 Note 1: The INIT ACK chunks can contain any number of IP address 1630 parameters that can be IPv4 and/or IPv6 in any combination. 1632 Note 2: The ECN Capable field is reserved for future use of Explicit 1633 Congestion Notification. 1635 Note 3: An INIT ACK chunk MUST NOT contain the Host Name Address 1636 parameter. The receiver of INIT ACK chunks containing a Host Name 1637 Address parameter MUST send an ABORT chunk and MAY include an 1638 "Unresolvable Address" error cause. 1640 The Chunk Flags field in INIT ACK chunks is reserved, and all bits in 1641 it SHOULD be set to 0 by the sender and ignored by the receiver. 1643 Initiate Tag: 32 bits (unsigned integer) 1644 The receiver of the INIT ACK chunk records the value of the 1645 Initiate Tag parameter. This value MUST be placed into the 1646 Verification Tag field of every SCTP packet that the receiver of 1647 the INIT ACK chunk transmits within this association. 1649 The Initiate Tag MUST NOT take the value 0. See Section 5.3.1 for 1650 more on the selection of the Initiate Tag value. 1652 If an endpoint in the COOKIE-WAIT state receives an INIT ACK chunk 1653 with the Initiate Tag set to 0, it MUST destroy the TCB and SHOULD 1654 send an ABORT chunk with the T bit set. If such an INIT-ACK chunk 1655 is received in any state other than CLOSED or COOKIE-WAIT, it 1656 SHOULD be discarded silently (see Section 5.2.3). 1658 Advertised Receiver Window Credit (a_rwnd): 32 bits (unsigned 1659 integer) 1660 This value represents the dedicated buffer space, in number of 1661 bytes, the sender of the INIT ACK chunk has reserved in 1662 association with this window. 1664 The Advertised Receiver Window Credit MUST NOT be smaller than 1665 1500. 1667 A receiver of an INIT ACK chunk with the a_rwnd value set to a 1668 value smaller than 1500 MUST discard the packet, SHOULD send a 1669 packet in response containing an ABORT chunk and using the 1670 Initiate Tag as the Verification Tag, and MUST NOT change the 1671 state of any existing association. 1673 During the life of the association, this buffer space SHOULD NOT 1674 be reduced (i.e., dedicated buffers ought not to be taken away 1675 from this association); however, an endpoint MAY change the value 1676 of a_rwnd it sends in SACK chunks. 1678 Number of Outbound Streams (OS): 16 bits (unsigned integer) 1679 Defines the number of outbound streams the sender of this INIT ACK 1680 chunk wishes to create in this association. The value of 0 MUST 1681 NOT be used, and the value MUST NOT be greater than the MIS value 1682 sent in the INIT chunk. 1684 If an endpoint in the COOKIE-WAIT state receives an INIT ACK chunk 1685 with the OS value set to 0, it MUST destroy the TCB and SHOULD 1686 send an ABORT chunk. If such an INIT-ACK chunk is received in any 1687 state other than CLOSED or COOKIE-WAIT, it SHOULD be discarded 1688 silently (see Section 5.2.3). 1690 Number of Inbound Streams (MIS): 16 bits (unsigned integer) 1691 Defines the maximum number of streams the sender of this INIT ACK 1692 chunk allows the peer end to create in this association. The 1693 value 0 MUST NOT be used. 1695 Note: There is no negotiation of the actual number of streams but 1696 instead the two endpoints will use the min(requested, offered). 1697 See Section 5.1.1 for details. 1699 If an endpoint in the COOKIE-WAIT state receives an INIT ACK chunk 1700 with the MIS value set to 0, it MUST destroy the TCB and SHOULD 1701 send an ABORT chunk. If such an INIT-ACK chunk is received in any 1702 state other than CLOSED or COOKIE-WAIT, it SHOULD be discarded 1703 silently (see Section 5.2.3). 1705 Initial TSN (I-TSN): 32 bits (unsigned integer) 1706 Defines the initial TSN that the sender of the INIT ACK chunk will 1707 use. The valid range is from 0 to 4294967295 and the Initial TSN 1708 SHOULD be set to a random value in that range. The methods 1709 described in [RFC4086] can be used for the Initial TSN 1710 randomization. 1712 Implementation Note: An implementation MUST be prepared to receive an 1713 INIT ACK chunk that is quite large (more than 1500 bytes) due to the 1714 variable size of the State Cookie and the variable address list. For 1715 example if a responder to the INIT chunk has 1000 IPv4 addresses it 1716 wishes to send, it would need at least 8,000 bytes to encode this in 1717 the INIT ACK chunk. 1719 If an INIT ACK chunk is received with all mandatory parameters that 1720 are specified for the INIT ACK chunk, then the receiver SHOULD 1721 process the INIT ACK chunk and send back a COOKIE ECHO chunk. The 1722 receiver of the INIT ACK chunk MAY bundle an ERROR chunk with the 1723 COOKIE ECHO chunk. However, restrictive implementations MAY send 1724 back an ABORT chunk in response to the INIT ACK chunk. 1726 In combination with the Source Port carried in the SCTP common 1727 header, each IP Address parameter in the INIT ACK chunk indicates to 1728 the receiver of the INIT ACK chunk a valid transport address 1729 supported by the sender of the INIT ACK chunk for the life time of 1730 the association being initiated. 1732 If the INIT ACK chunk contains at least one IP Address parameter, 1733 then the source address of the IP datagram containing the INIT ACK 1734 chunk and any additional address(es) provided within the INIT ACK 1735 chunk MAY be used as destinations by the receiver of the INIT ACK 1736 chunk. If the INIT ACK chunk does not contain any IP Address 1737 parameters, the receiver of the INIT ACK chunk MUST use the source 1738 address associated with the received IP datagram as its sole 1739 destination address for the association. 1741 The State Cookie and Unrecognized Parameters use the Type-Length- 1742 Value format as defined in Section 3.2.1 and are described below. 1743 The other fields are defined the same as their counterparts in the 1744 INIT chunk. 1746 3.3.3.1. Optional or Variable-Length Parameters in INIT ACK chunks 1748 The State Cookie and Unrecognized Parameters use the Type-Length- 1749 Value format as defined in Section 3.2.1 and are described below. 1750 The IPv4 Address Parameter is described in Section 3.3.2.1.1, and the 1751 IPv6 Address Parameter is described in Section 3.3.2.1.2. The Host 1752 Name Address Parameter is described in Section 3.3.2.1.4 and MUST NOT 1753 be included in an INIT ACK chunk. Any Type-Length-Value fields MUST 1754 be placed after the fixed-length fields. (The fixed-length fields 1755 are defined in the previous section.) 1757 3.3.3.1.1. State Cookie (7) 1759 0 1 2 3 1760 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 1761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1762 | Type = 7 | Length | 1763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1764 / Cookie / 1765 \ \ 1766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1768 Cookie: variable length 1769 This parameter value MUST contain all the necessary state and 1770 parameter information required for the sender of this INIT ACK 1771 chunk to create the association, along with a Message 1772 Authentication Code (MAC). See Section 5.1.3 for details on State 1773 Cookie definition. 1775 3.3.3.1.2. Unrecognized Parameter (8) 1777 This parameter is returned to the originator of the INIT chunk when 1778 the INIT chunk contains an unrecognized parameter that has a type 1779 that indicates it SHOULD be reported to the sender. 1781 0 1 2 3 1782 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 1783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1784 | Type = 8 | Length | 1785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1786 / Unrecognized Parameter / 1787 \ \ 1788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1790 Unrecognized Parameter: variable length 1791 The parameter value field will contain an unrecognized parameter 1792 copied from the INIT chunk complete with Parameter Type, Length, 1793 and Value fields. 1795 3.3.4. Selective Acknowledgement (SACK) (3) 1797 This chunk is sent to the peer endpoint to acknowledge received DATA 1798 chunks and to inform the peer endpoint of gaps in the received 1799 subsequences of DATA chunks as represented by their TSNs. 1801 The SACK chunk MUST contain the Cumulative TSN Ack, Advertised 1802 Receiver Window Credit (a_rwnd), Number of Gap Ack Blocks, and Number 1803 of Duplicate TSNs fields. 1805 By definition, the value of the Cumulative TSN Ack parameter is the 1806 last TSN received before a break in the sequence of received TSNs 1807 occurs; the next TSN value following this one has not yet been 1808 received at the endpoint sending the SACK chunk. This parameter 1809 therefore acknowledges receipt of all TSNs less than or equal to its 1810 value. 1812 The handling of a_rwnd by the receiver of the SACK chunk is discussed 1813 in detail in Section 6.2.1. 1815 The SACK chunk also contains zero or more Gap Ack Blocks. Each Gap 1816 Ack Block acknowledges a subsequence of TSNs received following a 1817 break in the sequence of received TSNs. The Gap Ack Blocks SHOULD be 1818 isolated. This means that the TSN just before each Gap Ack Block and 1819 the TSN just after each Gap Ack Block have not been received. By 1820 definition, all TSNs acknowledged by Gap Ack Blocks are greater than 1821 the value of the Cumulative TSN Ack. 1823 0 1 2 3 1824 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 1825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1826 | Type = 3 | Chunk Flags | Chunk Length | 1827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1828 | Cumulative TSN Ack | 1829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1830 | Advertised Receiver Window Credit (a_rwnd) | 1831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1832 | Number of Gap Ack Blocks = N | Number of Duplicate TSNs = M | 1833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1834 | Gap Ack Block #1 Start | Gap Ack Block #1 End | 1835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1836 / / 1837 \ ... \ 1838 / / 1839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1840 | Gap Ack Block #N Start | Gap Ack Block #N End | 1841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1842 | Duplicate TSN 1 | 1843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1844 / / 1845 \ ... \ 1846 / / 1847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1848 | Duplicate TSN M | 1849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1851 Chunk Flags: 8 bits 1852 All set to 0 on transmit and ignored on receipt. 1854 Cumulative TSN Ack: 32 bits (unsigned integer) 1855 The largest TSN, such that all TSNs smaller than or equal to it 1856 have been received and the next one has not been received. In the 1857 case where no DATA chunk has been received, this value is set to 1858 the peer's Initial TSN minus one. 1860 Advertised Receiver Window Credit (a_rwnd): 32 bits (unsigned 1861 integer) 1862 This field indicates the updated receive buffer space in bytes of 1863 the sender of this SACK chunk; see Section 6.2.1 for details. 1865 Number of Gap Ack Blocks: 16 bits (unsigned integer) 1866 Indicates the number of Gap Ack Blocks included in this SACK 1867 chunk. 1869 Number of Duplicate TSNs: 16 bit 1870 This field contains the number of duplicate TSNs the endpoint has 1871 received. Each duplicate TSN is listed following the Gap Ack 1872 Block list. 1874 Gap Ack Blocks: 1875 These fields contain the Gap Ack Blocks. They are repeated for 1876 each Gap Ack Block up to the number of Gap Ack Blocks defined in 1877 the Number of Gap Ack Blocks field. All DATA chunks with TSNs 1878 greater than or equal to (Cumulative TSN Ack + Gap Ack Block 1879 Start) and less than or equal to (Cumulative TSN Ack + Gap Ack 1880 Block End) of each Gap Ack Block are assumed to have been received 1881 correctly. 1883 Gap Ack Block Start: 16 bits (unsigned integer) 1884 Indicates the Start offset TSN for this Gap Ack Block. To 1885 calculate the actual TSN number the Cumulative TSN Ack is added to 1886 this offset number. This calculated TSN identifies the lowest TSN 1887 in this Gap Ack Block that has been received. 1889 Gap Ack Block End: 16 bits (unsigned integer) 1890 Indicates the End offset TSN for this Gap Ack Block. To calculate 1891 the actual TSN number, the Cumulative TSN Ack is added to this 1892 offset number. This calculated TSN identifies the highest TSN in 1893 this Gap Ack Block that has been received. 1895 For example, assume that the receiver has the following DATA 1896 chunks newly arrived at the time when it decides to send a 1897 Selective ACK, 1899 ------------ 1900 | TSN = 17 | 1901 ------------ 1902 | | <- still missing 1903 ------------ 1904 | TSN = 15 | 1905 ------------ 1906 | TSN = 14 | 1907 ------------ 1908 | | <- still missing 1909 ------------ 1910 | TSN = 12 | 1911 ------------ 1912 | TSN = 11 | 1913 ------------ 1914 | TSN = 10 | 1915 ------------ 1917 then the parameter part of the SACK chunk MUST be constructed as 1918 follows (assuming the new a_rwnd is set to 4660 by the sender): 1920 +-------------------+-------------------+ 1921 | Cumulative TSN Ack = 12 | 1922 +-------------------+-------------------+ 1923 | a_rwnd = 4660 | 1924 +-------------------+-------------------+ 1925 | num of block = 2 | num of dup = 0 | 1926 +-------------------+-------------------+ 1927 |block #1 start = 2 | block #1 end = 3 | 1928 +-------------------+-------------------+ 1929 |block #2 start = 5 | block #2 end = 5 | 1930 +-------------------+-------------------+ 1932 Duplicate TSN: 32 bits (unsigned integer) 1933 Indicates the number of times a TSN was received in duplicate 1934 since the last SACK chunk was sent. Every time a receiver gets a 1935 duplicate TSN (before sending the SACK chunk), it adds it to the 1936 list of duplicates. The duplicate count is reinitialized to zero 1937 after sending each SACK chunk. 1939 For example, if a receiver were to get the TSN 19 three times it 1940 would list 19 twice in the outbound SACK chunk. After sending the 1941 SACK chunk, if it received yet one more TSN 19 it would list 19 as 1942 a duplicate once in the next outgoing SACK chunk. 1944 3.3.5. Heartbeat Request (HEARTBEAT) (4) 1946 An endpoint SHOULD send a HEARTBEAT (HB) chunk to its peer endpoint 1947 to probe the reachability of a particular destination transport 1948 address defined in the present association. 1950 The parameter field contains the Heartbeat Information, which is a 1951 variable-length opaque data structure understood only by the sender. 1953 0 1 2 3 1954 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 1955 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1956 | Type = 4 | Chunk Flags | Heartbeat Length | 1957 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1958 \ \ 1959 / Heartbeat Information TLV (Variable-Length) / 1960 \ \ 1961 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1963 Chunk Flags: 8 bits 1964 Set to 0 on transmit and ignored on receipt. 1966 Heartbeat Length: 16 bits (unsigned integer) 1967 Set to the size of the chunk in bytes, including the chunk header 1968 and the Heartbeat Information field. 1970 Heartbeat Information: variable length 1971 Defined as a variable-length parameter using the format described 1972 in Section 3.2.1, i.e.: 1974 +---------------------+-----------+------------+ 1975 | Variable Parameters | Status | Type Value | 1976 +---------------------+-----------+------------+ 1977 | Heartbeat Info | Mandatory | 1 | 1978 +---------------------+-----------+------------+ 1980 Table 9: Variable Length Parameters of 1981 HEARTBEAT Chunks 1983 0 1 2 3 1984 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 1985 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1986 | Heartbeat Info Type = 1 | HB Info Length | 1987 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1988 / Sender-Specific Heartbeat Info / 1989 \ \ 1990 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1992 The Sender-Specific Heartbeat Info field SHOULD include 1993 information about the sender's current time when this HEARTBEAT 1994 chunk is sent and the destination transport address to which this 1995 HEARTBEAT chunk is sent (see Section 8.3). This information is 1996 simply reflected back by the receiver in the HEARTBEAT ACK chunk 1997 (see Section 3.3.6). Note also that the HEARTBEAT chunk is both 1998 for reachability checking and for path verification (see 1999 Section 5.4). When a HEARTBEAT chunk is being used for path 2000 verification purposes, it MUST include a random nonce of length 2001 64-bit or longer ([RFC4086] provides some information on 2002 randomness guidelines). 2004 3.3.6. Heartbeat Acknowledgement (HEARTBEAT ACK) (5) 2006 An endpoint MUST send this chunk to its peer endpoint as a response 2007 to a HEARTBEAT chunk (see Section 8.3). A packet containing the 2008 HEARTBEAT ACK chunk is always sent to the source IP address of the IP 2009 datagram containing the HEARTBEAT chunk to which this HEARTBEAT ACK 2010 chunk is responding. 2012 The parameter field contains a variable-length opaque data structure. 2014 0 1 2 3 2015 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 2016 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2017 | Type = 5 | Chunk Flags | Heartbeat Ack Length | 2018 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2019 \ \ 2020 / Heartbeat Information TLV (Variable-Length) / 2021 \ \ 2022 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2024 Chunk Flags: 8 bits 2025 Set to 0 on transmit and ignored on receipt. 2027 Heartbeat Ack Length: 16 bits (unsigned integer) 2028 Set to the size of the chunk in bytes, including the chunk header 2029 and the Heartbeat Information field. 2031 Heartbeat Information: variable length 2032 This field MUST contain the Heartbeat Info parameter (as defined 2033 in Section 3.3.5) of the Heartbeat Request to which this Heartbeat 2034 Acknowledgement is responding. 2036 +---------------------+-----------+------------+ 2037 | Variable Parameters | Status | Type Value | 2038 +---------------------+-----------+------------+ 2039 | Heartbeat Info | Mandatory | 1 | 2040 +---------------------+-----------+------------+ 2042 Table 10: Variable Length Parameters of 2043 HEARTBEAT ACK Chunks 2045 3.3.7. Abort Association (ABORT) (6) 2047 The ABORT chunk is sent to the peer of an association to close the 2048 association. The ABORT chunk MAY contain Cause Parameters to inform 2049 the receiver about the reason of the abort. DATA chunks MUST NOT be 2050 bundled with ABORT chunks. Control chunks (except for INIT, INIT 2051 ACK, and SHUTDOWN COMPLETE) MAY be bundled with an ABORT chunk, but 2052 they MUST be placed before the ABORT chunk in the SCTP packet, 2053 otherwise they will be ignored by the receiver. 2055 If an endpoint receives an ABORT chunk with a format error or no TCB 2056 is found, it MUST silently discard it. Moreover, under any 2057 circumstances, an endpoint that receives an ABORT chunk MUST NOT 2058 respond to that ABORT chunk by sending an ABORT chunk of its own. 2060 0 1 2 3 2061 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 2062 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2063 | Type = 6 | Reserved |T| Length | 2064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2065 \ \ 2066 / zero or more Error Causes / 2067 \ \ 2068 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2070 Chunk Flags: 8 bits 2071 Reserved: 7 bits 2072 Set to 0 on transmit and ignored on receipt. 2074 T bit: 1 bit 2075 The T bit is set to 0 if the sender filled in the Verification 2076 Tag expected by the peer. If the Verification Tag is 2077 reflected, the T bit MUST be set to 1. Reflecting means that 2078 the sent Verification Tag is the same as the received one. 2080 Length: 16 bits (unsigned integer) 2081 Set to the size of the chunk in bytes, including the chunk header 2082 and all the Error Cause fields present. 2084 See Section 3.3.10 for Error Cause definitions. 2086 Note: Special rules apply to this chunk for verification; please see 2087 Section 8.5.1 for details. 2089 3.3.8. Shutdown Association (SHUTDOWN) (7) 2091 An endpoint in an association MUST use this chunk to initiate a 2092 graceful close of the association with its peer. This chunk has the 2093 following format. 2095 0 1 2 3 2096 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 2097 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2098 | Type = 7 | Chunk Flags | Length = 8 | 2099 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2100 | Cumulative TSN Ack | 2101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2103 Chunk Flags: 8 bits 2104 Set to 0 on transmit and ignored on receipt. 2106 Length: 16 bits (unsigned integer) 2107 Indicates the length of the parameter. Set to 8. 2109 Cumulative TSN Ack: 32 bits (unsigned integer) 2110 The largest TSN, such that all TSNs smaller than or equal to it 2111 have been received and the next one has not been received. 2113 Note: Since the SHUTDOWN chunk does not contain Gap Ack Blocks, it 2114 cannot be used to acknowledge TSNs received out of order. In a SACK 2115 chunk, lack of Gap Ack Blocks that were previously included indicates 2116 that the data receiver reneged on the associated DATA chunks. 2118 Since the SHUTDOWN chunk does not contain Gap Ack Blocks, the 2119 receiver of the SHUTDOWN chunk MUST NOT interpret the lack of a Gap 2120 Ack Block as a renege. (See Section 6.2 for information on 2121 reneging.) 2123 The sender of the SHUTDOWN chunk MAY bundle a SACK chunk to indicate 2124 any gaps in the received TSNs. 2126 3.3.9. Shutdown Acknowledgement (SHUTDOWN ACK) (8) 2128 This chunk MUST be used to acknowledge the receipt of the SHUTDOWN 2129 chunk at the completion of the shutdown process; see Section 9.2 for 2130 details. 2132 The SHUTDOWN ACK chunk has no parameters. 2134 0 1 2 3 2135 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 2136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2137 | Type = 8 | Chunk Flags | Length = 4 | 2138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2140 Chunk Flags: 8 bits 2141 Set to 0 on transmit and ignored on receipt. 2143 3.3.10. Operation Error (ERROR) (9) 2145 An endpoint sends this chunk to its peer endpoint to notify it of 2146 certain error conditions. It contains one or more error causes. An 2147 Operation Error is not considered fatal in and of itself, but the 2148 corresponding error cause MAY be used with an ABORT chunk to report a 2149 fatal condition. An ERROR chunk has the following format: 2151 0 1 2 3 2152 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 2153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2154 | Type = 9 | Chunk Flags | Length | 2155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2156 \ \ 2157 / one or more Error Causes / 2158 \ \ 2159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2161 Chunk Flags: 8 bits 2162 Set to 0 on transmit and ignored on receipt. 2164 Length: 16 bits (unsigned integer) 2165 Set to the size of the chunk in bytes, including the chunk header 2166 and all the Error Cause fields present. 2168 Error causes are defined as variable-length parameters using the 2169 format described in Section 3.2.1, that is: 2171 0 1 2 3 2172 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 2173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2174 | Cause Code | Cause Length | 2175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2176 / Cause-Specific Information / 2177 \ \ 2178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2180 Cause Code: 16 bits (unsigned integer) 2181 Defines the type of error conditions being reported. 2183 +-------+----------------------------------------------+ 2184 | Value | Cause Code | 2185 +-------+----------------------------------------------+ 2186 | 1 | Invalid Stream Identifier | 2187 +-------+----------------------------------------------+ 2188 | 2 | Missing Mandatory Parameter | 2189 +-------+----------------------------------------------+ 2190 | 3 | Stale Cookie Error | 2191 +-------+----------------------------------------------+ 2192 | 4 | Out of Resource | 2193 +-------+----------------------------------------------+ 2194 | 5 | Unresolvable Address | 2195 +-------+----------------------------------------------+ 2196 | 6 | Unrecognized Chunk Type | 2197 +-------+----------------------------------------------+ 2198 | 7 | Invalid Mandatory Parameter | 2199 +-------+----------------------------------------------+ 2200 | 8 | Unrecognized Parameters | 2201 +-------+----------------------------------------------+ 2202 | 9 | No User Data | 2203 +-------+----------------------------------------------+ 2204 | 10 | Cookie Received While Shutting Down | 2205 +-------+----------------------------------------------+ 2206 | 11 | Restart of an Association with New Addresses | 2207 +-------+----------------------------------------------+ 2208 | 12 | User Initiated Abort | 2209 +-------+----------------------------------------------+ 2210 | 13 | Protocol Violation | 2211 +-------+----------------------------------------------+ 2213 Table 11: Cause Code 2215 Cause Length: 16 bits (unsigned integer) 2216 Set to the size of the parameter in bytes, including the Cause 2217 Code, Cause Length, and Cause-Specific Information fields. 2219 Cause-Specific Information: variable length 2220 This field carries the details of the error condition. 2222 Section 3.3.10.1 - Section 3.3.10.13 define error causes for SCTP. 2223 Guidelines for the IETF to define new error cause values are 2224 discussed in Section 15.4. 2226 3.3.10.1. Invalid Stream Identifier (1) 2228 Indicates that the endpoint received a DATA chunk sent using a 2229 nonexistent stream. 2231 0 1 2 3 2232 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 2233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2234 | Cause Code = 1 | Cause Length = 8 | 2235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2236 | Stream Identifier | (Reserved) | 2237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2239 Stream Identifier: 16 bits (unsigned integer) 2240 Contains the Stream Identifier of the DATA chunk received in 2241 error. 2243 Reserved: 16 bits 2244 This field is reserved. It is set to all 0's on transmit and 2245 ignored on receipt. 2247 3.3.10.2. Missing Mandatory Parameter (2) 2249 Indicates that one or more mandatory TLV parameters are missing in a 2250 received INIT or INIT ACK chunk. 2252 0 1 2 3 2253 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 2254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2255 | Cause Code = 2 | Cause Length = 8 + N * 2 | 2256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2257 | Number of missing params = N | 2258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2259 | Missing Param Type #1 | Missing Param Type #2 | 2260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2261 | Missing Param Type #N-1 | Missing Param Type #N | 2262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2264 Number of Missing params: 32 bits (unsigned integer) 2265 This field contains the number of parameters contained in the 2266 Cause-Specific Information field. 2268 Missing Param Type: 16 bits (unsigned integer) 2269 Each field will contain the missing mandatory parameter number. 2271 3.3.10.3. Stale Cookie Error (3) 2273 Indicates the receipt of a valid State Cookie that has expired. 2275 0 1 2 3 2276 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 2277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2278 | Cause Code = 3 | Cause Length = 8 | 2279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2280 | Measure of Staleness (usec.) | 2281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2283 Measure of Staleness: 32 bits (unsigned integer) 2284 This field contains the difference, rounded up in microseconds, 2285 between the current time and the time the State Cookie expired. 2287 The sender of this error cause MAY choose to report how long past 2288 expiration the State Cookie is by including a non-zero value in 2289 the Measure of Staleness field. If the sender does not wish to 2290 provide the Measure of Staleness, it SHOULD set this field to the 2291 value of zero. 2293 3.3.10.4. Out of Resource (4) 2295 Indicates that the sender is out of resource. This is usually sent 2296 in combination with or within an ABORT chunk. 2298 0 1 2 3 2299 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 2300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2301 | Cause Code = 4 | Cause Length = 4 | 2302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2304 3.3.10.5. Unresolvable Address (5) 2306 Indicates that the sender is not able to resolve the specified 2307 address parameter (e.g., type of address is not supported by the 2308 sender). This is usually sent in combination with or within an ABORT 2309 chunk. 2311 0 1 2 3 2312 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 2313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2314 | Cause Code = 5 | Cause Length | 2315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2316 / Unresolvable Address / 2317 \ \ 2318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2320 Unresolvable Address: variable length 2321 The Unresolvable Address field contains the complete Type, Length, 2322 and Value of the address parameter (or Host Name parameter) that 2323 contains the unresolvable address or host name. 2325 3.3.10.6. Unrecognized Chunk Type (6) 2327 This error cause is returned to the originator of the chunk if the 2328 receiver does not understand the chunk and the upper bits of the 2329 'Chunk Type' are set to 01 or 11. 2331 0 1 2 3 2332 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 2333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2334 | Cause Code = 6 | Cause Length | 2335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2336 / Unrecognized Chunk / 2337 \ \ 2338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2340 Unrecognized Chunk: variable length 2341 The Unrecognized Chunk field contains the unrecognized chunk from 2342 the SCTP packet complete with Chunk Type, Chunk Flags, and Chunk 2343 Length. 2345 3.3.10.7. Invalid Mandatory Parameter (7) 2347 This error cause is returned to the originator of an INIT or INIT ACK 2348 chunk when one of the mandatory parameters is set to an invalid 2349 value. 2351 0 1 2 3 2352 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 2353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2354 | Cause Code = 7 | Cause Length = 4 | 2355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2357 3.3.10.8. Unrecognized Parameters (8) 2359 This error cause is returned to the originator of the INIT ACK chunk 2360 if the receiver does not recognize one or more Optional TLV 2361 parameters in the INIT ACK chunk. 2363 0 1 2 3 2364 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 2365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2366 | Cause Code = 8 | Cause Length | 2367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2368 / Unrecognized Parameters / 2369 \ \ 2370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2372 Unrecognized Parameters: variable length 2373 The Unrecognized Parameters field contains the unrecognized 2374 parameters copied from the INIT ACK chunk complete with TLV. This 2375 error cause is normally contained in an ERROR chunk bundled with 2376 the COOKIE ECHO chunk when responding to the INIT ACK chunk, when 2377 the sender of the COOKIE ECHO chunk wishes to report unrecognized 2378 parameters. 2380 3.3.10.9. No User Data (9) 2382 This error cause is returned to the originator of a DATA chunk if a 2383 received DATA chunk has no user data. 2385 0 1 2 3 2386 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 2387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2388 | Cause Code = 9 | Cause Length = 8 | 2389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2390 | TSN | 2391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2393 TSN: 32 bits (unsigned integer) 2394 This parameter contains the TSN of the DATA chunk received with no 2395 user data field. 2397 This cause code is normally returned in an ABORT chunk (see 2398 Section 6.2). 2400 3.3.10.10. Cookie Received While Shutting Down (10) 2402 A COOKIE ECHO chunk was received while the endpoint was in the 2403 SHUTDOWN-ACK-SENT state. This error is usually returned in an ERROR 2404 chunk bundled with the retransmitted SHUTDOWN ACK chunk. 2406 0 1 2 3 2407 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 2408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2409 | Cause Code = 10 | Cause Length = 4 | 2410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2412 3.3.10.11. Restart of an Association with New Addresses (11) 2414 An INIT chunk was received on an existing association. But the INIT 2415 chunk added addresses to the association that were previously not 2416 part of the association. The new addresses are listed in the error 2417 cause. This error cause is normally sent as part of an ABORT chunk 2418 refusing the INIT chunk (see Section 5.2). 2420 0 1 2 3 2421 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 2422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2423 | Cause Code = 11 | Cause Length | 2424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2425 / New Address TLVs / 2426 \ \ 2427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2429 Note: Each New Address TLV is an exact copy of the TLV that was found 2430 in the INIT chunk that was new, including the Parameter Type and the 2431 Parameter Length. 2433 3.3.10.12. User-Initiated Abort (12) 2435 This error cause MAY be included in ABORT chunks that are sent 2436 because of an upper-layer request. The upper layer can specify an 2437 Upper Layer Abort Reason that is transported by SCTP transparently 2438 and MAY be delivered to the upper-layer protocol at the peer. 2440 0 1 2 3 2441 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 2442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2443 | Cause Code = 12 | Cause Length | 2444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2445 / Upper Layer Abort Reason / 2446 \ \ 2447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2449 3.3.10.13. Protocol Violation (13) 2451 This error cause MAY be included in ABORT chunks that are sent 2452 because an SCTP endpoint detects a protocol violation of the peer 2453 that is not covered by the error causes described in Section 3.3.10.1 2454 to Section 3.3.10.12. An implementation MAY provide additional 2455 information specifying what kind of protocol violation has been 2456 detected. 2458 0 1 2 3 2459 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 2460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2461 | Cause Code = 13 | Cause Length | 2462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2463 / Additional Information / 2464 \ \ 2465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2467 3.3.11. Cookie Echo (COOKIE ECHO) (10) 2469 This chunk is used only during the initialization of an association. 2470 It is sent by the initiator of an association to its peer to complete 2471 the initialization process. This chunk MUST precede any DATA chunk 2472 sent within the association, but MAY be bundled with one or more DATA 2473 chunks in the same packet. 2475 0 1 2 3 2476 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 2477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2478 | Type = 10 | Chunk Flags | Length | 2479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2480 / Cookie / 2481 \ \ 2482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2484 Chunk Flags: 8 bits 2485 Set to 0 on transmit and ignored on receipt. 2487 Length: 16 bits (unsigned integer) 2488 Set to the size of the chunk in bytes, including the 4 bytes of 2489 the chunk header and the size of the cookie. 2491 Cookie: variable size 2492 This field MUST contain the exact cookie received in the State 2493 Cookie parameter from the previous INIT ACK chunk. 2495 An implementation SHOULD make the cookie as small as possible to 2496 ensure interoperability. 2498 Note: A Cookie Echo does not contain a State Cookie parameter; 2499 instead, the data within the State Cookie's Parameter Value 2500 becomes the data within the Cookie Echo's Chunk Value. This 2501 allows an implementation to change only the first 2 bytes of the 2502 State Cookie parameter to become a COOKIE ECHO chunk. 2504 3.3.12. Cookie Acknowledgement (COOKIE ACK) (11) 2506 This chunk is used only during the initialization of an association. 2507 It is used to acknowledge the receipt of a COOKIE ECHO chunk. This 2508 chunk MUST precede any DATA or SACK chunk sent within the 2509 association, but MAY be bundled with one or more DATA chunks or SACK 2510 chunk's in the same SCTP packet. 2512 0 1 2 3 2513 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 2514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2515 | Type = 11 | Chunk Flags | Length = 4 | 2516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2518 Chunk Flags: 8 bits 2519 Set to 0 on transmit and ignored on receipt. 2521 3.3.13. Shutdown Complete (SHUTDOWN COMPLETE) (14) 2523 This chunk MUST be used to acknowledge the receipt of the SHUTDOWN 2524 ACK chunk at the completion of the shutdown process; see Section 9.2 2525 for details. 2527 The SHUTDOWN COMPLETE chunk has no parameters. 2529 0 1 2 3 2530 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 2531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2532 | Type = 14 | Reserved |T| Length = 4 | 2533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2535 Chunk Flags: 8 bits 2536 Reserved: 7 bits 2537 Set to 0 on transmit and ignored on receipt. 2539 T bit: 1 bit 2540 The T bit is set to 0 if the sender filled in the Verification 2541 Tag expected by the peer. If the Verification Tag is 2542 reflected, the T bit MUST be set to 1. Reflecting means that 2543 the sent Verification Tag is the same as the received one. 2545 Note: Special rules apply to this chunk for verification, please see 2546 Section 8.5.1 for details. 2548 4. SCTP Association State Diagram 2550 During the life time of an SCTP association, the SCTP endpoint's 2551 association progresses from one state to another in response to 2552 various events. The events that might potentially advance an 2553 association's state include: 2555 * SCTP user primitive calls, e.g., [ASSOCIATE], [SHUTDOWN], [ABORT], 2557 * Reception of INIT, COOKIE ECHO, ABORT, SHUTDOWN, etc., control 2558 chunks, or 2560 * Some timeout events. 2562 The state diagram in the figures below illustrates state changes, 2563 together with the causing events and resulting actions. Note that 2564 some of the error conditions are not shown in the state diagram. 2565 Full descriptions of all special cases are found in the text. 2567 Note: Chunk names are given in all capital letters, while parameter 2568 names have the first letter capitalized, e.g., COOKIE ECHO chunk type 2569 vs. State Cookie parameter. If more than one event/message can occur 2570 that causes a state transition, it is labeled (A), (B). 2572 ----- -------- (from any state) 2573 / \ /receive ABORT [ABORT] 2574 receive INIT | | |-------------- or ---------- 2575 ---------------------| v v delete TCB send ABORT 2576 generate State Cookie \ +---------+ delete TCB 2577 send INIT ACK ---| CLOSED | 2578 +---------+ 2579 / \ 2580 / \ [ASSOCIATE] 2581 | |----------------- 2582 | | create TCB 2583 | | send INIT 2584 receive valid | | start T1-init timer 2585 COOKIE ECHO | v 2586 (1) -----------------| +-----------+ 2587 create TCB | |COOKIE-WAIT| (2) 2588 send COOKIE ACK | +-----------+ 2589 | | 2590 | | receive INIT ACK 2591 | |------------------- 2592 | | send COOKIE ECHO 2593 | | stop T1-init timer 2594 | | start T1-cookie timer 2595 | v 2596 | +-------------+ 2597 | |COOKIE-ECHOED| (3) 2598 | +-------------+ 2599 | | 2600 | | receive COOKIE ACK 2601 | |------------------- 2602 | | stop T1-cookie timer 2603 v v 2604 +---------------+ 2605 | ESTABLISHED | 2606 +---------------+ 2607 | 2608 | 2609 /--------+--------\ 2610 [SHUTDOWN] / \ 2611 -------------------| | 2612 check outstanding | | 2613 DATA chunks | | 2614 v | 2615 +----------------+ | 2616 |SHUTDOWN-PENDING| | receive SHUTDOWN 2617 +----------------+ |------------------ 2618 | check outstanding 2619 | | DATA chunks 2620 No more outstanding | | 2621 -----------------------| | 2622 send SHUTDOWN | | 2623 start T2-shutdown timer| | 2624 v v 2625 +-------------+ +-----------------+ 2626 (4) |SHUTDOWN-SENT| |SHUTDOWN-RECEIVED| (5,6) 2627 +-------------+ +-----------------+ 2628 | \ | 2629 receive SHUTDOWN ACK | \ | 2630 -----------------------| \ | 2631 stop T2-shutdown timer | \ | 2632 send SHUTDOWN COMPLETE | \ | 2633 delete TCB | \ | 2634 | \ | No more outstanding 2635 | \ |-------------------- 2636 | \ | send SHUTDOWN ACK 2637 receive SHUTDOWN -|- \ | start T2-shutdown timer 2638 --------------------/ | \----------\ | 2639 send SHUTDOWN ACK | \ | 2640 start T2-shutdown timer| \ | 2641 | \ | 2642 | | | 2643 | v v 2644 | +-----------------+ 2645 | |SHUTDOWN-ACK-SENT| (7) 2646 | +-----------------+ 2647 | | (A) 2648 | |receive SHUTDOWN COMPLETE 2649 | |------------------------- 2650 | | stop T2-shutdown timer 2651 | | delete TCB 2652 | | 2653 | | (B) 2654 | | receive SHUTDOWN ACK 2655 | |----------------------- 2656 | | stop T2-shutdown timer 2657 | | send SHUTDOWN COMPLETE 2658 | | delete TCB 2659 | | 2660 \ +---------+ / 2661 \-->| CLOSED |<--/ 2662 +---------+ 2664 Figure 3: State Transition Diagram of SCTP 2666 The following applies: 2668 1) If the State Cookie in the received COOKIE ECHO chunk is invalid 2669 (i.e., failed to pass the integrity check), the receiver MUST 2670 silently discard the packet. Or, if the received State Cookie is 2671 expired (see Section 5.1.5), the receiver MUST send back an ERROR 2672 chunk. In either case, the receiver stays in the CLOSED state. 2674 2) If the T1-init timer expires, the endpoint MUST retransmit the 2675 INIT chunk and restart the T1-init timer without changing state. 2676 This MUST be repeated up to 'Max.Init.Retransmits' times. After 2677 that, the endpoint MUST abort the initialization process and 2678 report the error to the SCTP user. 2680 3) If the T1-cookie timer expires, the endpoint MUST retransmit 2681 COOKIE ECHO chunk and restart the T1-cookie timer without 2682 changing state. This MUST be repeated up to 2683 'Max.Init.Retransmits' times. After that, the endpoint MUST 2684 abort the initialization process and report the error to the SCTP 2685 user. 2687 4) In the SHUTDOWN-SENT state, the endpoint MUST acknowledge any 2688 received DATA chunks without delay. 2690 5) In the SHUTDOWN-RECEIVED state, the endpoint MUST NOT accept any 2691 new send requests from its SCTP user. 2693 6) In the SHUTDOWN-RECEIVED state, the endpoint MUST transmit or 2694 retransmit data and leave this state when all data in queue is 2695 transmitted. 2697 7) In the SHUTDOWN-ACK-SENT state, the endpoint MUST NOT accept any 2698 new send requests from its SCTP user. 2700 The CLOSED state is used to indicate that an association is not 2701 created (i.e., does not exist). 2703 5. Association Initialization 2705 Before the first data transmission can take place from one SCTP 2706 endpoint ("A") to another SCTP endpoint ("Z"), the two endpoints MUST 2707 complete an initialization process in order to set up an SCTP 2708 association between them. 2710 The SCTP user at an endpoint can use the ASSOCIATE primitive to 2711 initialize an SCTP association to another SCTP endpoint. 2713 Implementation Note: From an SCTP user's point of view, an 2714 association might be implicitly opened, without an ASSOCIATE 2715 primitive (see Section 11.1.2) being invoked, by the initiating 2716 endpoint's sending of the first user data to the destination 2717 endpoint. The initiating SCTP will assume default values for all 2718 mandatory and optional parameters for the INIT/INIT ACK chunk. 2720 Once the association is established, unidirectional streams are open 2721 for data transfer on both ends (see Section 5.1.1). 2723 5.1. Normal Establishment of an Association 2725 The initialization process consists of the following steps (assuming 2726 that SCTP endpoint "A" tries to set up an association with SCTP 2727 endpoint "Z" and "Z" accepts the new association): 2729 A) "A" first builds a TCB and sends an INIT chunk to "Z". In the 2730 INIT chunk, "A" MUST provide its Verification Tag (Tag_A) in the 2731 Initiate Tag field. Tag_A SHOULD be a random number in the range 2732 of 1 to 4294967295 (see Section 5.3.1 for Tag value selection). 2733 After sending the INIT chunk, "A" starts the T1-init timer and 2734 enters the COOKIE-WAIT state. 2736 B) "Z" responds immediately with an INIT ACK chunk. The destination 2737 IP address of the INIT ACK chunk MUST be set to the source IP 2738 address of the INIT chunk to which this INIT ACK chunk is 2739 responding. In the response, besides filling in other 2740 parameters, "Z" MUST set the Verification Tag field to Tag_A, and 2741 also provide its own Verification Tag (Tag_Z) in the Initiate Tag 2742 field. 2744 Moreover, "Z" MUST generate and send along with the INIT ACK 2745 chunk a State Cookie. See Section 5.1.3 for State Cookie 2746 generation. 2748 After sending an INIT ACK chunk with the State Cookie parameter, 2749 "Z" MUST NOT allocate any resources or keep any states for the 2750 new association. Otherwise, "Z" will be vulnerable to resource 2751 attacks. 2753 C) Upon reception of the INIT ACK chunk from "Z", "A" stops the 2754 T1-init timer and leaves the COOKIE-WAIT state. "A" then sends 2755 the State Cookie received in the INIT ACK chunk in a COOKIE ECHO 2756 chunk, starts the T1-cookie timer, and enters the COOKIE-ECHOED 2757 state. 2759 The COOKIE ECHO chunk MAY be bundled with any pending outbound 2760 DATA chunks, but it MUST be the first chunk in the packet and 2761 until the COOKIE ACK chunk is returned the sender MUST NOT send 2762 any other packets to the peer. 2764 D) Upon reception of the COOKIE ECHO chunk, endpoint "Z" replies 2765 with a COOKIE ACK chunk after building a TCB and moving to the 2766 ESTABLISHED state. A COOKIE ACK chunk MAY be bundled with any 2767 pending DATA chunks (and/or SACK chunks), but the COOKIE ACK 2768 chunk MUST be the first chunk in the packet. 2770 Implementation Note: An implementation can choose to send the 2771 Communication Up notification to the SCTP user upon reception of 2772 a valid COOKIE ECHO chunk. 2774 E) Upon reception of the COOKIE ACK chunk, endpoint "A" moves from 2775 the COOKIE-ECHOED state to the ESTABLISHED state, stopping the 2776 T1-cookie timer. It can also notify its ULP about the successful 2777 establishment of the association with a Communication Up 2778 notification (see Section 11). 2780 An INIT or INIT ACK chunk MUST NOT be bundled with any other chunk. 2781 They MUST be the only chunks present in the SCTP packets that carry 2782 them. 2784 An endpoint MUST send the INIT ACK chunk to the IP address from which 2785 it received the INIT chunk. 2787 T1-init timer and T1-cookie timer SHOULD follow the same rules given 2788 in Section 6.3. If the application provided multiple IP addresses of 2789 the peer, there SHOULD be a T1-init and T1-cookie timer for each 2790 address of the peer. Retransmissions of INIT chunks and COOKIE ECHO 2791 chunks SHOULD use all addresses of the peer similar to 2792 retransmissions of DATA chunks. 2794 If an endpoint receives an INIT, INIT ACK, or COOKIE ECHO chunk but 2795 decides not to establish the new association due to missing mandatory 2796 parameters in the received INIT or INIT ACK chunk, invalid parameter 2797 values, or lack of local resources, it SHOULD respond with an ABORT 2798 chunk. It SHOULD also specify the cause of abort, such as the type 2799 of the missing mandatory parameters, etc., by including the error 2800 cause parameters with the ABORT chunk. The Verification Tag field in 2801 the common header of the outbound SCTP packet containing the ABORT 2802 chunk MUST be set to the Initiate Tag value of the received INIT or 2803 INIT ACK chunk this ABORT chunk is responding to. 2805 Note that a COOKIE ECHO chunk that does not pass the integrity check 2806 is not considered an 'invalid mandatory parameter' and requires 2807 special handling; see Section 5.1.5. 2809 After the reception of the first DATA chunk in an association the 2810 endpoint MUST immediately respond with a SACK chunk to acknowledge 2811 the DATA chunk. Subsequent acknowledgements SHOULD be done as 2812 described in Section 6.2. 2814 When the TCB is created, each endpoint MUST set its internal 2815 Cumulative TSN Ack Point to the value of its transmitted Initial TSN 2816 minus one. 2818 Implementation Note: The IP addresses and SCTP port are generally 2819 used as the key to find the TCB within an SCTP instance. 2821 5.1.1. Handle Stream Parameters 2823 In the INIT and INIT ACK chunks, the sender of the chunk MUST 2824 indicate the number of outbound streams (OSs) it wishes to have in 2825 the association, as well as the maximum inbound streams (MISs) it 2826 will accept from the other endpoint. 2828 After receiving the stream configuration information from the other 2829 side, each endpoint MUST perform the following check: If the peer's 2830 MIS is less than the endpoint's OS, meaning that the peer is 2831 incapable of supporting all the outbound streams the endpoint wants 2832 to configure, the endpoint MUST use MIS outbound streams and MAY 2833 report any shortage to the upper layer. The upper layer can then 2834 choose to abort the association if the resource shortage is 2835 unacceptable. 2837 After the association is initialized, the valid outbound stream 2838 identifier range for either endpoint MUST be 0 to min(local OS, 2839 remote MIS) - 1. 2841 5.1.2. Handle Address Parameters 2843 During the association initialization, an endpoint uses the following 2844 rules to discover and collect the destination transport address(es) 2845 of its peer. 2847 A) If there are no address parameters present in the received INIT 2848 or INIT ACK chunk, the endpoint MUST take the source IP address 2849 from which the chunk arrives and record it, in combination with 2850 the SCTP source port number, as the only destination transport 2851 address for this peer. 2853 B) If there is a Host Name Address parameter present in the received 2854 INIT or INIT ACK chunk, the endpoint MUST immediately send an 2855 ABORT chunk and MAY include an "Unresolvable Address" error cause 2856 to its peer. The ABORT chunk SHOULD be sent to the source IP 2857 address from which the last peer packet was received. 2859 C) If there are only IPv4/IPv6 addresses present in the received 2860 INIT or INIT ACK chunk, the receiver MUST derive and record all 2861 the transport addresses from the received chunk AND the source IP 2862 address that sent the INIT or INIT ACK chunk. The transport 2863 addresses are derived by the combination of SCTP source port 2864 (from the common header) and the IP Address parameter(s) carried 2865 in the INIT or INIT ACK chunk and the source IP address of the IP 2866 datagram. The receiver SHOULD use only these transport addresses 2867 as destination transport addresses when sending subsequent 2868 packets to its peer. 2870 D) An INIT or INIT ACK chunk MUST be treated as belonging to an 2871 already established association (or one in the process of being 2872 established) if the use of any of the valid address parameters 2873 contained within the chunk would identify an existing TCB. 2875 Implementation Note: In some cases (e.g., when the implementation 2876 does not control the source IP address that is used for 2877 transmitting), an endpoint might need to include in its INIT or INIT 2878 ACK chunk all possible IP addresses from which packets to the peer 2879 could be transmitted. 2881 After all transport addresses are derived from the INIT or INIT ACK 2882 chunk using the above rules, the endpoint selects one of the 2883 transport addresses as the initial primary path. 2885 The packet containing the INIT ACK chunk MUST be sent to the source 2886 address of the packet containing the INIT chunk. 2888 The sender of INIT chunks MAY include a 'Supported Address Types' 2889 parameter in the INIT chunk to indicate what types of addresses are 2890 acceptable. 2892 Implementation Note: In the case that the receiver of an INIT ACK 2893 chunk fails to resolve the address parameter due to an unsupported 2894 type, it can abort the initiation process and then attempt a 2895 reinitiation by using a 'Supported Address Types' parameter in the 2896 new INIT chunk to indicate what types of address it prefers. 2898 If an SCTP endpoint that only supports either IPv4 or IPv6 receives 2899 IPv4 and IPv6 addresses in an INIT or INIT ACK chunk from its peer, 2900 it MUST use all the addresses belonging to the supported address 2901 family. The other addresses MAY be ignored. The endpoint SHOULD NOT 2902 respond with any kind of error indication. 2904 If an SCTP endpoint lists in the 'Supported Address Types' parameter 2905 either IPv4 or IPv6, but uses the other family for sending the packet 2906 containing the INIT chunk, or if it also lists addresses of the other 2907 family in the INIT chunk, then the address family that is not listed 2908 in the 'Supported Address Types' parameter SHOULD also be considered 2909 as supported by the receiver of the INIT chunk. The receiver of the 2910 INIT chunk SHOULD NOT respond with any kind of error indication. 2912 5.1.3. Generating State Cookie 2914 When sending an INIT ACK chunk as a response to an INIT chunk, the 2915 sender of INIT ACK chunk creates a State Cookie and sends it in the 2916 State Cookie parameter of the INIT ACK chunk. Inside this State 2917 Cookie, the sender MUST include a MAC (see [RFC2104] for an example) 2918 to provide integrity protection on the State Cookie. The State 2919 Cookie SHOULD also contain a timestamp on when the State Cookie is 2920 created, and the lifespan of the State Cookie, along with all the 2921 information necessary for it to establish the association including 2922 the port numbers and the verification tags. 2924 The method used to generate the MAC is strictly a private matter for 2925 the receiver of the INIT chunk. The use of a MAC is mandatory to 2926 prevent denial-of-service attacks. MAC algorithms can have different 2927 performance depending on the platform. Choosing a high performance 2928 MAC algorithm increases the resistance against cookie flooding 2929 attacks. A MAC with acceptable security properties SHOULD be used. 2930 The secret key SHOULD be random ([RFC4086] provides some information 2931 on randomness guidelines). The secret keys need to have an 2932 appropriate size. The secret key SHOULD be changed reasonably 2933 frequently (e.g., hourly), and the timestamp in the State Cookie MAY 2934 be used to determine which key is used to verify the MAC. 2936 If the State Cookie is not encrypted, it MUST NOT contain information 2937 which is not being envisioned to be shared. 2939 An implementation SHOULD make the cookie as small as possible to 2940 ensure interoperability. 2942 5.1.4. State Cookie Processing 2944 When an endpoint (in the COOKIE-WAIT state) receives an INIT ACK 2945 chunk with a State Cookie parameter, it MUST immediately send a 2946 COOKIE ECHO chunk to its peer with the received State Cookie. The 2947 sender MAY also add any pending DATA chunks to the packet after the 2948 COOKIE ECHO chunk. 2950 The endpoint MUST also start the T1-cookie timer after sending the 2951 COOKIE ECHO chunk. If the timer expires, the endpoint MUST 2952 retransmit the COOKIE ECHO chunk and restart the T1-cookie timer. 2953 This is repeated until either a COOKIE ACK chunk is received or 2954 'Max.Init.Retransmits' (see Section 16) is reached causing the peer 2955 endpoint to be marked unreachable (and thus the association enters 2956 the CLOSED state). 2958 5.1.5. State Cookie Authentication 2960 When an endpoint receives a COOKIE ECHO chunk from another endpoint 2961 with which it has no association, it takes the following actions: 2963 1) Compute a MAC using the information carried in the State Cookie 2964 and the secret key. The timestamp in the State Cookie MAY be 2965 used to determine which secret key to use. If secrets are kept 2966 only for a limited amount of time and the secret key to use is 2967 not available anymore, the packet containing the COOKIE ECHO 2968 chunk MUST be silently discarded. [RFC2104] can be used as a 2969 guideline for generating the MAC, 2971 2) Authenticate the State Cookie as one that it previously generated 2972 by comparing the computed MAC against the one carried in the 2973 State Cookie. If this comparison fails, the SCTP packet, 2974 including the COOKIE ECHO chunk and any DATA chunks, MUST be 2975 silently discarded, 2977 3) Compare the port numbers and the Verification Tag contained 2978 within the COOKIE ECHO chunk to the actual port numbers and the 2979 Verification Tag within the SCTP common header of the received 2980 packet. If these values do not match, the packet MUST be 2981 silently discarded. 2983 4) Compare the creation timestamp in the State Cookie to the current 2984 local time. If the elapsed time is longer than the lifespan 2985 carried in the State Cookie, then the packet, including the 2986 COOKIE ECHO chunk and any attached DATA chunks, SHOULD be 2987 discarded, and the endpoint MUST transmit an ERROR chunk with a 2988 "Stale Cookie" error cause to the peer endpoint. 2990 5) If the State Cookie is valid, create an association to the sender 2991 of the COOKIE ECHO chunk with the information in the State Cookie 2992 carried in the COOKIE ECHO chunk and enter the ESTABLISHED state. 2994 6) Send a COOKIE ACK chunk to the peer acknowledging receipt of the 2995 COOKIE ECHO chunk. The COOKIE ACK chunk MAY be bundled with an 2996 outbound DATA chunk or SACK chunk; however, the COOKIE ACK chunk 2997 MUST be the first chunk in the SCTP packet. 2999 7) Immediately acknowledge any DATA chunk bundled with the COOKIE 3000 ECHO chunk with a SACK chunk (subsequent DATA chunk 3001 acknowledgement SHOULD follow the rules defined in Section 6.2). 3002 As mentioned in step 6, if the SACK chunk is bundled with the 3003 COOKIE ACK chunk, the COOKIE ACK chunk MUST appear first in the 3004 SCTP packet. 3006 If a COOKIE ECHO chunk is received from an endpoint with which the 3007 receiver of the COOKIE ECHO chunk has an existing association, the 3008 procedures in Section 5.2 SHOULD be followed. 3010 5.1.6. An Example of Normal Association Establishment 3012 In the following example, "A" initiates the association and then 3013 sends a user message to "Z", then "Z" sends two user messages to "A" 3014 later (assuming no bundling or fragmentation occurs): 3016 Endpoint A Endpoint Z 3017 {app sets association with Z} 3018 (build TCB) 3019 INIT [I-Tag=Tag_A 3020 & other info] ------\ 3021 (Start T1-init timer) \ 3022 (Enter COOKIE-WAIT state) \---> (compose Cookie_Z) 3023 /-- INIT ACK [Veri Tag=Tag_A, 3024 / I-Tag=Tag_Z, 3025 (Cancel T1-init timer) <------/ Cookie_Z, & other info] 3027 COOKIE ECHO [Cookie_Z] ------\ 3028 (Start T1-cookie timer) \ 3029 (Enter COOKIE-ECHOED state) \---> (build TCB, enter ESTABLISHED 3030 state) 3031 /---- COOKIE ACK 3032 / 3033 (Cancel T1-cookie timer, <---/ 3034 enter ESTABLISHED state) 3035 {app sends 1st user data; strm 0} 3036 DATA [TSN=init TSN_A 3037 Strm=0,Seq=0 & user data]--\ 3038 (Start T3-rtx timer) \ 3039 \-> 3040 /----- SACK [TSN Ack=init TSN_A, 3041 Block=0] 3042 (Cancel T3-rtx timer) <------/ 3043 ... 3044 {app sends 2 messages;strm 0} 3045 /---- DATA 3046 / [TSN=init TSN_Z, 3047 <--/ Strm=0,Seq=0 & user data 1] 3048 SACK [TSN Ack=init TSN_Z, /---- DATA 3049 Block=0] --------\ / [TSN=init TSN_Z +1, 3050 \/ Strm=0,Seq=1 & user data 2] 3051 <------/\ 3052 \ 3053 \------> 3055 Figure 4: A Setup Example 3057 If the T1-init timer expires at "A" after the INIT or COOKIE ECHO 3058 chunks are sent, the same INIT or COOKIE ECHO chunk with the same 3059 Initiate Tag (i.e., Tag_A) or State Cookie is retransmitted and the 3060 timer restarted. This is repeated 'Max.Init.Retransmits' times 3061 before "A" considers "Z" unreachable and reports the failure to its 3062 upper layer (and thus the association enters the CLOSED state). 3064 When retransmitting the INIT chunk, the endpoint MUST follow the 3065 rules defined in Section 6.3 to determine the proper timer value. 3067 5.2. Handle Duplicate or Unexpected INIT, INIT ACK, COOKIE ECHO, and 3068 COOKIE ACK Chunks 3070 During the life time of an association (in one of the possible 3071 states), an endpoint can receive from its peer endpoint one of the 3072 setup chunks (INIT, INIT ACK, COOKIE ECHO, and COOKIE ACK). The 3073 receiver treats such a setup chunk as a duplicate and process it as 3074 described in this section. 3076 Note: An endpoint will not receive the chunk unless the chunk was 3077 sent to an SCTP transport address and is from an SCTP transport 3078 address associated with this endpoint. Therefore, the endpoint 3079 processes such a chunk as part of its current association. 3081 The following scenarios can cause duplicated or unexpected chunks: 3083 A) The peer has crashed without being detected, restarted itself, 3084 and sent a new INIT chunk trying to restore the association, 3086 B) Both sides are trying to initialize the association at about the 3087 same time, 3089 C) The chunk is from a stale packet that was used to establish the 3090 present association or a past association that is no longer in 3091 existence, 3093 D) The chunk is a false packet generated by an attacker, or 3095 E) The peer never received the COOKIE ACK chunk and is 3096 retransmitting its COOKIE ECHO chunk. 3098 The rules in the following sections are applied in order to identify 3099 and correctly handle these cases. 3101 5.2.1. INIT Chunk Received in COOKIE-WAIT or COOKIE-ECHOED State (Item 3102 B) 3104 This usually indicates an initialization collision, i.e., each 3105 endpoint is attempting, at about the same time, to establish an 3106 association with the other endpoint. 3108 Upon receipt of an INIT chunk in the COOKIE-WAIT state, an endpoint 3109 MUST respond with an INIT ACK chunk using the same parameters it sent 3110 in its original INIT chunk (including its Initiate Tag, unchanged). 3111 When responding, the following rules MUST be applied: 3113 1) The packet containing the INIT ACK chunk MUST only be sent to an 3114 address passed by the upper layer in the request to initialize 3115 the association. 3117 2) The packet containing the INIT ACK chunk MUST only be sent to an 3118 address reported in the incoming INIT chunk. 3120 3) The packet containing the INIT ACK chunk SHOULD be sent to the 3121 source address of the received packet containing the INIT chunk. 3123 Upon receipt of an INIT chunk in the COOKIE-ECHOED state, an endpoint 3124 MUST respond with an INIT ACK chunk using the same parameters it sent 3125 in its original INIT chunk (including its Initiate Tag, unchanged), 3126 provided that no NEW address has been added to the forming 3127 association. If the INIT chunk indicates that a new address has been 3128 added to the association, then the entire INIT chunk MUST be 3129 discarded, and the state of the existing association SHOULD NOT be 3130 changed. An ABORT chunk SHOULD be sent in response that MAY include 3131 the error 'Restart of an association with new addresses'. The error 3132 SHOULD list the addresses that were added to the restarting 3133 association. 3135 When responding in either state (COOKIE-WAIT or COOKIE-ECHOED) with 3136 an INIT ACK chunk, the original parameters are combined with those 3137 from the newly received INIT chunk. The endpoint MUST also generate 3138 a State Cookie with the INIT ACK chunk. The endpoint uses the 3139 parameters sent in its INIT chunk to calculate the State Cookie. 3141 After that, the endpoint MUST NOT change its state, the T1-init timer 3142 MUST be left running, and the corresponding TCB MUST NOT be 3143 destroyed. The normal procedures for handling State Cookies when a 3144 TCB exists will resolve the duplicate INIT chunks to a single 3145 association. 3147 For an endpoint that is in the COOKIE-ECHOED state, it MUST populate 3148 its Tie-Tags within both the association TCB and inside the State 3149 Cookie (see Section 5.2.2 for a description of the Tie-Tags). 3151 5.2.2. Unexpected INIT Chunk in States Other than CLOSED, COOKIE- 3152 ECHOED, COOKIE-WAIT, and SHUTDOWN-ACK-SENT 3154 Unless otherwise stated, upon receipt of an unexpected INIT chunk for 3155 this association, the endpoint MUST generate an INIT ACK chunk with a 3156 State Cookie. Before responding, the endpoint MUST check to see if 3157 the unexpected INIT chunk adds new addresses to the association. If 3158 new addresses are added to the association, the endpoint MUST respond 3159 with an ABORT chunk, copying the 'Initiate Tag' of the unexpected 3160 INIT chunk into the 'Verification Tag' of the outbound packet 3161 carrying the ABORT chunk. In the ABORT chunk, the error cause MAY be 3162 set to 'restart of an association with new addresses'. The error 3163 SHOULD list the addresses that were added to the restarting 3164 association. If no new addresses are added, when responding to the 3165 INIT chunk in the outbound INIT ACK chunk, the endpoint MUST copy its 3166 current Tie-Tags to a reserved place within the State Cookie and the 3167 association's TCB. We refer to these locations inside the cookie as 3168 the Peer's-Tie-Tag and the Local-Tie-Tag. We will refer to the copy 3169 within an association's TCB as the Local Tag and Peer's Tag. The 3170 outbound SCTP packet containing this INIT ACK chunk MUST carry a 3171 Verification Tag value equal to the Initiate Tag found in the 3172 unexpected INIT chunk. And the INIT ACK chunk MUST contain a new 3173 Initiate Tag (randomly generated; see Section 5.3.1). Other 3174 parameters for the endpoint SHOULD be copied from the existing 3175 parameters of the association (e.g., number of outbound streams) into 3176 the INIT ACK chunk and cookie. 3178 After sending the INIT ACK or ABORT chunk, the endpoint MUST take no 3179 further actions; i.e., the existing association, including its 3180 current state, and the corresponding TCB MUST NOT be changed. 3182 Only when a TCB exists and the association is not in a COOKIE-WAIT or 3183 SHUTDOWN-ACK-SENT state are the Tie-Tags populated with a random 3184 value other than 0. For a normal association INIT chunk (i.e., the 3185 endpoint is in the CLOSED state), the Tie-Tags MUST be set to 0 3186 (indicating that no previous TCB existed). 3188 5.2.3. Unexpected INIT ACK Chunk 3190 If an INIT ACK chunk is received by an endpoint in any state other 3191 than the COOKIE-WAIT or CLOSED state, the endpoint SHOULD discard the 3192 INIT ACK chunk. An unexpected INIT ACK chunk usually indicates the 3193 processing of an old or duplicated INIT chunk. 3195 5.2.4. Handle a COOKIE ECHO Chunk when a TCB Exists 3197 When a COOKIE ECHO chunk is received by an endpoint in any state for 3198 an existing association (i.e., not in the CLOSED state) the following 3199 rules are applied: 3201 1) Compute a MAC as described in step 1 of Section 5.1.5, 3203 2) Authenticate the State Cookie as described in step 2 of 3204 Section 5.1.5 (this is case C or D above). 3206 3) Compare the timestamp in the State Cookie to the current time. 3207 If the State Cookie is older than the lifespan carried in the 3208 State Cookie and the Verification Tags contained in the State 3209 Cookie do not match the current association's Verification Tags, 3210 the packet, including the COOKIE ECHO chunk and any DATA chunks, 3211 SHOULD be discarded. The endpoint also MUST transmit an ERROR 3212 chunk with a "Stale Cookie" error cause to the peer endpoint 3213 (this is case C or D in Section 5.2). 3215 If both Verification Tags in the State Cookie match the 3216 Verification Tags of the current association, consider the State 3217 Cookie valid (this is case E in Section 5.2) even if the lifespan 3218 is exceeded. 3220 4) If the State Cookie proves to be valid, unpack the TCB into a 3221 temporary TCB. 3223 5) Refer to Table 12 to determine the correct action to be taken. 3225 +-----------+------------+---------------+----------------+--------+ 3226 | Local Tag | Peer's Tag | Local-Tie-Tag | Peer's-Tie-Tag | Action | 3227 +-----------+------------+---------------+----------------+--------+ 3228 | X | X | M | M | (A) | 3229 +-----------+------------+---------------+----------------+--------+ 3230 | M | X | A | A | (B) | 3231 +-----------+------------+---------------+----------------+--------+ 3232 | M | 0 | A | A | (B) | 3233 +-----------+------------+---------------+----------------+--------+ 3234 | X | M | 0 | 0 | (C) | 3235 +-----------+------------+---------------+----------------+--------+ 3236 | M | M | A | A | (D) | 3237 +-----------+------------+---------------+----------------+--------+ 3239 Table 12: Handling of a COOKIE ECHO Chunk when a TCB Exists 3241 Legend: 3243 X - Tag does not match the existing TCB. 3244 M - Tag matches the existing TCB. 3245 0 - Tag unknown (Peer's Tag not known yet / No tie-tag in cookie). 3246 A - All cases, i.e., M, X, or 0. 3248 For any case not shown in Table 12, the cookie SHOULD be silently 3249 discarded. 3251 Action 3253 A) In this case, the peer might have restarted. When the endpoint 3254 recognizes this potential 'restart', the existing session is 3255 treated the same as if it received an ABORT chunk followed by a 3256 new COOKIE ECHO chunk with the following exceptions: 3258 * Any SCTP DATA chunks MAY be retained (this is an 3259 implementation-specific option). 3261 * A notification of RESTART SHOULD be sent to the ULP instead of 3262 a "COMMUNICATION LOST" notification. 3264 All the congestion control parameters (e.g., cwnd, ssthresh) 3265 related to this peer MUST be reset to their initial values (see 3266 Section 6.2.1). 3268 After this, the endpoint enters the ESTABLISHED state. 3270 If the endpoint is in the SHUTDOWN-ACK-SENT state and recognizes 3271 that the peer has restarted (Action A), it MUST NOT set up a new 3272 association but instead resend the SHUTDOWN ACK chunk and send an 3273 ERROR chunk with a "Cookie Received While Shutting Down" error 3274 cause to its peer. 3276 B) In this case, both sides might be attempting to start an 3277 association at about the same time, but the peer endpoint sent 3278 its INIT chunk after responding to the local endpoint's INIT 3279 chunk. Thus, it might have picked a new Verification Tag, not 3280 being aware of the previous tag it had sent this endpoint. The 3281 endpoint SHOULD stay in or enter the ESTABLISHED state, but it 3282 MUST update its peer's Verification Tag from the State Cookie, 3283 stop any T1-init or T1-cookie timers that might be running, and 3284 send a COOKIE ACK chunk. 3286 C) In this case, the local endpoint's cookie has arrived late. 3287 Before it arrived, the local endpoint sent an INIT chunk and 3288 received an INIT ACK chunk and finally sent a COOKIE ECHO chunk 3289 with the peer's same tag but a new tag of its own. The cookie 3290 SHOULD be silently discarded. The endpoint SHOULD NOT change 3291 states and SHOULD leave any timers running. 3293 D) When both local and remote tags match, the endpoint SHOULD enter 3294 the ESTABLISHED state, if it is in the COOKIE-ECHOED state. It 3295 SHOULD stop any T1-cookie timer that is running and send a COOKIE 3296 ACK chunk. 3298 Note: The "peer's Verification Tag" is the tag received in the 3299 Initiate Tag field of the INIT or INIT ACK chunk. 3301 5.2.4.1. An Example of a Association Restart 3303 In the following example, "A" initiates the association after a 3304 restart has occurred. Endpoint "Z" had no knowledge of the restart 3305 until the exchange (i.e., Heartbeats had not yet detected the failure 3306 of "A") (assuming no bundling or fragmentation occurs): 3308 Endpoint A Endpoint Z 3309 <-------------- Association is established----------------------> 3310 Tag=Tag_A Tag=Tag_Z 3311 <---------------------------------------------------------------> 3312 {A crashes and restarts} 3313 {app sets up a association with Z} 3314 (build TCB) 3315 INIT [I-Tag=Tag_A' 3316 & other info] --------\ 3317 (Start T1-init timer) \ 3318 (Enter COOKIE-WAIT state) \---> (find an existing TCB, 3319 populate TieTags if needed, 3320 compose Cookie_Z with Tie-Tags 3321 and other info) 3322 /--- INIT ACK [Veri Tag=Tag_A', 3323 / I-Tag=Tag_Z', 3324 (Cancel T1-init timer) <------/ Cookie_Z] 3325 (leave original TCB in place) 3326 COOKIE ECHO [Veri=Tag_Z', 3327 Cookie_Z]-------\ 3328 (Start T1-init timer) \ 3329 (Enter COOKIE-ECHOED state) \---> (Find existing association, 3330 Tie-Tags in Cookie_Z match 3331 Tie-Tags in TCB, 3332 Tags do not match, i.e., 3333 case X X M M above, 3334 Announce Restart to ULP 3335 and reset association). 3336 /---- COOKIE ACK 3337 (Cancel T1-init timer, <------/ 3338 Enter ESTABLISHED state) 3339 {app sends 1st user data; strm 0} 3340 DATA [TSN=initial TSN_A 3341 Strm=0,Seq=0 & user data]--\ 3342 (Start T3-rtx timer) \ 3343 \-> 3344 /--- SACK [TSN Ack=init TSN_A,Block=0] 3345 (Cancel T3-rtx timer) <------/ 3347 Figure 5: A Restart Example 3349 5.2.5. Handle Duplicate COOKIE ACK Chunk 3351 At any state other than COOKIE-ECHOED, an endpoint SHOULD silently 3352 discard a received COOKIE ACK chunk. 3354 5.2.6. Handle Stale Cookie Error 3356 Receipt of an ERROR chunk with a "Stale Cookie" error cause indicates 3357 one of a number of possible events: 3359 A) The association failed to completely setup before the State 3360 Cookie issued by the sender was processed. 3362 B) An old State Cookie was processed after setup completed. 3364 C) An old State Cookie is received from someone that the receiver is 3365 not interested in having an association with and the ABORT chunk 3366 was lost. 3368 When processing an ERROR chunk with a "Stale Cookie" error cause an 3369 endpoint SHOULD first examine if an association is in the process of 3370 being set up, i.e., the association is in the COOKIE-ECHOED state. 3371 In all cases, if the association is not in the COOKIE-ECHOED state, 3372 the ERROR chunk SHOULD be silently discarded. 3374 If the association is in the COOKIE-ECHOED state, the endpoint MAY 3375 elect one of the following three alternatives. 3377 1) Send a new INIT chunk to the endpoint to generate a new State 3378 Cookie and reattempt the setup procedure. 3380 2) Discard the TCB and report to the upper layer the inability to 3381 set up the association. 3383 3) Send a new INIT chunk to the endpoint, adding a Cookie 3384 Preservative parameter requesting an extension to the life time 3385 of the State Cookie. When calculating the time extension, an 3386 implementation SHOULD use the RTT information measured based on 3387 the previous COOKIE ECHO / ERROR chunk exchange, and SHOULD add 3388 no more than 1 second beyond the measured RTT, due to long State 3389 Cookie life times making the endpoint more subject to a replay 3390 attack. 3392 5.3. Other Initialization Issues 3393 5.3.1. Selection of Tag Value 3395 Initiate Tag values SHOULD be selected from the range of 1 to 2^32 - 3396 1. It is very important that the Initiate Tag value be randomized to 3397 help protect against "man in the middle" and "sequence number" 3398 attacks. The methods described in [RFC4086] can be used for the 3399 Initiate Tag randomization. Careful selection of Initiate Tags is 3400 also necessary to prevent old duplicate packets from previous 3401 associations being mistakenly processed as belonging to the current 3402 association. 3404 Moreover, the Verification Tag value used by either endpoint in a 3405 given association MUST NOT change during the life time of an 3406 association. A new Verification Tag value MUST be used each time the 3407 endpoint tears down and then reestablishes an association to the same 3408 peer. 3410 5.4. Path Verification 3412 During association establishment, the two peers exchange a list of 3413 addresses. In the predominant case, these lists accurately represent 3414 the addresses owned by each peer. However, a misbehaving peer might 3415 supply addresses that it does not own. To prevent this, the 3416 following rules are applied to all addresses of the new association: 3418 1) Any addresses passed to the sender of the INIT chunk by its upper 3419 layer in the request to initialize an association are 3420 automatically considered to be CONFIRMED. 3422 2) For the receiver of the COOKIE ECHO chunk, the only CONFIRMED 3423 address is the address to which the packet containing the INIT 3424 ACK chunk was sent. 3426 3) All other addresses not covered by rules 1 and 2 are considered 3427 UNCONFIRMED and are subject to probing for verification. 3429 To probe an address for verification, an endpoint will send HEARTBEAT 3430 chunks including a 64-bit random nonce and a path indicator (to 3431 identify the address that the HEARTBEAT chunk is sent to) within the 3432 Heartbeat Info parameter. 3434 Upon receipt of the HEARTBEAT ACK chunk, a verification is made that 3435 the nonce included in the Heartbeat Info parameter is the one sent to 3436 the address indicated inside the Heartbeat Info parameter. When this 3437 match occurs, the address that the original HEARTBEAT was sent to is 3438 now considered CONFIRMED and available for normal data transfer. 3440 These probing procedures are started when an association moves to the 3441 ESTABLISHED state and are ended when all paths are confirmed. 3443 In each RTO, a probe MAY be sent on an active UNCONFIRMED path in an 3444 attempt to move it to the CONFIRMED state. If during this probing 3445 the path becomes inactive, this rate is lowered to the normal 3446 HEARTBEAT rate. At the expiration of the RTO timer, the error 3447 counter of any path that was probed but not CONFIRMED is incremented 3448 by one and subjected to path failure detection, as defined in 3449 Section 8.2. When probing UNCONFIRMED addresses, however, the 3450 association overall error count is not incremented. 3452 The number of packets containing HEARTBEAT chunks sent at each RTO 3453 SHOULD be limited by the 'HB.Max.Burst' parameter. It is an 3454 implementation decision as to how to distribute packets containing 3455 HEARTBEAT chunks to the peer's addresses for path verification. 3457 Whenever a path is confirmed, an indication MAY be given to the upper 3458 layer. 3460 An endpoint MUST NOT send any chunks to an UNCONFIRMED address, with 3461 the following exceptions: 3463 * A HEARTBEAT chunk including a nonce MAY be sent to an UNCONFIRMED 3464 address. 3466 * A HEARTBEAT ACK chunk MAY be sent to an UNCONFIRMED address. 3468 * A COOKIE ACK chunk MAY be sent to an UNCONFIRMED address, but it 3469 MUST be bundled with a HEARTBEAT chunk including a nonce. An 3470 implementation that does not support bundling MUST NOT send a 3471 COOKIE ACK chunk to an UNCONFIRMED address. 3473 * A COOKIE ECHO chunk MAY be sent to an UNCONFIRMED address, but it 3474 MUST be bundled with a HEARTBEAT chunk including a nonce, and the 3475 size of the SCTP packet MUST NOT exceed the PMTU. If the 3476 implementation does not support bundling or if the bundled COOKIE 3477 ECHO chunk plus HEARTBEAT chunk (including nonce) would result in 3478 an SCTP packet larger than the PMTU, then the implementation MUST 3479 NOT send a COOKIE ECHO chunk to an UNCONFIRMED address. 3481 6. User Data Transfer 3483 Data transmission MUST only happen in the ESTABLISHED, SHUTDOWN- 3484 PENDING, and SHUTDOWN-RECEIVED states. The only exception to this is 3485 that DATA chunks are allowed to be bundled with an outbound COOKIE 3486 ECHO chunk when in the COOKIE-WAIT state. 3488 DATA chunks MUST only be received according to the rules below in 3489 ESTABLISHED, SHUTDOWN-PENDING, and SHUTDOWN-SENT states. A DATA 3490 chunk received in CLOSED is out of the blue and SHOULD be handled per 3491 Section 8.4. A DATA chunk received in any other state SHOULD be 3492 discarded. 3494 A SACK chunk MUST be processed in ESTABLISHED, SHUTDOWN-PENDING, and 3495 SHUTDOWN-RECEIVED states. An incoming SACK chunk MAY be processed in 3496 COOKIE-ECHOED. A SACK chunk in the CLOSED state is out of the blue 3497 and SHOULD be processed according to the rules in Section 8.4. A 3498 SACK chunk received in any other state SHOULD be discarded. 3500 For transmission efficiency, SCTP defines mechanisms for bundling of 3501 small user messages and fragmentation of large user messages. The 3502 following diagram depicts the flow of user messages through SCTP. 3504 In this section, the term "data sender" refers to the endpoint that 3505 transmits a DATA chunk and the term "data receiver" refers to the 3506 endpoint that receives a DATA chunk. A data receiver will transmit 3507 SACK chunks. 3509 +-------------------------+ 3510 | User Messages | 3511 +-------------------------+ 3512 SCTP user ^ | 3513 ==================|==|======================================= 3514 | v (1) 3515 +------------------+ +---------------------+ 3516 | SCTP DATA Chunks | | SCTP Control Chunks | 3517 +------------------+ +---------------------+ 3518 ^ | ^ | 3519 | v (2) | v (2) 3520 +--------------------------+ 3521 | SCTP packets | 3522 +--------------------------+ 3523 SCTP ^ | 3524 ===========================|==|=========================== 3525 | v 3526 Connectionless Packet Transfer Service (e.g., IP) 3528 Figure 6: Illustration of User Data Transfer 3530 The following applies: 3532 1) When converting user messages into DATA chunks, an endpoint MUST 3533 fragment large user messages into multiple DATA chunks. The size 3534 of each DATA chunk SHOULD be smaller than or equal to the 3535 Association Maximum DATA Chunk Size (AMDCS). The data receiver 3536 will normally reassemble the fragmented message from DATA chunks 3537 before delivery to the user (see Section 6.9 for details). 3539 2) Multiple DATA and control chunks MAY be bundled by the sender 3540 into a single SCTP packet for transmission, as long as the final 3541 size of the SCTP packet does not exceed the current PMTU. The 3542 receiver will unbundle the packet back into the original chunks. 3543 Control chunks MUST come before DATA chunks in the packet. 3545 The fragmentation and bundling mechanisms, as detailed in Section 6.9 3546 and Section 6.10, are OPTIONAL to implement by the data sender, but 3547 they MUST be implemented by the data receiver, i.e., an endpoint MUST 3548 properly receive and process bundled or fragmented data. 3550 6.1. Transmission of DATA Chunks 3552 This section specifies the rules for sending DATA chunks. In 3553 particular, it defines zero window probing, which is required to 3554 avoid the indefinite stalling of an association in case of a loss of 3555 packets containing SACK chunks performing window updates. 3557 This document is specified as if there is a single retransmission 3558 timer per destination transport address, but implementations MAY have 3559 a retransmission timer for each DATA chunk. 3561 The following general rules MUST be applied by the data sender for 3562 transmission and/or retransmission of outbound DATA chunks: 3564 A) At any given time, the data sender MUST NOT transmit new data to 3565 any destination transport address if its peer's rwnd indicates 3566 that the peer has no buffer space (i.e., rwnd is smaller than the 3567 size of the next DATA chunk; see Section 6.2.1), except for zero 3568 window probes. 3570 A zero window probe is a DATA chunk sent when the receiver has no 3571 buffer space. This rule allows the sender to probe for a change 3572 in rwnd that the sender missed due to the SACK chunks having been 3573 lost in transit from the data receiver to the data sender. A 3574 zero window probe MUST only be sent when the cwnd allows (see 3575 Rule B below). A zero window probe SHOULD only be sent when all 3576 outstanding DATA chunks have been cumulatively acknowledged and 3577 no DATA chunks are in flight. Senders MUST support zero window 3578 probing. 3580 If the sender continues to receive SACK chunks from the peer 3581 while doing zero window probing, the unacknowledged window probes 3582 SHOULD NOT increment the error counter for the association or any 3583 destination transport address. This is because the receiver 3584 could keep its window closed for an indefinite time. Section 6.2 3585 describes the receiver behavior when it advertises a zero window. 3586 The sender SHOULD send the first zero window probe after 1 RTO 3587 when it detects that the receiver has closed its window and 3588 SHOULD increase the probe interval exponentially afterwards. 3589 Also note that the cwnd SHOULD be adjusted according to 3590 Section 7.2.1. Zero window probing does not affect the 3591 calculation of cwnd. 3593 The sender MUST also have an algorithm for sending new DATA 3594 chunks to avoid silly window syndrome (SWS) as described in 3595 [RFC1122]. The algorithm can be similar to the one described in 3596 Section 4.2.3.4 of [RFC1122]. 3598 B) At any given time, the sender MUST NOT transmit new data to a 3599 given transport address if it has cwnd + (PMDCS - 1) or more 3600 bytes of data outstanding to that transport address. If data is 3601 available, the sender SHOULD exceed cwnd by up to (PMDCS - 1) 3602 bytes on a new data transmission if the flightsize does not 3603 currently reach cwnd. The breach of cwnd MUST constitute one 3604 packet only. 3606 C) When the time comes for the sender to transmit, before sending 3607 new DATA chunks, the sender MUST first transmit any DATA chunks 3608 that are marked for retransmission (limited by the current cwnd). 3610 D) When the time comes for the sender to transmit new DATA chunks, 3611 the protocol parameter 'Max.Burst' SHOULD be used to limit the 3612 number of packets sent. The limit MAY be applied by adjusting 3613 cwnd temporarily, as follows: 3615 if ((flightsize + Max.Burst * PMDCS) < cwnd) 3616 cwnd = flightsize + Max.Burst * PMDCS; 3618 Or, it MAY be applied by strictly limiting the number of packets 3619 emitted by the output routine. When calculating the number of 3620 packets to transmit, and particularly when using the formula 3621 above, cwnd SHOULD NOT be changed permanently. 3623 E) Then, the sender can send as many new DATA chunks as rule A and 3624 rule B allow. 3626 Multiple DATA chunks committed for transmission MAY be bundled in a 3627 single packet. Furthermore, DATA chunks being retransmitted MAY be 3628 bundled with new DATA chunks, as long as the resulting SCTP packet 3629 size does not exceed the PMTU. A ULP can request that no bundling is 3630 performed, but this only turns off any delays that an SCTP 3631 implementation might be using to increase bundling efficiency. It 3632 does not in itself stop all bundling from occurring (i.e., in case of 3633 congestion or retransmission). 3635 Before an endpoint transmits a DATA chunk, if any received DATA 3636 chunks have not been acknowledged (e.g., due to delayed ack), the 3637 sender SHOULD create a SACK chunk and bundle it with the outbound 3638 DATA chunk, as long as the size of the final SCTP packet does not 3639 exceed the current PMTU. See Section 6.2. 3641 When the window is full (i.e., transmission is disallowed by rule A 3642 and/or rule B), the sender MAY still accept send requests from its 3643 upper layer, but MUST transmit no more DATA chunks until some or all 3644 of the outstanding DATA chunks are acknowledged and transmission is 3645 allowed by rule A and rule B again. 3647 Whenever a transmission or retransmission is made to any address, if 3648 the T3-rtx timer of that address is not currently running, the sender 3649 MUST start that timer. If the timer for that address is already 3650 running, the sender MUST restart the timer if the earliest (i.e., 3651 lowest TSN) outstanding DATA chunk sent to that address is being 3652 retransmitted. Otherwise, the data sender MUST NOT restart the 3653 timer. 3655 When starting or restarting the T3-rtx timer, the timer value SHOULD 3656 be adjusted according to the timer rules defined in Section 6.3.2 and 3657 Section 6.3.3. 3659 The data sender MUST NOT use a TSN that is more than 2^31 - 1 above 3660 the beginning TSN of the current send window. 3662 For each stream, the data sender MUST NOT have more than 2^16 - 1 3663 ordered user messages in the current send window. 3665 Whenever the sender of a DATA chunk can benefit from the 3666 corresponding SACK chunk being sent back without delay, the sender 3667 MAY set the I bit in the DATA chunk header. Please note that why the 3668 sender has set the I bit is irrelevant to the receiver. 3670 Reasons for setting the I bit include, but are not limited to, the 3671 following (see Section 4 of [RFC7053] for a discussion of the 3672 benefits): 3674 * The application requests that the I bit of the last DATA chunk of 3675 a user message be set when providing the user message to the SCTP 3676 implementation (see Section 11.1). 3678 * The sender is in the SHUTDOWN-PENDING state. 3680 * The sending of a DATA chunk fills the congestion or receiver 3681 window. 3683 6.2. Acknowledgement on Reception of DATA Chunks 3685 The SCTP endpoint MUST always acknowledge the reception of each valid 3686 DATA chunk when the DATA chunk received is inside its receive window. 3688 When the receiver's advertised window is 0, the receiver MUST drop 3689 any new incoming DATA chunk with a TSN larger than the largest TSN 3690 received so far. Also, if the new incoming DATA chunk holds a TSN 3691 value less than the largest TSN received so far, then the receiver 3692 SHOULD drop the largest TSN held for reordering and accept the new 3693 incoming DATA chunk. In either case, if such a DATA chunk is 3694 dropped, the receiver MUST immediately send back a SACK chunk with 3695 the current receive window showing only DATA chunks received and 3696 accepted so far. The dropped DATA chunk(s) MUST NOT be included in 3697 the SACK chunk, as they were not accepted. The receiver MUST also 3698 have an algorithm for advertising its receive window to avoid 3699 receiver silly window syndrome (SWS), as described in [RFC1122]. The 3700 algorithm can be similar to the one described in Section 4.2.3.3 of 3701 [RFC1122]. 3703 The guidelines on delayed acknowledgement algorithm specified in 3704 Section 4.2 of [RFC5681] SHOULD be followed. Specifically, an 3705 acknowledgement SHOULD be generated for at least every second packet 3706 (not every second DATA chunk) received, and SHOULD be generated 3707 within 200 ms of the arrival of any unacknowledged DATA chunk. In 3708 some situations, it might be beneficial for an SCTP transmitter to be 3709 more conservative than the algorithms detailed in this document 3710 allow. However, an SCTP transmitter MUST NOT be more aggressive in 3711 sending SACK chunks than the following algorithms allow. 3713 An SCTP receiver MUST NOT generate more than one SACK chunk for every 3714 incoming packet, other than to update the offered window as the 3715 receiving application consumes new data. When the window opens up, 3716 an SCTP receiver SHOULD send additional SACK chunks to update the 3717 window even if no new data is received. The receiver MUST avoid 3718 sending a large number of window updates -- in particular, large 3719 bursts of them. One way to achieve this is to send a window update 3720 only if the window can be increased by at least a quarter of the 3721 receive buffer size of the association. 3723 Implementation Note: The maximum delay for generating an 3724 acknowledgement MAY be configured by the SCTP administrator, either 3725 statically or dynamically, in order to meet the specific timing 3726 requirement of the protocol being carried. 3728 An implementation MUST NOT allow the maximum delay (protocol 3729 parameter 'SACK.Delay') to be configured to be more than 500 ms. In 3730 other words, an implementation MAY lower the value of 'SACK.Delay' 3731 below 500 ms but MUST NOT raise it above 500 ms. 3733 Acknowledgements MUST be sent in SACK chunks unless shutdown was 3734 requested by the ULP, in which case an endpoint MAY send an 3735 acknowledgement in the SHUTDOWN chunk. A SACK chunk can acknowledge 3736 the reception of multiple DATA chunks. See Section 3.3.4 for SACK 3737 chunk format. In particular, the SCTP endpoint MUST fill in the 3738 Cumulative TSN Ack field to indicate the latest sequential TSN (of a 3739 valid DATA chunk) it has received. Any received DATA chunks with TSN 3740 greater than the value in the Cumulative TSN Ack field are reported 3741 in the Gap Ack Block fields. The SCTP endpoint MUST report as many 3742 Gap Ack Blocks as can fit in a single SACK chunk such that the size 3743 of the SCTP packet does not exceed the current PMTU. 3745 The SHUTDOWN chunk does not contain Gap Ack Block fields. Therefore, 3746 the endpoint SHOULD use a SACK chunk instead of the SHUTDOWN chunk to 3747 acknowledge DATA chunks received out of order. 3749 Upon receipt of an SCTP packet containing a DATA chunk with the I bit 3750 set, the receiver SHOULD NOT delay the sending of the corresponding 3751 SACK chunk, i.e., the receiver SHOULD immediately respond with the 3752 corresponding SACK chunk. 3754 When a packet arrives with duplicate DATA chunk(s) and with no new 3755 DATA chunk(s), the endpoint MUST immediately send a SACK chunk with 3756 no delay. If a packet arrives with duplicate DATA chunk(s) bundled 3757 with new DATA chunks, the endpoint MAY immediately send a SACK chunk. 3758 Normally, receipt of duplicate DATA chunks will occur when the 3759 original SACK chunk was lost and the peer's RTO has expired. The 3760 duplicate TSN number(s) SHOULD be reported in the SACK chunk as 3761 duplicate. 3763 When an endpoint receives a SACK chunk, it MAY use the duplicate TSN 3764 information to determine if SACK chunk loss is occurring. Further 3765 use of this data is for future study. 3767 The data receiver is responsible for maintaining its receive buffers. 3768 The data receiver SHOULD notify the data sender in a timely manner of 3769 changes in its ability to receive data. How an implementation 3770 manages its receive buffers is dependent on many factors (e.g., 3771 operating system, memory management system, amount of memory, etc.). 3772 However, the data sender strategy defined in Section 6.2.1 is based 3773 on the assumption of receiver operation similar to the following: 3775 A) At initialization of the association, the endpoint tells the peer 3776 how much receive buffer space it has allocated to the association 3777 in the INIT or INIT ACK chunk. The endpoint sets a_rwnd to this 3778 value. 3780 B) As DATA chunks are received and buffered, decrement a_rwnd by the 3781 number of bytes received and buffered. This is, in effect, 3782 closing rwnd at the data sender and restricting the amount of 3783 data it can transmit. 3785 C) As DATA chunks are delivered to the ULP and released from the 3786 receive buffers, increment a_rwnd by the number of bytes 3787 delivered to the upper layer. This is, in effect, opening up 3788 rwnd on the data sender and allowing it to send more data. The 3789 data receiver SHOULD NOT increment a_rwnd unless it has released 3790 bytes from its receive buffer. For example, if the receiver is 3791 holding fragmented DATA chunks in a reassembly queue, it SHOULD 3792 NOT increment a_rwnd. 3794 D) When sending a SACK chunk, the data receiver SHOULD place the 3795 current value of a_rwnd into the a_rwnd field. The data receiver 3796 SHOULD take into account that the data sender will not retransmit 3797 DATA chunks that are acked via the Cumulative TSN Ack (i.e., will 3798 drop from its retransmit queue). 3800 Under certain circumstances, the data receiver MAY drop DATA chunks 3801 that it has received but has not released from its receive buffers 3802 (i.e., delivered to the ULP). These DATA chunks might have been 3803 acked in Gap Ack Blocks. For example, the data receiver might be 3804 holding data in its receive buffers while reassembling a fragmented 3805 user message from its peer when it runs out of receive buffer space. 3806 It MAY drop these DATA chunks even though it has acknowledged them in 3807 Gap Ack Blocks. If a data receiver drops DATA chunks, it MUST NOT 3808 include them in Gap Ack Blocks in subsequent SACK chunks until they 3809 are received again via retransmission. In addition, the endpoint 3810 SHOULD take into account the dropped data when calculating its 3811 a_rwnd. 3813 An endpoint SHOULD NOT revoke a SACK chunk and discard data. Only in 3814 extreme circumstances might an endpoint use this procedure (such as 3815 out of buffer space). The data receiver SHOULD take into account 3816 that dropping data that has been acked in Gap Ack Blocks can result 3817 in suboptimal retransmission strategies in the data sender and thus 3818 in suboptimal performance. 3820 The following example illustrates the use of delayed 3821 acknowledgements: 3823 Endpoint A Endpoint Z 3825 {App sends 3 messages; strm 0} 3826 DATA [TSN=7,Strm=0,Seq=3] ------------> (ack delayed) 3827 (Start T3-rtx timer) 3829 DATA [TSN=8,Strm=0,Seq=4] ------------> (send ack) 3830 /------- SACK [TSN Ack=8,block=0] 3831 (cancel T3-rtx timer) <-----/ 3833 DATA [TSN=9,Strm=0,Seq=5] ------------> (ack delayed) 3834 (Start T3-rtx timer) 3835 ... 3836 {App sends 1 message; strm 1} 3837 (bundle SACK with DATA) 3838 /----- SACK [TSN Ack=9,block=0] \ 3839 / DATA [TSN=6,Strm=1,Seq=2] 3840 (cancel T3-rtx timer) <------/ (Start T3-rtx timer) 3842 (ack delayed) 3843 (send ack) 3844 SACK [TSN Ack=6,block=0] -------------> (cancel T3-rtx timer) 3846 Figure 7: Delayed Acknowledgement Example 3848 If an endpoint receives a DATA chunk with no user data (i.e., the 3849 Length field is set to 16), it SHOULD send an ABORT chunk with a "No 3850 User Data" error cause. 3852 An endpoint SHOULD NOT send a DATA chunk with no user data part. 3853 This avoids the need to be able to return a zero-length user message 3854 in the API, especially in the socket API as specified in [RFC6458] 3855 for details. 3857 6.2.1. Processing a Received SACK Chunk 3859 Each SACK chunk an endpoint receives contains an a_rwnd value. This 3860 value represents the amount of buffer space the data receiver, at the 3861 time of transmitting the SACK chunk, has left of its total receive 3862 buffer space (as specified in the INIT/INIT ACK chunk). Using 3863 a_rwnd, Cumulative TSN Ack, and Gap Ack Blocks, the data sender can 3864 develop a representation of the peer's receive buffer space. 3866 One of the problems the data sender takes into account when 3867 processing a SACK chunk is that a SACK chunk can be received out of 3868 order. That is, a SACK chunk sent by the data receiver can pass an 3869 earlier SACK chunk and be received first by the data sender. If a 3870 SACK chunk is received out of order, the data sender can develop an 3871 incorrect view of the peer's receive buffer space. 3873 Since there is no explicit identifier that can be used to detect out- 3874 of-order SACK chunks, the data sender uses heuristics to determine if 3875 a SACK chunk is new. 3877 An endpoint SHOULD use the following rules to calculate the rwnd, 3878 using the a_rwnd value, the Cumulative TSN Ack, and Gap Ack Blocks in 3879 a received SACK chunk. 3881 A) At the establishment of the association, the endpoint initializes 3882 the rwnd to the Advertised Receiver Window Credit (a_rwnd) the 3883 peer specified in the INIT or INIT ACK chunk. 3885 B) Any time a DATA chunk is transmitted (or retransmitted) to a 3886 peer, the endpoint subtracts the data size of the chunk from the 3887 rwnd of that peer. 3889 C) Any time a DATA chunk is marked for retransmission, either via 3890 T3-rtx timer expiration (Section 6.3.3) or via Fast Retransmit 3891 (Section 7.2.4), add the data size of those chunks to the rwnd. 3893 D) Any time a SACK chunk arrives, the endpoint performs the 3894 following: 3896 i) If Cumulative TSN Ack is less than the Cumulative TSN Ack 3897 Point, then drop the SACK chunk. Since Cumulative TSN Ack 3898 is monotonically increasing, a SACK chunk whose Cumulative 3899 TSN Ack is less than the Cumulative TSN Ack Point indicates 3900 an out-of-order SACK chunk. 3902 ii) Set rwnd equal to the newly received a_rwnd minus the 3903 number of bytes still outstanding after processing the 3904 Cumulative TSN Ack and the Gap Ack Blocks. 3906 iii) If the SACK chunk is missing a TSN that was previously 3907 acknowledged via a Gap Ack Block (e.g., the data receiver 3908 reneged on the data), then consider the corresponding DATA 3909 that might be possibly missing: Count one miss indication 3910 towards Fast Retransmit as described in Section 7.2.4, and 3911 if no retransmit timer is running for the destination 3912 address to which the DATA chunk was originally transmitted, 3913 then T3-rtx is started for that destination address. 3915 iv) If the Cumulative TSN Ack matches or exceeds the Fast 3916 Recovery exitpoint (Section 7.2.4), Fast Recovery is 3917 exited. 3919 6.3. Management of Retransmission Timer 3921 An SCTP endpoint uses a retransmission timer T3-rtx to ensure data 3922 delivery in the absence of any feedback from its peer. The duration 3923 of this timer is referred to as RTO (retransmission timeout). 3925 When an endpoint's peer is multi-homed, the endpoint will calculate a 3926 separate RTO for each different destination transport address of its 3927 peer endpoint. 3929 The computation and management of RTO in SCTP follow closely how TCP 3930 manages its retransmission timer. To compute the current RTO, an 3931 endpoint maintains two state variables per destination transport 3932 address: SRTT (smoothed round-trip time) and RTTVAR (round-trip time 3933 variation). 3935 6.3.1. RTO Calculation 3937 The rules governing the computation of SRTT, RTTVAR, and RTO are as 3938 follows: 3940 C1) Until an RTT measurement has been made for a packet sent to the 3941 given destination transport address, set RTO to the protocol 3942 parameter 'RTO.Initial'. 3944 C2) When the first RTT measurement R is made, perform 3946 SRTT = R; 3947 RTTVAR = R/2; 3948 RTO = SRTT + 4 * RTTVAR; 3950 C3) When a new RTT measurement R' is made, perform: 3952 RTTVAR = (1 - RTO.Beta) * RTTVAR + RTO.Beta * |SRTT - R'|; 3953 SRTT = (1 - RTO.Alpha) * SRTT + RTO.Alpha * R'; 3955 Note: The value of SRTT used in the update to RTTVAR is its 3956 value before updating SRTT itself using the second assignment. 3958 After the computation, update 3960 RTO = SRTT + 4 * RTTVAR; 3962 C4) When data is in flight and when allowed by rule C5 below, a new 3963 RTT measurement MUST be made each round trip. Furthermore, new 3964 RTT measurements SHOULD be made no more than once per round trip 3965 for a given destination transport address. There are two 3966 reasons for this recommendation: First, it appears that 3967 measuring more frequently often does not in practice yield any 3968 significant benefit [ALLMAN99]; second, if measurements are made 3969 more often, then the values of 'RTO.Alpha' and 'RTO.Beta' in 3970 rule C3 above SHOULD be adjusted so that SRTT and RTTVAR still 3971 adjust to changes at roughly the same rate (in terms of how many 3972 round trips it takes them to reflect new values) as they would 3973 if making only one measurement per round-trip and using 3974 'RTO.Alpha' and 'RTO.Beta' as given in rule C3. However, the 3975 exact nature of these adjustments remains a research issue. 3977 C5) Karn's algorithm: RTT measurements MUST NOT be made using chunks 3978 that were retransmitted (and thus for which it is ambiguous 3979 whether the reply was for the first instance of the chunk or for 3980 a later instance). 3982 RTT measurements SHOULD only be made using a DATA chunk with TSN 3983 r, if no DATA chunk with TSN less than or equal to r was 3984 retransmitted since the DATA chunk with TSN r was sent first. 3986 C6) Whenever RTO is computed, if it is less than 'RTO.Min' seconds 3987 then it is rounded up to 'RTO.Min' seconds. The reason for this 3988 rule is that RTOs that do not have a high minimum value are 3989 susceptible to unnecessary timeouts [ALLMAN99]. 3991 C7) A maximum value MAY be placed on RTO provided it is at least 3992 'RTO.max' seconds. 3994 There is no requirement for the clock granularity G used for 3995 computing RTT measurements and the different state variables, other 3996 than: 3998 G1) Whenever RTTVAR is computed, if RTTVAR == 0, then adjust RTTVAR 3999 = G. 4001 Experience [ALLMAN99] has shown that finer clock granularities (less 4002 than 100 msec) perform somewhat better than more coarse 4003 granularities. 4005 See Section 16 for suggested parameter values. 4007 6.3.2. Retransmission Timer Rules 4009 The rules for managing the retransmission timer are as follows: 4011 R1) Every time a DATA chunk is sent to any address (including a 4012 retransmission), if the T3-rtx timer of that address is not 4013 running, start it running so that it will expire after the RTO 4014 of that address. The RTO used here is that obtained after any 4015 doubling due to previous T3-rtx timer expirations on the 4016 corresponding destination address as discussed in rule E2 below. 4018 R2) Whenever all outstanding data sent to an address have been 4019 acknowledged, turn off the T3-rtx timer of that address. 4021 R3) Whenever a SACK chunk is received that acknowledges the DATA 4022 chunk with the earliest outstanding TSN for that address, 4023 restart the T3-rtx timer for that address with its current RTO 4024 (if there is still outstanding data on that address). 4026 R4) Whenever a SACK chunk is received missing a TSN that was 4027 previously acknowledged via a Gap Ack Block, start the T3-rtx 4028 for the destination address to which the DATA chunk was 4029 originally transmitted if it is not already running. 4031 The following example shows the use of various timer rules (assuming 4032 that the receiver uses delayed acks). 4034 Endpoint A Endpoint Z 4035 {App begins to send} 4036 Data [TSN=7,Strm=0,Seq=3] ------------> (ack delayed) 4037 (Start T3-rtx timer) 4038 {App sends 1 message; strm 1} 4039 (bundle ack with data) 4040 DATA [TSN=8,Strm=0,Seq=4] ----\ /-- SACK [TSN Ack=7,Block=0] 4041 \ / DATA [TSN=6,Strm=1,Seq=2] 4042 \ / (Start T3-rtx timer) 4043 \ 4044 / \ 4045 (Restart T3-rtx timer) <------/ \--> (ack delayed) 4046 (ack delayed) 4047 {send ack} 4048 SACK [TSN Ack=6,Block=0] --------------> (Cancel T3-rtx timer) 4049 .. 4050 (send ack) 4051 (Cancel T3-rtx timer) <-------------- SACK [TSN Ack=8,Block=0] 4053 Figure 8: Timer Rule Examples 4055 6.3.3. Handle T3-rtx Expiration 4057 Whenever the retransmission timer T3-rtx expires for a destination 4058 address, do the following: 4060 E1) For the destination address for which the timer expires, adjust 4061 its ssthresh with rules defined in Section 7.2.3 and set the 4062 cwnd = PMDCS. 4064 E2) For the destination address for which the timer expires, set RTO 4065 = RTO * 2 ("back off the timer"). The maximum value discussed 4066 in rule C7 above ('RTO.max') MAY be used to provide an upper 4067 bound to this doubling operation. 4069 E3) Determine how many of the earliest (i.e., lowest TSN) 4070 outstanding DATA chunks for the address for which the T3-rtx has 4071 expired will fit into a single SCTP packet, subject to the PMTU 4072 corresponding to the destination transport address to which the 4073 retransmission is being sent (this might be different from the 4074 address for which the timer expires; see Section 6.4). Call 4075 this value K. Bundle and retransmit those K DATA chunks in a 4076 single packet to the destination endpoint. 4078 E4) Start the retransmission timer T3-rtx on the destination address 4079 to which the retransmission is sent, if rule R1 above indicates 4080 to do so. The RTO to be used for starting T3-rtx SHOULD be the 4081 one for the destination address to which the retransmission is 4082 sent, which, when the receiver is multi-homed, might be 4083 different from the destination address for which the timer 4084 expired (see Section 6.4 below). 4086 After retransmitting, once a new RTT measurement is obtained (which 4087 can happen only when new data has been sent and acknowledged, per 4088 rule C5, or for a measurement made from a HEARTBEAT chunk; see 4089 Section 8.3), the computation in rule C3 is performed, including the 4090 computation of RTO, which might result in "collapsing" RTO back down 4091 after it has been subject to doubling (rule E2). 4093 Any DATA chunks that were sent to the address for which the T3-rtx 4094 timer expired but did not fit in an SCTP packet of size smaller than 4095 or equal to the PMTU (rule E3 above) SHOULD be marked for 4096 retransmission and sent as soon as cwnd allows (normally, when a SACK 4097 chunk arrives). 4099 The final rule for managing the retransmission timer concerns 4100 failover (see Section 6.4.1): 4102 F1) Whenever an endpoint switches from the current destination 4103 transport address to a different one, the current retransmission 4104 timers are left running. As soon as the endpoint transmits a 4105 packet containing DATA chunk(s) to the new transport address, 4106 start the timer on that transport address, using the RTO value 4107 of the destination address to which the data is being sent, if 4108 rule R1 indicates to do so. 4110 6.4. Multi-Homed SCTP Endpoints 4112 An SCTP endpoint is considered multi-homed if there is more than one 4113 transport address that can be used as a destination address to reach 4114 that endpoint. 4116 Moreover, the ULP of an endpoint selects one of the multiple 4117 destination addresses of a multi-homed peer endpoint as the primary 4118 path (see Section 5.1.2 and Section 11.1 for details). 4120 By default, an endpoint SHOULD always transmit to the primary path, 4121 unless the SCTP user explicitly specifies the destination transport 4122 address (and possibly source transport address) to use. 4124 An endpoint SHOULD transmit reply chunks (e.g., INIT ACK, COOKIE ACK, 4125 HEARTBEAT ACK) in response to control chunks to the same destination 4126 transport address from which it received the control chunk to which 4127 it is replying. 4129 The selection of the destination transport address for packets 4130 containing SACK chunks is implementation dependent. However, an 4131 endpoint SHOULD NOT vary the destination transport address of a SACK 4132 chunk when it receives DATA chunks coming from the same source 4133 address. 4135 When acknowledging multiple DATA chunks received in packets from 4136 different source addresses in a single SACK chunk, the SACK chunk MAY 4137 be transmitted to one of the destination transport addresses from 4138 which the DATA or control chunks being acknowledged were received. 4140 When a receiver of a duplicate DATA chunk sends a SACK chunk to a 4141 multi-homed endpoint, it MAY be beneficial to vary the destination 4142 address and not use the source address of the DATA chunk. The reason 4143 is that receiving a duplicate from a multi-homed endpoint might 4144 indicate that the return path (as specified in the source address of 4145 the DATA chunk) for the SACK chunk is broken. 4147 Furthermore, when its peer is multi-homed, an endpoint SHOULD try to 4148 retransmit a chunk that timed out to an active destination transport 4149 address that is different from the last destination address to which 4150 the chunk was sent. 4152 When its peer is multi-homed, an endpoint SHOULD send fast 4153 retransmissions to the same destination transport address to which 4154 the original data was sent. If the primary path has been changed and 4155 the original data was sent to the old primary path before the Fast 4156 Retransmit, the implementation MAY send it to the new primary path. 4158 Retransmissions do not affect the total outstanding data count. 4159 However, if the DATA chunk is retransmitted onto a different 4160 destination address, both the outstanding data counts on the new 4161 destination address and the old destination address to which the data 4162 chunk was last sent is adjusted accordingly. 4164 6.4.1. Failover from an Inactive Destination Address 4166 Some of the transport addresses of a multi-homed SCTP endpoint might 4167 become inactive due to either the occurrence of certain error 4168 conditions (see Section 8.2) or adjustments from the SCTP user. 4170 When there is outbound data to send and the primary path becomes 4171 inactive (e.g., due to failures), or where the SCTP user explicitly 4172 requests to send data to an inactive destination transport address, 4173 before reporting an error to its ULP, the SCTP endpoint SHOULD try to 4174 send the data to an alternate active destination transport address if 4175 one exists. 4177 When retransmitting data that timed out, if the endpoint is multi- 4178 homed, it needs to consider each source-destination address pair in 4179 its retransmission selection policy. When retransmitting timed-out 4180 data, the endpoint SHOULD attempt to pick the most divergent source- 4181 destination pair from the original source-destination pair to which 4182 the packet was transmitted. 4184 Note: Rules for picking the most divergent source-destination pair 4185 are an implementation decision and are not specified within this 4186 document. 4188 6.5. Stream Identifier and Stream Sequence Number 4190 Every DATA chunk MUST carry a valid stream identifier. If an 4191 endpoint receives a DATA chunk with an invalid stream identifier, it 4192 SHOULD acknowledge the reception of the DATA chunk following the 4193 normal procedure, immediately send an ERROR chunk with cause set to 4194 "Invalid Stream Identifier" (see Section 3.3.10), and discard the 4195 DATA chunk. The endpoint MAY bundle the ERROR chunk and the SACK 4196 chunk in the same packet. 4198 The Stream Sequence Number in all the outgoing streams MUST start 4199 from 0 when the association is established. The Stream Sequence 4200 Number of an outgoing stream MUST be incremented by 1 for each 4201 ordered user message sent on that outgoing stream. In particular, 4202 when the Stream Sequence Number reaches the value 65535 the next 4203 Stream Sequence Number MUST be set to 0. For unordered user messages 4204 the Stream Sequence Number MUST NOT be changed. 4206 6.6. Ordered and Unordered Delivery 4208 Within a stream, an endpoint MUST deliver DATA chunks received with 4209 the U flag set to 0 to the upper layer according to the order of 4210 their Stream Sequence Number. If DATA chunks arrive out of order of 4211 their Stream Sequence Number, the endpoint MUST hold the received 4212 DATA chunks from delivery to the ULP until they are reordered. 4214 However, an SCTP endpoint can indicate that no ordered delivery is 4215 required for a particular DATA chunk transmitted within the stream by 4216 setting the U flag of the DATA chunk to 1. 4218 When an endpoint receives a DATA chunk with the U flag set to 1, it 4219 bypasses the ordering mechanism and immediately deliver the data to 4220 the upper layer (after reassembly if the user data is fragmented by 4221 the data sender). 4223 This provides an effective way of transmitting "out-of-band" data in 4224 a given stream. Also, a stream can be used as an "unordered" stream 4225 by simply setting the U flag to 1 in all DATA chunks sent through 4226 that stream. 4228 Implementation Note: When sending an unordered DATA chunk, an 4229 implementation MAY choose to place the DATA chunk in an outbound 4230 packet that is at the head of the outbound transmission queue if 4231 possible. 4233 The 'Stream Sequence Number' field in a DATA chunk with U flag set to 4234 1 has no significance. The sender can fill the 'Stream Sequence 4235 Number' with arbitrary value, but the receiver MUST ignore the field. 4237 Note: When transmitting ordered and unordered data, an endpoint does 4238 not increment its Stream Sequence Number when transmitting a DATA 4239 chunk with U flag set to 1. 4241 6.7. Report Gaps in Received DATA TSNs 4243 Upon the reception of a new DATA chunk, an endpoint examines the 4244 continuity of the TSNs received. If the endpoint detects a gap in 4245 the received DATA chunk sequence, it SHOULD send a SACK chunk with 4246 Gap Ack Blocks immediately. The data receiver continues sending a 4247 SACK chunk after receipt of each SCTP packet that does not fill the 4248 gap. 4250 Based on the Gap Ack Block from the received SACK chunk, the endpoint 4251 can calculate the missing DATA chunks and make decisions on whether 4252 to retransmit them (see Section 6.2.1 for details). 4254 Multiple gaps can be reported in one single SACK chunk (see 4255 Section 3.3.4). 4257 When its peer is multi-homed, the SCTP endpoint SHOULD always try to 4258 send the SACK chunk to the same destination address from which the 4259 last DATA chunk was received. 4261 Upon the reception of a SACK chunk, the endpoint MUST remove all DATA 4262 chunks that have been acknowledged by the SACK chunk's Cumulative TSN 4263 Ack from its transmit queue. All DATA chunks with TSNs not included 4264 in the Gap Ack Blocks that are smaller than the highest acknowledged 4265 TSN reported in the SACK chunk MUST be treated as "missing" by the 4266 sending endpoint. The number of "missing" reports for each 4267 outstanding DATA chunk MUST be recorded by the data sender to make 4268 retransmission decisions. See Section 7.2.4 for details. 4270 The following example shows the use of SACK chunk to report a gap. 4272 Endpoint A Endpoint Z 4273 {App sends 3 messages; strm 0} 4274 DATA [TSN=6,Strm=0,Seq=2] ---------------> (ack delayed) 4275 (Start T3-rtx timer) 4277 DATA [TSN=7,Strm=0,Seq=3] --------> X (lost) 4279 DATA [TSN=8,Strm=0,Seq=4] ---------------> (gap detected, 4280 immediately send ack) 4281 /----- SACK [TSN Ack=6,Block=1, 4282 / Start=2,End=2] 4283 <-----/ 4284 (remove 6 from out-queue, 4285 and mark 7 as "1" missing report) 4287 Figure 9: Reporting a Gap using SACK Chunk 4289 The maximum number of Gap Ack Blocks that can be reported within a 4290 single SACK chunk is limited by the current PMTU. When a single SACK 4291 chunk cannot cover all the Gap Ack Blocks needed to be reported due 4292 to the PMTU limitation, the endpoint MUST send only one SACK chunk. 4293 This single SACK chunk MUST report the Gap Ack Blocks from the lowest 4294 to highest TSNs, within the size limit set by the PMTU, and leave the 4295 remaining highest TSN numbers unacknowledged. 4297 6.8. CRC32c Checksum Calculation 4299 When sending an SCTP packet, the endpoint MUST strengthen the data 4300 integrity of the transmission by including the CRC32c checksum value 4301 calculated on the packet, as described below. 4303 After the packet is constructed (containing the SCTP common header 4304 and one or more control or DATA chunks), the transmitter MUST 4306 1) fill in the proper Verification Tag in the SCTP common header and 4307 initialize the checksum field to 0, 4309 2) calculate the CRC32c checksum of the whole packet, including the 4310 SCTP common header and all the chunks (refer to Appendix A for 4311 details of the CRC32c algorithm); and 4313 3) put the resultant value into the checksum field in the common 4314 header, and leave the rest of the bits unchanged. 4316 When an SCTP packet is received, the receiver MUST first check the 4317 CRC32c checksum as follows: 4319 1) Store the received CRC32c checksum value aside. 4321 2) Replace the 32 bits of the checksum field in the received SCTP 4322 packet with 0 and calculate a CRC32c checksum value of the whole 4323 received packet. 4325 3) Verify that the calculated CRC32c checksum is the same as the 4326 received CRC32c checksum. If it is not, the receiver MUST treat 4327 the packet as an invalid SCTP packet. 4329 The default procedure for handling invalid SCTP packets is to 4330 silently discard them. 4332 Any hardware implementation SHOULD permit alternative verification of 4333 the CRC in software. 4335 6.9. Fragmentation and Reassembly 4337 An endpoint MAY support fragmentation when sending DATA chunks, but 4338 it MUST support reassembly when receiving DATA chunks. If an 4339 endpoint supports fragmentation, it MUST fragment a user message if 4340 the size of the user message to be sent causes the outbound SCTP 4341 packet size to exceed the current PMTU. An endpoint that does not 4342 support fragmentation and is requested to send a user message such 4343 that the outbound SCTP packet size would exceed the current PMTU MUST 4344 return an error to its upper layer and MUST NOT attempt to send the 4345 user message. 4347 An SCTP implementation MAY provide a mechanism to the upper layer 4348 that disables fragmentation when sending DATA chunks. When 4349 fragmentation of DATA chunks is disabeled, the SCTP implementation 4350 MUST behave in the same way an implementation that does not support 4351 fragmentation, i.e., it rejects calls that would result in sending 4352 SCTP packets that exceed the current PMTU. 4354 Implementation Note: In this error case, the SEND primitive discussed 4355 in Section 11.1 would need to return an error to the upper layer. 4357 If its peer is multi-homed, the endpoint SHOULD choose a DATA chunk 4358 size smaller than or equal to the AMDCS. 4360 Once a user message is fragmented, it cannot be re-fragmented. 4361 Instead, if the PMTU has been reduced, then IP fragmentation MUST be 4362 used. Therefore, an SCTP association can fail if IP fragmentation is 4363 not working on any path. Please see Section 7.3 for details of PMTU 4364 discovery. 4366 When determining when to fragment, the SCTP implementation MUST take 4367 into account the SCTP packet header as well as the DATA chunk 4368 header(s). The implementation MUST also take into account the space 4369 required for a SACK chunk if bundling a SACK chunk with the DATA 4370 chunk. 4372 Fragmentation takes the following steps: 4374 1) The data sender MUST break the user message into a series of DATA 4375 chunks. The sender SHOULD choose a size of DATA chunks that is 4376 smaller than or equal to the AMDCS. 4378 2) The transmitter MUST then assign, in sequence, a separate TSN to 4379 each of the DATA chunks in the series. The transmitter assigns 4380 the same Stream Sequence Number to each of the DATA chunks. If 4381 the user indicates that the user message is to be delivered using 4382 unordered delivery, then the U flag of each DATA chunk of the 4383 user message MUST be set to 1. 4385 3) The transmitter MUST also set the B/E bits of the first DATA 4386 chunk in the series to '10', the B/E bits of the last DATA chunk 4387 in the series to '01', and the B/E bits of all other DATA chunks 4388 in the series to '00'. 4390 An endpoint MUST recognize fragmented DATA chunks by examining the B/ 4391 E bits in each of the received DATA chunks, and queue the fragmented 4392 DATA chunks for reassembly. Once the user message is reassembled, 4393 SCTP passes the reassembled user message to the specific stream for 4394 possible reordering and final dispatching. 4396 If the data receiver runs out of buffer space while still waiting for 4397 more fragments to complete the reassembly of the message, it SHOULD 4398 dispatch part of its inbound message through a partial delivery API 4399 (see Section 11), freeing some of its receive buffer space so that 4400 the rest of the message can be received. 4402 6.10. Bundling 4404 An endpoint bundles chunks by simply including multiple chunks in one 4405 outbound SCTP packet. The total size of the resultant SCTP packet 4406 MUST be less that or equal to the current PMTU. 4408 If its peer endpoint is multi-homed, the sending endpoint SHOULD 4409 choose a size no larger than the PMTU of the current primary path. 4411 When bundling control chunks with DATA chunks, an endpoint MUST place 4412 control chunks first in the outbound SCTP packet. The transmitter 4413 MUST transmit DATA chunks within an SCTP packet in increasing order 4414 of TSN. 4416 Note: Since control chunks are placed first in a packet and since 4417 DATA chunks are transmitted before SHUTDOWN or SHUTDOWN ACK chunks, 4418 DATA chunks cannot be bundled with SHUTDOWN or SHUTDOWN ACK chunks. 4420 Partial chunks MUST NOT be placed in an SCTP packet. A partial chunk 4421 is a chunk that is not completely contained in the SCTP packet; i.e., 4422 the SCTP packet is too short to contain all the bytes of the chunk as 4423 indicated by the chunk length. 4425 An endpoint MUST process received chunks in their order in the 4426 packet. The receiver uses the Chunk Length field to determine the 4427 end of a chunk and beginning of the next chunk taking account of the 4428 fact that all chunks end on a 4-byte boundary. If the receiver 4429 detects a partial chunk, it MUST drop the chunk. 4431 An endpoint MUST NOT bundle INIT, INIT ACK, or SHUTDOWN COMPLETE 4432 chunks with any other chunks. 4434 7. Congestion Control 4436 Congestion control is one of the basic functions in SCTP. To manage 4437 congestion, the mechanisms and algorithms in this section are to be 4438 employed. 4440 Implementation Note: As far as its specific performance requirements 4441 are met, an implementation is always allowed to adopt a more 4442 conservative congestion control algorithm than the one defined below. 4444 The congestion control algorithms used by SCTP are based on 4445 [RFC5681]. This section describes how the algorithms defined in 4446 [RFC5681] are adapted for use in SCTP. We first list differences in 4447 protocol designs between TCP and SCTP, and then describe SCTP's 4448 congestion control scheme. The description will use the same 4449 terminology as in TCP congestion control whenever appropriate. 4451 SCTP congestion control is always applied to the entire association, 4452 and not to individual streams. 4454 7.1. SCTP Differences from TCP Congestion Control 4456 Gap Ack Blocks in the SCTP SACK chunk carry the same semantic meaning 4457 as the TCP SACK. TCP considers the information carried in the SACK 4458 as advisory information only. SCTP considers the information carried 4459 in the Gap Ack Blocks in the SACK chunk as advisory. In SCTP, any 4460 DATA chunk that has been acknowledged by a SACK chunk, including DATA 4461 that arrived at the receiving end out of order, is not considered 4462 fully delivered until the Cumulative TSN Ack Point passes the TSN of 4463 the DATA chunk (i.e., the DATA chunk has been acknowledged by the 4464 Cumulative TSN Ack field in the SACK chunk). Consequently, the value 4465 of cwnd controls the amount of outstanding data, rather than (as in 4466 the case of non-SACK TCP) the upper bound between the highest 4467 acknowledged sequence number and the latest DATA chunk that can be 4468 sent within the congestion window. SCTP SACK leads to different 4469 implementations of Fast Retransmit and Fast Recovery than non-SACK 4470 TCP. As an example, see [FALL96]. 4472 The biggest difference between SCTP and TCP, however, is multi- 4473 homing. SCTP is designed to establish robust communication 4474 associations between two endpoints each of which might be reachable 4475 by more than one transport address. Potentially different addresses 4476 might lead to different data paths between the two endpoints; thus, 4477 ideally one needs a separate set of congestion control parameters for 4478 each of the paths. The treatment here of congestion control for 4479 multi-homed receivers is new with SCTP and might require refinement 4480 in the future. The current algorithms make the following 4481 assumptions: 4483 * The sender usually uses the same destination address until being 4484 instructed by the upper layer to do otherwise; however, SCTP MAY 4485 change to an alternate destination in the event an address is 4486 marked inactive (see Section 8.2). Also, SCTP MAY retransmit to a 4487 different transport address than the original transmission. 4489 * The sender keeps a separate congestion control parameter set for 4490 each of the destination addresses it can send to (not each source- 4491 destination pair but for each destination). The parameters SHOULD 4492 decay if the address is not used for a long enough time period. 4493 [RFC5681] specifies this period of time as a retransmission 4494 timeout. 4496 * For each of the destination addresses, an endpoint does slow start 4497 upon the first transmission to that address. 4499 Note: TCP guarantees in-sequence delivery of data to its upper-layer 4500 protocol within a single TCP session. This means that when TCP 4501 notices a gap in the received sequence number, it waits until the gap 4502 is filled before delivering the data that was received with sequence 4503 numbers higher than that of the missing data. On the other hand, 4504 SCTP can deliver data to its upper-layer protocol even if there is a 4505 gap in TSN if the Stream Sequence Numbers are in sequence for a 4506 particular stream (i.e., the missing DATA chunks are for a different 4507 stream) or if unordered delivery is indicated. Although this does 4508 not affect cwnd, it might affect rwnd calculation. 4510 7.2. SCTP Slow-Start and Congestion Avoidance 4512 The slow-start and congestion avoidance algorithms MUST be used by an 4513 endpoint to control the amount of data being injected into the 4514 network. The congestion control in SCTP is employed in regard to the 4515 association, not to an individual stream. In some situations, it 4516 might be beneficial for an SCTP sender to be more conservative than 4517 the algorithms allow; however, an SCTP sender MUST NOT be more 4518 aggressive than the following algorithms allow. 4520 Like TCP, an SCTP endpoint uses the following three control variables 4521 to regulate its transmission rate. 4523 * Receiver advertised window size (rwnd, in bytes), which is set by 4524 the receiver based on its available buffer space for incoming 4525 packets. 4527 Note: This variable is kept on the entire association. 4529 * Congestion control window (cwnd, in bytes), which is adjusted by 4530 the sender based on observed network conditions. 4532 Note: This variable is maintained on a per-destination-address 4533 basis. 4535 * Slow-start threshold (ssthresh, in bytes), which is used by the 4536 sender to distinguish slow-start and congestion avoidance phases. 4538 Note: This variable is maintained on a per-destination-address 4539 basis. 4541 SCTP also requires one additional control variable, 4542 partial_bytes_acked, which is used during congestion avoidance phase 4543 to facilitate cwnd adjustment. 4545 Unlike TCP, an SCTP sender MUST keep a set of these control variables 4546 cwnd, ssthresh, and partial_bytes_acked for EACH destination address 4547 of its peer (when its peer is multi-homed). When calculating one of 4548 these variables, the length of the DATA chunk including the padding 4549 SHOULD be used. 4551 Only one rwnd is kept for the whole association (no matter if the 4552 peer is multi-homed or has a single address). 4554 7.2.1. Slow-Start 4556 Beginning data transmission into a network with unknown conditions or 4557 after a sufficiently long idle period requires SCTP to probe the 4558 network to determine the available capacity. The slow-start 4559 algorithm is used for this purpose at the beginning of a transfer, or 4560 after repairing loss detected by the retransmission timer. 4562 * The initial cwnd before data transmission MUST be set to min(4 * 4563 PMDCS, max(2 * PMDCS, 4404)) bytes if the peer address is an IPv4 4564 address and to min(4 * PMDCS, max(2 * PMDCS, 4344)) bytes if the 4565 peer address is an IPv6 address. 4567 * The initial cwnd after a retransmission timeout MUST be no more 4568 than PMDCS, and only one packet is allowed to be in flight until 4569 successful acknowledgement. 4571 * The initial value of ssthresh SHOULD be arbitrarily high (e.g., 4572 the size of the largest possible advertised window). 4574 * Whenever cwnd is greater than zero, the endpoint is allowed to 4575 have cwnd bytes of data outstanding on that transport address. A 4576 limited overbooking as described in Section 6.1 B) SHOULD be 4577 supported. 4579 * When cwnd is less than or equal to ssthresh, an SCTP endpoint MUST 4580 use the slow-start algorithm to increase cwnd only if the current 4581 congestion window is being fully utilized, and the data sender is 4582 not in Fast Recovery. Only when these two conditions are met can 4583 the cwnd be increased; otherwise, the cwnd MUST NOT be increased. 4584 If these conditions are met, then cwnd MUST be increased by, at 4585 most, the lesser of 4587 1. the total size of the previously outstanding DATA chunk(s) 4588 acknowledged, and 4590 2. L times the destination's PMDCS. 4592 The first upper bound protects against the ACK-Splitting attack 4593 outlined in [SAVAGE99]. The positive integer L SHOULD be 1, and 4594 MAY be larger than 1. See [RFC3465] for details of choosing L. 4596 In instances where its peer endpoint is multi-homed, if an 4597 endpoint receives a SACK chunk that results in updating the cwnd, 4598 then it SHOULD update its cwnd (or cwnds) apportioned to the 4599 destination addresses to which it transmitted the acknowledged 4600 data. 4602 * While the endpoint does not transmit data on a given transport 4603 address, the cwnd of the transport address SHOULD be adjusted to 4604 max(cwnd / 2, 4 * PMDCS) once per RTO. Before the first cwnd 4605 adjustment, the ssthresh of the transport address SHOULD be set to 4606 the cwnd. 4608 7.2.2. Congestion Avoidance 4610 When cwnd is greater than ssthresh, cwnd SHOULD be incremented by 4611 PMDCS per RTT if the sender has cwnd or more bytes of data 4612 outstanding for the corresponding transport address. The basic 4613 recommendations for incrementing cwnd during congestion avoidance are 4614 as follows: 4616 * SCTP MAY increment cwnd by PMDCS. 4618 * SCTP SHOULD increment cwnd by PMDCS once per RTT when the sender 4619 has cwnd or more bytes of data outstanding for the corresponding 4620 transport address. 4622 * SCTP MUST NOT increment cwnd by more than PMDCS per RTT. 4624 In practice, an implementation can achieve this goal in the following 4625 way: 4627 * partial_bytes_acked is initialized to 0. 4629 * Whenever cwnd is greater than ssthresh, upon each SACK chunk 4630 arrival, increase partial_bytes_acked by the total number of bytes 4631 (including the chunk header and the padding) of all new DATA 4632 chunks acknowledged in that SACK chunk, including chunks 4633 acknowledged by the new Cumulative TSN Ack, by Gap Ack Blocks, and 4634 by the number of bytes of duplicated chunks reported in Duplicate 4635 TSNs. 4637 * When (1) partial_bytes_acked is greater than cwnd and (2) before 4638 the arrival of the SACK chunk the sender had less than cwnd bytes 4639 of data outstanding (i.e., before the arrival of the SACK chunk, 4640 flightsize was less than cwnd), reset partial_bytes_acked to cwnd. 4642 * When (1) partial_bytes_acked is equal to or greater than cwnd and 4643 (2) before the arrival of the SACK chunk the sender had cwnd or 4644 more bytes of data outstanding (i.e., before the arrival of the 4645 SACK chunk, flightsize was greater than or equal to cwnd), 4646 partial_bytes_acked is reset to (partial_bytes_acked - cwnd). 4647 Next, cwnd is increased by PMDCS. 4649 * Same as in the slow start, when the sender does not transmit DATA 4650 chunks on a given transport address, the cwnd of the transport 4651 address SHOULD be adjusted to max(cwnd / 2, 4 * PMDCS) per RTO. 4653 * When all of the data transmitted by the sender has been 4654 acknowledged by the receiver, partial_bytes_acked is initialized 4655 to 0. 4657 7.2.3. Congestion Control 4659 Upon detection of packet losses from SACK chunks (see Section 7.2.4), 4660 an endpoint SHOULD do the following: 4662 ssthresh = max(cwnd / 2, 4 * PMDCS) 4663 cwnd = ssthresh 4664 partial_bytes_acked = 0 4666 Basically, a packet loss causes cwnd to be cut in half. 4668 When the T3-rtx timer expires on an address, SCTP SHOULD perform slow 4669 start by: 4671 ssthresh = max(cwnd / 2, 4 * PMDCS) 4672 cwnd = PMDCS 4673 partial_bytes_acked = 0 4675 and ensure that no more than one SCTP packet will be in flight for 4676 that address until the endpoint receives acknowledgement for 4677 successful delivery of data to that address. 4679 7.2.4. Fast Retransmit on Gap Reports 4681 In the absence of data loss, an endpoint performs delayed 4682 acknowledgement. However, whenever an endpoint notices a hole in the 4683 arriving TSN sequence, it SHOULD start sending a SACK chunk back 4684 every time a packet arrives carrying data until the hole is filled. 4686 Whenever an endpoint receives a SACK chunk that indicates that some 4687 TSNs are missing, it SHOULD wait for two further miss indications 4688 (via subsequent SACK chunks for a total of three missing reports) on 4689 the same TSNs before taking action with regard to Fast Retransmit. 4691 Miss indications SHOULD follow the HTNA (Highest TSN Newly 4692 Acknowledged) algorithm. For each incoming SACK chunk, miss 4693 indications are incremented only for missing TSNs prior to the 4694 highest TSN newly acknowledged in the SACK chunk. A newly 4695 acknowledged DATA chunk is one not previously acknowledged in a SACK 4696 chunk. If an endpoint is in Fast Recovery and a SACK chunks arrives 4697 that advances the Cumulative TSN Ack Point, the miss indications are 4698 incremented for all TSNs reported missing in the SACK chunk. 4700 When the third consecutive miss indication is received for a TSN(s), 4701 the data sender does the following: 4703 1) Mark the DATA chunk(s) with three miss indications for 4704 retransmission. 4706 2) If not in Fast Recovery, adjust the ssthresh and cwnd of the 4707 destination address(es) to which the missing DATA chunks were 4708 last sent, according to the formula described in Section 7.2.3. 4710 3) If not in Fast Recovery, determine how many of the earliest 4711 (i.e., lowest TSN) DATA chunks marked for retransmission will fit 4712 into a single packet, subject to constraint of the PMTU of the 4713 destination transport address to which the packet is being sent. 4714 Call this value K. Retransmit those K DATA chunks in a single 4715 packet. When a Fast Retransmit is being performed, the sender 4716 SHOULD ignore the value of cwnd and SHOULD NOT delay 4717 retransmission for this single packet. 4719 4) Restart the T3-rtx timer only if the last SACK chunk acknowledged 4720 the lowest outstanding TSN number sent to that address, or the 4721 endpoint is retransmitting the first outstanding DATA chunk sent 4722 to that address. 4724 5) Mark the DATA chunk(s) as being fast retransmitted and thus 4725 ineligible for a subsequent Fast Retransmit. Those TSNs marked 4726 for retransmission due to the Fast-Retransmit algorithm that did 4727 not fit in the sent datagram carrying K other TSNs are also 4728 marked as ineligible for a subsequent Fast Retransmit. However, 4729 as they are marked for retransmission they will be retransmitted 4730 later on as soon as cwnd allows. 4732 6) If not in Fast Recovery, enter Fast Recovery and mark the highest 4733 outstanding TSN as the Fast Recovery exit point. When a SACK 4734 chunk acknowledges all TSNs up to and including this exit point, 4735 Fast Recovery is exited. While in Fast Recovery, the ssthresh 4736 and cwnd SHOULD NOT change for any destinations due to a 4737 subsequent Fast Recovery event (i.e., one SHOULD NOT reduce the 4738 cwnd further due to a subsequent Fast Retransmit). 4740 Note: Before the above adjustments, if the received SACK chunk also 4741 acknowledges new DATA chunks and advances the Cumulative TSN Ack 4742 Point, the cwnd adjustment rules defined in Section 7.2.1 and 4743 Section 7.2.2 MUST be applied first. 4745 7.2.5. Reinitialization 4747 During the lifetime of an SCTP association events can happen, which 4748 result in using the network under unknown new conditions. When 4749 detected by an SCTP implementation, the congestion control MUST be 4750 reinitialized. 4752 7.2.5.1. Change of Differentiated Services Code Points 4754 SCTP implementations MAY allow an application to configure the 4755 Differentiated Services Code Point (DSCP) used for sending packets. 4756 If a DSCP change might result in outgoing packets being queued in 4757 different queues, the congestion control parameters for all affected 4758 destination addresses MUST be reset to their initial values. 4760 7.2.5.2. Change of Routes 4762 SCTP implementations MAY be aware of routing changes affecting 4763 packets sent to a destination address. In particular, this includes 4764 the selection of a different source address used for sending packets 4765 to a destination address. If such a routing change happens, the 4766 congestion control parameters for the affected destination addresses 4767 MUST be reset to their initial values. 4769 7.3. PMTU Discovery 4771 [RFC8899], [RFC8201], and [RFC1191] specify "Packetization Layer Path 4772 MTU Discovery", whereby an endpoint maintains an estimate of PMTU 4773 along a given Internet path and refrains from sending packets along 4774 that path that exceed the PMTU, other than occasional attempts to 4775 probe for a change in the PMTU. [RFC8899] is thorough in its 4776 discussion of the PMTU discovery mechanism and strategies for 4777 determining the current end-to-end PMTU setting as well as detecting 4778 changes in this value. 4780 An endpoint SHOULD apply these techniques, and SHOULD do so on a per- 4781 destination-address basis. 4783 There are two important SCTP-specific points regarding PMTU 4784 discovery: 4786 1) SCTP associations can span multiple addresses. An endpoint MUST 4787 maintain separate PMTU estimates for each destination address of 4788 its peer. 4790 2) The sender SHOULD track an AMDCS that will be the smallest PMDCS 4791 discovered for all of the peer's destination addresses. When 4792 fragmenting messages into multiple parts this AMDCS SHOULD be 4793 used to calculate the size of each DATA chunk. This will allow 4794 retransmissions to be seamlessly sent to an alternate address 4795 without encountering IP fragmentation. 4797 8. Fault Management 4799 8.1. Endpoint Failure Detection 4801 An endpoint SHOULD keep a counter on the total number of consecutive 4802 retransmissions to its peer (this includes data retransmissions to 4803 all the destination transport addresses of the peer if it is multi- 4804 homed), including the number of unacknowledged HEARTBEAT chunks 4805 observed on the path that is currently used for data transfer. 4806 Unacknowledged HEARTBEAT chunks observed on paths different from the 4807 path currently used for data transfer SHOULD NOT increment the 4808 association error counter, as this could lead to association closure 4809 even if the path that is currently used for data transfer is 4810 available (but idle). If the value of this counter exceeds the limit 4811 indicated in the protocol parameter 'Association.Max.Retrans', the 4812 endpoint SHOULD consider the peer endpoint unreachable and SHALL stop 4813 transmitting any more data to it (and thus the association enters the 4814 CLOSED state). In addition, the endpoint SHOULD report the failure 4815 to the upper layer and optionally report back all outstanding user 4816 data remaining in its outbound queue. The association is 4817 automatically closed when the peer endpoint becomes unreachable. 4819 The counter used for endpoint failure detection MUST be reset each 4820 time a DATA chunk sent to that peer endpoint is acknowledged (by the 4821 reception of a SACK chunk). When a HEARTBEAT ACK chunk is received 4822 from the peer endpoint, the counter SHOULD also be reset. The 4823 receiver of the HEARTBEAT ACK chunk MAY choose not to clear the 4824 counter if there is outstanding data on the association. This allows 4825 for handling the possible difference in reachability based on DATA 4826 chunks and HEARTBEAT chunks. 4828 8.2. Path Failure Detection 4830 When its peer endpoint is multi-homed, an endpoint SHOULD keep an 4831 error counter for each of the destination transport addresses of the 4832 peer endpoint. 4834 Each time the T3-rtx timer expires on any address, or when a 4835 HEARTBEAT chunk sent to an idle address is not acknowledged within an 4836 RTO, the error counter of that destination address will be 4837 incremented. When the value in the error counter exceeds the 4838 protocol parameter 'Path.Max.Retrans' of that destination address, 4839 the endpoint SHOULD mark the destination transport address as 4840 inactive, and a notification SHOULD be sent to the upper layer. 4842 When an outstanding TSN is acknowledged or a HEARTBEAT chunk sent to 4843 that address is acknowledged with a HEARTBEAT ACK chunk, the endpoint 4844 SHOULD clear the error counter of the destination transport address 4845 to which the DATA chunk was last sent (or HEARTBEAT chunk was sent) 4846 and SHOULD also report to the upper layer when an inactive 4847 destination address is marked as active. When the peer endpoint is 4848 multi-homed and the last chunk sent to it was a retransmission to an 4849 alternate address, there exists an ambiguity as to whether or not the 4850 acknowledgement could be credited to the address of the last chunk 4851 sent. However, this ambiguity does not seem to have significant 4852 consequences for SCTP behavior. If this ambiguity is undesirable, 4853 the transmitter MAY choose not to clear the error counter if the last 4854 chunk sent was a retransmission. 4856 Note: When configuring the SCTP endpoint, the user ought to avoid 4857 having the value of 'Association.Max.Retrans' larger than the 4858 summation of the 'Path.Max.Retrans' of all the destination addresses 4859 for the remote endpoint. Otherwise, all the destination addresses 4860 might become inactive while the endpoint still considers the peer 4861 endpoint reachable. When this condition occurs, how SCTP chooses to 4862 function is implementation specific. 4864 When the primary path is marked inactive (due to excessive 4865 retransmissions, for instance), the sender MAY automatically transmit 4866 new packets to an alternate destination address if one exists and is 4867 active. If more than one alternate address is active when the 4868 primary path is marked inactive, only ONE transport address SHOULD be 4869 chosen and used as the new destination transport address. 4871 8.3. Path Heartbeat 4873 By default, an SCTP endpoint SHOULD monitor the reachability of the 4874 idle destination transport address(es) of its peer by sending a 4875 HEARTBEAT chunk periodically to the destination transport 4876 address(es). The sending of HEARTBEAT chunks MAY begin upon reaching 4877 the ESTABLISHED state and is discontinued after sending either a 4878 SHUTDOWN chunk or SHUTDOWN ACK chunk. A receiver of a HEARTBEAT 4879 chunks MUST respond to a HEARTBEAT chunk with a HEARTBEAT ACK chunk 4880 after entering the COOKIE-ECHOED state (sender of the INIT chunk) or 4881 the ESTABLISHED state (receiver of the INIT chunk), up until reaching 4882 the SHUTDOWN-SENT state (sender of the SHUTDOWN chunk) or the 4883 SHUTDOWN-ACK-SENT state (receiver of the SHUTDOWN chunk). 4885 A destination transport address is considered "idle" if no new chunk 4886 that can be used for updating path RTT (usually including first 4887 transmission DATA, INIT, COOKIE ECHO, or HEARTBEAT chunks, etc.) and 4888 no HEARTBEAT chunk has been sent to it within the current heartbeat 4889 period of that address. This applies to both active and inactive 4890 destination addresses. 4892 The upper layer can optionally initiate the following functions: 4894 A) Disable heartbeat on a specific destination transport address of 4895 a given association, 4897 B) Change the 'HB.interval', 4899 C) Re-enable heartbeat on a specific destination transport address 4900 of a given association, and 4902 D) Request the sending of an on-demand HEARTBEAT chunk on a specific 4903 destination transport address of a given association. 4905 The endpoint SHOULD increment the respective error counter of the 4906 destination transport address each time a HEARTBEAT chunk is sent to 4907 that address and not acknowledged within one RTO. 4909 When the value of this counter exceeds the protocol parameter 4910 'Path.Max.Retrans', the endpoint SHOULD mark the corresponding 4911 destination address as inactive if it is not so marked and SHOULD 4912 also report to the upper layer the change in reachability of this 4913 destination address. After this, the endpoint SHOULD continue 4914 sending HEARTBEAT chunks on this destination address but SHOULD stop 4915 increasing the counter. 4917 The sender of the HEARTBEAT chunk SHOULD include in the Heartbeat 4918 Information field of the chunk the current time when the packet is 4919 sent and the destination address to which the packet is sent. 4921 Implementation Note: An alternative implementation of the heartbeat 4922 mechanism that can be used is to increment the error counter variable 4923 every time a HEARTBEAT chunk is sent to a destination. Whenever a 4924 HEARTBEAT ACK chunk arrives, the sender SHOULD clear the error 4925 counter of the destination that the HEARTBEAT chunk was sent to. 4926 This in effect would clear the previously stroked error (and any 4927 other error counts as well). 4929 The receiver of the HEARTBEAT chunk SHOULD immediately respond with a 4930 HEARTBEAT ACK chunk that contains the Heartbeat Information TLV, 4931 together with any other received TLVs, copied unchanged from the 4932 received HEARTBEAT chunk. 4934 Upon the receipt of the HEARTBEAT ACK chunk, the sender of the 4935 HEARTBEAT chunk SHOULD clear the error counter of the destination 4936 transport address to which the HEARTBEAT chunk was sent and mark the 4937 destination transport address as active if it is not so marked. The 4938 endpoint SHOULD report to the upper layer when an inactive 4939 destination address is marked as active due to the reception of the 4940 latest HEARTBEAT ACK chunk. The receiver of the HEARTBEAT ACK chunk 4941 SHOULD also clear the association overall error count (as defined in 4942 Section 8.1). 4944 The receiver of the HEARTBEAT ACK chunk SHOULD also perform an RTT 4945 measurement for that destination transport address using the time 4946 value carried in the HEARTBEAT ACK chunk. 4948 On an idle destination address that is allowed to heartbeat, it is 4949 RECOMMENDED that a HEARTBEAT chunk is sent once per RTO of that 4950 destination address plus the protocol parameter 'HB.interval', with 4951 jittering of +/- 50% of the RTO value, and exponential backoff of the 4952 RTO if the previous HEARTBEAT chunk is unanswered. 4954 A primitive is provided for the SCTP user to change the 'HB.interval' 4955 and turn on or off the heartbeat on a given destination address. The 4956 'HB.interval' set by the SCTP user is added to the RTO of that 4957 destination (including any exponential backoff). Only one heartbeat 4958 SHOULD be sent each time the heartbeat timer expires (if multiple 4959 destinations are idle). It is an implementation decision on how to 4960 choose which of the candidate idle destinations to heartbeat to (if 4961 more than one destination is idle). 4963 When tuning the 'HB.interval', there is a side effect that SHOULD be 4964 taken into account. When this value is increased, i.e., the time 4965 between the sending of HEARTBEAT chunks is longer, the detection of 4966 lost ABORT chunks takes longer as well. If a peer endpoint sends an 4967 ABORT chunk for any reason and the ABORT chunk is lost, the local 4968 endpoint will only discover the lost ABORT chunk by sending a DATA 4969 chunk or HEARTBEAT chunk (thus causing the peer to send another ABORT 4970 chunk). This is to be considered when tuning the heartbeat timer. 4971 If the sending of HEARTBEAT chunks is disabled, only sending DATA 4972 chunks to the association will discover a lost ABORT chunk from the 4973 peer. 4975 8.4. Handle "Out of the Blue" Packets 4977 An SCTP packet is called an "out of the blue" (OOTB) packet if it is 4978 correctly formed (i.e., passed the receiver's CRC32c check; see 4979 Section 6.8), but the receiver is not able to identify the 4980 association to which this packet belongs. 4982 The receiver of an OOTB packet does the following: 4984 1) If the OOTB packet is to or from a non-unicast address, a 4985 receiver SHOULD silently discard the packet. Otherwise, 4987 2) If the OOTB packet contains an ABORT chunk, the receiver MUST 4988 silently discard the OOTB packet and take no further action. 4989 Otherwise, 4991 3) If the packet contains an INIT chunk with a Verification Tag set 4992 to 0, it SHOULD be processed as described in Section 5.1. If, 4993 for whatever reason, the INIT chunk cannot be processed normally 4994 and an ABORT chunk has to be sent in response, the Verification 4995 Tag of the packet containing the ABORT chunk MUST be the Initiate 4996 Tag of the received INIT chunk, and the T bit of the ABORT chunk 4997 has to be set to 0, indicating that the Verification Tag is not 4998 reflected. Otherwise, 5000 4) If the packet contains a COOKIE ECHO chunk as the first chunk, it 5001 MUST be processed as described in Section 5.1. Otherwise, 5003 5) If the packet contains a SHUTDOWN ACK chunk, the receiver SHOULD 5004 respond to the sender of the OOTB packet with a SHUTDOWN COMPLETE 5005 chunk. When sending the SHUTDOWN COMPLETE chunk, the receiver of 5006 the OOTB packet MUST fill in the Verification Tag field of the 5007 outbound packet with the Verification Tag received in the 5008 SHUTDOWN ACK chunk and set the T bit in the Chunk Flags to 5009 indicate that the Verification Tag is reflected. Otherwise, 5011 6) If the packet contains a SHUTDOWN COMPLETE chunk, the receiver 5012 SHOULD silently discard the packet and take no further action. 5013 Otherwise, 5015 7) If the packet contains a ERROR chunk with the "Stale Cookie" 5016 error cause or a COOKIE ACK chunk, the SCTP packet SHOULD be 5017 silently discarded. Otherwise, 5019 8) The receiver SHOULD respond to the sender of the OOTB packet with 5020 an ABORT chunk. When sending the ABORT chunk, the receiver of 5021 the OOTB packet MUST fill in the Verification Tag field of the 5022 outbound packet with the value found in the Verification Tag 5023 field of the OOTB packet and set the T bit in the Chunk Flags to 5024 indicate that the Verification Tag is reflected. After sending 5025 this ABORT chunk, the receiver of the OOTB packet MUST discard 5026 the OOTB packet and MUST NOT take any further action. 5028 8.5. Verification Tag 5030 The Verification Tag rules defined in this section apply when sending 5031 or receiving SCTP packets that do not contain an INIT, SHUTDOWN 5032 COMPLETE, COOKIE ECHO (see Section 5.1), ABORT, or SHUTDOWN ACK 5033 chunk. The rules for sending and receiving SCTP packets containing 5034 one of these chunk types are discussed separately in Section 8.5.1. 5036 When sending an SCTP packet, the endpoint MUST fill in the 5037 Verification Tag field of the outbound packet with the tag value in 5038 the Initiate Tag parameter of the INIT or INIT ACK chunk received 5039 from its peer. 5041 When receiving an SCTP packet, the endpoint MUST ensure that the 5042 value in the Verification Tag field of the received SCTP packet 5043 matches its own tag. If the received Verification Tag value does not 5044 match the receiver's own tag value, the receiver MUST silently 5045 discard the packet and MUST NOT process it any further except for 5046 those cases listed in Section 8.5.1 below. 5048 8.5.1. Exceptions in Verification Tag Rules 5050 A) Rules for packets carrying an INIT chunk: 5051 * The sender MUST set the Verification Tag of the packet to 0. 5053 * When an endpoint receives an SCTP packet with the Verification 5054 Tag set to 0, it SHOULD verify that the packet contains only an 5055 INIT chunk. Otherwise, the receiver MUST silently discard the 5056 packet. 5058 B) Rules for packets carrying an ABORT chunk: 5059 * The endpoint MUST always fill in the Verification Tag field of 5060 the outbound packet with the destination endpoint's tag value, 5061 if it is known. 5063 * If the ABORT chunk is sent in response to an OOTB packet, the 5064 endpoint MUST follow the procedure described in Section 8.4. 5066 * The receiver of an ABORT chunk MUST accept the packet if the 5067 Verification Tag field of the packet matches its own tag and 5068 the T bit is not set OR if it is set to its peer's tag and the 5069 T bit is set in the Chunk Flags. Otherwise, the receiver MUST 5070 silently discard the packet and take no further action. 5072 C) Rules for packets carrying a SHUTDOWN COMPLETE chunk: 5073 * When sending a SHUTDOWN COMPLETE chunk, if the receiver of the 5074 SHUTDOWN ACK chunk has a TCB, then the destination endpoint's 5075 tag MUST be used, and the T bit MUST NOT be set. Only where no 5076 TCB exists SHOULD the sender use the Verification Tag from the 5077 SHUTDOWN ACK chunk, and MUST set the T bit. 5079 * The receiver of a SHUTDOWN COMPLETE chunk accepts the packet if 5080 the Verification Tag field of the packet matches its own tag 5081 and the T bit is not set OR if it is set to its peer's tag and 5082 the T bit is set in the Chunk Flags. Otherwise, the receiver 5083 MUST silently discard the packet and take no further action. 5084 An endpoint MUST ignore the SHUTDOWN COMPLETE chunk if it is 5085 not in the SHUTDOWN-ACK-SENT state. 5087 D) Rules for packets carrying a COOKIE ECHO chunk: 5088 * When sending a COOKIE ECHO chunk, the endpoint MUST use the 5089 value of the Initiate Tag received in the INIT ACK chunk. 5091 * The receiver of a COOKIE ECHO chunk follows the procedures in 5092 Section 5. 5094 E) Rules for packets carrying a SHUTDOWN ACK chunk: 5095 * If the receiver is in COOKIE-ECHOED or COOKIE-WAIT state the 5096 procedures in Section 8.4 SHOULD be followed; in other words, 5097 it is treated as an OOTB packet. 5099 9. Termination of Association 5101 An endpoint SHOULD terminate its association when it exits from 5102 service. An association can be terminated by either abort or 5103 shutdown. An abort of an association is abortive by definition in 5104 that any data pending on either end of the association is discarded 5105 and not delivered to the peer. A shutdown of an association is 5106 considered a graceful close where all data in queue by either 5107 endpoint is delivered to the respective peers. However, in the case 5108 of a shutdown, SCTP does not support a half-open state (like TCP) 5109 wherein one side might continue sending data while the other end is 5110 closed. When either endpoint performs a shutdown, the association on 5111 each peer will stop accepting new data from its user and only deliver 5112 data in queue at the time of sending or receiving the SHUTDOWN chunk. 5114 9.1. Abort of an Association 5116 When an endpoint decides to abort an existing association, it MUST 5117 send an ABORT chunk to its peer endpoint. The sender MUST fill in 5118 the peer's Verification Tag in the outbound packet and MUST NOT 5119 bundle any DATA chunk with the ABORT chunk. If the association is 5120 aborted on request of the upper layer, a "User-Initiated Abort" error 5121 cause (see Section 3.3.10.12) SHOULD be present in the ABORT chunk. 5123 An endpoint MUST NOT respond to any received packet that contains an 5124 ABORT chunk (also see Section 8.4). 5126 An endpoint receiving an ABORT chunk MUST apply the special 5127 Verification Tag check rules described in Section 8.5.1. 5129 After checking the Verification Tag, the receiving endpoint MUST 5130 remove the association from its record and SHOULD report the 5131 termination to its upper layer. If a "User-Initiated Abort" error 5132 cause is present in the ABORT chunk, the Upper Layer Abort Reason 5133 SHOULD be made available to the upper layer. 5135 9.2. Shutdown of an Association 5137 Using the SHUTDOWN primitive (see Section 11.1), the upper layer of 5138 an endpoint in an association can gracefully close the association. 5139 This will allow all outstanding DATA chunks from the peer of the 5140 shutdown initiator to be delivered before the association terminates. 5142 Upon receipt of the SHUTDOWN primitive from its upper layer, the 5143 endpoint enters the SHUTDOWN-PENDING state and remains there until 5144 all outstanding data has been acknowledged by its peer. The endpoint 5145 accepts no new data from its upper layer, but retransmits data to the 5146 peer endpoint if necessary to fill gaps. 5148 Once all its outstanding data has been acknowledged, the endpoint 5149 sends a SHUTDOWN chunk to its peer including in the Cumulative TSN 5150 Ack field the last sequential TSN it has received from the peer. It 5151 SHOULD then start the T2-shutdown timer and enter the SHUTDOWN-SENT 5152 state. If the timer expires, the endpoint MUST resend the SHUTDOWN 5153 chunk with the updated last sequential TSN received from its peer. 5155 The rules in Section 6.3 MUST be followed to determine the proper 5156 timer value for T2-shutdown. To indicate any gaps in TSN, the 5157 endpoint MAY also bundle a SACK chunk with the SHUTDOWN chunk in the 5158 same SCTP packet. 5160 An endpoint SHOULD limit the number of retransmissions of the 5161 SHUTDOWN chunk to the protocol parameter 'Association.Max.Retrans'. 5162 If this threshold is exceeded, the endpoint SHOULD destroy the TCB 5163 and SHOULD report the peer endpoint unreachable to the upper layer 5164 (and thus the association enters the CLOSED state). The reception of 5165 any packet from its peer (i.e., as the peer sends all of its queued 5166 DATA chunks) SHOULD clear the endpoint's retransmission count and 5167 restart the T2-shutdown timer, giving its peer ample opportunity to 5168 transmit all of its queued DATA chunks that have not yet been sent. 5170 Upon reception of the SHUTDOWN chunk, the peer endpoint does the 5171 following: 5173 * enter the SHUTDOWN-RECEIVED state, 5175 * stop accepting new data from its SCTP user, and 5177 * verify, by checking the Cumulative TSN Ack field of the chunk, 5178 that all its outstanding DATA chunks have been received by the 5179 SHUTDOWN chunk sender. 5181 Once an endpoint has reached the SHUTDOWN-RECEIVED state, it MUST 5182 ignore ULP shutdown requests but MUST continue responding to SHUTDOWN 5183 chunks from its peer. 5185 If there are still outstanding DATA chunks left, the SHUTDOWN chunk 5186 receiver MUST continue to follow normal data transmission procedures 5187 defined in Section 6, until all outstanding DATA chunks are 5188 acknowledged; however, the SHUTDOWN chunk receiver MUST NOT accept 5189 new data from its SCTP user. 5191 While in the SHUTDOWN-SENT state, the SHUTDOWN chunk sender MUST 5192 immediately respond to each received packet containing one or more 5193 DATA chunks with a SHUTDOWN chunk and restart the T2-shutdown timer. 5194 If a SHUTDOWN chunk by itself cannot acknowledge all of the received 5195 DATA chunks (i.e., there are TSNs that can be acknowledged that are 5196 larger than the cumulative TSN, and thus gaps exist in the TSN 5197 sequence), or if duplicate TSNs have been received, then a SACK chunk 5198 MUST also be sent. 5200 The sender of the SHUTDOWN chunk MAY also start an overall guard 5201 timer T5-shutdown-guard to bound the overall time for the shutdown 5202 sequence. At the expiration of this timer, the sender SHOULD abort 5203 the association by sending an ABORT chunk. If the T5-shutdown-guard 5204 timer is used, it SHOULD be set to the RECOMMENDED value of 5 times 5205 'RTO.Max'. 5207 If the receiver of the SHUTDOWN chunk has no more outstanding DATA 5208 chunks, the SHUTDOWN chunk receiver MUST send a SHUTDOWN ACK chunk 5209 and start a T2-shutdown timer of its own, entering the SHUTDOWN-ACK- 5210 SENT state. If the timer expires, the endpoint MUST resend the 5211 SHUTDOWN ACK chunk. 5213 The sender of the SHUTDOWN ACK chunk SHOULD limit the number of 5214 retransmissions of the SHUTDOWN ACK chunk to the protocol parameter 5215 'Association.Max.Retrans'. If this threshold is exceeded, the 5216 endpoint SHOULD destroy the TCB and SHOULD report the peer endpoint 5217 unreachable to the upper layer (and thus the association enters the 5218 CLOSED state). 5220 Upon the receipt of the SHUTDOWN ACK chunk, the sender of the 5221 SHUTDOWN chunk MUST stop the T2-shutdown timer, send a SHUTDOWN 5222 COMPLETE chunk to its peer, and remove all record of the association. 5224 Upon reception of the SHUTDOWN COMPLETE chunk, the endpoint verifies 5225 that it is in the SHUTDOWN-ACK-SENT state; if it is not, the chunk 5226 SHOULD be discarded. If the endpoint is in the SHUTDOWN-ACK-SENT 5227 state, the endpoint SHOULD stop the T2-shutdown timer and remove all 5228 knowledge of the association (and thus the association enters the 5229 CLOSED state). 5231 An endpoint SHOULD ensure that all its outstanding DATA chunks have 5232 been acknowledged before initiating the shutdown procedure. 5234 An endpoint SHOULD reject any new data request from its upper layer 5235 if it is in the SHUTDOWN-PENDING, SHUTDOWN-SENT, SHUTDOWN-RECEIVED, 5236 or SHUTDOWN-ACK-SENT state. 5238 If an endpoint is in the SHUTDOWN-ACK-SENT state and receives an INIT 5239 chunk (e.g., if the SHUTDOWN COMPLETE chunk was lost) with source and 5240 destination transport addresses (either in the IP addresses or in the 5241 INIT chunk) that belong to this association, it SHOULD discard the 5242 INIT chunk and retransmit the SHUTDOWN ACK chunk. 5244 Note: Receipt of a packet containing an INIT chunk with the same 5245 source and destination IP addresses as used in transport addresses 5246 assigned to an endpoint but with a different port number indicates 5247 the initialization of a separate association. 5249 The sender of the INIT or COOKIE ECHO chunk SHOULD respond to the 5250 receipt of a SHUTDOWN ACK chunk with a stand-alone SHUTDOWN COMPLETE 5251 chunk in an SCTP packet with the Verification Tag field of its common 5252 header set to the same tag that was received in the packet containing 5253 the SHUTDOWN ACK chunk. This is considered an OOTB packet as defined 5254 in Section 8.4. The sender of the INIT chunk lets T1-init continue 5255 running and remains in the COOKIE-WAIT or COOKIE-ECHOED state. 5256 Normal T1-init timer expiration will cause the INIT or COOKIE chunk 5257 to be retransmitted and thus start a new association. 5259 If a SHUTDOWN chunk is received in the COOKIE-WAIT or COOKIE ECHOED 5260 state, the SHUTDOWN chunk SHOULD be silently discarded. 5262 If an endpoint is in the SHUTDOWN-SENT state and receives a SHUTDOWN 5263 chunk from its peer, the endpoint SHOULD respond immediately with a 5264 SHUTDOWN ACK chunk to its peer, and move into the SHUTDOWN-ACK-SENT 5265 state restarting its T2-shutdown timer. 5267 If an endpoint is in the SHUTDOWN-ACK-SENT state and receives a 5268 SHUTDOWN ACK, it MUST stop the T2-shutdown timer, send a SHUTDOWN 5269 COMPLETE chunk to its peer, and remove all record of the association. 5271 10. ICMP Handling 5273 Whenever an ICMP message is received by an SCTP endpoint, the 5274 following procedures MUST be followed to ensure proper utilization of 5275 the information being provided by layer 3. 5277 ICMP1) An implementation MAY ignore all ICMPv4 messages where the 5278 type field is not set to "Destination Unreachable". 5280 ICMP2) An implementation MAY ignore all ICMPv6 messages where the 5281 type field is not "Destination Unreachable", "Parameter 5282 Problem", or "Packet Too Big". 5284 ICMP3) An implementation SHOULD ignore any ICMP messages where the 5285 code indicates "Port Unreachable". 5287 ICMP4) An implementation MAY ignore all ICMPv6 messages of type 5288 "Parameter Problem" if the code is not "Unrecognized Next 5289 Header Type Encountered". 5291 ICMP5) An implementation MUST use the payload of the ICMP message 5292 (v4 or v6) to locate the association that sent the message to 5293 which ICMP is responding. If the association cannot be 5294 found, an implementation SHOULD ignore the ICMP message. 5296 ICMP6) An implementation MUST validate that the Verification Tag 5297 contained in the ICMP message matches the Verification Tag of 5298 the peer. If the Verification Tag is not 0 and does not 5299 match, discard the ICMP message. If it is 0 and the ICMP 5300 message contains enough bytes to verify that the chunk type 5301 is an INIT chunk and that the Initiate Tag matches the tag of 5302 the peer, continue with ICMP7. If the ICMP message is too 5303 short or the chunk type or the Initiate Tag does not match, 5304 silently discard the packet. 5306 ICMP7) If the ICMP message is either an ICMPv6 message of type 5307 "Packet Too Big" or an ICMPv4 message of type "Destination 5308 Unreachable" and code "Fragmentation Needed", an 5309 implementation SHOULD process this information as defined for 5310 PMTU discovery. 5312 ICMP8) If the ICMP code is an "Unrecognized Next Header Type 5313 Encountered" or a "Protocol Unreachable", an implementation 5314 MUST treat this message as an abort with the T bit set if it 5315 does not contain an INIT chunk. If it does contain an INIT 5316 chunk and the association is in the COOKIE-WAIT state, handle 5317 the ICMP message like an ABORT chunk. 5319 ICMP9) If the ICMP type is "Destination Unreachable", the 5320 implementation MAY move the destination to the unreachable 5321 state or, alternatively, increment the path error counter. 5322 SCTP MAY provide information to the upper layer indicating 5323 the reception of ICMP messages when reporting a network 5324 status change. 5326 These procedures differ from [RFC1122] and from its requirements for 5327 processing of port-unreachable messages and the requirements that an 5328 implementation MUST abort associations in response to a "protocol 5329 unreachable" message. Port-unreachable messages are not processed, 5330 since an implementation will send an ABORT chunk, not a port 5331 unreachable. The stricter handling of the "protocol unreachable" 5332 message is due to security concerns for hosts that do not support 5333 SCTP. 5335 11. Interface with Upper Layer 5337 The Upper Layer Protocols (ULPs) request services by passing 5338 primitives to SCTP and receive notifications from SCTP for various 5339 events. 5341 The primitives and notifications described in this section can be 5342 used as a guideline for implementing SCTP. The following functional 5343 description of ULP interface primitives is shown for illustrative 5344 purposes. Different SCTP implementations can have different ULP 5345 interfaces. However, all SCTP implementations are expected to 5346 provide a certain minimum set of services to guarantee that all SCTP 5347 implementations can support the same protocol hierarchy. 5349 Please note that this section is informational only. 5351 [RFC6458] and the Socket API Considerations section of [RFC7053] 5352 define an extension of the socket API for SCTP as described in this 5353 document. 5355 11.1. ULP-to-SCTP 5357 The following sections functionally characterize a ULP/SCTP 5358 interface. The notation used is similar to most procedure or 5359 function calls in high-level languages. 5361 The ULP primitives described below specify the basic functions that 5362 SCTP performs to support inter-process communication. Individual 5363 implementations define their own exact format, and provide 5364 combinations or subsets of the basic functions in single calls. 5366 11.1.1. Initialize 5368 INITIALIZE ([local port],[local eligible address list]) 5369 -> local SCTP instance name 5371 This primitive allows SCTP to initialize its internal data structures 5372 and allocate necessary resources for setting up its operation 5373 environment. Once SCTP is initialized, ULP can communicate directly 5374 with other endpoints without re-invoking this primitive. 5376 SCTP will return a local SCTP instance name to the ULP. 5378 Mandatory attributes: 5379 None. 5381 Optional attributes: 5382 local port: SCTP port number, if ULP wants it to be specified. 5384 local eligible address list: an address list that the local SCTP 5385 endpoint binds. By default, if an address list is not 5386 included, all IP addresses assigned to the host are used by the 5387 local endpoint. 5389 Implementation Note: If this optional attribute is supported by an 5390 implementation, it will be the responsibility of the implementation 5391 to enforce that the IP source address field of any SCTP packets sent 5392 by this endpoint contains one of the IP addresses indicated in the 5393 local eligible address list. 5395 11.1.2. Associate 5397 ASSOCIATE(local SCTP instance name, 5398 initial destination transport addr list, outbound stream count) 5399 -> association id [,destination transport addr list] 5400 [,outbound stream count] 5402 This primitive allows the upper layer to initiate an association to a 5403 specific peer endpoint. 5405 The peer endpoint is specified by one or more of the transport 5406 addresses that defines the endpoint (see Section 2.3). If the local 5407 SCTP instance has not been initialized, the ASSOCIATE is considered 5408 an error. 5410 An association id, which is a local handle to the SCTP association, 5411 will be returned on successful establishment of the association. If 5412 SCTP is not able to open an SCTP association with the peer endpoint, 5413 an error is returned. 5415 Other association parameters can be returned, including the complete 5416 destination transport addresses of the peer as well as the outbound 5417 stream count of the local endpoint. One of the transport addresses 5418 from the returned destination addresses will be selected by the local 5419 endpoint as default primary path for sending SCTP packets to this 5420 peer. The returned "destination transport addr list" can be used by 5421 the ULP to change the default primary path or to force sending a 5422 packet to a specific transport address. 5424 Implementation Note: If ASSOCIATE primitive is implemented as a 5425 blocking function call, the ASSOCIATE primitive can return 5426 association parameters in addition to the association id upon 5427 successful establishment. If ASSOCIATE primitive is implemented as a 5428 non-blocking call, only the association id is returned and 5429 association parameters are passed using the COMMUNICATION UP 5430 notification. 5432 Mandatory attributes: 5433 local SCTP instance name: obtained from the INITIALIZE operation. 5435 initial destination transport addr list: a non-empty list of 5436 transport addresses of the peer endpoint with which the 5437 association is to be established. 5439 outbound stream count: the number of outbound streams the ULP 5440 would like to open towards this peer endpoint. 5442 Optional attributes: 5443 None. 5445 11.1.3. Shutdown 5447 SHUTDOWN(association id) -> result 5449 Gracefully closes an association. Any locally queued user data will 5450 be delivered to the peer. The association will be terminated only 5451 after the peer acknowledges all the SCTP packets sent. A success 5452 code will be returned on successful termination of the association. 5453 If attempting to terminate the association results in a failure, an 5454 error code is returned. 5456 Mandatory attributes: 5457 association id: local handle to the SCTP association. 5459 Optional attributes: 5460 None. 5462 11.1.4. Abort 5464 ABORT(association id [, Upper Layer Abort Reason]) -> result 5466 Ungracefully closes an association. Any locally queued user data 5467 will be discarded, and an ABORT chunk is sent to the peer. A success 5468 code will be returned on successful abort of the association. If 5469 attempting to abort the association results in a failure, an error 5470 code is returned. 5472 Mandatory attributes: 5473 association id: local handle to the SCTP association. 5475 Optional attributes: 5476 Upper Layer Abort Reason: reason of the abort to be passed to the 5477 peer. 5479 11.1.5. Send 5480 SEND(association id, buffer address, byte count [,context] 5481 [,stream id] [,life time] [,destination transport address] 5482 [,unordered flag] [,no-bundle flag] [,payload protocol-id] 5483 [,sack-immediately flag]) -> result 5485 This is the main method to send user data via SCTP. 5487 Mandatory attributes: 5488 association id: local handle to the SCTP association. 5490 buffer address: the location where the user message to be 5491 transmitted is stored. 5493 byte count: the size of the user data in number of bytes. 5495 Optional attributes: 5496 context: an optional information provided that will be carried in 5497 the sending failure notification to the ULP if the 5498 transportation of this user message fails. 5500 stream id: to indicate which stream to send the data on. If not 5501 specified, stream 0 will be used. 5503 life time: specifies the life time of the user data. The user 5504 data will not be sent by SCTP after the life time expires. 5505 This parameter can be used to avoid efforts to transmit stale 5506 user messages. SCTP notifies the ULP if the data cannot be 5507 initiated to transport (i.e., sent to the destination via 5508 SCTP's SEND primitive) within the life time variable. However, 5509 the user data will be transmitted if SCTP has attempted to 5510 transmit a chunk before the life time expired. 5512 Implementation Note: In order to better support the data life 5513 time option, the transmitter can hold back the assigning of the 5514 TSN number to an outbound DATA chunk to the last moment. And, 5515 for implementation simplicity, once a TSN number has been 5516 assigned the sender considers the send of this DATA chunk as 5517 committed, overriding any life time option attached to the DATA 5518 chunk. 5520 destination transport address: specified as one of the 5521 destination transport addresses of the peer endpoint to which 5522 this packet is sent. Whenever possible, SCTP uses this 5523 destination transport address for sending the packets, instead 5524 of the current primary path. 5526 unordered flag: this flag, if present, indicates that the user 5527 would like the data delivered in an unordered fashion to the 5528 peer (i.e., the U flag is set to 1 on all DATA chunks carrying 5529 this message). 5531 no-bundle flag: instructs SCTP not to delay the sending of DATA 5532 chunks for this user data just to allow it to be bundled with 5533 other outbound DATA chunks. When faced with network 5534 congestion, SCTP might still bundle the data, even when this 5535 flag is present. 5537 payload protocol-id: a 32-bit unsigned integer that is to be 5538 passed to the peer indicating the type of payload protocol data 5539 being transmitted. Note that the upper layer is responsible 5540 for the host to network byte order conversion of this field, 5541 which is passed by SCTP as 4 bytes of opaque data. 5543 sack-immediately flag: set the I bit on the last DATA chunk used 5544 for the user message to be transmitted. 5546 11.1.6. Set Primary 5548 SETPRIMARY(association id, destination transport address, 5549 [source transport address]) -> result 5551 Instructs the local SCTP to use the specified destination transport 5552 address as the primary path for sending packets. 5554 The result of attempting this operation is returned. If the 5555 specified destination transport address is not present in the 5556 "destination transport address list" returned earlier in an associate 5557 command or communication up notification, an error is returned. 5559 Mandatory attributes: 5560 association id: local handle to the SCTP association. 5562 destination transport address: specified as one of the transport 5563 addresses of the peer endpoint, which is used as the primary 5564 address for sending packets. This overrides the current 5565 primary address information maintained by the local SCTP 5566 endpoint. 5568 Optional attributes: 5569 source transport address: optionally, some implementations can 5570 allow you to set the default source address placed in all 5571 outgoing IP datagrams. 5573 11.1.7. Receive 5574 RECEIVE(association id, buffer address, buffer size [,stream id]) 5575 -> byte count [,transport address] [,stream id] 5576 [,stream sequence number] [,partial flag] [,payload protocol-id] 5578 This primitive reads the first user message in the SCTP in-queue into 5579 the buffer specified by ULP, if there is one available. The size of 5580 the message read, in bytes, will be returned. It might, depending on 5581 the specific implementation, also return other information such as 5582 the sender's address, the stream id on which it is received, whether 5583 there are more messages available for retrieval, etc. For ordered 5584 messages, their Stream Sequence Number might also be returned. 5586 Depending upon the implementation, if this primitive is invoked when 5587 no message is available the implementation returns an indication of 5588 this condition or blocks the invoking process until data does become 5589 available. 5591 Mandatory attributes: 5592 association id: local handle to the SCTP association 5594 buffer address: the memory location indicated by the ULP to store 5595 the received message. 5597 buffer size: the maximum size of data to be received, in bytes. 5599 Optional attributes: 5600 stream id: to indicate which stream to receive the data on. 5602 stream sequence number: the Stream Sequence Number assigned by 5603 the sending SCTP peer. 5605 partial flag: if this returned flag is set to 1, then this 5606 primitive contains a partial delivery of the whole message. 5607 When this flag is set, the stream id and stream sequence number 5608 accompanies this primitive. When this flag is set to 0, it 5609 indicates that no more deliveries will be received for this 5610 stream sequence number. 5612 payload protocol-id: a 32-bit unsigned integer that is received 5613 from the peer indicating the type of payload protocol of the 5614 received data. Note that the upper layer is responsible for 5615 the host to network byte order conversion of this field, which 5616 is passed by SCTP as 4 bytes of opaque data. 5618 11.1.8. Status 5620 STATUS(association id) -> status data 5621 This primitive returns a data block containing the following 5622 information: 5624 * association connection state, 5626 * destination transport address list, 5628 * destination transport address reachability states, 5630 * current receiver window size, 5632 * current congestion window sizes, 5634 * number of unacknowledged DATA chunks, 5636 * number of DATA chunks pending receipt, 5638 * primary path, 5640 * most recent SRTT on primary path, 5642 * RTO on primary path, 5644 * SRTT and RTO on other destination addresses, etc. 5646 Mandatory attributes: 5647 association id: local handle to the SCTP association. 5649 Optional attributes: 5650 None. 5652 11.1.9. Change Heartbeat 5654 CHANGE HEARTBEAT(association id, destination transport address, 5655 new state [,interval]) -> result 5657 Instructs the local endpoint to enable or disable heartbeat on the 5658 specified destination transport address. 5660 The result of attempting this operation is returned. 5662 Note: Even when enabled, heartbeat will not take place if the 5663 destination transport address is not idle. 5665 Mandatory attributes: 5666 association id: local handle to the SCTP association. 5668 destination transport address: specified as one of the transport 5669 addresses of the peer endpoint. 5671 new state: the new state of heartbeat for this destination 5672 transport address (either enabled or disabled). 5674 Optional attributes: 5675 interval: if present, indicates the frequency of the heartbeat if 5676 this is to enable heartbeat on a destination transport address. 5677 This value is added to the RTO of the destination transport 5678 address. This value, if present, affects all destinations. 5680 11.1.10. Request Heartbeat 5682 REQUESTHEARTBEAT(association id, destination transport address) 5683 -> result 5685 Instructs the local endpoint to perform a heartbeat on the specified 5686 destination transport address of the given association. The returned 5687 result indicates whether the transmission of the HEARTBEAT chunk 5688 chunk to the destination address is successful. 5690 Mandatory attributes: 5691 association id: local handle to the SCTP association. 5693 destination transport address: the transport address of the 5694 association on which a heartbeat is issued. 5696 Optional attributes: 5697 None. 5699 11.1.11. Get SRTT Report 5701 GETSRTTREPORT(association id, destination transport address) 5702 -> srtt result 5704 Instructs the local SCTP to report the current SRTT measurement on 5705 the specified destination transport address of the given association. 5706 The returned result can be an integer containing the most recent SRTT 5707 in milliseconds. 5709 Mandatory attributes: 5710 association id: local handle to the SCTP association. 5712 destination transport address: the transport address of the 5713 association on which the SRTT measurement is to be reported. 5715 Optional attributes: 5716 None. 5718 11.1.12. Set Failure Threshold 5720 SETFAILURETHRESHOLD(association id, destination transport address, 5721 failure threshold) -> result 5723 This primitive allows the local SCTP to customize the reachability 5724 failure detection threshold 'Path.Max.Retrans' for the specified 5725 destination address. Note that this can also be done using the 5726 SETPROTOCOLPARAMETERS primitive (Section 11.1.13). 5728 Mandatory attributes: 5729 association id: local handle to the SCTP association. 5731 destination transport address: the transport address of the 5732 association on which the failure detection threshold is to be 5733 set. 5735 failure threshold: the new value of 'Path.Max.Retrans' for the 5736 destination address. 5738 Optional attributes: 5739 None. 5741 11.1.13. Set Protocol Parameters 5743 SETPROTOCOLPARAMETERS(association id, 5744 [destination transport address,] protocol parameter list) 5745 -> result 5747 This primitive allows the local SCTP to customize the protocol 5748 parameters. 5750 Mandatory attributes: 5751 association id: local handle to the SCTP association. 5753 protocol parameter list: the specific names and values of the 5754 protocol parameters (e.g., 'Association.Max.Retrans' (see 5755 Section 16), or other parameters like the DSCP) that the SCTP 5756 user wishes to customize. 5758 Optional attributes: 5759 destination transport address: some of the protocol parameters 5760 might be set on a per destination transport address basis. 5762 11.1.14. Receive Unsent Message 5763 RECEIVE_UNSENT(data retrieval id, buffer address, buffer size 5764 [,stream id] [, stream sequence number] [,partial flag] 5765 [,payload protocol-id]) 5767 This primitive reads a user message, which has never been sent, into 5768 the buffer specified by ULP. 5770 Mandatory attributes: 5771 data retrieval id: the identification passed to the ULP in the 5772 failure notification. 5774 buffer address: the memory location indicated by the ULP to store 5775 the received message. 5777 buffer size: the maximum size of data to be received, in bytes. 5779 Optional attributes: 5780 stream id: this is a return value that is set to indicate which 5781 stream the data was sent to. 5783 stream sequence number: this value is returned indicating the 5784 Stream Sequence Number that was associated with the message. 5786 partial flag: if this returned flag is set to 1, then this 5787 message is a partial delivery of the whole message. When this 5788 flag is set, the stream id and stream sequence number 5789 accompanies this primitive. When this flag is set to 0, it 5790 indicates that no more deliveries will be received for this 5791 stream sequence number. 5793 payload protocol-id: The 32 bit unsigned integer that was set to 5794 be sent to the peer indicating the type of payload protocol of 5795 the received data. 5797 11.1.15. Receive Unacknowledged Message 5799 RECEIVE_UNACKED(data retrieval id, buffer address, buffer size, 5800 [,stream id] [,stream sequence number] [,partial flag] 5801 [,payload protocol-id]) 5803 This primitive reads a user message, which has been sent and has not 5804 been acknowledged by the peer, into the buffer specified by ULP. 5806 Mandatory attributes: 5807 data retrieval id: the identification passed to the ULP in the 5808 failure notification. 5810 buffer address: the memory location indicated by the ULP to store 5811 the received message. 5813 buffer size: the maximum size of data to be received, in bytes. 5815 Optional attributes: 5816 stream id: this is a return value that is set to indicate which 5817 stream the data was sent to. 5819 stream sequence number: this value is returned indicating the 5820 Stream Sequence Number that was associated with the message. 5822 partial flag: if this returned flag is set to 1, then this 5823 message is a partial delivery of the whole message. When this 5824 flag is set, the stream id and stream sequence number 5825 accompanies this primitive. When this flag is set to 0, it 5826 indicates that no more deliveries will be received for this 5827 stream sequence number. 5829 payload protocol-id: the 32-bit unsigned integer that was sent to 5830 the peer indicating the type of payload protocol of the 5831 received data. 5833 11.1.16. Destroy SCTP Instance 5835 DESTROY(local SCTP instance name) 5837 Mandatory attributes: 5838 local SCTP instance name: this is the value that was passed to 5839 the application in the initialize primitive and it indicates 5840 which SCTP instance is to be destroyed. 5842 Optional attributes: 5843 None. 5845 11.2. SCTP-to-ULP 5847 It is assumed that the operating system or application environment 5848 provides a means for the SCTP to asynchronously signal the ULP 5849 process. When SCTP does signal a ULP process, certain information is 5850 passed to the ULP. 5852 Implementation Note: In some cases, this might be done through a 5853 separate socket or error channel. 5855 11.2.1. DATA ARRIVE Notification 5857 SCTP invokes this notification on the ULP when a user message is 5858 successfully received and ready for retrieval. 5860 The following might optionally be passed with the notification: 5862 association id: local handle to the SCTP association. 5864 stream id: to indicate which stream the data is received on. 5866 11.2.2. SEND FAILURE Notification 5868 If a message cannot be delivered, SCTP invokes this notification on 5869 the ULP. 5871 The following might optionally be passed with the notification: 5873 association id: local handle to the SCTP association. 5875 data retrieval id: an identification used to retrieve unsent and 5876 unacknowledged data. 5878 mode: Indicate whether no part of the message never has been sent or 5879 if at least part of it has been sent but it is not completely 5880 acknowledged. 5882 cause code: indicating the reason of the failure, e.g., size too 5883 large, message life time expiration, etc. 5885 context: optional information associated with this message (see 5886 Section 11.1.5). 5888 11.2.3. NETWORK STATUS CHANGE Notification 5890 When a destination transport address is marked inactive (e.g., when 5891 SCTP detects a failure) or marked active (e.g., when SCTP detects a 5892 recovery), SCTP invokes this notification on the ULP. 5894 The following is passed with the notification: 5896 association id: local handle to the SCTP association. 5898 destination transport address: this indicates the destination 5899 transport address of the peer endpoint affected by the change. 5901 new-status: this indicates the new status. 5903 11.2.4. COMMUNICATION UP Notification 5905 This notification is used when SCTP becomes ready to send or receive 5906 user messages, or when a lost communication to an endpoint is 5907 restored. 5909 Implementation Note: If the ASSOCIATE primitive is implemented as a 5910 blocking function call, the association parameters are returned as a 5911 result of the ASSOCIATE primitive itself. In that case, 5912 COMMUNICATION UP notification is optional at the association 5913 initiator's side. 5915 The following is passed with the notification: 5917 association id: local handle to the SCTP association. 5919 status: This indicates what type of event has occurred. 5921 destination transport address list: the complete set of transport 5922 addresses of the peer. 5924 outbound stream count: the maximum number of streams allowed to be 5925 used in this association by the ULP. 5927 inbound stream count: the number of streams the peer endpoint has 5928 requested with this association (this might not be the same number 5929 as 'outbound stream count'). 5931 11.2.5. COMMUNICATION LOST Notification 5933 When SCTP loses communication to an endpoint completely (e.g., via 5934 Heartbeats) or detects that the endpoint has performed an abort 5935 operation, it invokes this notification on the ULP. 5937 The following is passed with the notification: 5939 association id: local handle to the SCTP association. 5941 status: this indicates what type of event has occurred; the status 5942 might indicate that a failure OR a normal termination event 5943 occurred in response to a shutdown or abort request. 5945 The following might be passed with the notification: 5947 last-acked: the TSN last acked by that peer endpoint. 5949 last-sent: the TSN last sent to that peer endpoint. 5951 Upper Layer Abort Reason: the abort reason specified in case of a 5952 user-initiated abort. 5954 11.2.6. COMMUNICATION ERROR Notification 5956 When SCTP receives an ERROR chunk from its peer and decides to notify 5957 its ULP, it can invoke this notification on the ULP. 5959 The following can be passed with the notification: 5961 association id: local handle to the SCTP association. 5963 error info: this indicates the type of error and optionally some 5964 additional information received through the ERROR chunk. 5966 11.2.7. RESTART Notification 5968 When SCTP detects that the peer has restarted, it might send this 5969 notification to its ULP. 5971 The following can be passed with the notification: 5973 association id: local handle to the SCTP association. 5975 11.2.8. SHUTDOWN COMPLETE Notification 5977 When SCTP completes the shutdown procedures (Section 9.2), this 5978 notification is passed to the upper layer. 5980 The following can be passed with the notification: 5982 association id: local handle to the SCTP association. 5984 12. Security Considerations 5986 12.1. Security Objectives 5988 As a common transport protocol designed to reliably carry time- 5989 sensitive user messages, such as billing or signaling messages for 5990 telephony services, between two networked endpoints, SCTP has the 5991 following security objectives. 5993 * availability of reliable and timely data transport services 5995 * integrity of the user-to-user information carried by SCTP 5997 12.2. SCTP Responses to Potential Threats 5999 SCTP could potentially be used in a wide variety of risk situations. 6000 It is important for operators of systems running SCTP to analyze 6001 their particular situations and decide on the appropriate counter- 6002 measures. 6004 Operators of systems running SCTP might consult [RFC2196] for 6005 guidance in securing their site. 6007 12.2.1. Countering Insider Attacks 6009 The principles of [RFC2196] might be applied to minimize the risk of 6010 theft of information or sabotage by insiders. Such procedures 6011 include publication of security policies, control of access at the 6012 physical, software, and network levels, and separation of services. 6014 12.2.2. Protecting against Data Corruption in the Network 6016 Where the risk of undetected errors in datagrams delivered by the 6017 lower-layer transport services is considered to be too great, 6018 additional integrity protection is required. If this additional 6019 protection were provided in the application layer, the SCTP header 6020 would remain vulnerable to deliberate integrity attacks. While the 6021 existing SCTP mechanisms for detection of packet replays are 6022 considered sufficient for normal operation, stronger protections are 6023 needed to protect SCTP when the operating environment contains 6024 significant risk of deliberate attacks from a sophisticated 6025 adversary. 6027 The SCTP Authentication extension SCTP-AUTH [RFC4895] MAY be used 6028 when the threat environment requires stronger integrity protections, 6029 but does not require confidentiality. 6031 12.2.3. Protecting Confidentiality 6033 In most cases, the risk of breach of confidentiality applies to the 6034 signaling data payload, not to the SCTP or lower-layer protocol 6035 overheads. If that is true, encryption of the SCTP user data only 6036 might be considered. As with the supplementary checksum service, 6037 user data encryption MAY be performed by the SCTP user application. 6038 [RFC6083] MAY be used for this. Alternately, the user application 6039 MAY use an implementation-specific API to request that the IP 6040 Encapsulating Security Payload (ESP) [RFC4303] be used to provide 6041 confidentiality and integrity. 6043 Particularly for mobile users, the requirement for confidentiality 6044 might include the masking of IP addresses and ports. In this case, 6045 ESP SHOULD be used instead of application-level confidentiality. If 6046 ESP is used to protect confidentiality of SCTP traffic, an ESP 6047 cryptographic transform that includes cryptographic integrity 6048 protection MUST be used, because if there is a confidentiality threat 6049 there will also be a strong integrity threat. 6051 Regardless of where confidentiality is provided, the Internet Key 6052 Exchange Protocol version 2 (IKEv2) [RFC7296] SHOULD be used for key 6053 management of ESP. 6055 Operators might consult [RFC4301] for more information on the 6056 security services available at and immediately above the Internet 6057 Protocol layer. 6059 12.2.4. Protecting against Blind Denial-of-Service Attacks 6061 A blind attack is one where the attacker is unable to intercept or 6062 otherwise see the content of data flows passing to and from the 6063 target SCTP node. Blind denial-of-service attacks can take the form 6064 of flooding, masquerade, or improper monopolization of services. 6066 12.2.4.1. Flooding 6068 The objective of flooding is to cause loss of service and incorrect 6069 behavior at target systems through resource exhaustion, interference 6070 with legitimate transactions, and exploitation of buffer-related 6071 software bugs. Flooding can be directed either at the SCTP node or 6072 at resources in the intervening IP Access Links or the Internet. 6073 Where the latter entities are the target, flooding will manifest 6074 itself as loss of network services, including potentially the breach 6075 of any firewalls in place. 6077 In general, protection against flooding begins at the equipment 6078 design level, where it includes measures such as: 6080 * avoiding commitment of limited resources before determining that 6081 the request for service is legitimate. 6083 * giving priority to completion of processing in progress over the 6084 acceptance of new work. 6086 * identification and removal of duplicate or stale queued requests 6087 for service. 6089 * not responding to unexpected packets sent to non-unicast 6090 addresses. 6092 Network equipment is expected to be capable of generating an alarm 6093 and log if a suspicious increase in traffic occurs. The log provides 6094 information such as the identity of the incoming link and source 6095 address(es) used, which will help the network or SCTP system operator 6096 to take protective measures. Procedures are expected to be in place 6097 for the operator to act on such alarms if a clear pattern of abuse 6098 emerges. 6100 The design of SCTP is resistant to flooding attacks, particularly in 6101 its use of a four-way startup handshake, its use of a cookie to defer 6102 commitment of resources at the responding SCTP node until the 6103 handshake is completed, and its use of a Verification Tag to prevent 6104 insertion of extraneous packets into the flow of an established 6105 association. 6107 ESP might be useful in reducing the risk of certain kinds of denial- 6108 of-service attacks. 6110 Support for the Host Name Address parameter has been removed from the 6111 protocol. Endpoints receiving INIT or INIT ACK chunks containing the 6112 Host Name Address parameter MUST send an ABORT chunk in response and 6113 MAY include an "Unresolvable Address" error cause. 6115 12.2.4.2. Blind Masquerade 6117 Masquerade can be used to deny service in several ways: 6119 * by tying up resources at the target SCTP node to which the 6120 impersonated node has limited access. For example, the target 6121 node can by policy permit a maximum of one SCTP association with 6122 the impersonated SCTP node. The masquerading attacker can attempt 6123 to establish an association purporting to come from the 6124 impersonated node so that the latter cannot do so when it requires 6125 it. 6127 * by deliberately allowing the impersonation to be detected, thereby 6128 provoking counter-measures that cause the impersonated node to be 6129 locked out of the target SCTP node. 6131 * by interfering with an established association by inserting 6132 extraneous content such as a SHUTDOWN chunk. 6134 SCTP reduces the risk of blind masquerade attacks through IP spoofing 6135 by use of the four-way startup handshake. Because the initial 6136 exchange is memory-less, no lockout mechanism is triggered by blind 6137 masquerade attacks. In addition, the packet containing the INIT ACK 6138 chunk with the State Cookie is transmitted back to the IP address 6139 from which it received the packet containing the INIT chunk. Thus, 6140 the attacker would not receive the INIT ACK chunk containing the 6141 State Cookie. SCTP protects against insertion of extraneous packets 6142 into the flow of an established association by use of the 6143 Verification Tag. 6145 Logging of received INIT chunks and abnormalities such as unexpected 6146 INIT ACK chunks might be considered as a way to detect patterns of 6147 hostile activity. However, the potential usefulness of such logging 6148 has to be weighed against the increased SCTP startup processing it 6149 implies, rendering the SCTP node more vulnerable to flooding attacks. 6150 Logging is pointless without the establishment of operating 6151 procedures to review and analyze the logs on a routine basis. 6153 12.2.4.3. Improper Monopolization of Services 6155 Attacks under this heading are performed openly and legitimately by 6156 the attacker. They are directed against fellow users of the target 6157 SCTP node or of the shared resources between the attacker and the 6158 target node. Possible attacks include the opening of a large number 6159 of associations between the attacker's node and the target, or 6160 transfer of large volumes of information within a legitimately 6161 established association. 6163 Policy limits are expected to be placed on the number of associations 6164 per adjoining SCTP node. SCTP user applications are expected to be 6165 capable of detecting large volumes of illegitimate or "no-op" 6166 messages within a given association and either logging or terminating 6167 the association as a result, based on local policy. 6169 12.3. SCTP Interactions with Firewalls 6171 It is helpful for some firewalls if they can inspect just the first 6172 fragment of a fragmented SCTP packet and unambiguously determine 6173 whether it corresponds to an INIT chunk (for further information, 6174 please refer to [RFC1858]). Accordingly, we stress the requirements, 6175 as stated in Section 3.1, that (1) an INIT chunk MUST NOT be bundled 6176 with any other chunk in a packet and (2) a packet containing an INIT 6177 chunk MUST have a zero Verification Tag. The receiver of an INIT 6178 chunk MUST silently discard the INIT chunk and all further chunks if 6179 the INIT chunk is bundled with other chunks or the packet has a non- 6180 zero Verification Tag. 6182 12.4. Protection of Non-SCTP-Capable Hosts 6184 To provide a non-SCTP-capable host with the same level of protection 6185 against attacks as for SCTP-capable ones, all SCTP implementations 6186 MUST implement the ICMP handling described in Section 10. 6188 When an SCTP implementation receives a packet containing multiple 6189 control or DATA chunks and the processing of the packet would result 6190 in sending multiple chunks in response, the sender of the response 6191 chunk(s) MUST NOT send more than one packet containing chunks other 6192 than DATA chunks. This requirement protects the network for 6193 triggering a packet burst in response to a single packet. If 6194 bundling is supported, multiple response chunks that fit into a 6195 single packet MAY be bundled together into one single response 6196 packet. If bundling is not supported, then the sender MUST NOT send 6197 more than one response chunk and MUST discard all other responses. 6198 Note that this rule does not apply to a SACK chunk, since a SACK 6199 chunk is, in itself, a response to DATA chunks and a SACK chunk does 6200 not require a response of more DATA chunks. 6202 An SCTP implementation MUST abort the association if it receives a 6203 SACK chunk acknowledging a TSN that has not been sent. 6205 An SCTP implementation that receives an INIT chunk that would require 6206 a large packet in response, due to the inclusion of multiple 6207 "Unrecognized Parameter" parameters, MAY (at its discretion) elect to 6208 omit some or all of the "Unrecognized Parameter" parameters to reduce 6209 the size of the INIT ACK chunk. Due to a combination of the size of 6210 the State Cookie parameter and the number of addresses a receiver of 6211 an INIT chunk indicates to a peer, it is always possible that the 6212 INIT ACK chunk will be larger than the original INIT chunk. An SCTP 6213 implementation SHOULD attempt to make the INIT ACK chunk as small as 6214 possible to reduce the possibility of byte amplification attacks. 6216 13. Network Management Considerations 6218 The MIB module for SCTP defined in [RFC3873] applies for the version 6219 of the protocol specified in this document. 6221 14. Recommended Transmission Control Block (TCB) Parameters 6223 This section details a set of parameters that are expected to be 6224 contained within the TCB for an implementation. This section is for 6225 illustrative purposes and is not considered to be requirements on an 6226 implementation or as an exhaustive list of all parameters inside an 6227 SCTP TCB. Each implementation might need its own additional 6228 parameters for optimization. 6230 14.1. Parameters Necessary for the SCTP Instance 6232 Associations: A list of current associations and mappings to the 6233 data consumers for each association. This might be in the form of 6234 a hash table or other implementation-dependent structure. The 6235 data consumers might be process identification information such as 6236 file descriptors, named pipe pointer, or table pointers dependent 6237 on how SCTP is implemented. 6239 Secret Key: A secret key used by this endpoint to compute the MAC. 6240 This SHOULD be a cryptographic quality random number with a 6241 sufficient length. Discussion in [RFC4086] can be helpful in 6242 selection of the key. 6244 Address List: The list of IP addresses that this instance has bound. 6245 This information is passed to one's peer(s) in INIT and INIT ACK 6246 chunks. 6248 SCTP Port: The local SCTP port number to which the endpoint is 6249 bound. 6251 14.2. Parameters Necessary per Association (i.e., the TCB) 6253 Peer Verification Tag: Tag value to be sent in every packet and is 6254 received in the INIT or INIT ACK chunk. 6256 My Verification Tag: Tag expected in every inbound packet and sent 6257 in the INIT or INIT ACK chunk. 6259 State: COOKIE-WAIT, COOKIE-ECHOED, ESTABLISHED, SHUTDOWN-PENDING, 6260 SHUTDOWN-SENT, SHUTDOWN-RECEIVED, SHUTDOWN-ACK-SENT. 6262 Note: No "CLOSED" state is illustrated since if a association is 6263 "CLOSED" its TCB SHOULD be removed. 6265 Peer Transport Address List: A list of SCTP transport addresses to 6266 which the peer is bound. This information is derived from the 6267 INIT or INIT ACK chunk and is used to associate an inbound packet 6268 with a given association. Normally, this information is hashed or 6269 keyed for quick lookup and access of the TCB. 6271 Primary Path: This is the current primary destination transport 6272 address of the peer endpoint. It might also specify a source 6273 transport address on this endpoint. 6275 Overall Error Count: The overall association error count. 6277 Overall Error Threshold: The threshold for this association that if 6278 the Overall Error Count reaches will cause this association to be 6279 torn down. 6281 Peer Rwnd: Current calculated value of the peer's rwnd. 6283 Next TSN: The next TSN number to be assigned to a new DATA chunk. 6284 This is sent in the INIT or INIT ACK chunk to the peer and 6285 incremented each time a DATA chunk is assigned a TSN (normally 6286 just prior to transmit or during fragmentation). 6288 Last Rcvd TSN: This is the last TSN received in sequence. This 6289 value is set initially by taking the peer's initial TSN, received 6290 in the INIT or INIT ACK chunk, and subtracting one from it. 6292 Mapping Array: An array of bits or bytes indicating which out-of- 6293 order TSNs have been received (relative to the Last Rcvd TSN). If 6294 no gaps exist, i.e., no out-of-order packets have been received, 6295 this array will be set to all zero. This structure might be in 6296 the form of a circular buffer or bit array. 6298 Ack State: This flag indicates if the next received packet is to be 6299 responded to with a SACK chunk. This is initialized to 0. When a 6300 packet is received it is incremented. If this value reaches 2 or 6301 more, a SACK chunk is sent and the value is reset to 0. Note: 6302 This is used only when no DATA chunks are received out of order. 6303 When DATA chunks are out of order, SACK chunks are not delayed 6304 (see Section 6). 6306 Inbound Streams: An array of structures to track the inbound 6307 streams, normally including the next sequence number expected and 6308 possibly the stream number. 6310 Outbound Streams: An array of structures to track the outbound 6311 streams, normally including the next sequence number to be sent on 6312 the stream. 6314 Reasm Queue: A reassembly queue. 6316 Receive Buffer: A buffer to store received user data which has not 6317 been delivered to the upper layer. 6319 Local Transport Address List: The list of local IP addresses bound 6320 in to this association. 6322 Association Maximum DATA Chunk Size: The smallest Path Maximum DATA 6323 Chunk Size of all destination addresses. 6325 14.3. Per Transport Address Data 6327 For each destination transport address in the peer's address list 6328 derived from the INIT or INIT ACK chunk, a number of data elements 6329 need to be maintained including: 6331 Error Count: The current error count for this destination. 6333 Error Threshold: Current error threshold for this destination, i.e., 6334 what value marks the destination down if error count reaches this 6335 value. 6337 cwnd: The current congestion window. 6339 ssthresh: The current ssthresh value. 6341 RTO: The current retransmission timeout value. 6343 SRTT: The current smoothed round-trip time. 6345 RTTVAR: The current RTT variation. 6347 partial bytes acked: The tracking method for increase of cwnd when 6348 in congestion avoidance mode (see Section 7.2.2). 6350 state: The current state of this destination, i.e., DOWN, UP, ALLOW- 6351 HEARTBEAT, NO-HEARTBEAT, etc. 6353 PMTU: The current known PMTU. 6355 PMDCS: The current known PMDCS. 6357 Per Destination Timer: A timer used by each destination. 6359 RTO-Pending: A flag used to track if one of the DATA chunks sent to 6360 this address is currently being used to compute an RTT. If this 6361 flag is 0, the next DATA chunk sent to this destination is 6362 expected to be used to compute an RTT and this flag is expected to 6363 be set. Every time the RTT calculation completes (i.e., the DATA 6364 chunk is acknowledged), clear this flag. 6366 last-time: The time to which this destination was last sent. This 6367 can used be to determine if the sending of a HEARTBEAT chunk is 6368 needed. 6370 14.4. General Parameters Needed 6372 Out Queue: A queue of outbound DATA chunks. 6374 In Queue: A queue of inbound DATA chunks. 6376 15. IANA Considerations 6378 This document defines five registries that IANA maintains: 6380 * through definition of additional chunk types, 6382 * through definition of additional chunk flags, 6384 * through definition of additional parameter types, 6386 * through definition of additional cause codes within ERROR chunks, 6387 or 6389 * through definition of additional payload protocol identifiers. 6391 IANA is requested to perform the following updates for the above five 6392 registries: 6394 * In the Chunk Types Registry replace in the Reference section the 6395 reference to [RFC4960] and [RFC6096] by a reference to this 6396 document. 6398 Replace in the Notes section the reference to Section 3.2 of 6399 [RFC6096] by a reference to Section 15.2 of this document. 6401 Finally replace each reference to [RFC4960] by a reference to this 6402 document for the following chunk types: 6404 - Payload Data (DATA) 6406 - Initiation (INIT) 6408 - Initiation Acknowledgement (INIT ACK) 6410 - Selective Acknowledgement (SACK) 6412 - Heartbeat Request (HEARTBEAT) 6414 - Heartbeat Acknowledgement (HEARTBEAT ACK) 6416 - Abort (ABORT) 6417 - Shutdown (SHUTDOWN) 6419 - Shutdown Acknowledgement (SHUTDOWN ACK) 6421 - Operation Error (ERROR) 6423 - State Cookie (COOKIE ECHO) 6425 - Cookie Acknowledgement (COOKIE ACK) 6427 - Reserved for Explicit Congestion Notification Echo (ECNE) 6429 - Reserved for Congestion Window Reduced (CWR) 6431 - Shutdown Complete (SHUTDOWN COMPLETE) 6433 - Reserved for IETF-defined Chunk Extensions 6435 * In the Chunk Parameter Types Registry replace in the Reference 6436 section the reference to [RFC4960] by a reference to this 6437 document. 6439 Replace each reference to [RFC4960] by a reference to this 6440 document for the following chunk parameter types: 6442 - Heartbeat Info 6444 - IPv4 Address 6446 - IPv6 Address 6448 - State Cookie 6450 - Unrecognized Parameters 6452 - Cookie Preservative 6454 - Host Name Address 6456 - Supported Address Types 6458 Add a reference to this document for the following chunk parameter 6459 type: 6461 - Reserved for ECN Capable (0x8000) 6463 * In the Chunk Flags Registry replace in the Reference section the 6464 reference to [RFC6096] by a reference to this document. 6466 Replace each reference to [RFC4960] by a reference to this 6467 document for the following DATA chunk flags: 6469 - E bit 6471 - B bit 6473 - U bit 6475 Replace each reference to [RFC4960] by a reference to this 6476 document for the following ABORT chunk flags: 6478 - T bit 6480 Replace each reference to [RFC4960] by a reference to this 6481 document for the following SHUTDOWN COMPLETE chunk flags: 6483 - T bit 6485 * In the Error Cause Codes Registry replace in the Reference section 6486 the reference to [RFC6096] by a reference to this document. 6488 Replace each reference to [RFC4960] by a reference to this 6489 document for the following cause codes: 6491 - Invalid Stream Identifier 6493 - Missing Mandatory Parameter 6495 - Stale Cookie Error 6497 - Out of Resource 6499 - Unresolvable Address 6501 - Unrecognized Chunk Type 6503 - Invalid Mandatory Parameter 6505 - Unrecognized Parameters 6507 - No User Data 6509 - Cookie Received While Shutting Down 6511 - Restart of an Association with New Addressess 6512 Replace each reference to [RFC4460] by a reference to this 6513 document for the following cause codes: 6515 - User Initiated Abort 6517 - Protocol Violation 6519 * In the SCTP Payload Protocol Identifiers Registry replace in the 6520 Reference section the reference to [RFC6096] by a reference to 6521 this document. 6523 Replace each reference to [RFC4960] by a reference to this 6524 document for the following SCTP payload protocol identifiers: 6526 - Reserved by SCTP 6528 SCTP requires that the IANA Port Numbers registry be opened for SCTP 6529 port registrations, Section 15.6 describes how. An IESG-appointed 6530 Expert Reviewer supports IANA in evaluating SCTP port allocation 6531 requests. 6533 IANA is requested to perform the following update for the Port Number 6534 registry. Replace each reference to [RFC4960] by a reference to this 6535 document for the following SCTP port numbers: 6537 * 9 (discard) 6539 * 20 (ftp-data) 6541 * 21 (ftp) 6543 * 22 (ssh) 6545 * 80 (http) 6547 * 179 (bgp) 6549 * 443 (https) 6551 Furthermore, IANA is requested to replace in the HTTP Digest 6552 Algorithm Values registry the reference to Appendix B of [RFC4960] to 6553 Appendix A of this document. 6555 IANA is also requested to replace in the ONC RPC Netids registry, 6556 each of the reference to [RFC4960] by a reference to this document 6557 for the following netids: 6559 * sctp 6560 * sctp6 6562 IANA is finally requested to replace in the IPFIX Information 6563 Elements registry, each of the reference to [RFC4960] by a reference 6564 to this document for the following elements with the name: 6566 * sourceTransportPort 6568 * destinationTransportPort 6570 * collectorTransportPort 6572 * exporterTransportPort 6574 * postNAPTSourceTransportPort 6576 * postNAPTDestinationTransportPort 6578 15.1. IETF-Defined Chunk Extension 6580 The assignment of new chunk type codes is done through an IETF Review 6581 action, as defined in [RFC8126]. Documentation for a new chunk MUST 6582 contain the following information: 6584 a) A long and short name for the new chunk type. 6586 b) A detailed description of the structure of the chunk, which MUST 6587 conform to the basic structure defined in Section 3.2. 6589 c) A detailed definition and description of intended use of each 6590 field within the chunk, including the chunk flags if any. 6591 Defined chunk flags will be used as initial entries in the chunk 6592 flags table for the new chunk type. 6594 d) A detailed procedural description of the use of the new chunk 6595 type within the operation of the protocol. 6597 The last chunk type (255) is reserved for future extension if 6598 necessary. 6600 For each new chunk type, IANA creates a registration table for the 6601 chunk flags of that type. The procedure for registering particular 6602 chunk flags is described in Section 15.2. 6604 15.2. IETF Chunk Flags Registration 6606 The assignment of new chunk flags is done through an RFC Required 6607 action, as defined in [RFC8126]. Documentation for the chunk flags 6608 MUST contain the following information: 6610 a) A name for the new chunk flag. 6612 b) A detailed procedural description of the use of the new chunk 6613 flag within the operation of the protocol. It MUST be considered 6614 that implementations not supporting the flag will send 0 on 6615 transmit and just ignore it on receipt. 6617 IANA selects a chunk flags value. This MUST be one of 0x01, 0x02, 6618 0x04, 0x08, 0x10, 0x20, 0x40, or 0x80, which MUST be unique within 6619 the chunk flag values for the specific chunk type. 6621 15.3. IETF-Defined Chunk Parameter Extension 6623 The assignment of new chunk parameter type codes is done through an 6624 IETF Review action as defined in [RFC8126]. Documentation of the 6625 chunk parameter MUST contain the following information: 6627 a) Name of the parameter type. 6629 b) Detailed description of the structure of the parameter field. 6630 This structure MUST conform to the general Type-Length-Value 6631 format described in Section 3.2.1. 6633 c) Detailed definition of each component of the parameter value. 6635 d) Detailed description of the intended use of this parameter type, 6636 and an indication of whether and under what circumstances 6637 multiple instances of this parameter type can be found within the 6638 same chunk. 6640 e) Each parameter type MUST be unique across all chunks. 6642 15.4. IETF-Defined Additional Error Causes 6644 Additional cause codes can be allocated in the range 11 to 65535 6645 through a Specification Required action as defined in [RFC8126]. 6646 Provided documentation MUST include the following information: 6648 a) Name of the error condition. 6650 b) Detailed description of the conditions under which an SCTP 6651 endpoint issues an ERROR (or ABORT) chunk with this cause code. 6653 c) Expected action by the SCTP endpoint that receives an ERROR (or 6654 ABORT) chunk containing this cause code. 6656 d) Detailed description of the structure and content of data fields 6657 that accompany this cause code. 6659 The initial word (32 bits) of a cause code parameter MUST conform to 6660 the format shown in Section 3.3.10, i.e.: 6662 * first 2 bytes contain the cause code value 6664 * last 2 bytes contain the length of the cause parameter. 6666 15.5. Payload Protocol Identifiers 6668 The assignment of payload protocol identifier is done using the First 6669 Come First Served policy as defined in [RFC8126]. 6671 Except for value 0, which is reserved to indicate an unspecified 6672 payload protocol identifier in a DATA chunk, an SCTP implementation 6673 will not be responsible for standardizing or verifying any payload 6674 protocol identifiers; An SCTP implementation simply receives the 6675 identifier from the upper layer and carries it with the corresponding 6676 payload data. 6678 The upper layer, i.e., the SCTP user, SHOULD standardize any specific 6679 protocol identifier with IANA if it is so desired. The use of any 6680 specific payload protocol identifier is out of the scope of this 6681 specification. 6683 15.6. Port Numbers Registry 6685 SCTP services can use contact port numbers to provide service to 6686 unknown callers, as in TCP and UDP. An IESG-appointed expert 6687 reviewer supports IANA in evaluating SCTP port allocation requests, 6688 according to the procedure defined in [RFC8126]. The details of this 6689 process are defined in [RFC6335]. 6691 16. Suggested SCTP Protocol Parameter Values 6693 The following protocol parameters are RECOMMENDED: 6695 RTO.Initial: 1 second 6697 RTO.Min: 1 second 6699 RTO.Max: 60 seconds 6700 Max.Burst: 4 6702 RTO.Alpha: 1/8 6704 RTO.Beta: 1/4 6706 Valid.Cookie.Life: 60 seconds 6708 Association.Max.Retrans: 10 attempts 6710 Path.Max.Retrans: 5 attempts (per destination address) 6712 Max.Init.Retransmits: 8 attempts 6714 HB.interval: 30 seconds 6716 HB.Max.Burst: 1 6718 SACK.Delay: 200 milliseconds 6720 Implementation Note: The SCTP implementation can allow ULP to 6721 customize some of these protocol parameters (see Section 11). 6723 'RTO.Min' SHOULD be set as described above in this section. 6725 17. Acknowledgements 6727 An undertaking represented by this updated document is not a small 6728 feat and represents the summation of the initial co-authors of 6729 [RFC2960]: Q. Xie, K. Morneault, C. Sharp, H. Schwarzbauer, 6730 T. Taylor, I. Rytina, M. Kalla, L. Zhang, and V. Paxson. 6732 Add to that, the comments from everyone who contributed to [RFC2960]: 6733 Mark Allman, R. J. Atkinson, Richard Band, Scott Bradner, Steve 6734 Bellovin, Peter Butler, Ram Dantu, R. Ezhirpavai, Mike Fisk, Sally 6735 Floyd, Atsushi Fukumoto, Matt Holdrege, Henry Houh, Christian 6736 Huitema, Gary Lehecka, Jonathan Lee, David Lehmann, John Loughney, 6737 Daniel Luan, Barry Nagelberg, Thomas Narten, Erik Nordmark, Lyndon 6738 Ong, Shyamal Prasad, Kelvin Porter, Heinz Prantner, Jarno Rajahalme, 6739 Raymond E. Reeves, Renee Revis, Ivan Arias Rodriguez, A. Sankar, Greg 6740 Sidebottom, Brian Wyld, La Monte Yarroll, and many others for their 6741 invaluable comments. 6743 Then, add the co-authors of [RFC4460]: I. Arias-Rodriguez, K. Poon, 6744 and A. Caro. 6746 Then add to these the efforts of all the subsequent seven SCTP 6747 interoperability tests and those who commented on [RFC4460] as shown 6748 in its acknowledgements: Barry Zuckerman, La Monte Yarroll, Qiaobing 6749 Xie, Wang Xiaopeng, Jonathan Wood, Jeff Waskow, Mike Turner, John 6750 Townsend, Sabina Torrente, Cliff Thomas, Yuji Suzuki, Manoj Solanki, 6751 Sverre Slotte, Keyur Shah, Jan Rovins, Ben Robinson, Renee Revis, Ian 6752 Periam, RC Monee, Sanjay Rao, Sujith Radhakrishnan, Heinz Prantner, 6753 Biren Patel, Nathalie Mouellic, Mitch Miers, Bernward Meyknecht, Stan 6754 McClellan, Oliver Mayor, Tomas Orti Martin, Sandeep Mahajan, David 6755 Lehmann, Jonathan Lee, Philippe Langlois, Karl Knutson, Joe Keller, 6756 Gareth Keily, Andreas Jungmaier, Janardhan Iyengar, Mutsuya Irie, 6757 John Hebert, Kausar Hassan, Fred Hasle, Dan Harrison, Jon Grim, 6758 Laurent Glaude, Steven Furniss, Atsushi Fukumoto, Ken Fujita, Steve 6759 Dimig, Thomas Curran, Serkan Cil, Melissa Campbell, Peter Butler, Rob 6760 Brennan, Harsh Bhondwe, Brian Bidulock, Caitlin Bestler, Jon Berger, 6761 Robby Benedyk, Stephen Baucke, Sandeep Balani, and Ronnie Sellar. 6763 A special thanks to Mark Allman, who should actually be a co-author 6764 for his work on the max-burst, but managed to wiggle out due to a 6765 technicality. 6767 Also, we would like to acknowledge Lyndon Ong and Phil Conrad for 6768 their valuable input and many contributions. 6770 Furthermore, you have [RFC4960], and those who have commented upon 6771 that including Alfred Hönes and Ronnie Sellars. 6773 Then, add the co-author of [RFC8540]: Maksim Proshin. 6775 And people who have commented on [RFC8540]: Pontus Andersson, Eric 6776 W. Biederman, Cedric Bonnet, Spencer Dawkins, Gorry Fairhurst, 6777 Benjamin Kaduk, Mirja Kühlewind, Peter Lei, Gyula Marosi, Lionel 6778 Morand, Jeff Morriss, Tom Petch, Kacheong Poon, Julien Pourtet, Irene 6779 Rüngeler, Michael Welzl, and Qiaobing Xie. 6781 And finally the people who have provided comments for this document 6782 including Gorry Fairhurst, Martin Duke, Benjamin Kaduk, Tero Kivinen, 6783 Eliot Lear, Marcelo Ricardo Leitner, David Mandelberg, John Mattsson, 6784 Claudio Porfiri, Maksim Proshin, Ines Robles, Timo Völker, Magnus 6785 Westerlund, and Zhouming. 6787 Our thanks cannot be adequately expressed to all of you who have 6788 participated in the coding, testing, and updating process of this 6789 document. All we can say is, Thank You! 6791 18. Normative References 6793 [ITU.V42.1994] 6794 International Telecommunications Union, "Error-correcting 6795 Procedures for DCEs Using Asynchronous-to-Synchronous 6796 Conversion", ITU-T Recommendation V.42, 1994. 6798 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 6799 Communication Layers", STD 3, RFC 1122, 6800 DOI 10.17487/RFC1122, October 1989, 6801 . 6803 [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - 6804 Application and Support", STD 3, RFC 1123, 6805 DOI 10.17487/RFC1123, October 1989, 6806 . 6808 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 6809 DOI 10.17487/RFC1191, November 1990, 6810 . 6812 [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, 6813 DOI 10.17487/RFC1982, August 1996, 6814 . 6816 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 6817 Requirement Levels", BCP 14, RFC 2119, 6818 DOI 10.17487/RFC2119, March 1997, 6819 . 6821 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 6822 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 6823 2006, . 6825 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 6826 RFC 4303, DOI 10.17487/RFC4303, December 2005, 6827 . 6829 [RFC4895] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla, 6830 "Authenticated Chunks for the Stream Control Transmission 6831 Protocol (SCTP)", RFC 4895, DOI 10.17487/RFC4895, August 6832 2007, . 6834 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 6835 Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, 6836 . 6838 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 6839 Cheshire, "Internet Assigned Numbers Authority (IANA) 6840 Procedures for the Management of the Service Name and 6841 Transport Protocol Port Number Registry", BCP 165, 6842 RFC 6335, DOI 10.17487/RFC6335, August 2011, 6843 . 6845 [RFC6083] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram 6846 Transport Layer Security (DTLS) for Stream Control 6847 Transmission Protocol (SCTP)", RFC 6083, 6848 DOI 10.17487/RFC6083, January 2011, 6849 . 6851 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 6852 Kivinen, "Internet Key Exchange Protocol Version 2 6853 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 6854 2014, . 6856 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 6857 Writing an IANA Considerations Section in RFCs", BCP 26, 6858 RFC 8126, DOI 10.17487/RFC8126, June 2017, 6859 . 6861 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 6862 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 6863 May 2017, . 6865 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 6866 (IPv6) Specification", STD 86, RFC 8200, 6867 DOI 10.17487/RFC8200, July 2017, 6868 . 6870 [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., 6871 "Path MTU Discovery for IP version 6", STD 87, RFC 8201, 6872 DOI 10.17487/RFC8201, July 2017, 6873 . 6875 [RFC8899] Fairhurst, G., Jones, T., Tüxen, M., Rüngeler, I., and T. 6876 Völker, "Packetization Layer Path MTU Discovery for 6877 Datagram Transports", RFC 8899, DOI 10.17487/RFC8899, 6878 September 2020, . 6880 19. Informative References 6882 [FALL96] Fall, K. and S. Floyd, "Simulation-based Comparisons of 6883 Tahoe, Reno, and SACK TCP", SIGCOM 99, V. 26, N. 3, 6884 pp 5-21, July 1996. 6886 [SAVAGE99] Savage, S., Cardwell, N., Wetherall, D., and T. Anderson, 6887 "TCP Congestion Control with a Misbehaving Receiver", ACM 6888 Computer Communications Review 29(5), October 1999. 6890 [ALLMAN99] Allman, M. and V. Paxson, "On Estimating End-to-End 6891 Network Path Properties", SIGCOM 99, 1999. 6893 [WILLIAMS93] 6894 Williams, R., "A PAINLESS GUIDE TO CRC ERROR DETECTION 6895 ALGORITHMS", SIGCOM 99, August 1993, 6896 . 6899 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 6900 DOI 10.17487/RFC0768, August 1980, 6901 . 6903 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 6904 RFC 793, DOI 10.17487/RFC0793, September 1981, 6905 . 6907 [RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security 6908 Considerations for IP Fragment Filtering", RFC 1858, 6909 DOI 10.17487/RFC1858, October 1995, 6910 . 6912 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 6913 Hashing for Message Authentication", RFC 2104, 6914 DOI 10.17487/RFC2104, February 1997, 6915 . 6917 [RFC2196] Fraser, B., "Site Security Handbook", FYI 8, RFC 2196, 6918 DOI 10.17487/RFC2196, September 1997, 6919 . 6921 [RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management 6922 Protocol", RFC 2522, DOI 10.17487/RFC2522, March 1999, 6923 . 6925 [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., 6926 Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., 6927 Zhang, L., and V. Paxson, "Stream Control Transmission 6928 Protocol", RFC 2960, DOI 10.17487/RFC2960, October 2000, 6929 . 6931 [RFC3465] Allman, M., "TCP Congestion Control with Appropriate Byte 6932 Counting (ABC)", RFC 3465, DOI 10.17487/RFC3465, February 6933 2003, . 6935 [RFC3873] Pastor, J. and M. Belinchon, "Stream Control Transmission 6936 Protocol (SCTP) Management Information Base (MIB)", 6937 RFC 3873, DOI 10.17487/RFC3873, September 2004, 6938 . 6940 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 6941 "Randomness Requirements for Security", BCP 106, RFC 4086, 6942 DOI 10.17487/RFC4086, June 2005, 6943 . 6945 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 6946 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 6947 December 2005, . 6949 [RFC4460] Stewart, R., Arias-Rodriguez, I., Poon, K., Caro, A., and 6950 M. Tuexen, "Stream Control Transmission Protocol (SCTP) 6951 Specification Errata and Issues", RFC 4460, 6952 DOI 10.17487/RFC4460, April 2006, 6953 . 6955 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 6956 RFC 4960, DOI 10.17487/RFC4960, September 2007, 6957 . 6959 [RFC6096] Tuexen, M. and R. Stewart, "Stream Control Transmission 6960 Protocol (SCTP) Chunk Flags Registration", RFC 6096, 6961 DOI 10.17487/RFC6096, January 2011, 6962 . 6964 [RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V. 6965 Yasevich, "Sockets API Extensions for the Stream Control 6966 Transmission Protocol (SCTP)", RFC 6458, 6967 DOI 10.17487/RFC6458, December 2011, 6968 . 6970 [RFC6951] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream 6971 Control Transmission Protocol (SCTP) Packets for End-Host 6972 to End-Host Communication", RFC 6951, 6973 DOI 10.17487/RFC6951, May 2013, 6974 . 6976 [RFC7053] Tuexen, M., Ruengeler, I., and R. Stewart, "SACK- 6977 IMMEDIATELY Extension for the Stream Control Transmission 6978 Protocol", RFC 7053, DOI 10.17487/RFC7053, November 2013, 6979 . 6981 [RFC8260] Stewart, R., Tuexen, M., Loreto, S., and R. Seggelmann, 6982 "Stream Schedulers and User Message Interleaving for the 6983 Stream Control Transmission Protocol", RFC 8260, 6984 DOI 10.17487/RFC8260, November 2017, 6985 . 6987 [RFC8261] Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, 6988 "Datagram Transport Layer Security (DTLS) Encapsulation of 6989 SCTP Packets", RFC 8261, DOI 10.17487/RFC8261, November 6990 2017, . 6992 [RFC8540] Stewart, R., Tuexen, M., and M. Proshin, "Stream Control 6993 Transmission Protocol: Errata and Issues in RFC 4960", 6994 RFC 8540, DOI 10.17487/RFC8540, February 2019, 6995 . 6997 Appendix A. CRC32c Checksum Calculation 6999 We define a 'reflected value' as one that is the opposite of the 7000 normal bit order of the machine. The 32-bit CRC (Cyclic Redundancy 7001 Check) is calculated as described for CRC32c and uses the polynomial 7002 code 0x11EDC6F41 (Castagnoli93) or x^32+x^28+x^27+x^26+x^25+x^23+x^22 7003 +x^20+x^19+x^18+x^14+x^13+x^11+x^10+x^9+x^8+x^6+x^0. The CRC is 7004 computed using a procedure similar to ETHERNET CRC [ITU.V42.1994], 7005 modified to reflect transport-level usage. 7007 CRC computation uses polynomial division. A message bit-string M is 7008 transformed to a polynomial, M(X), and the CRC is calculated from 7009 M(X) using polynomial arithmetic. 7011 When CRCs are used at the link layer, the polynomial is derived from 7012 on-the-wire bit ordering: the first bit 'on the wire' is the high- 7013 order coefficient. Since SCTP is a transport-level protocol, it 7014 cannot know the actual serial-media bit ordering. Moreover, 7015 different links in the path between SCTP endpoints can use different 7016 link-level bit orders. 7018 A convention therefore is established for mapping SCTP transport 7019 messages to polynomials for purposes of CRC computation. The bit- 7020 ordering for mapping SCTP messages to polynomials is that bytes are 7021 taken most-significant first, but within each byte, bits are taken 7022 least-significant first. The first byte of the message provides the 7023 eight highest coefficients. Within each byte, the least-significant 7024 SCTP bit gives the most-significant polynomial coefficient within 7025 that byte, and the most-significant SCTP bit is the least-significant 7026 polynomial coefficient in that byte. (This bit ordering is sometimes 7027 called 'mirrored' or 'reflected' [WILLIAMS93].) CRC polynomials are 7028 to be transformed back into SCTP transport-level byte values, using a 7029 consistent mapping. 7031 The SCTP transport-level CRC value can be calculated as follows: 7033 * CRC input data are assigned to a byte stream, numbered from 0 to 7034 N-1. 7036 * The transport-level byte stream is mapped to a polynomial value. 7037 An N-byte PDU with j bytes numbered 0 to N-1 is considered as 7038 coefficients of a polynomial M(x) of order 8*N-1, with bit 0 of 7039 byte j being coefficient x^(8*(N-j)-8), and bit 7 of byte j being 7040 coefficient x^(8*(N-j)-1). 7042 * The CRC remainder register is initialized with all 1s and the CRC 7043 is computed with an algorithm that simultaneously multiplies by 7044 x^32 and divides by the CRC polynomial. 7046 * The polynomial is multiplied by x^32 and divided by G(x), the 7047 generator polynomial, producing a remainder R(x) of degree less 7048 than or equal to 31. 7050 * The coefficients of R(x) are considered a 32-bit sequence. 7052 * The bit sequence is complemented. The result is the CRC 7053 polynomial. 7055 * The CRC polynomial is mapped back into SCTP transport-level bytes. 7056 The coefficient of x^31 gives the value of bit 7 of SCTP byte 0, 7057 and the coefficient of x^24 gives the value of bit 0 of byte 0. 7058 The coefficient of x^7 gives bit 7 of byte 3, and the coefficient 7059 of x^0 gives bit 0 of byte 3. The resulting 4-byte transport- 7060 level sequence is the 32-bit SCTP checksum value. 7062 Implementation Note: Standards documents, textbooks, and vendor 7063 literature on CRCs often follow an alternative formulation, in which 7064 the register used to hold the remainder of the long-division 7065 algorithm is initialized to zero rather than all ones, and instead 7066 the first 32 bits of the message are complemented. The long-division 7067 algorithm used in our formulation is specified such that the initial 7068 multiplication by 2^32 and the long-division are combined into one 7069 simultaneous operation. For such algorithms, and for messages longer 7070 than 64 bits, the two specifications are precisely equivalent. That 7071 equivalence is the intent of this document. 7073 Implementors of SCTP are warned that both specifications are to be 7074 found in the literature, sometimes with no restriction on the long- 7075 division algorithm. The choice of formulation in this document is to 7076 permit non-SCTP usage, where the same CRC algorithm can be used to 7077 protect messages shorter than 64 bits. 7079 There can be a computational advantage in validating the association 7080 against the Verification Tag, prior to performing a checksum, as 7081 invalid tags will result in the same action as a bad checksum in most 7082 cases. The exceptions for this technique would be packets containing 7083 INIT chunks and some SHUTDOWN-COMPLETE chunks, as well as a stale 7084 COOKIE ECHO chunks. These special-case exchanges represent small 7085 packets and will minimize the effect of the checksum calculation. 7087 The following non-normative sample code is taken from an open-source 7088 CRC generator [WILLIAMS93], using the "mirroring" technique and 7089 yielding a lookup table for SCTP CRC32c with 256 entries, each 32 7090 bits wide. While neither especially slow nor especially fast, as 7091 software table-lookup CRCs go, it has the advantage of working on 7092 both big-endian and little-endian CPUs, using the same (host-order) 7093 lookup tables, and using only the predefined ntohl() and htonl() 7094 operations. The code is somewhat modified from [WILLIAMS93], to 7095 ensure portability between big-endian and little-endian 7096 architectures, use fixed sized types to allow portability between 7097 32-bit and 64-bit platforms, and general C code improvements. (Note 7098 that if the byte endian-ness of the target architecture is known to 7099 be little-endian, the final bit-reversal and byte-reversal steps can 7100 be folded into a single operation.) 7102 7103 /****************************************************************/ 7104 /* Note: The definitions for Ross Williams's table generator */ 7105 /* would be TB_WIDTH=4, TB_POLY=0x1EDC6F41, TB_REVER=TRUE. */ 7106 /* For Mr. Williams's direct calculation code, use the settings */ 7107 /* cm_width=32, cm_poly=0x1EDC6F41, cm_init=0xFFFFFFFF, */ 7108 /* cm_refin=TRUE, cm_refot=TRUE, cm_xorot=0x00000000. */ 7109 /****************************************************************/ 7111 /* Example of the crc table file */ 7112 #ifndef __crc32cr_h__ 7113 #define __crc32cr_h__ 7114 #define CRC32C_POLY 0x1EDC6F41UL 7115 #define CRC32C(c,d) (c=(c>>8)^crc_c[(c^(d))&0xFF]) 7117 uint32_t crc_c[256] = { 7118 0x00000000UL, 0xF26B8303UL, 0xE13B70F7UL, 0x1350F3F4UL, 7119 0xC79A971FUL, 0x35F1141CUL, 0x26A1E7E8UL, 0xD4CA64EBUL, 7120 0x8AD958CFUL, 0x78B2DBCCUL, 0x6BE22838UL, 0x9989AB3BUL, 7121 0x4D43CFD0UL, 0xBF284CD3UL, 0xAC78BF27UL, 0x5E133C24UL, 7122 0x105EC76FUL, 0xE235446CUL, 0xF165B798UL, 0x030E349BUL, 7123 0xD7C45070UL, 0x25AFD373UL, 0x36FF2087UL, 0xC494A384UL, 7124 0x9A879FA0UL, 0x68EC1CA3UL, 0x7BBCEF57UL, 0x89D76C54UL, 7125 0x5D1D08BFUL, 0xAF768BBCUL, 0xBC267848UL, 0x4E4DFB4BUL, 7126 0x20BD8EDEUL, 0xD2D60DDDUL, 0xC186FE29UL, 0x33ED7D2AUL, 7127 0xE72719C1UL, 0x154C9AC2UL, 0x061C6936UL, 0xF477EA35UL, 7128 0xAA64D611UL, 0x580F5512UL, 0x4B5FA6E6UL, 0xB93425E5UL, 7129 0x6DFE410EUL, 0x9F95C20DUL, 0x8CC531F9UL, 0x7EAEB2FAUL, 7130 0x30E349B1UL, 0xC288CAB2UL, 0xD1D83946UL, 0x23B3BA45UL, 7131 0xF779DEAEUL, 0x05125DADUL, 0x1642AE59UL, 0xE4292D5AUL, 7132 0xBA3A117EUL, 0x4851927DUL, 0x5B016189UL, 0xA96AE28AUL, 7133 0x7DA08661UL, 0x8FCB0562UL, 0x9C9BF696UL, 0x6EF07595UL, 7134 0x417B1DBCUL, 0xB3109EBFUL, 0xA0406D4BUL, 0x522BEE48UL, 7135 0x86E18AA3UL, 0x748A09A0UL, 0x67DAFA54UL, 0x95B17957UL, 7136 0xCBA24573UL, 0x39C9C670UL, 0x2A993584UL, 0xD8F2B687UL, 7137 0x0C38D26CUL, 0xFE53516FUL, 0xED03A29BUL, 0x1F682198UL, 7138 0x5125DAD3UL, 0xA34E59D0UL, 0xB01EAA24UL, 0x42752927UL, 7139 0x96BF4DCCUL, 0x64D4CECFUL, 0x77843D3BUL, 0x85EFBE38UL, 7140 0xDBFC821CUL, 0x2997011FUL, 0x3AC7F2EBUL, 0xC8AC71E8UL, 7141 0x1C661503UL, 0xEE0D9600UL, 0xFD5D65F4UL, 0x0F36E6F7UL, 7142 0x61C69362UL, 0x93AD1061UL, 0x80FDE395UL, 0x72966096UL, 7143 0xA65C047DUL, 0x5437877EUL, 0x4767748AUL, 0xB50CF789UL, 7144 0xEB1FCBADUL, 0x197448AEUL, 0x0A24BB5AUL, 0xF84F3859UL, 7145 0x2C855CB2UL, 0xDEEEDFB1UL, 0xCDBE2C45UL, 0x3FD5AF46UL, 7146 0x7198540DUL, 0x83F3D70EUL, 0x90A324FAUL, 0x62C8A7F9UL, 7147 0xB602C312UL, 0x44694011UL, 0x5739B3E5UL, 0xA55230E6UL, 7148 0xFB410CC2UL, 0x092A8FC1UL, 0x1A7A7C35UL, 0xE811FF36UL, 7149 0x3CDB9BDDUL, 0xCEB018DEUL, 0xDDE0EB2AUL, 0x2F8B6829UL, 7150 0x82F63B78UL, 0x709DB87BUL, 0x63CD4B8FUL, 0x91A6C88CUL, 7151 0x456CAC67UL, 0xB7072F64UL, 0xA457DC90UL, 0x563C5F93UL, 7152 0x082F63B7UL, 0xFA44E0B4UL, 0xE9141340UL, 0x1B7F9043UL, 7153 0xCFB5F4A8UL, 0x3DDE77ABUL, 0x2E8E845FUL, 0xDCE5075CUL, 7154 0x92A8FC17UL, 0x60C37F14UL, 0x73938CE0UL, 0x81F80FE3UL, 7155 0x55326B08UL, 0xA759E80BUL, 0xB4091BFFUL, 0x466298FCUL, 7156 0x1871A4D8UL, 0xEA1A27DBUL, 0xF94AD42FUL, 0x0B21572CUL, 7157 0xDFEB33C7UL, 0x2D80B0C4UL, 0x3ED04330UL, 0xCCBBC033UL, 7158 0xA24BB5A6UL, 0x502036A5UL, 0x4370C551UL, 0xB11B4652UL, 7159 0x65D122B9UL, 0x97BAA1BAUL, 0x84EA524EUL, 0x7681D14DUL, 7160 0x2892ED69UL, 0xDAF96E6AUL, 0xC9A99D9EUL, 0x3BC21E9DUL, 7161 0xEF087A76UL, 0x1D63F975UL, 0x0E330A81UL, 0xFC588982UL, 7162 0xB21572C9UL, 0x407EF1CAUL, 0x532E023EUL, 0xA145813DUL, 7163 0x758FE5D6UL, 0x87E466D5UL, 0x94B49521UL, 0x66DF1622UL, 7164 0x38CC2A06UL, 0xCAA7A905UL, 0xD9F75AF1UL, 0x2B9CD9F2UL, 7165 0xFF56BD19UL, 0x0D3D3E1AUL, 0x1E6DCDEEUL, 0xEC064EEDUL, 7166 0xC38D26C4UL, 0x31E6A5C7UL, 0x22B65633UL, 0xD0DDD530UL, 7167 0x0417B1DBUL, 0xF67C32D8UL, 0xE52CC12CUL, 0x1747422FUL, 7168 0x49547E0BUL, 0xBB3FFD08UL, 0xA86F0EFCUL, 0x5A048DFFUL, 7169 0x8ECEE914UL, 0x7CA56A17UL, 0x6FF599E3UL, 0x9D9E1AE0UL, 7170 0xD3D3E1ABUL, 0x21B862A8UL, 0x32E8915CUL, 0xC083125FUL, 7171 0x144976B4UL, 0xE622F5B7UL, 0xF5720643UL, 0x07198540UL, 7172 0x590AB964UL, 0xAB613A67UL, 0xB831C993UL, 0x4A5A4A90UL, 7173 0x9E902E7BUL, 0x6CFBAD78UL, 0x7FAB5E8CUL, 0x8DC0DD8FUL, 7174 0xE330A81AUL, 0x115B2B19UL, 0x020BD8EDUL, 0xF0605BEEUL, 7175 0x24AA3F05UL, 0xD6C1BC06UL, 0xC5914FF2UL, 0x37FACCF1UL, 7176 0x69E9F0D5UL, 0x9B8273D6UL, 0x88D28022UL, 0x7AB90321UL, 7177 0xAE7367CAUL, 0x5C18E4C9UL, 0x4F48173DUL, 0xBD23943EUL, 7178 0xF36E6F75UL, 0x0105EC76UL, 0x12551F82UL, 0xE03E9C81UL, 7179 0x34F4F86AUL, 0xC69F7B69UL, 0xD5CF889DUL, 0x27A40B9EUL, 7180 0x79B737BAUL, 0x8BDCB4B9UL, 0x988C474DUL, 0x6AE7C44EUL, 7181 0xBE2DA0A5UL, 0x4C4623A6UL, 0x5F16D052UL, 0xAD7D5351UL, 7182 }; 7184 #endif 7186 /* Example of table build routine */ 7188 #include 7189 #include 7191 #define OUTPUT_FILE "crc32cr.h" 7192 #define CRC32C_POLY 0x1EDC6F41UL 7194 static FILE *tf; 7196 static uint32_t 7197 reflect_32(uint32_t b) 7198 { 7199 int i; 7200 uint32_t rw = 0UL; 7202 for (i = 0; i < 32; i++) { 7203 if (b & 1) 7204 rw |= 1UL << (31 - i); 7205 b >>= 1; 7206 } 7207 return (rw); 7208 } 7209 static uint32_t 7210 build_crc_table (int index) 7211 { 7212 int i; 7213 uint32_t rb; 7215 rb = reflect_32(index); 7217 for (i = 0; i < 8; i++) { 7218 if (rb & 0x80000000UL) 7219 rb = (rb << 1) ^ (uint32_t)CRC32C_POLY; 7220 else 7221 rb <<= 1; 7222 } 7223 return (reflect_32(rb)); 7224 } 7226 int 7227 main (void) 7228 { 7229 int i; 7231 printf("\nGenerating CRC32c table file <%s>.\n", 7232 OUTPUT_FILE); 7233 if ((tf = fopen(OUTPUT_FILE, "w")) == NULL) { 7234 printf("Unable to open %s.\n", OUTPUT_FILE); 7235 exit (1); 7236 } 7237 fprintf(tf, "#ifndef __crc32cr_h__\n"); 7238 fprintf(tf, "#define __crc32cr_h__\n\n"); 7239 fprintf(tf, "#define CRC32C_POLY 0x%08XUL\n", 7240 (uint32_t)CRC32C_POLY); 7241 fprintf(tf, 7242 "#define CRC32C(c,d) (c=(c>>8)^crc_c[(c^(d))&0xFF])\n"); 7243 fprintf(tf, "\nuint32_t crc_c[256] =\n{\n"); 7244 for (i = 0; i < 256; i++) { 7245 fprintf(tf, "0x%08XUL,", build_crc_table (i)); 7246 if ((i & 3) == 3) 7247 fprintf(tf, "\n"); 7248 else 7249 fprintf(tf, " "); 7250 } 7251 fprintf(tf, "};\n\n#endif\n"); 7253 if (fclose(tf) != 0) 7254 printf("Unable to close <%s>.\n", OUTPUT_FILE); 7255 else 7256 printf("\nThe CRC32c table has been written to <%s>.\n", 7257 OUTPUT_FILE); 7258 return (0); 7259 } 7261 /* Example of crc insertion */ 7263 #include "crc32cr.h" 7265 uint32_t 7266 generate_crc32c(unsigned char *buffer, unsigned int length) 7267 { 7268 unsigned int i; 7269 uint32_t crc32 = 0xffffffffUL; 7270 uint32_t result; 7271 uint32_t byte0, byte1, byte2, byte3; 7273 for (i = 0; i < length; i++) { 7274 CRC32C(crc32, buffer[i]); 7275 } 7277 result = ~crc32; 7279 /* result now holds the negated polynomial remainder, 7280 * since the table and algorithm are "reflected" [williams95]. 7281 * That is, result has the same value as if we mapped the message 7282 * to a polynomial, computed the host-bit-order polynomial 7283 * remainder, performed final negation, and then did an 7284 * end-for-end bit-reversal. 7285 * Note that a 32-bit bit-reversal is identical to four in-place 7286 * 8-bit bit-reversals followed by an end-for-end byteswap. 7287 * In other words, the bits of each byte are in the right order, 7288 * but the bytes have been byteswapped. So, we now do an explicit 7289 * byteswap. On a little-endian machine, this byteswap and 7290 * the final ntohl cancel out and could be elided. 7291 */ 7293 byte0 = result & 0xff; 7294 byte1 = (result>>8) & 0xff; 7295 byte2 = (result>>16) & 0xff; 7296 byte3 = (result>>24) & 0xff; 7297 crc32 = ((byte0 << 24) | 7298 (byte1 << 16) | 7299 (byte2 << 8) | 7300 byte3); 7301 return (crc32); 7302 } 7304 int 7305 insert_crc32(unsigned char *buffer, unsigned int length) 7306 { 7307 SCTP_message *message; 7308 uint32_t crc32; 7310 message = (SCTP_message *)buffer; 7311 message->common_header.checksum = 0UL; 7312 crc32 = generate_crc32c(buffer,length); 7313 /* and insert it into the message */ 7314 message->common_header.checksum = htonl(crc32); 7315 return (1); 7316 } 7318 int 7319 validate_crc32(unsigned char *buffer, unsigned int length) 7320 { 7321 SCTP_message *message; 7322 unsigned int i; 7323 uint32_t original_crc32; 7324 uint32_t crc32; 7326 /* save and zero checksum */ 7327 message = (SCTP_message *)buffer; 7328 original_crc32 = ntohl(message->common_header.checksum); 7329 message->common_header.checksum = 0L; 7330 crc32 = generate_crc32c(buffer, length); 7331 return ((original_crc32 == crc32) ? 1 : -1); 7332 } 7333 7335 Authors' Addresses 7337 Randall R. Stewart 7338 Netflix, Inc. 7339 2455 Heritage Green Ave 7340 Davenport, FL 33837 7341 United States 7343 Email: randall@lakerest.net 7345 Michael Tüxen 7346 Münster University of Applied Sciences 7347 Stegerwaldstrasse 39 7348 48565 Steinfurt 7349 Germany 7351 Email: tuexen@fh-muenster.de 7352 Karen E. E. Nielsen 7353 Kamstrup A/S 7354 Industrivej 28 7355 DK-8660 Skanderborg 7356 Denmark 7358 Email: kee@kamstrup.com