How to Analyze Network Protocols, Learn More >>

Being able to support more than 300 protocols in the latest version, Capsa Network Sniffer make it easy to analyze protocols in network and understand what is happening.

Recommend Network Analysis Software >>

RFC 2960

The Stream Control Transmission Protocol (SCTP) is designed to transport PSTN signalling messages over IP networks, but is capable of broader applications. SCTP is an application-level datagram transfer protocol operating on top of an unreliable datagram service such as UDP. It offers the following services:

  • Acknowledged error-free non-duplicated transfer of user data.
  • Application-level segmentation to conform to discovered MTU size.
  • Sequenced delivery of user datagrams within multiple streams, with an option for order-of-arrival delivery of individual datagrams.
  • Optional multiplexing of user datagrams into SCTP datagrams, subject to MTU size restrictions.
  • Enhanced reliability through support of multi-homing at either or both ends of the association.

The design of SCTP includes appropriate congestion avoidance behaviour and resistance to flooding and masquerade attacks. The SCTP datagram is comprised of a common header and chunks. The chunks contain either control information or user data.

The following is the format of the SCTP header.

2 bytes 2 bytes
Source Port Number Destination Port Number
Verification Tag
Adler 32 Checksum

Source Port Number
This is the SCTP sender's port number. It can be used by the receiver, in combination with the source IP Address, to identify the association to which this datagram belongs.

Destination Port Number
This is the SCTP port number to which this datagram is destined. The receiving host will use this port number to de-multiplex the SCTP datagram to the correct receiving endpoint/application.

Verification Tag
The receiver of this 32 bit datagram uses the Verification tag to identify the association. 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.

For datagrams carrying the INIT chunk, the transmitter sets the Verification tag to all 0's. If the receiver receives a datagram with an all-zeros Verification tag field, it checks the Chunk ID immediately following the common header. If the chunk type is not INIT or SHUTDOWN ACK, the receiver drops the datagram. For datagrams carrying the SHUTDOWN-ACK chunk, the transmitter sets the Verification tag to the Initiate tag received from the peer endpoint during the association initialization, if known. Otherwise the Verification tag is set to all 0's.

Adler 32 Checksum
This field contains an Adler-32 checksum on this SCTP datagram.

Chunk Field Descriptions

The following is the field format for the chunks transmitted in the SCTP datagram. Each chunk has a chunk ID field, a chunk specific Flag field, a Length field and a Value field.

1 byte 1 byte 2 bytes
Chunk ID Chunk Flags Chunk Length
Chunk Value (variable)

Chunk ID
The type of information contained in the chunk value field. The values of the chunk ID are defined as follows:

ID ValueChunk Type
00000000 Payload Data (DATA)
00000001 Initiation (INIT)
00000010 Initiation Acknowledgment (INIT ACK)
00000011 Selective Acknowledgment (SACK)
00000100 Heartbeat Request (HEARTBEAT)
00000101 Heartbeat Acknowledgment (HEARTBEAT ACK)
00000110 Abort (ABORT)
00000111 Shutdown (SHUTDOWN)
00001000 Shutdown Acknowledgment (SHUTDOWN ACK)
00001001 Operation Error (ERROR)
00001010 State Cookie (COOKIE)
00001011 Cookie Acknowledgment (COOKIE ACK)
00001100 Reserved for Explicit Congestion Notification Echo (ECNE)
00001101 Reserved for Congestion Window Reduced (CWR)
00001110 to11111101 reserved by IETF
11111110 Vendor-specific Chunk Extensions
11111111 IETF-defined Chunk Extensions

Chunk Flags
The type of chunk flag as defined in the chunk ID defines whether these bits will be used. Their value is generally 0 unless otherwise specified.

Chunk Length
The size of the chunk in octets including the Chunk ID, Flags, Length and Value fields.

Chunk Value
This field contains the actual information to be transferred in the chunk. This is dependent on the chunk ID.

