Network Working Group R. Stewart, Ed. Request for Comments: 4960 September 2007 Obsoletes: 2960, 3309 Category: Standards Track Stream Control Transmission Protocol Status of This Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Abstract This document obsoletes RFC 2960 and RFC 3309. It describes the Stream Control Transmission Protocol (SCTP). SCTP is designed to transport Public Switched Telephone Network (PSTN) signaling messages over IP networks, but is capable of broader applications. SCTP is a reliable transport protocol operating on top of a connectionless packet network such as IP. It offers the following services to its users: -- acknowledged error-free non-duplicated transfer of user data, -- data fragmentation to conform to discovered path MTU size, -- sequenced delivery of user messages within multiple streams, with an option for order-of-arrival delivery of individual user messages, -- optional bundling of multiple user messages into a single SCTP packet, and -- network-level fault tolerance through supporting of multi-homing at either or both ends of an association. The design of SCTP includes appropriate congestion avoidance behavior and resistance to flooding and masquerade attacks. Stewart Standards Track [Page 1] RFC 4960 Stream Control Transmission Protocol September 2007 Table of Contents 1. Introduction ....................................................5 1.1. Motivation .................................................5 1.2. Architectural View of SCTP .................................6 1.3. Key Terms ..................................................6 1.4. Abbreviations .............................................10 1.5. Functional View of SCTP ...................................10 1.5.1. Association Startup and Takedown ...................11 1.5.2. Sequenced Delivery within Streams ..................12 1.5.3. User Data Fragmentation ............................12 1.5.4. Acknowledgement and Congestion Avoidance ...........12 1.5.5. Chunk Bundling .....................................13 1.5.6. Packet Validation ..................................13 1.5.7. Path Management ....................................13 1.6. Serial Number Arithmetic ..................................14 1.7. Changes from RFC 2960 .....................................15 2. Conventions ....................................................15 3. SCTP Packet Format .............................................15 3.1. SCTP Common Header Field Descriptions .....................16 3.2. Chunk Field Descriptions ..................................17 3.2.1. Optional/Variable-Length Parameter Format ..........19 3.2.2. Reporting of Unrecognized Parameters ...............21 3.3. SCTP Chunk Definitions ....................................21 3.3.1. Payload Data (DATA) (0) ............................22 3.3.2. Initiation (INIT) (1) ..............................24 3.3.2.1. Optional/Variable-Length Parameters in INIT ........................27 3.3.3. Initiation Acknowledgement (INIT ACK) (2) ..........30 3.3.3.1. Optional or Variable-Length Parameters ....33 3.3.4. Selective Acknowledgement (SACK) (3) ...............34 3.3.5. Heartbeat Request (HEARTBEAT) (4) ..................38 3.3.6. Heartbeat Acknowledgement (HEARTBEAT ACK) (5) ......39 3.3.7. Abort Association (ABORT) (6) ......................40 3.3.8. Shutdown Association (SHUTDOWN) (7) ................41 3.3.9. Shutdown Acknowledgement (SHUTDOWN ACK) (8) ........41 3.3.10. Operation Error (ERROR) (9) .......................42 3.3.10.1. Invalid Stream Identifier (1) ............44 3.3.10.2. Missing Mandatory Parameter (2) ..........44 3.3.10.3. Stale Cookie Error (3) ...................45 3.3.10.4. Out of Resource (4) ......................45 3.3.10.5. Unresolvable Address (5) .................46 3.3.10.6. Unrecognized Chunk Type (6) ..............46 3.3.10.7. Invalid Mandatory Parameter (7) ..........47 3.3.10.8. Unrecognized Parameters (8) ..............47 3.3.10.9. No User Data (9) .........................48 3.3.10.10. Cookie Received While Shutting Down (10) ...............................48 Stewart Standards Track [Page 2] RFC 4960 Stream Control Transmission Protocol September 2007 3.3.10.11. Restart of an Association with New Addresses (11) ......................49 3.3.10.12. User-Initiated Abort (12) ...............49 3.3.10.13. Protocol Violation (13) .................50 3.3.11. Cookie Echo (COOKIE ECHO) (10) ....................50 3.3.12. Cookie Acknowledgement (COOKIE ACK) (11) ..........51 3.3.13. Shutdown Complete (SHUTDOWN COMPLETE) (14) ........51 4. SCTP Association State Diagram .................................52 5. Association Initialization .....................................56 5.1. Normal Establishment of an Association ....................56 5.1.1. Handle Stream Parameters ...........................58 5.1.2. Handle Address Parameters ..........................58 5.1.3. Generating State Cookie ............................61 5.1.4. State Cookie Processing ............................62 5.1.5. State Cookie Authentication ........................62 5.1.6. An Example of Normal Association Establishment .....64 5.2. Handle Duplicate or Unexpected INIT, INIT ACK, COOKIE ECHO, and ..........................................65 5.2.1. INIT Received in COOKIE-WAIT or COOKIE-ECHOED State (Item B) .......................66 5.2.2. Unexpected INIT in States Other than CLOSED, COOKIE-ECHOED, .............................66 5.2.3. Unexpected INIT ACK ................................67 5.2.4. Handle a COOKIE ECHO when a TCB Exists .............67 5.2.4.1. An Example of a Association Restart .......69 5.2.5. Handle Duplicate COOKIE-ACK. .......................71 5.2.6. Handle Stale COOKIE Error ..........................71 5.3. Other Initialization Issues ...............................72 5.3.1. Selection of Tag Value .............................72 5.4. Path Verification .........................................72 6. User Data Transfer .............................................73 6.1. Transmission of DATA Chunks ...............................75 6.2. Acknowledgement on Reception of DATA Chunks ...............78 6.2.1. Processing a Received SACK .........................81 6.3. Management of Retransmission Timer ........................83 6.3.1. RTO Calculation ....................................83 6.3.2. Retransmission Timer Rules .........................85 6.3.3. Handle T3-rtx Expiration ...........................86 6.4. Multi-Homed SCTP Endpoints ................................87 6.4.1. Failover from an Inactive Destination Address ......88 6.5. Stream Identifier and Stream Sequence Number ..............88 6.6. Ordered and Unordered Delivery ............................88 6.7. Report Gaps in Received DATA TSNs .........................89 6.8. CRC32c Checksum Calculation ...............................90 6.9. Fragmentation and Reassembly ..............................91 6.10. Bundling .................................................92 7. Congestion Control .............................................93 7.1. SCTP Differences from TCP Congestion Control ..............94 Stewart Standards Track [Page 3] RFC 4960 Stream Control Transmission Protocol September 2007 7.2. SCTP Slow-Start and Congestion Avoidance ..................95 7.2.1. Slow-Start .........................................96 7.2.2. Congestion Avoidance ...............................97 7.2.3. Congestion Control .................................98 7.2.4. Fast Retransmit on Gap Reports .....................98 7.3. Path MTU Discovery .......................................100 8. Fault Management ..............................................100 8.1. Endpoint Failure Detection ...............................100 8.2. Path Failure Detection ...................................101 8.3. Path Heartbeat ...........................................102 8.4. Handle "Out of the Blue" Packets .........................104 8.5. Verification Tag .........................................105 8.5.1. Exceptions in Verification Tag Rules ..............105 9. Termination of Association ....................................106 9.1. Abort of an Association ..................................107 9.2. Shutdown of an Association ...............................107 10. Interface with Upper Layer ...................................110 10.1. ULP-to-SCTP .............................................110 10.2. SCTP-to-ULP .............................................120 11. Security Considerations ......................................123 11.1. Security Objectives .....................................123 11.2. SCTP Responses to Potential Threats .....................124 11.2.1. Countering Insider Attacks .......................124 11.2.2. Protecting against Data Corruption in the Network ..........................................124 11.2.3. Protecting Confidentiality .......................124 11.2.4. Protecting against Blind Denial-of-Service Attacks ........................125 11.2.4.1. Flooding ................................125 11.2.4.2. Blind Masquerade ........................126 11.2.4.3. Improper Monopolization of Services .....127 11.3. SCTP Interactions with Firewalls ........................127 11.4. Protection of Non-SCTP-Capable Hosts ....................128 12. Network Management Considerations ............................128 13. Recommended Transmission Control Block (TCB) Parameters ......129 13.1. Parameters Necessary for the SCTP Instance ..............129 13.2. Parameters Necessary per Association (i.e., the TCB) ....129 13.3. Per Transport Address Data ..............................131 13.4. General Parameters Needed ...............................132 14. IANA Considerations ..........................................132 14.1. IETF-defined Chunk Extension ............................132 14.2. IETF-Defined Chunk Parameter Extension ..................133 14.3. IETF-Defined Additional Error Causes ....................133 14.4. Payload Protocol Identifiers ............................134 14.5. Port Numbers Registry ...................................134 15. Suggested SCTP Protocol Parameter Values .....................136 16. Acknowledgements .............................................137 Appendix A. Explicit Congestion Notification .....................139 Stewart Standards Track [Page 4] RFC 4960 Stream Control Transmission Protocol September 2007 Appendix B. CRC32c Checksum Calculation ..........................140 Appendix C. ICMP Handling ........................................142 References .......................................................149 Normative References ..........................................149 Informative References ........................................150 1. Introduction This section explains the reasoning behind the development of the Stream Control Transmission Protocol (SCTP), the services it offers, and the basic concepts needed to understand the detailed description of the protocol. This document obsoletes [RFC2960] and [RFC3309]. 1.1. Motivation TCP [RFC0793] has performed immense service as the primary means of reliable data transfer in IP networks. However, an increasing number of recent applications have found TCP too limiting, and have incorporated their own reliable data transfer protocol on top of UDP [RFC0768]. The limitations that users have wished to bypass include the following: -- TCP provides both reliable data transfer and strict order-of- transmission delivery of data. Some applications need reliable transfer without sequence maintenance, while others would be satisfied with partial ordering of the data. In both of these cases, the head-of-line blocking offered by TCP causes unnecessary delay. -- The stream-oriented nature of TCP is often an inconvenience. Applications must add their own record marking to delineate their messages, and must make explicit use of the push facility to ensure that a complete message is transferred in a reasonable time. -- The limited scope of TCP sockets complicates the task of providing highly-available data transfer capability using multi-homed hosts. -- TCP is relatively vulnerable to denial-of-service attacks, such as SYN attacks. Transport of PSTN signaling across the IP network is an application for which all of these limitations of TCP are relevant. While this application directly motivated the development of SCTP, other applications may find SCTP a good match to their requirements. Stewart Standards Track [Page 5] RFC 4960 Stream Control Transmission Protocol September 2007 1.2. Architectural View of SCTP SCTP is viewed as a layer between the SCTP user application ("SCTP user" for short) and a connectionless packet network service such as IP. The remainder of this document assumes SCTP runs on top of IP. The basic service offered by SCTP is the reliable transfer of user messages between peer SCTP users. It performs this service within the context of an association between two SCTP endpoints. Section 10 of this document sketches the API that should exist at the boundary between the SCTP and the SCTP user layers. SCTP is connection-oriented in nature, but the SCTP association is a broader concept than the TCP connection. SCTP provides the means for each SCTP endpoint (Section 1.3) to provide the other endpoint (during association startup) with a list of transport addresses (i.e., multiple IP addresses in combination with an SCTP port) through which that endpoint can be reached and from which it will originate SCTP packets. The association spans transfers over all of the possible source/destination combinations that may be generated from each endpoint's lists. _____________ _____________ | SCTP User | | SCTP User | | Application | | Application | |-------------| |-------------| | SCTP | | SCTP | | Transport | | Transport | | Service | | Service | |-------------| |-------------| | |One or more ---- One or more| | | IP Network |IP address \/ IP address| IP Network | | Service |appearances /\ appearances| Service | |_____________| ---- |_____________| SCTP Node A |<-------- Network transport ------->| SCTP Node B Figure 1: An SCTP Association 1.3. Key Terms Some of the language used to describe SCTP has been introduced in the previous sections. This section provides a consolidated list of the key terms and their definitions. o Active destination transport address: A transport address on a peer endpoint that a transmitting endpoint considers available for receiving user messages. Stewart Standards Track [Page 6] RFC 4960 Stream Control Transmission Protocol September 2007 o Bundling: An optional multiplexing operation, whereby more than one user message may be carried in the same SCTP packet. Each user message occupies its own DATA chunk. o Chunk: A unit of information within an SCTP packet, consisting of a chunk header and chunk-specific content. o Congestion window (cwnd): An SCTP variable that limits the data, in number of bytes, a sender can send to a particular destination transport address before receiving an acknowledgement. o Cumulative TSN Ack Point: The TSN of the last DATA chunk acknowledged via the Cumulative TSN Ack field of a SACK. o Idle destination address: An address that has not had user messages sent to it within some length of time, normally the HEARTBEAT interval or greater. o Inactive destination transport address: An address that is considered inactive due to errors and unavailable to transport user messages. o Message = user message: Data submitted to SCTP by the Upper Layer Protocol (ULP). o Message Authentication Code (MAC): An integrity check mechanism based on cryptographic hash functions using a secret key. Typically, message authentication codes are used between two parties that share a secret key in order to validate information transmitted between these parties. In SCTP, it is used by an endpoint to validate the State Cookie information that is returned from the peer in the COOKIE ECHO chunk. The term "MAC" has different meanings in different contexts. SCTP uses this term with the same meaning as in [RFC2104]. o Network Byte Order: Most significant byte first, a.k.a., big endian. o Ordered Message: A user message that is delivered in order with respect to all previous user messages sent within the stream on which the message was sent. o Outstanding TSN (at an SCTP endpoint): A TSN (and the associated DATA chunk) that has been sent by the endpoint but for which it has not yet received an acknowledgement. Stewart Standards Track [Page 7] RFC 4960 Stream Control Transmission Protocol September 2007 o Path: The route taken by the SCTP packets sent by one SCTP endpoint to a specific destination transport address of its peer SCTP endpoint. Sending to different destination transport addresses does not necessarily guarantee getting separate paths. o Primary Path: The primary path is the destination and source address that will be put into a packet outbound to the peer endpoint by default. The definition includes the source address since an implementation MAY wish to specify both destination and source address to better control the return path taken by reply chunks and on which interface the packet is transmitted when the data sender is multi-homed. o Receiver Window (rwnd): An SCTP variable a data sender uses to store the most recently calculated receiver window of its peer, in number of bytes. This gives the sender an indication of the space available in the receiver's inbound buffer. o SCTP association: A protocol relationship between SCTP endpoints, composed of the two SCTP endpoints and protocol state information including Verification Tags and the currently active set of Transmission Sequence Numbers (TSNs), etc. An association can be uniquely identified by the transport addresses used by the endpoints in the association. Two SCTP endpoints MUST NOT have more than one SCTP association between them at any given time. o SCTP endpoint: The logical sender/receiver of SCTP packets. On a multi-homed host, an SCTP endpoint is represented to its peers as a combination of a set of eligible destination transport addresses to which SCTP packets can be sent and a set of eligible source transport addresses from which SCTP packets can be received. All transport addresses used by an SCTP endpoint must use the same port number, but can use multiple IP addresses. A transport address used by an SCTP endpoint must not be used by another SCTP endpoint. In other words, a transport address is unique to an SCTP endpoint. o SCTP packet (or packet): The unit of data delivery across the interface between SCTP and the connectionless packet network (e.g., IP). An SCTP packet includes the common SCTP header, possible SCTP control chunks, and user data encapsulated within SCTP DATA chunks. o SCTP user application (SCTP user): The logical higher-layer application entity which uses the services of SCTP, also called the Upper-Layer Protocol (ULP). Stewart Standards Track [Page 8] RFC 4960 Stream Control Transmission Protocol September 2007 o Slow-Start Threshold (ssthresh): An SCTP variable. This is the threshold that the endpoint will use to determine whether to perform slow start or congestion avoidance on a particular destination transport address. Ssthresh is in number of bytes. o Stream: A unidirectional logical channel established from one to another associated SCTP endpoint, within which all user messages are delivered in sequence except for those submitted to the unordered delivery service. Note: The relationship between stream numbers in opposite directions is strictly a matter of how the applications use them. It is the responsibility of the SCTP user to create and manage these correlations if they are so desired. o Stream Sequence Number: A 16-bit sequence number used internally by SCTP to ensure sequenced delivery of the user messages within a given stream. One Stream Sequence Number is attached to each user message. o Tie-Tags: Two 32-bit random numbers that together make a 64-bit nonce. These tags are used within a State Cookie and TCB so that a newly restarting association can be linked to the original association within the endpoint that did not restart and yet not reveal the true Verification Tags of an existing association. o Transmission Control Block (TCB): An internal data structure created by an SCTP endpoint for each of its existing SCTP associations to other SCTP endpoints. TCB contains all the status and operational information for the endpoint to maintain and manage the corresponding association. o Transmission Sequence Number (TSN): A 32-bit sequence number used internally by SCTP. One TSN is attached to each chunk containing user data to permit the receiving SCTP endpoint to acknowledge its receipt and detect duplicate deliveries. o Transport address: A transport address is traditionally defined by a network-layer address, a transport-layer protocol, and a transport-layer port number. In the case of SCTP running over IP, a transport address is defined by the combination of an IP address and an SCTP port number (where SCTP is the transport protocol). o Unacknowledged TSN (at an SCTP endpoint): A TSN (and the associated DATA chunk) that has been received by the endpoint but for which an acknowledgement has not yet been sent. Or in the opposite case, for a packet that has been sent but no acknowledgement has been received. Stewart Standards Track [Page 9] RFC 4960 Stream Control Transmission Protocol September 2007 o Unordered Message: Unordered messages are "unordered" with respect to any other message; this includes both other unordered messages as well as other ordered messages. An unordered message might be delivered prior to or later than ordered messages sent on the same stream. o User message: The unit of data delivery across the interface between SCTP and its user. o Verification Tag: A 32-bit unsigned integer that is randomly generated. The Verification Tag provides a key that allows a receiver to verify that the SCTP packet belongs to the current association and is not an old or stale packet from a previous association. 1.4. Abbreviations MAC - Message Authentication Code [RFC2104] RTO - Retransmission Timeout RTT - Round-Trip Time RTTVAR - Round-Trip Time Variation SCTP - Stream Control Transmission Protocol SRTT - Smoothed RTT TCB - Transmission Control Block TLV - Type-Length-Value coding format TSN - Transmission Sequence Number ULP - Upper-Layer Protocol 1.5. Functional View of SCTP The SCTP transport service can be decomposed into a number of functions. These are depicted in Figure 2 and explained in the remainder of this section. Stewart Standards Track [Page 10] RFC 4960 Stream Control Transmission Protocol September 2007 SCTP User Application ----------------------------------------------------- _____________ ____________________ | | | Sequenced Delivery | | Association | | within Streams | | | |____________________| | Startup | | | ____________________________ | and | | User Data Fragmentation | | | |____________________________| | Takedown | | | ____________________________ | | | Acknowledgement | | | | and | | | | Congestion Avoidance | | | |____________________________| | | | | ____________________________ | | | Chunk Bundling | | | |____________________________| | | | | ________________________________ | | | Packet Validation | | | |________________________________| | | | | ________________________________ | | | Path Management | |_____________| |________________________________| Figure 2: Functional View of the SCTP Transport Service 1.5.1. Association Startup and Takedown An association is initiated by a request from the SCTP user (see the description of the ASSOCIATE (or SEND) primitive in Section 10). A cookie mechanism, similar to one described by Karn and Simpson in [RFC2522], is employed during the initialization to provide protection against synchronization attacks. The cookie mechanism uses a four-way handshake, the last two legs of which are allowed to carry user data for fast setup. The startup sequence is described in Section 5 of this document. SCTP provides for graceful close (i.e., shutdown) of an active association on request from the SCTP user. See the description of the SHUTDOWN primitive in Section 10. SCTP also allows ungraceful close (i.e., abort), either on request from the user (ABORT Stewart Standards Track [Page 11] RFC 4960 Stream Control Transmission Protocol September 2007 primitive) or as a result of an error condition detected within the SCTP layer. Section 9 describes both the graceful and the ungraceful close procedures. SCTP does not support a half-open state (like TCP) wherein one side may continue sending data while the other end is closed. When either endpoint performs a shutdown, the association on each peer will stop accepting new data from its user and only deliver data in queue at the time of the graceful close (see Section 9). 1.5.2. Sequenced Delivery within Streams The term "stream" is used in SCTP to refer to a sequence of user messages that are to be delivered to the upper-layer protocol in order with respect to other messages within the same stream. This is in contrast to its usage in TCP, where it refers to a sequence of bytes (in this document, a byte is assumed to be 8 bits). The SCTP user can specify at association startup time the number of streams to be supported by the association. This number is negotiated with the remote end (see Section 5.1.1). User messages are associated with stream numbers (SEND, RECEIVE primitives, Section 10). Internally, SCTP assigns a Stream Sequence Number to each message passed to it by the SCTP user. On the receiving side, SCTP ensures that messages are delivered to the SCTP user in sequence within a given stream. However, while one stream may be blocked waiting for the next in-sequence user message, delivery from other streams may proceed. SCTP provides a mechanism for bypassing the sequenced delivery service. User messages sent using this mechanism are delivered to the SCTP user as soon as they are received. 1.5.3. User Data Fragmentation When needed, SCTP fragments user messages to ensure that the SCTP packet passed to the lower layer conforms to the path MTU. On receipt, fragments are reassembled into complete messages before being passed to the SCTP user. 1.5.4. Acknowledgement and Congestion Avoidance SCTP assigns a Transmission Sequence Number (TSN) to each user data fragment or unfragmented message. The TSN is independent of any Stream Sequence Number assigned at the stream level. The receiving end acknowledges all TSNs received, even if there are gaps in the sequence. In this way, reliable delivery is kept functionally separate from sequenced stream delivery. Stewart Standards Track [Page 12] RFC 4960 Stream Control Transmission Protocol September 2007 The acknowledgement and congestion avoidance function is responsible for packet retransmission when timely acknowledgement has not been received. Packet retransmission is conditioned by congestion avoidance procedures similar to those used for TCP. See Section 6 and Section 7 for a detailed description of the protocol procedures associated with this function. 1.5.5. Chunk Bundling As described in Section 3, the SCTP packet as delivered to the lower layer consists of a common header followed by one or more chunks. Each chunk may contain either user data or SCTP control information. The SCTP user has the option to request bundling of more than one user message into a single SCTP packet. The chunk bundling function of SCTP is responsible for assembly of the complete SCTP packet and its disassembly at the receiving end. During times of congestion, an SCTP implementation MAY still perform bundling even if the user has requested that SCTP not bundle. The user's disabling of bundling only affects SCTP implementations that may delay a small period of time before transmission (to attempt to encourage bundling). When the user layer disables bundling, this small delay is prohibited but not bundling that is performed during congestion or retransmission. 1.5.6. Packet Validation A mandatory Verification Tag field and a 32-bit checksum field (see Appendix B for a description of the CRC32c checksum) are included in the SCTP common header. The Verification Tag value is chosen by each end of the association during association startup. Packets received without the expected Verification Tag value are discarded, as a protection against blind masquerade attacks and against stale SCTP packets from a previous association. The CRC32c checksum should be set by the sender of each SCTP packet to provide additional protection against data corruption in the network. The receiver of an SCTP packet with an invalid CRC32c checksum silently discards the packet. 1.5.7. Path Management The sending SCTP user is able to manipulate the set of transport addresses used as destinations for SCTP packets through the primitives described in Section 10. The SCTP path management function chooses the destination transport address for each outgoing SCTP packet based on the SCTP user's instructions and the currently perceived reachability status of the eligible destination set. The path management function monitors reachability through heartbeats Stewart Standards Track [Page 13] RFC 4960 Stream Control Transmission Protocol September 2007 when other packet traffic is inadequate to provide this information and advises the SCTP user when reachability of any far-end transport address changes. The path management function is also responsible for reporting the eligible set of local transport addresses to the far end during association startup, and for reporting the transport addresses returned from the far end to the SCTP user. At association startup, a primary path is defined for each SCTP endpoint, and is used for normal sending of SCTP packets. On the receiving end, the path management is responsible for verifying the existence of a valid SCTP association to which the inbound SCTP packet belongs before passing it for further processing. Note: Path Management and Packet Validation are done at the same time, so although described separately above, in reality they cannot be performed as separate items. 1.6. Serial Number Arithmetic It is essential to remember that the actual Transmission Sequence Number space is finite, though very large. This space ranges from 0 to 2**32 - 1. Since the space is finite, all arithmetic dealing with Transmission Sequence Numbers must be performed modulo 2**32. This unsigned arithmetic preserves the relationship of sequence numbers as they cycle from 2**32 - 1 to 0 again. There are some subtleties to computer modulo arithmetic, so great care should be taken in programming the comparison of such values. When referring to TSNs, the symbol "=<" means "less than or equal"(modulo 2**32). Comparisons and arithmetic on TSNs in this document SHOULD use Serial Number Arithmetic as defined in [RFC1982] where SERIAL_BITS = 32. An endpoint SHOULD NOT transmit a DATA chunk with a TSN that is more than 2**31 - 1 above the beginning TSN of its current send window. Doing so will cause problems in comparing TSNs. Transmission Sequence Numbers wrap around when they reach 2**32 - 1. That is, the next TSN a DATA chunk MUST use after transmitting TSN = 2*32 - 1 is TSN = 0. Any arithmetic done on Stream Sequence Numbers SHOULD use Serial Number Arithmetic as defined in [RFC1982] where SERIAL_BITS = 16. All other arithmetic and comparisons in this document use normal arithmetic. Stewart Standards Track [Page 14] RFC 4960 Stream Control Transmission Protocol September 2007 1.7. Changes from RFC 2960 SCTP was originally defined in [RFC2960], which this document obsoletes. Readers interested in the details of the various changes that this document incorporates are asked to consult [RFC4460]. 2. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 3. SCTP Packet Format An SCTP packet is composed of a common header and chunks. A chunk contains either control information or user data. The SCTP packet format is shown below: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Common Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Chunk #1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Chunk #n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Multiple chunks can be bundled into one SCTP packet up to the MTU size, except for the INIT, INIT ACK, and SHUTDOWN COMPLETE chunks. These chunks MUST NOT be bundled with any other chunk in a packet. See Section 6.10 for more details on chunk bundling. If a user data message doesn't fit into one SCTP packet it can be fragmented into multiple chunks using the procedure defined in Section 6.9. All integer fields in an SCTP packet MUST be transmitted in network byte order, unless otherwise stated. Stewart Standards Track [Page 15] RFC 4960 Stream Control Transmission Protocol September 2007 3.1. SCTP Common Header Field Descriptions SCTP Common Header Format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port Number | Destination Port Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Verification Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Source Port Number: 16 bits (unsigned integer) This is the SCTP sender's port number. It can be used by the receiver in combination with the source IP address, the SCTP destination port, and possibly the destination IP address to identify the association to which this packet belongs. The port number 0 MUST NOT be used. Destination Port Number: 16 bits (unsigned integer) This is the SCTP port number to which this packet is destined. The receiving host will use this port number to de-multiplex the SCTP packet to the correct receiving endpoint/application. The port number 0 MUST NOT be used. Verification Tag: 32 bits (unsigned integer) The receiver of this packet uses the Verification Tag to validate the sender of this SCTP packet. On transmit, the value of this Verification Tag MUST be set to the value of the Initiate Tag received from the peer endpoint during the association initialization, with the following exceptions: - A packet containing an INIT chunk MUST have a zero Verification Tag. - A packet containing a SHUTDOWN COMPLETE chunk with the T bit set MUST have the Verification Tag copied from the packet with the SHUTDOWN ACK chunk. - A packet containing an ABORT chunk may have the verification tag copied from the packet that caused the ABORT to be sent. For details see Section 8.4 and Section 8.5. Stewart Standards Track [Page 16] RFC 4960 Stream Control Transmission Protocol September 2007 An INIT chunk MUST be the only chunk in the SCTP packet carrying it. Checksum: 32 bits (unsigned integer) This field contains the checksum of this SCTP packet. Its calculation is discussed in Section 6.8. SCTP uses the CRC32c algorithm as described in Appendix B for calculating the checksum. 3.2. Chunk Field Descriptions The figure below illustrates the field format for the chunks to be transmitted in the SCTP packet. Each chunk is formatted with a Chunk Type field, a chunk-specific Flag field, a Chunk Length field, and a Value field. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Chunk Type | Chunk Flags | Chunk Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / Chunk Value / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Chunk Type: 8 bits (unsigned integer) This field identifies the type of information contained in the Chunk Value field. It takes a value from 0 to 254. The value of 255 is reserved for future use as an extension field. The values of Chunk Types are defined as follows: ID Value Chunk Type ----- ---------- 0 - Payload Data (DATA) 1 - Initiation (INIT) 2 - Initiation Acknowledgement (INIT ACK) 3 - Selective Acknowledgement (SACK) 4 - Heartbeat Request (HEARTBEAT) 5 - Heartbeat Acknowledgement (HEARTBEAT ACK) 6 - Abort (ABORT) 7 - Shutdown (SHUTDOWN) 8 - Shutdown Acknowledgement (SHUTDOWN ACK) 9 - Operation Error (ERROR) 10 - State Cookie (COOKIE ECHO) 11 - Cookie Acknowledgement (COOKIE ACK) Stewart Standards Track [Page 17] RFC 4960 Stream Control Transmission Protocol September 2007 12 - Reserved for Explicit Congestion Notification Echo (ECNE) 13 - Reserved for Congestion Window Reduced (CWR) 14 - Shutdown Complete (SHUTDOWN COMPLETE) 15 to 62 - available 63 - reserved for IETF-defined Chunk Extensions 64 to 126 - available 127 - reserved for IETF-defined Chunk Extensions 128 to 190 - available 191 - reserved for IETF-defined Chunk Extensions 192 to 254 - available 255 - reserved for IETF-defined Chunk Extensions Chunk Types are encoded such that the highest-order 2 bits specify the action that must be taken if the processing endpoint does not recognize the Chunk Type. 00 - Stop processing this SCTP packet and discard it, do not process any further chunks within it. 01 - Stop processing this SCTP packet and discard it, do not process any further chunks within it, and report the unrecognized chunk in an 'Unrecognized Chunk Type'. 10 - Skip this chunk and continue processing. 11 - Skip this chunk and continue processing, but report in an ERROR chunk using the 'Unrecognized Chunk Type' cause of error. Note: The ECNE and CWR chunk types are reserved for future use of Explicit Congestion Notification (ECN); see Appendix A. Chunk Flags: 8 bits The usage of these bits depends on the Chunk type as given by the Chunk Type field. Unless otherwise specified, they are set to 0 on transmit and are ignored on receipt. Chunk Length: 16 bits (unsigned integer) This value represents the size of the chunk in bytes, including the Chunk Type, Chunk Flags, Chunk Length, and Chunk Value fields. Therefore, if the Chunk Value field is zero-length, the Length field will be set to 4. The Chunk Length field does not count any chunk padding. Stewart Standards Track [Page 18] RFC 4960 Stream Control Transmission Protocol September 2007 Chunks (including Type, Length, and Value fields) are padded out by the sender with all zero bytes to be a multiple of 4 bytes long. This padding MUST NOT be more than 3 bytes in total. The Chunk Length value does not include terminating padding of the chunk. However, it does include padding of any variable-length parameter except the last parameter in the chunk. The receiver MUST ignore the padding. Note: A robust implementation should accept the chunk whether or not the final padding has been included in the Chunk Length. Chunk Value: variable length The Chunk Value field contains the actual information to be transferred in the chunk. The usage and format of this field is dependent on the Chunk Type. The total length of a chunk (including Type, Length, and Value fields) MUST be a multiple of 4 bytes. If the length of the chunk is not a multiple of 4 bytes, the sender MUST pad the chunk with all zero bytes, and this padding is not included in the Chunk Length field. The sender MUST NOT pad with more than 3 bytes. The receiver MUST ignore the padding bytes. SCTP-defined chunks are described in detail in Section 3.3. The guidelines for IETF-defined chunk extensions can be found in Section 14.1 of this document. 3.2.1. Optional/Variable-Length Parameter Format Chunk values of SCTP control chunks consist of a chunk-type-specific header of required fields, followed by zero or more parameters. The optional and variable-length parameters contained in a chunk are defined in a Type-Length-Value format as shown below. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Parameter Type | Parameter Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / Parameter Value / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Stewart Standards Track [Page 19] RFC 4960 Stream Control Transmission Protocol September 2007 Chunk Parameter Type: 16 bits (unsigned integer) The Type field is a 16-bit identifier of the type of parameter. It takes a value of 0 to 65534. The value of 65535 is reserved for IETF-defined extensions. Values other than those defined in specific SCTP chunk descriptions are reserved for use by IETF. Chunk Parameter Length: 16 bits (unsigned integer) The Parameter Length field contains the size of the parameter in bytes, including the Parameter Type, Parameter Length, and Parameter Value fields. Thus, a parameter with a zero-length Parameter Value field would have a Length field of 4. The Parameter Length does not include any padding bytes. Chunk Parameter Value: variable length The Parameter Value field contains the actual information to be transferred in the parameter. The total length of a parameter (including Type, Parameter Length, and Value fields) MUST be a multiple of 4 bytes. If the length of the parameter is not a multiple of 4 bytes, the sender pads the parameter at the end (i.e., after the Parameter Value field) with all zero bytes. The length of the padding is not included in the Parameter Length field. A sender MUST NOT pad with more than 3 bytes. The receiver MUST ignore the padding bytes. The Parameter Types are encoded such that the highest-order 2 bits specify the action that must be taken if the processing endpoint does not recognize the Parameter Type. 00 - Stop processing this parameter; do not process any further parameters within this chunk. 01 - Stop processing this parameter, do not process any further parameters within this chunk, and report the unrecognized parameter in an 'Unrecognized Parameter', as described in Section 3.2.2. 10 - Skip this parameter and continue processing. 11 - Skip this parameter and continue processing but report the unrecognized parameter in an 'Unrecognized Parameter', as described in Section 3.2.2. Stewart Standards Track [Page 20] RFC 4960 Stream Control Transmission Protocol September 2007 Please note that in all four cases, an INIT ACK or COOKIE ECHO chunk is sent. In the 00 or 01 case, the processing of the parameters after the unknown parameter is canceled, but no processing already done is rolled back. The actual SCTP parameters are defined in the specific SCTP chunk sections. The rules for IETF-defined parameter extensions are defined in Section 14.2. Note that a parameter type MUST be unique across all chunks. For example, the parameter type '5' is used to represent an IPv4 address (see Section 3.3.2.1). The value '5' then is reserved across all chunks to represent an IPv4 address and MUST NOT be reused with a different meaning in any other chunk. 3.2.2. Reporting of Unrecognized Parameters If the receiver of an INIT chunk detects unrecognized parameters and has to report them according to Section 3.2.1, it MUST put the 'Unrecognized Parameter' parameter(s) in the INIT ACK chunk sent in response to the INIT chunk. Note that if the receiver of the INIT chunk is NOT going to establish an association (e.g., due to lack of resources), an 'Unrecognized Parameter' would NOT be included with any ABORT being sent to the sender of the INIT. If the receiver of an INIT ACK chunk detects unrecognized parameters and has to report them according to Section 3.2.1, it SHOULD bundle the ERROR chunk containing the 'Unrecognized Parameters' error cause with the COOKIE ECHO chunk sent in response to the INIT ACK chunk. If the receiver of the INIT ACK cannot bundle the COOKIE ECHO chunk with the ERROR chunk, the ERROR chunk MAY be sent separately but not before the COOKIE ACK has been received. Note: Any time a COOKIE ECHO is sent in a packet, it MUST be the first chunk. 3.3. SCTP Chunk Definitions This section defines the format of the different SCTP chunk types. Stewart Standards Track [Page 21] RFC 4960 Stream Control Transmission Protocol September 2007 3.3.1. Payload Data (DATA) (0) The following format MUST be used for the DATA chunk: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0 | Reserved|U|B|E| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TSN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Stream Identifier S | Stream Sequence Number n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Protocol Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / User Data (seq n of Stream S) / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reserved: 5 bits Should be set to all '0's and ignored by the receiver. U bit: 1 bit The (U)nordered bit, if set to '1', indicates that this is an unordered DATA chunk, and there is no Stream Sequence Number assigned to this DATA chunk. Therefore, the receiver MUST ignore the Stream Sequence Number field. After reassembly (if necessary), unordered DATA chunks MUST be dispatched to the upper layer by the receiver without any attempt to reorder. If an unordered user message is fragmented, each fragment of the message MUST have its U bit set to '1'. B bit: 1 bit The (B)eginning fragment bit, if set, indicates the first fragment of a user message. E bit: 1 bit The (E)nding fragment bit, if set, indicates the last fragment of a user message. Stewart Standards Track [Page 22] RFC 4960 Stream Control Transmission Protocol September 2007 An unfragmented user message shall have both the B and E bits set to '1'. Setting both B and E bits to '0' indicates a middle fragment of a multi-fragment user message, as summarized in the following table: B E Description ============================================================ | 1 0 | First piece of a fragmented user message | +----------------------------------------------------------+ | 0 0 | Middle piece of a fragmented user message | +----------------------------------------------------------+ | 0 1 | Last piece of a fragmented user message | +----------------------------------------------------------+ | 1 1 | Unfragmented message | ============================================================ | Table 1: Fragment Description Flags | ============================================================ When a user message is fragmented into multiple chunks, the TSNs are used by the receiver to reassemble the message. This means that the TSNs for each fragment of a fragmented user message MUST be strictly sequential. Length: 16 bits (unsigned integer) This field indicates the length of the DATA chunk in bytes from the beginning of the type field to the end of the User Data field excluding any padding. A DATA chunk with one byte of user data will have Length set to 17 (indicating 17 bytes). A DATA chunk with a User Data field of length L will have the Length field set to (16 + L) (indicating 16+L bytes) where L MUST be greater than 0. TSN: 32 bits (unsigned integer) This value represents the TSN for this DATA chunk. The valid range of TSN is from 0 to 4294967295 (2**32 - 1). TSN wraps back to 0 after reaching 4294967295. Stream Identifier S: 16 bits (unsigned integer) Identifies the stream to which the following user data belongs. Stream Sequence Number n: 16 bits (unsigned integer) This value represents the Stream Sequence Number of the following user data within the stream S. Valid range is 0 to 65535. Stewart Standards Track [Page 23] RFC 4960 Stream Control Transmission Protocol September 2007 When a user message is fragmented by SCTP for transport, the same Stream Sequence Number MUST be carried in each of the fragments of the message. Payload Protocol Identifier: 32 bits (unsigned integer) This value represents an application (or upper layer) specified protocol identifier. This value is passed to SCTP by its upper layer and sent to its peer. This identifier is not used by SCTP but can be used by certain network entities, as well as by the peer application, to identify the type of information being carried in this DATA chunk. This field must be sent even in fragmented DATA chunks (to make sure it is available for agents in the middle of the network). Note that this field is NOT touched by an SCTP implementation; therefore, its byte order is NOT necessarily big endian. The upper layer is responsible for any byte order conversions to this field. The value 0 indicates that no application identifier is specified by the upper layer for this payload data. User Data: variable length This is the payload user data. The implementation MUST pad the end of the data to a 4-byte boundary with all-zero bytes. Any padding MUST NOT be included in the Length field. A sender MUST never add more than 3 bytes of padding. 3.3.2. Initiation (INIT) (1) This chunk is used to initiate an SCTP association between two endpoints. The format of the INIT chunk is shown below: Stewart Standards Track [Page 24] RFC 4960 Stream Control Transmission Protocol September 2007 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 1 | Chunk Flags | Chunk Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Initiate Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertised Receiver Window Credit (a_rwnd) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of Outbound Streams | Number of Inbound Streams | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Initial TSN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / Optional/Variable-Length Parameters / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The INIT chunk contains the following parameters. Unless otherwise noted, each parameter MUST only be included once in the INIT chunk. Fixed Parameters Status ---------------------------------------------- Initiate Tag Mandatory Advertised Receiver Window Credit Mandatory Number of Outbound Streams Mandatory Number of Inbound Streams Mandatory Initial TSN Mandatory Variable Parameters Status Type Value ------------------------------------------------------------- IPv4 Address (Note 1) Optional 5 IPv6 Address (Note 1) Optional 6 Cookie Preservative Optional 9 Reserved for ECN Capable (Note 2) Optional 32768 (0x8000) Host Name Address (Note 3) Optional 11 Supported Address Types (Note 4) Optional 12 Note 1: The INIT chunks can contain multiple addresses that can be IPv4 and/or IPv6 in any combination. Note 2: The ECN Capable field is reserved for future use of Explicit Congestion Notification. Note 3: An INIT chunk MUST NOT contain more than one Host Name Address parameter. Moreover, the sender of the INIT MUST NOT combine any other address types with the Host Name Address in the INIT. The receiver of INIT MUST ignore any other address types if the Host Name Address parameter is present in the received INIT chunk. Stewart Standards Track [Page 25] RFC 4960 Stream Control Transmission Protocol September 2007 Note 4: This parameter, when present, specifies all the address types the sending endpoint can support. The absence of this parameter indicates that the sending endpoint can support any address type. IMPLEMENTATION NOTE: If an INIT chunk is received with known parameters that are not optional parameters of the INIT chunk, then the receiver SHOULD process the INIT chunk and send back an INIT ACK. The receiver of the INIT chunk MAY bundle an ERROR chunk with the COOKIE ACK chunk later. However, restrictive implementations MAY send back an ABORT chunk in response to the INIT chunk. The Chunk Flags field in INIT is reserved, and all bits in it should be set to 0 by the sender and ignored by the receiver. The sequence of parameters within an INIT can be processed in any order. Initiate Tag: 32 bits (unsigned integer) The receiver of the INIT (the responding end) records the value of the Initiate Tag parameter. This value MUST be placed into the Verification Tag field of every SCTP packet that the receiver of the INIT transmits within this association. The Initiate Tag is allowed to have any value except 0. See Section 5.3.1 for more on the selection of the tag value. If the value of the Initiate Tag in a received INIT chunk is found to be 0, the receiver MUST treat it as an error and close the association by transmitting an ABORT. Advertised Receiver Window Credit (a_rwnd): 32 bits (unsigned integer) This value represents the dedicated buffer space, in number of bytes, the sender of the INIT has reserved in association with this window. During the life of the association, this buffer space SHOULD NOT be lessened (i.e., dedicated buffers taken away from this association); however, an endpoint MAY change the value of a_rwnd it sends in SACK chunks. Number of Outbound Streams (OS): 16 bits (unsigned integer) Defines the number of outbound streams the sender of this INIT chunk wishes to create in this association. The value of 0 MUST NOT be used. Note: A receiver of an INIT with the OS value set to 0 SHOULD abort the association. Stewart Standards Track [Page 26] RFC 4960 Stream Control Transmission Protocol September 2007 Number of Inbound Streams (MIS): 16 bits (unsigned integer) Defines the maximum number of streams the sender of this INIT chunk allows the peer end to create in this association. The value 0 MUST NOT be used. Note: There is no negotiation of the actual number of streams but instead the two endpoints will use the min(requested, offered). See Section 5.1.1 for details. Note: A receiver of an INIT with the MIS value of 0 SHOULD abort the association. Initial TSN (I-TSN): 32 bits (unsigned integer) Defines the initial TSN that the sender will use. The valid range is from 0 to 4294967295. This field MAY be set to the value of the Initiate Tag field. 3.3.2.1. Optional/Variable-Length Parameters in INIT The following parameters follow the Type-Length-Value format as defined in Section 3.2.1. Any Type-Length-Value fields MUST come after the fixed-length fields defined in the previous section. IPv4 Address Parameter (5) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 5 | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IPv4 Address: 32 bits (unsigned integer) Contains an IPv4 address of the sending endpoint. It is binary encoded. Stewart Standards Track [Page 27] RFC 4960 Stream Control Transmission Protocol September 2007 IPv6 Address Parameter (6) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 6 | Length = 20 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | IPv6 Address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IPv6 Address: 128 bits (unsigned integer) Contains an IPv6 [RFC2460] address of the sending endpoint. It is binary encoded. Note: A sender MUST NOT use an IPv4-mapped IPv6 address [RFC4291], but should instead use an IPv4 Address parameter for an IPv4 address. Combined with the Source Port Number in the SCTP common header, the value passed in an IPv4 or IPv6 Address parameter indicates a transport address the sender of the INIT will support for the association being initiated. That is, during the life time of this association, this IP address can appear in the source address field of an IP datagram sent from the sender of the INIT, and can be used as a destination address of an IP datagram sent from the receiver of the INIT. More than one IP Address parameter can be included in an INIT chunk when the INIT sender is multi-homed. Moreover, a multi- homed endpoint may have access to different types of network; thus, more than one address type can be present in one INIT chunk, i.e., IPv4 and IPv6 addresses are allowed in the same INIT chunk. If the INIT contains at least one IP Address parameter, then the source address of the IP datagram containing the INIT chunk and any additional address(es) provided within the INIT can be used as destinations by the endpoint receiving the INIT. If the INIT does not contain any IP Address parameters, the endpoint receiving the INIT MUST use the source address associated with the received IP datagram as its sole destination address for the association. Note that not using any IP Address parameters in the INIT and INIT ACK is an alternative to make an association more likely to work across a NAT box. Stewart Standards Track [Page 28] RFC 4960 Stream Control Transmission Protocol September 2007 Cookie Preservative (9) The sender of the INIT shall use this parameter to suggest to the receiver of the INIT for a longer life-span of the State Cookie. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 9 | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Suggested Cookie Life-Span Increment (msec.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Suggested Cookie Life-Span Increment: 32 bits (unsigned integer) This parameter indicates to the receiver how much increment in milliseconds the sender wishes the receiver to add to its default cookie life-span. This optional parameter should be added to the INIT chunk by the sender when it reattempts establishing an association with a peer to which its previous attempt of establishing the association failed due to a stale cookie operation error. The receiver MAY choose to ignore the suggested cookie life-span increase for its own security reasons. Host Name Address (11) The sender of INIT uses this parameter to pass its Host Name (in place of its IP addresses) to its peer. The peer is responsible for resolving the name. Using this parameter might make it more likely for the association to work across a NAT box. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 11 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Host Name / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Host Name: variable length This field contains a host name in "host name syntax" per RFC 1123 Section 2.1 [RFC1123]. The method for resolving the host name is out of scope of SCTP. Stewart Standards Track [Page 29] RFC 4960 Stream Control Transmission Protocol September 2007 Note: At least one null terminator is included in the Host Name string and must be included in the length. Supported Address Types (12) The sender of INIT uses this parameter to list all the address types it can support. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 12 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Type #1 | Address Type #2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ...... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+ Address Type: 16 bits (unsigned integer) This is filled with the type value of the corresponding address TLV (e.g., IPv4 = 5, IPv6 = 6, Host name = 11). 3.3.3. Initiation Acknowledgement (INIT ACK) (2) The INIT ACK chunk is used to acknowledge the initiation of an SCTP association. The parameter part of INIT ACK is formatted similarly to the INIT chunk. It uses two extra variable parameters: The State Cookie and the Unrecognized Parameter: Stewart Standards Track [Page 30] RFC 4960 Stream Control Transmission Protocol September 2007 The format of the INIT ACK chunk is shown below: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 2 | Chunk Flags | Chunk Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Initiate Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertised Receiver Window Credit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of Outbound Streams | Number of Inbound Streams | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Initial TSN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / Optional/Variable-Length Parameters / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Initiate Tag: 32 bits (unsigned integer) The receiver of the INIT ACK records the value of the Initiate Tag parameter. This value MUST be placed into the Verification Tag field of every SCTP packet that the INIT ACK receiver transmits within this association. The Initiate Tag MUST NOT take the value 0. See Section 5.3.1 for more on the selection of the Initiate Tag value. If the value of the Initiate Tag in a received INIT ACK chunk is found to be 0, the receiver MUST destroy the association discarding its TCB. The receiver MAY send an ABORT for debugging purpose. Advertised Receiver Window Credit (a_rwnd): 32 bits (unsigned integer) This value represents the dedicated buffer space, in number of bytes, the sender of the INIT ACK has reserved in association with this window. During the life of the association, this buffer space SHOULD NOT be lessened (i.e., dedicated buffers taken away from this association). Number of Outbound Streams (OS): 16 bits (unsigned integer) Defines the number of outbound streams the sender of this INIT ACK chunk wishes to create in this association. The value of 0 MUST Stewart Standards Track [Page 31] RFC 4960 Stream Control Transmission Protocol September 2007 NOT be used, and the value MUST NOT be greater than the MIS value sent in the INIT chunk. Note: A receiver of an INIT ACK with the OS value set to 0 SHOULD destroy the association discarding its TCB. Number of Inbound Streams (MIS): 16 bits (unsigned integer) Defines the maximum number of streams the sender of this INIT ACK chunk allows the peer end to create in this association. The value 0 MUST NOT be used. Note: There is no negotiation of the actual number of streams but instead the two endpoints will use the min(requested, offered). See Section 5.1.1 for details. Note: A receiver of an INIT ACK with the MIS value set to 0 SHOULD destroy the association discarding its TCB. Initial TSN (I-TSN): 32 bits (unsigned integer) Defines the initial TSN that the INIT ACK sender will use. The valid range is from 0 to 4294967295. This field MAY be set to the value of the Initiate Tag field. Fixed Parameters Status ---------------------------------------------- Initiate Tag Mandatory Advertised Receiver Window Credit Mandatory Number of Outbound Streams Mandatory Number of Inbound Streams Mandatory Initial TSN Mandatory Variable Parameters Status Type Value ------------------------------------------------------------- State Cookie Mandatory 7 IPv4 Address (Note 1) Optional 5 IPv6 Address (Note 1) Optional 6 Unrecognized Parameter Optional 8 Reserved for ECN Capable (Note 2) Optional 32768 (0x8000) Host Name Address (Note 3) Optional 11 Note 1: The INIT ACK chunks can contain any number of IP address parameters that can be IPv4 and/or IPv6 in any combination. Note 2: The ECN Capable field is reserved for future use of Explicit Congestion Notification. Stewart Standards Track [Page 32] RFC 4960 Stream Control Transmission Protocol September 2007 Note 3: The INIT ACK chunks MUST NOT contain more than one Host Name Address parameter. Moreover, the sender of the INIT ACK MUST NOT combine any other address types with the Host Name Address in the INIT ACK. The receiver of the INIT ACK MUST ignore any other address types if the Host Name Address parameter is present. IMPLEMENTATION NOTE: An implementation MUST be prepared to receive an INIT ACK that is quite large (more than 1500 bytes) due to the variable size of the State Cookie AND the variable address list. For example if a responder to the INIT has 1000 IPv4 addresses it wishes to send, it would need at least 8,000 bytes to encode this in the INIT ACK. IMPLEMENTATION NOTE: If an INIT ACK chunk is received with known parameters that are not optional parameters of the INIT ACK chunk, then the receiver SHOULD process the INIT ACK chunk and send back a COOKIE ECHO. The receiver of the INIT ACK chunk MAY bundle an ERROR chunk with the COOKIE ECHO chunk. However, restrictive implementations MAY send back an ABORT chunk in response to the INIT ACK chunk. In combination with the Source Port carried in the SCTP common header, each IP Address parameter in the INIT ACK indicates to the receiver of the INIT ACK a valid transport address supported by the sender of the INIT ACK for the life time of the association being initiated. If the INIT ACK contains at least one IP Address parameter, then the source address of the IP datagram containing the INIT ACK and any additional address(es) provided within the INIT ACK may be used as destinations by the receiver of the INIT ACK. If the INIT ACK does not contain any IP Address parameters, the receiver of the INIT ACK MUST use the source address associated with the received IP datagram as its sole destination address for the association. The State Cookie and Unrecognized Parameters use the Type-Length- Value format as defined in Section 3.2.1 and are described below. The other fields are defined the same as their counterparts in the INIT chunk. 3.3.3.1. Optional or Variable-Length Parameters State Cookie Parameter Type Value: 7 Parameter Length: Variable size, depending on size of Cookie. Stewart Standards Track [Page 33] RFC 4960 Stream Control Transmission Protocol September 2007 Parameter Value: This parameter value MUST contain all the necessary state and parameter information required for the sender of this INIT ACK to create the association, along with a Message Authentication Code (MAC). See Section 5.1.3 for details on State Cookie definition. Unrecognized Parameter: Parameter Type Value: 8 Parameter Length: Variable size. Parameter Value: This parameter is returned to the originator of the INIT chunk when the INIT contains an unrecognized parameter that has a value that indicates it should be reported to the sender. This parameter value field will contain unrecognized parameters copied from the INIT chunk complete with Parameter Type, Length, and Value fields. 3.3.4. Selective Acknowledgement (SACK) (3) This chunk is sent to the peer endpoint to acknowledge received DATA chunks and to inform the peer endpoint of gaps in the received subsequences of DATA chunks as represented by their TSNs. The SACK MUST contain the Cumulative TSN Ack, Advertised Receiver Window Credit (a_rwnd), Number of Gap Ack Blocks, and Number of Duplicate TSNs fields. By definition, the value of the Cumulative TSN Ack parameter is the last TSN received before a break in the sequence of received TSNs occurs; the next TSN value following this one has not yet been received at the endpoint sending the SACK. This parameter therefore acknowledges receipt of all TSNs less than or equal to its value. The handling of a_rwnd by the receiver of the SACK is discussed in detail in Section 6.2.1. The SACK also contains zero or more Gap Ack Blocks. Each Gap Ack Block acknowledges a subsequence of TSNs received following a break in the sequence of received TSNs. By definition, all TSNs acknowledged by Gap Ack Blocks are greater than the value of the Cumulative TSN Ack. Stewart Standards Track [Page 34] RFC 4960 Stream Control Transmission Protocol September 2007 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 3 |Chunk Flags | Chunk Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cumulative TSN Ack | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertised Receiver Window Credit (a_rwnd) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of Gap Ack Blocks = N | Number of Duplicate TSNs = X | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Gap Ack Block #1 Start | Gap Ack Block #1 End | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / \ ... \ / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Gap Ack Block #N Start | Gap Ack Block #N End | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Duplicate TSN 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / \ ... \ / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Duplicate TSN X | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Chunk Flags: 8 bits Set to all '0's on transmit and ignored on receipt. Cumulative TSN Ack: 32 bits (unsigned integer) This parameter contains the TSN of the last DATA chunk received in sequence before a gap. In the case where no DATA chunk has been received, this value is set to the peer's Initial TSN minus one. Advertised Receiver Window Credit (a_rwnd): 32 bits (unsigned integer) This field indicates the updated receive buffer space in bytes of the sender of this SACK; see Section 6.2.1 for details. Number of Gap Ack Blocks: 16 bits (unsigned integer) Indicates the number of Gap Ack Blocks included in this SACK. Stewart Standards Track [Page 35] RFC 4960 Stream Control Transmission Protocol September 2007 Number of Duplicate TSNs: 16 bit This field contains the number of duplicate TSNs the endpoint has received. Each duplicate TSN is listed following the Gap Ack Block list. Gap Ack Blocks: These fields contain the Gap Ack Blocks. They are repeated for each Gap Ack Block up to the number of Gap Ack Blocks defined in the Number of Gap Ack Blocks field. All DATA chunks with TSNs greater than or equal to (Cumulative TSN Ack + Gap Ack Block Start) and less than or equal to (Cumulative TSN Ack + Gap Ack Block End) of each Gap Ack Block are assumed to have been received correctly. Gap Ack Block Start: 16 bits (unsigned integer) Indicates the Start offset TSN for this Gap Ack Block. To calculate the actual TSN number the Cumulative TSN Ack is added to this offset number. This calculated TSN identifies the first TSN in this Gap Ack Block that has been received. Gap Ack Block End: 16 bits (unsigned integer) Indicates the End offset TSN for this Gap Ack Block. To calculate the actual TSN number, the Cumulative TSN Ack is added to this offset number. This calculated TSN identifies the TSN of the last DATA chunk received in this Gap Ack Block. Stewart Standards Track [Page 36] RFC 4960 Stream Control Transmission Protocol September 2007 For example, assume that the receiver has the following DATA chunks newly arrived at the time when it decides to send a Selective ACK, ---------- | TSN=17 | ---------- | | <- still missing ---------- | TSN=15 | ---------- | TSN=14 | ---------- | | <- still missing ---------- | TSN=12 | ---------- | TSN=11 | ---------- | TSN=10 | ---------- then the parameter part of the SACK MUST be constructed as follows (assuming the new a_rwnd is set to 4660 by the sender): +--------------------------------+ | Cumulative TSN Ack = 12 | +--------------------------------+ | a_rwnd = 4660 | +----------------+---------------+ | num of block=2 | num of dup=0 | +----------------+---------------+ |block #1 strt=2 |block #1 end=3 | +----------------+---------------+ |block #2 strt=5 |block #2 end=5 | +----------------+---------------+ Duplicate TSN: 32 bits (unsigned integer) Indicates the number of times a TSN was received in duplicate since the last SACK was sent. Every time a receiver gets a duplicate TSN (before sending the SACK), it adds it to the list of duplicates. The duplicate count is reinitialized to zero after sending each SACK. For example, if a receiver were to get the TSN 19 three times it would list 19 twice in the outbound SACK. After sending the SACK, if it received yet one more TSN 19 it would list 19 as a duplicate once in the next outgoing SACK. Stewart Standards Track [Page 37] RFC 4960 Stream Control Transmission Protocol September 2007 3.3.5. Heartbeat Request (HEARTBEAT) (4) An endpoint should send this chunk to its peer endpoint to probe the reachability of a particular destination transport address defined in the present association. The parameter field contains the Heartbeat Information, which is a variable-length opaque data structure understood only by the sender. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 4 | Chunk Flags | Heartbeat Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / Heartbeat Information TLV (Variable-Length) / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Chunk Flags: 8 bits Set to 0 on transmit and ignored on receipt. Heartbeat Length: 16 bits (unsigned integer) Set to the size of the chunk in bytes, including the chunk header and the Heartbeat Information field. Heartbeat Information: variable length Defined as a variable-length parameter using the format described in Section 3.2.1, i.e.: Variable Parameters Status Type Value ------------------------------------------------------------- Heartbeat Info Mandatory 1 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Heartbeat Info Type=1 | HB Info Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Sender-Specific Heartbeat Info / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Sender-Specific Heartbeat Info field should normally include information about the sender's current time when this HEARTBEAT Stewart Standards Track [Page 38] RFC 4960 Stream Control Transmission Protocol September 2007 chunk is sent and the destination transport address to which this HEARTBEAT is sent (see Section 8.3). This information is simply reflected back by the receiver in the HEARTBEAT ACK message (see Section 3.3.6). Note also that the HEARTBEAT message is both for reachability checking and for path verification (see Section 5.4). When a HEARTBEAT chunk is being used for path verification purposes, it MUST hold a 64-bit random nonce. 3.3.6. Heartbeat Acknowledgement (HEARTBEAT ACK) (5) An endpoint should send this chunk to its peer endpoint as a response to a HEARTBEAT chunk (see Section 8.3). A HEARTBEAT ACK is always sent to the source IP address of the IP datagram containing the HEARTBEAT chunk to which this ack is responding. The parameter field contains a variable-length opaque data structure. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 5 | Chunk Flags | Heartbeat Ack Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / Heartbeat Information TLV (Variable-Length) / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Chunk Flags: 8 bits Set to 0 on transmit and ignored on receipt. Heartbeat Ack Length: 16 bits (unsigned integer) Set to the size of the chunk in bytes, including the chunk header and the Heartbeat Information field. Heartbeat Information: variable length This field MUST contain the Heartbeat Information parameter of the Heartbeat Request to which this Heartbeat Acknowledgement is responding. Variable Parameters Status Type Value ------------------------------------------------------------- Heartbeat Info Mandatory 1 Stewart Standards Track [Page 39] RFC 4960 Stream Control Transmission Protocol September 2007 3.3.7. Abort Association (ABORT) (6) The ABORT chunk is sent to the peer of an association to close the association. The ABORT chunk may contain Cause Parameters to inform the receiver about the reason of the abort. DATA chunks MUST NOT be bundled with ABORT. Control chunks (except for INIT, INIT ACK, and SHUTDOWN COMPLETE) MAY be bundled with an ABORT, but they MUST be placed before the ABORT in the SCTP packet or they will be ignored by the receiver. If an endpoint receives an ABORT with a format error or no TCB is found, it MUST silently discard it. Moreover, under any circumstances, an endpoint that receives an ABORT MUST NOT respond to that ABORT by sending an ABORT of its own. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 6 |Reserved |T| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / zero or more Error Causes / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Chunk Flags: 8 bits Reserved: 7 bits Set to 0 on transmit and ignored on receipt. T bit: 1 bit The T bit is set to 0 if the sender filled in the Verification Tag expected by the peer. If the Verification Tag is reflected, the T bit MUST be set to 1. Reflecting means that the sent Verification Tag is the same as the received one. Note: Special rules apply to this chunk for verification; please see Section 8.5.1 for details. Length: 16 bits (unsigned integer) Set to the size of the chunk in bytes, including the chunk header and all the Error Cause fields present. See Section 3.3.10 for Error Cause definitions. Stewart Standards Track [Page 40] RFC 4960 Stream Control Transmission Protocol September 2007 3.3.8. Shutdown Association (SHUTDOWN) (7) An endpoint in an association MUST use this chunk to initiate a graceful close of the association with its peer. This chunk has the following format. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 7 | Chunk Flags | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cumulative TSN Ack | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Chunk Flags: 8 bits Set to 0 on transmit and ignored on receipt. Length: 16 bits (unsigned integer) Indicates the length of the parameter. Set to 8. Cumulative TSN Ack: 32 bits (unsigned integer) This parameter contains the TSN of the last chunk received in sequence before any gaps. Note: Since the SHUTDOWN message does not contain Gap Ack Blocks, it cannot be used to acknowledge TSNs received out of order. In a SACK, lack of Gap Ack Blocks that were previously included indicates that the data receiver reneged on the associated DATA chunks. Since SHUTDOWN does not contain Gap Ack Blocks, the receiver of the SHUTDOWN shouldn't interpret the lack of a Gap Ack Block as a renege. (See Section 6.2 for information on reneging.) 3.3.9. Shutdown Acknowledgement (SHUTDOWN ACK) (8) This chunk MUST be used to acknowledge the receipt of the SHUTDOWN chunk at the completion of the shutdown process; see Section 9.2 for details. The SHUTDOWN ACK chunk has no parameters. Stewart Standards Track [Page 41] RFC 4960 Stream Control Transmission Protocol September 2007 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 8 |Chunk Flags | Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Chunk Flags: 8 bits Set to 0 on transmit and ignored on receipt. 3.3.10. Operation Error (ERROR) (9) An endpoint sends this chunk to its peer endpoint to notify it of certain error conditions. It contains one or more error causes. An Operation Error is not considered fatal in and of itself, but may be used with an ABORT chunk to report a fatal condition. It has the following parameters: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 9 | Chunk Flags | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / one or more Error Causes / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Chunk Flags: 8 bits Set to 0 on transmit and ignored on receipt. Length: 16 bits (unsigned integer) Set to the size of the chunk in bytes, including the chunk header and all the Error Cause fields present. Stewart Standards Track [Page 42] RFC 4960 Stream Control Transmission Protocol September 2007 Error causes are defined as variable-length parameters using the format described in Section 3.2.1, that is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code | Cause Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Cause-Specific Information / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Cause Code: 16 bits (unsigned integer) Defines the type of error conditions being reported. Cause Code Value Cause Code --------- ---------------- 1 Invalid Stream Identifier 2 Missing Mandatory Parameter 3 Stale Cookie Error 4 Out of Resource 5 Unresolvable Address 6 Unrecognized Chunk Type 7 Invalid Mandatory Parameter 8 Unrecognized Parameters 9 No User Data 10 Cookie Received While Shutting Down 11 Restart of an Association with New Addresses 12 User Initiated Abort 13 Protocol Violation Cause Length: 16 bits (unsigned integer) Set to the size of the parameter in bytes, including the Cause Code, Cause Length, and Cause-Specific Information fields. Cause-Specific Information: variable length This field carries the details of the error condition. Section 3.3.10.1 - Section 3.3.10.13 define error causes for SCTP. Guidelines for the IETF to define new error cause values are discussed in Section 14.3. Stewart Standards Track [Page 43] RFC 4960 Stream Control Transmission Protocol September 2007 3.3.10.1. Invalid Stream Identifier (1) Cause of error --------------- Invalid Stream Identifier: Indicates endpoint received a DATA chunk sent to a nonexistent stream. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code=1 | Cause Length=8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Stream Identifier | (Reserved) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Stream Identifier: 16 bits (unsigned integer) Contains the Stream Identifier of the DATA chunk received in error. Reserved: 16 bits This field is reserved. It is set to all 0's on transmit and ignored on receipt. 3.3.10.2. Missing Mandatory Parameter (2) Cause of error --------------- Missing Mandatory Parameter: Indicates that one or more mandatory TLV parameters are missing in a received INIT or INIT ACK. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code=2 | Cause Length=8+N*2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of missing params=N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Missing Param Type #1 | Missing Param Type #2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Missing Param Type #N-1 | Missing Param Type #N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Number of Missing params: 32 bits (unsigned integer) This field contains the number of parameters contained in the Cause-Specific Information field. Stewart Standards Track [Page 44] RFC 4960 Stream Control Transmission Protocol September 2007 Missing Param Type: 16 bits (unsigned integer) Each field will contain the missing mandatory parameter number. 3.3.10.3. Stale Cookie Error (3) Cause of error -------------- Stale Cookie Error: Indicates the receipt of a valid State Cookie that has expired. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code=3 | Cause Length=8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Measure of Staleness (usec.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Measure of Staleness: 32 bits (unsigned integer) This field contains the difference, in microseconds, between the current time and the time the State Cookie expired. The sender of this error cause MAY choose to report how long past expiration the State Cookie is by including a non-zero value in the Measure of Staleness field. If the sender does not wish to provide this information, it should set the Measure of Staleness field to the value of zero. 3.3.10.4. Out of Resource (4) Cause of error --------------- Out of Resource: Indicates that the sender is out of resource. This is usually sent in combination with or within an ABORT. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code=4 | Cause Length=4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Stewart Standards Track [Page 45] RFC 4960 Stream Control Transmission Protocol September 2007 3.3.10.5. Unresolvable Address (5) Cause of error --------------- Unresolvable Address: Indicates that the sender is not able to resolve the specified address parameter (e.g., type of address is not supported by the sender). This is usually sent in combination with or within an ABORT. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code=5 | Cause Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Unresolvable Address / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Unresolvable Address: variable length The Unresolvable Address field contains the complete Type, Length, and Value of the address parameter (or Host Name parameter) that contains the unresolvable address or host name. 3.3.10.6. Unrecognized Chunk Type (6) Cause of error --------------- Unrecognized Chunk Type: This error cause is returned to the originator of the chunk if the receiver does not understand the chunk and the upper bits of the 'Chunk Type' are set to 01 or 11. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code=6 | Cause Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Unrecognized Chunk / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Unrecognized Chunk: variable length The Unrecognized Chunk field contains the unrecognized chunk from the SCTP packet complete with Chunk Type, Chunk Flags, and Chunk Length. Stewart Standards Track [Page 46] RFC 4960 Stream Control Transmission Protocol September 2007 3.3.10.7. Invalid Mandatory Parameter (7) Cause of error --------------- Invalid Mandatory Parameter: This error cause is returned to the originator of an INIT or INIT ACK chunk when one of the mandatory parameters is set to an invalid value. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code=7 | Cause Length=4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.3.10.8. Unrecognized Parameters (8) Cause of error --------------- Unrecognized Parameters: This error cause is returned to the originator of the INIT ACK chunk if the receiver does not recognize one or more Optional TLV parameters in the INIT ACK chunk. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code=8 | Cause Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Unrecognized Parameters / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Unrecognized Parameters: variable length The Unrecognized Parameters field contains the unrecognized parameters copied from the INIT ACK chunk complete with TLV. This error cause is normally contained in an ERROR chunk bundled with the COOKIE ECHO chunk when responding to the INIT ACK, when the sender of the COOKIE ECHO chunk wishes to report unrecognized parameters. Stewart Standards Track [Page 47] RFC 4960 Stream Control Transmission Protocol September 2007 3.3.10.9. No User Data (9) Cause of error --------------- No User Data: This error cause is returned to the originator of a DATA chunk if a received DATA chunk has no user data. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code=9 | Cause Length=8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / TSN value / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TSN value: 32 bits (unsigned integer) The TSN value field contains the TSN of the DATA chunk received with no user data field. This cause code is normally returned in an ABORT chunk (see Section 6.2). 3.3.10.10. Cookie Received While Shutting Down (10) Cause of error --------------- Cookie Received While Shutting Down: A COOKIE ECHO was received while the endpoint was in the SHUTDOWN-ACK-SENT state. This error is usually returned in an ERROR chunk bundled with the retransmitted SHUTDOWN ACK. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code=10 | Cause Length=4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Stewart Standards Track [Page 48] RFC 4960 Stream Control Transmission Protocol September 2007 3.3.10.11. Restart of an Association with New Addresses (11) Cause of error -------------- Restart of an association with new addresses: An INIT was received on an existing association. But the INIT added addresses to the association that were previously NOT part of the association. The new addresses are listed in the error code. This ERROR is normally sent as part of an ABORT refusing the INIT (see Section 5.2). 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code=11 | Cause Length=Variable | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / New Address TLVs / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Note: Each New Address TLV is an exact copy of the TLV that was found in the INIT chunk that was new, including the Parameter Type and the Parameter Length. 3.3.10.12. User-Initiated Abort (12) Cause of error -------------- This error cause MAY be included in ABORT chunks that are sent because of an upper-layer request. The upper layer can specify an Upper Layer Abort Reason that is transported by SCTP transparently and MAY be delivered to the upper-layer protocol at the peer. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code=12 | Cause Length=Variable | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Upper Layer Abort Reason / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Stewart Standards Track [Page 49] RFC 4960 Stream Control Transmission Protocol September 2007 3.3.10.13. Protocol Violation (13) Cause of error -------------- This error cause MAY be included in ABORT chunks that are sent because an SCTP endpoint detects a protocol violation of the peer that is not covered by the error causes described in Section 3.3.10.1 to Section 3.3.10.12. An implementation MAY provide additional information specifying what kind of protocol violation has been detected. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code=13 | Cause Length=Variable | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Additional Information / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.3.11. Cookie Echo (COOKIE ECHO) (10) This chunk is used only during the initialization of an association. It is sent by the initiator of an association to its peer to complete the initialization process. This chunk MUST precede any DATA chunk sent within the association, but MAY be bundled with one or more DATA chunks in the same packet. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 10 |Chunk Flags | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Cookie / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Chunk Flags: 8 bit Set to 0 on transmit and ignored on receipt. Length: 16 bits (unsigned integer) Set to the size of the chunk in bytes, including the 4 bytes of the chunk header and the size of the cookie. Stewart Standards Track [Page 50] RFC 4960 Stream Control Transmission Protocol September 2007 Cookie: variable size This field must contain the exact cookie received in the State Cookie parameter from the previous INIT ACK. An implementation SHOULD make the cookie as small as possible to ensure interoperability. Note: A Cookie Echo does NOT contain a State Cookie parameter; instead, the data within the State Cookie's Parameter Value becomes the data within the Cookie Echo's Chunk Value. This allows an implementation to change only the first 2 bytes of the State Cookie parameter to become a COOKIE ECHO chunk. 3.3.12. Cookie Acknowledgement (COOKIE ACK) (11) This chunk is used only during the initialization of an association. It is used to acknowledge the receipt of a COOKIE ECHO chunk. This chunk MUST precede any DATA or SACK chunk sent within the association, but MAY be bundled with one or more DATA chunks or SACK chunk's in the same SCTP packet. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 11 |Chunk Flags | Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Chunk Flags: 8 bits Set to 0 on transmit and ignored on receipt. 3.3.13. Shutdown Complete (SHUTDOWN COMPLETE) (14) This chunk MUST be used to acknowledge the receipt of the SHUTDOWN ACK chunk at the completion of the shutdown process; see Section 9.2 for details. The SHUTDOWN COMPLETE chunk has no parameters. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 14 |Reserved |T| Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Chunk Flags: 8 bits Stewart Standards Track [Page 51] RFC 4960 Stream Control Transmission Protocol September 2007 Reserved: 7 bits Set to 0 on transmit and ignored on receipt. T bit: 1 bit The T bit is set to 0 if the sender filled in the Verification Tag expected by the peer. If the Verification Tag is reflected, the T bit MUST be set to 1. Reflecting means that the sent Verification Tag is the same as the received one. Note: Special rules apply to this chunk for verification, please see Section 8.5.1 for details. 4. SCTP Association State Diagram During the life time of an SCTP association, the SCTP endpoint's association progresses from one state to another in response to various events. The events that may potentially advance an association's state include: o SCTP user primitive calls, e.g., [ASSOCIATE], [SHUTDOWN], [ABORT], o Reception of INIT, COOKIE ECHO, ABORT, SHUTDOWN, etc., control chunks, or o Some timeout events. The state diagram in the figures below illustrates state changes, together with the causing events and resulting actions. Note that some of the error conditions are not shown in the state diagram. Full descriptions of all special cases are found in the text. Note: Chunk names are given in all capital letters, while parameter names have the first letter capitalized, e.g., COOKIE ECHO chunk type vs. State Cookie parameter. If more than one event/message can occur that causes a state transition, it is labeled (A), (B), etc. Stewart Standards Track [Page 52] RFC 4960 Stream Control Transmission Protocol September 2007 ----- -------- (from any state) / \ / rcv ABORT [ABORT] rcv INIT | | | ---------- or ---------- --------------- | v v delete TCB snd ABORT generate Cookie \ +---------+ delete TCB snd INIT ACK ---| CLOSED | +---------+ / \ [ASSOCIATE] / \ --------------- | | create TCB | | snd INIT | | strt init timer rcv valid | | COOKIE ECHO | v (1) ---------------- | +------------+ create TCB | | COOKIE-WAIT| (2) snd COOKIE ACK | +------------+ | | | | rcv INIT ACK | | ----------------- | | snd COOKIE ECHO | | stop init timer | | strt cookie timer | v | +--------------+ | | COOKIE-ECHOED| (3) | +--------------+ | | | | rcv COOKIE ACK | | ----------------- | | stop cookie timer v v +---------------+ | ESTABLISHED | +---------------+ Stewart Standards Track [Page 53] RFC 4960 Stream Control Transmission Protocol September 2007 (from the ESTABLISHED state only) | | /--------+--------\ [SHUTDOWN] / \ -------------------| | check outstanding | | DATA chunks | | v | +---------+ | |SHUTDOWN-| | rcv SHUTDOWN |PENDING | |------------------ +---------+ | check outstanding | | DATA chunks No more outstanding | | ---------------------| | snd SHUTDOWN | | strt shutdown timer | | v v +---------+ +-----------+ (4) |SHUTDOWN-| | SHUTDOWN- | (5,6) |SENT | | RECEIVED | +---------+ +-----------+ | \ | (A) rcv SHUTDOWN ACK | \ | ----------------------| \ | stop shutdown timer | \rcv:SHUTDOWN | send SHUTDOWN COMPLETE| \ (B) | delete TCB | \ | | \ | No more outstanding | \ |----------------- | \ | send SHUTDOWN ACK (B)rcv SHUTDOWN | \ | strt shutdown timer ----------------------| \ | send SHUTDOWN ACK | \ | start shutdown timer | \ | move to SHUTDOWN- | \ | ACK-SENT | | | | v | | +-----------+ | | SHUTDOWN- | (7) | | ACK-SENT | | +----------+- | | (C)rcv SHUTDOWN COMPLETE | |----------------- | | stop shutdown timer | | delete TCB | | Stewart Standards Track [Page 54] RFC 4960 Stream Control Transmission Protocol September 2007 | | (D)rcv SHUTDOWN ACK | |-------------- | | stop shutdown timer | | send SHUTDOWN COMPLETE | | delete TCB | | \ +---------+ / \-->| CLOSED |<--/ +---------+ Figure 3: State Transition Diagram of SCTP Notes: 1) If the State Cookie in the received COOKIE ECHO is invalid (i.e., failed to pass the integrity check), the receiver MUST silently discard the packet. Or, if the received State Cookie is expired (see Section 5.1.5), the receiver MUST send back an ERROR chunk. In either case, the receiver stays in the CLOSED state. 2) If the T1-init timer expires, the endpoint MUST retransmit INIT and restart the T1-init timer without changing state. This MUST be repeated up to 'Max.Init.Retransmits' times. After that, the endpoint MUST abort the initialization process and report the error to the SCTP user. 3) If the T1-cookie timer expires, the endpoint MUST retransmit COOKIE ECHO and restart the T1-cookie timer without changing state. This MUST be repeated up to 'Max.Init.Retransmits' times. After that, the endpoint MUST abort the initialization process and report the error to the SCTP user. 4) In the SHUTDOWN-SENT state, the endpoint MUST acknowledge any received DATA chunks without delay. 5) In the SHUTDOWN-RECEIVED state, the endpoint MUST NOT accept any new send requests from its SCTP user. 6) In the SHUTDOWN-RECEIVED state, the endpoint MUST transmit or retransmit data and leave this state when all data in queue is transmitted. 7) In the SHUTDOWN-ACK-SENT state, the endpoint MUST NOT accept any new send requests from its SCTP user. The CLOSED state is used to indicate that an association is not created (i.e., doesn't exist). Stewart Standards Track [Page 55] RFC 4960 Stream Control Transmission Protocol September 2007 5. Association Initialization Before the first data transmission can take place from one SCTP endpoint ("A") to another SCTP endpoint ("Z"), the two endpoints must complete an initialization process in order to set up an SCTP association between them. The SCTP user at an endpoint should use the ASSOCIATE primitive to initialize an SCTP association to another SCTP endpoint. IMPLEMENTATION NOTE: From an SCTP user's point of view, an association may be implicitly opened, without an ASSOCIATE primitive (see Section 10.1 B) being invoked, by the initiating endpoint's sending of the first user data to the destination endpoint. The initiating SCTP will assume default values for all mandatory and optional parameters for the INIT/INIT ACK. Once the association is established, unidirectional streams are open for data transfer on both ends (see Section 5.1.1). 5.1. Normal Establishment of an Association The initialization process consists of the following steps (assuming that SCTP endpoint "A" tries to set up an association with SCTP endpoint "Z" and "Z" accepts the new association): A) "A" first sends an INIT chunk to "Z". In the INIT, "A" must provide its Verification Tag (Tag_A) in the Initiate Tag field. Tag_A SHOULD be a random number in the range of 1 to 4294967295 (see Section 5.3.1 for Tag value selection). After sending the INIT, "A" starts the T1-init timer and enters the COOKIE-WAIT state. B) "Z" shall respond immediately with an INIT ACK chunk. The destination IP address of the INIT ACK MUST be set to the source IP address of the INIT to which this INIT ACK is responding. In the response, besides filling in other parameters, "Z" must set the Verification Tag field to Tag_A, and also provide its own Verification Tag (Tag_Z) in the Initiate Tag field. Moreover, "Z" MUST generate and send along with the INIT ACK a State Cookie. See Section 5.1.3 for State Cookie generation. Note: After sending out INIT ACK with the State Cookie parameter, "Z" MUST NOT allocate any resources or keep any states for the new association. Otherwise, "Z" will be vulnerable to resource attacks. Stewart Standards Track [Page 56] RFC 4960 Stream Control Transmission Protocol September 2007 C) Upon reception of the INIT ACK from "Z", "A" shall stop the T1- init timer and leave the COOKIE-WAIT state. "A" shall then send the State Cookie received in the INIT ACK chunk in a COOKIE ECHO chunk, start the T1-cookie timer, and enter the COOKIE-ECHOED state. Note: The COOKIE ECHO chunk can be bundled with any pending outbound DATA chunks, but it MUST be the first chunk in the packet and until the COOKIE ACK is returned the sender MUST NOT send any other packets to the peer. D) Upon reception of the COOKIE ECHO chunk, endpoint "Z" will reply with a COOKIE ACK chunk after building a TCB and moving to the ESTABLISHED state. A COOKIE ACK chunk may be bundled with any pending DATA chunks (and/or SACK chunks), but the COOKIE ACK chunk MUST be the first chunk in the packet. IMPLEMENTATION NOTE: An implementation may choose to send the Communication Up notification to the SCTP user upon reception of a valid COOKIE ECHO chunk. E) Upon reception of the COOKIE ACK, endpoint "A" will move from the COOKIE-ECHOED state to the ESTABLISHED state, stopping the T1- cookie timer. It may also notify its ULP about the successful establishment of the association with a Communication Up notification (see Section 10). An INIT or INIT ACK chunk MUST NOT be bundled with any other ch