Stream Control Transmission Protocol

IPv6 uses Stream Control Transmission Protocol (SCTP) as the transport layer protocol. SCTP provides reliable transport service, as well as sequencing and acknowledging functions as provided by TCP.

SCTP was built to overcome the limitations of TCP which requires a strict order of transmission that can cause head-of-line blocking and eventually delay due to the reassembled of out-of-order segments and retransmission of loss segments. TCP sends a stream of bytes, whereas SCTP sends several independent streams of messages that are sequenced and delivered independently. SCTP uses a selective acknowledgement (SACK) mechanism to recover error SCTP segments.

Another main benefit of SCTP is the support for multi-homing, which can provide transparent failover upon network failures. Multi-homed nodes have multiple NICs and can be reached via several IP addresses as well as a variety of paths. During SCTP setup, a multi-homed client informs the server about all its addresses in the INIT chunk. The client needs to know only a single address for the server (the server provides all its addresses to the client in the INIT-ACK). SCTP monitors all paths between the hosts with a heartbeat function and identifies one path as the primary. Secondary paths are used for retransmission or when the primary path fails.

SCTP also provides greater security than TCP by using a cookie function for each session. Below describes the steps when Host1 establishes an SCTP session with Host2:
i) Host1 sends an initialization request to Host2. Host1 waits for a message from Host2.
ii) Host2 receives the request. Host2 generates an encrypted key and a message authentication code (indicates the creator of the message – Host2), and includes these information into a cookie message. Host2 sends the cookie message to Host1.
iii) Host1 receives the cookie message. Host1 replies to Host2 with a cookie echo message. Host1 waits for a message from Host2.
iv) Host2 receives the cookie echo message. Host2 examines the message to ensure that the message authentication code indicates Host2 was the creator of the cookie. Host2 sends a cookie acknowledgment to Host1. Host2 initiates the SCTP session. Host2 is now ready to accept and send data.
v) Host1 receives the cookie acknowledgment. Host1 is now ready to accept and send data.

Note: Even though SCTP looks promising, it is rarely used in real-life environments due to:
 It was designed by the wrong IETF working group – SIGTRAN, which was focused on transport of PSTN signaling over IP networks.
 It was not properly promoted. The SIGTRAN working group solved their problems and moved on.
 Limited support for it in the networking equipments, eg: access lists, stateful inspection, etc.
 It is not shipped with modern operating systems by default, which is a major stopper for widespread deployment. Some installation and integration works are needed to support it.
 The biggest stopper to SCTP adoption is the lack of Session layer in TCP/IP and the legacy Berkeley Sockets API. The SCTP protocol must be specified in the socket() function call in order to use SCTP with the Berkeley Sockets API, which means that every application that would like to benefit from SCTP support must be changed, recompiled, and tested. It is impossible to simply add SCTP support into the operating systems to provide better performance for existing applications.