Chunk Types

Initiation (INIT)
This chunk is used to initiate a SCTP association between two endpoints. The INIT chunk contains the following parameters. Unless otherwise noted, each parameter is only be included once in the INIT chunk.

Fixed Parameters Status
Initiate Tag Mandatory
Receiver Window Credit Mandatory
Number of Outbound Streams Mandatory
Number of Inbound Streams Mandatory
Initial TSN
Variable Parameters Status
IPv4 Address/Port Optional
IPv6 Address/Port Optional
Cookie Preservative Optional
Reserved For ECN Capable Optional
Host Name Address Optional
Supported Address Types Optional

Initiate Acknowledgement (INIT ACK)
The INIT ACK chunk is used to acknowledge the initiation of a SCTP association. The parameter part of INIT ACK is formatted similarly to the INIT chunk. It uses two extra variable parameters: The Responder Cookie and the Unrecognized Parameter.

Selective Acknowledgement (SACK)
This chunk is sent to the remote endpoint to acknowledge received Data chunks and to inform the remote endpoint of gaps in the received subsequences of Data chunks as represented by their TSNs.

The selective acknowledgement chunk contains the highest consecutive TSN ACK and Rcv Window Credit (rwnd) parameters. By definition, the value of the highest consecutive TSN ACK parameter is the last TSN received at the time the Selective ACK is sent, before a break in the sequence of received TSNs occurs; the next TSN value following this one has not yet been received at the reporting end. This parameter therefore acknowledges receipt of all TSNs up to and including the value given.

The Selective ACK also contains zero or more fragment reports. Each fragment report acknowledges a sub-sequence of TSNs received following a break in the sequence of received TSNs. By definition, all TSNs acknowledged by fragment reports are higher than the value of the Highest Consecutive TSN ACK.

Heartbeat Request (HEARTBEAT)
An endpoint should send this chunk to its peer endpoint of the current association to probe the reachability of a particular destination transport address defined in the present association. The parameter fields contain the time values.

Heartbeat Acknowledgement (HEARTBEAT ACK)
An endpoint should send this chunk to its peer endpoint as a response to a Heartbeat Request. The parameter field contains the time values.

Abort Association (ABORT)
The Abort Association chunk is sent to the peer of an association to terminate the association. The Abort chunk may contain cause parameters to inform the receiver the reason for the abort. Data chunks are not bundled with the abort, control chunks may be bundled with an abort, but must be placed before the abort in the SCTP datagram or they will be ignored.

An endpoint in an association uses this chunk to initiate a graceful termination of the association with its peer.

Shutdown Acknowledgement (SHUTDOWN ACK)
This chunk is used to acknowledge the receipt of the SHUTDOWN chunk at the completion of the shutdown process. The SHUTDOWN ACK chunk has no parameters.

Operation Error (ERROR)
This chunk is sent to the other endpoint in the association to notify certain error conditions. It contains one or more error causes.

State Cookie (COOKIE)
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 precedes any Data chunk sent within the association, but may be bundled with one or more Data chunks in the same datagram.

Cookie Acknowledgement (COOKIE ACK)
This chunk is used only during the initialization of an association. It is used to acknowledge the receipt of a COOKIE chunk. This chunk precedes any Data chunk sent within the association, but may be bundled with one or more Data chunks in the same SCTP datagram.

Payload Data (DATA)
This contains the user data.

Vendor Specific Chunk Extensions
This chunk type is available to allow vendors to support their own extended data formats not defined by the IETF. It must not affect the operation of SCTP. Endpoints not equipped to interpret the vendor-specific chunk sent by a remote endpoint must ignore it. Endpoints that do not receive desired vendor specific information should make an attempt to operate without it, although they may do so (and report they are doing so) in a degraded mode.

Vulnerabilities for this protocol (from CVE)

CVE ID Protocol Source Port Targetport

TCP/IP Protocols: