| RFC 9260 | Stream Control Transmission Protocol | June 2022 |
| Stewart, et al. | Standards Track | [Page] |
This document describes the Stream Control Transmission Protocol (SCTP) and obsoletes RFC 4960. It incorporates the specification of the chunk flags registry from RFC 6096 and thespecification of the I bit of DATA chunks from RFC 7053.Therefore, RFCs 6096 and 7053 are also obsoleted by this document.In addition, RFCs 4460 and 8540, which describe errata for SCTP, are obsoleted by this document.¶
SCTP was originally designed to transport Public Switched TelephoneNetwork (PSTN) signaling messages over IP networks.It is also suited to be used for other applications, for example, WebRTC.¶
SCTP is a reliable transport protocol operating on top of aconnectionless 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 Maximum Transmission Unit (PMTU) size,¶
sequenced delivery of user messages within multiple streams, withan 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-homingat either or both ends of an association.¶
The design of SCTP includes appropriate congestion avoidance behaviorand resistance to flooding and masquerade attacks.¶
This is an Internet Standards Track document.¶
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.¶
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained athttps://www.rfc-editor.org/info/rfc9260.¶
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.¶
This section explains the reasoning behind the development of theStream Control Transmission Protocol (SCTP), the services it offers,and the basic concepts needed to understand the detailed descriptionof the protocol.¶
This document obsoletes[RFC4960].In addition to that, it incorporates the specification of the chunk flagsregistry from[RFC6096] and the specification of the I bit ofDATA chunks from[RFC7053].Therefore,[RFC6096] and[RFC7053] are alsoobsoleted by this document.¶
TCP[RFC0793] has performed immense service as the primarymeans of reliable data transfer in IP networks.However, an increasing number of recent applications have found TCP toolimiting and have incorporated their own reliable data transfer protocolon top of UDP[RFC0768].The limitations that users have wished to bypass include the following:¶
TCP provides both reliable data transfer and strictorder-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 causesunnecessary delay.¶
The stream-oriented nature of TCP is often an inconvenience.Applications add their own record marking to delineate theirmessages and make explicit use of the push facility toensure that a complete message is transferred in a reasonabletime.¶
The limited scope of TCP sockets complicates the task of providinghighly available data transfer capability using multi-homed hosts.¶
TCP is relatively vulnerable to denial-of-service attacks, suchas SYN attacks.¶
Transport of PSTN signaling across the IP network is an applicationfor which all of these limitations of TCP are relevant.While this application directly motivated the development of SCTP, otherapplications might find SCTP a good match to their requirements.One example of this is the use of data channels in the WebRTC infrastructure.¶
SCTP is viewed as a layer between the SCTP user application ("SCTPuser" for short) and a connectionless packet network service, such asIP.The remainder of this document assumes SCTP runs on top of IP.The basic service offered by SCTP is the reliable transfer of usermessages between peer SCTP users.It performs this service within the context of an association betweentwo SCTP endpoints.Section 11 of this document sketches the API that existsat the boundary between SCTP and the SCTP upper layers.¶
SCTP is connection oriented in nature, but the SCTP association is abroader 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 oftransport addresses (i.e., multiple IP addresses in combination with an SCTPport) through which that endpoint can be reached and from which it willoriginate SCTP packets.The association spans transfers over all of the possible source/destinationcombinations that can 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
In addition to encapsulating SCTP packets in IPv4 or IPv6, it is also possibleto encapsulate SCTP packets in UDP as specified in[RFC6951]or encapsulate them in DTLS as specified in[RFC8261].¶
Some of the language used to describe SCTP has been introduced in theprevious sections. This section provides a consolidated list of thekey terms and their definitions.¶
A unidirectional logical channel established from one toanother associated SCTP endpoint, within which all user messagesare delivered in sequence, except for those submitted to theunordered delivery service.¶
Note: The relationship between stream numbers in opposite directionsis strictly a matter of how the applications use them. It is theresponsibility of the SCTP user to create and manage thesecorrelations if they are so desired.¶
The SCTP transport service can be decomposed into a number of functions.These are depicted inFigure 2 and explainedin the remainder of this section.¶
SCTP User Application----------------------------------------------------- _____________ ____________________| | | Sequenced Delivery || Association | | within Streams || | |____________________|| Startup || | ____________________________| and | | User Data Fragmentation || | |____________________________|| Takedown || | ____________________________| | | Acknowledgement || | | and || | | Congestion Avoidance || | |____________________________|| || | ____________________________| | | Chunk Bundling || | |____________________________|| || | ________________________________| | | Packet Validation || | |________________________________|| || | ________________________________| | | Path Management ||_____________| |________________________________|
An association is initiated by a request from the SCTP user (see thedescription of the ASSOCIATE (or SEND) primitive inSection 11).¶
A cookie mechanism, similar to one described by Karn and Simpson in[RFC2522], is employed during the initialization to provideprotection against synchronization attacks.The cookie mechanism uses a four-way handshake, the last two legs of whichare allowed to carry user data for fast setup.The startup sequence is described inSection 5of this document.¶
SCTP provides for graceful close (i.e., shutdown) of an activeassociation on request from the SCTP user.See the description of the SHUTDOWN primitive inSection 11.SCTP also allows ungraceful close (i.e., abort), either on request from theuser (ABORT primitive) or as a result of an error condition detected withinthe SCTP layer.Section 9 describes both the graceful and theungraceful close procedures.¶
SCTP does not support a half-open state (like TCP) wherein one sidecontinues sending data while the other end is closed.When either endpoint performs a shutdown, the association on each peer willstop accepting new data from its user and only deliver data in queue atthe time of the graceful close (seeSection 9).¶
The term "stream" is used in SCTP to refer to a sequence of usermessages that are to be delivered to the upper-layer protocol inorder with respect to other messages within the same stream.This is in contrast to its usage in TCP, where it refers to a sequence ofbytes (in this document, a byte is assumed to be 8 bits).¶
At association startup time, the SCTP user can specify the number ofstreams to be supported by the association.This number is negotiated with the remote end(seeSection 5.1.1).User messages are associated with stream numbers (SEND, RECEIVE primitives;Section 11).Internally, SCTP assigns a Stream Sequence Number to each message passed toit by the SCTP user.On the receiving side, SCTP ensures that messages are delivered to the SCTPuser in sequence within a given stream.However, while one stream might be blocked waiting for the next in-sequenceuser message, delivery from other streams might proceed.¶
SCTP provides a mechanism for bypassing the sequenced deliveryservice.User messages sent using this mechanism are delivered to the SCTP user assoon as they are received.¶
When needed, SCTP fragments user messages to ensure that the size of the SCTPpacket passed to the lower layer does not exceed the PMTU.Once a user message has been fragmented, this fragmentation cannot be changedanymore.On receipt, fragments are reassembled into complete messages beforebeing passed to the SCTP user.¶
SCTP assigns a Transmission Sequence Number (TSN) to each user datafragment or unfragmented message.The TSN is independent of any Stream Sequence Number assigned at thestream level.The receiving end acknowledges all TSNs received, even if there are gaps in thesequence.If a user data fragment or unfragmented message needs to be retransmitted,the TSN assigned to it is used.In this way, reliable delivery is kept functionally separate from sequencedstream delivery.¶
The acknowledgement and congestion avoidance function is responsiblefor packet retransmission when timely acknowledgement has not beenreceived.Packet retransmission is conditioned by congestion avoidance proceduressimilar to those used for TCP. See Sections6 and7 for detailed descriptions of theprotocol procedures associated with this function.¶
As described inSection 3, the SCTP packetas delivered to the lower layer consists of a common header followed by oneor more chunks.Each chunk contains either user data or SCTP control information.An SCTP implementation supporting bundling on the sender side mightdelay the sending of user messages to allow the corresponding DATAchunks to be bundled.¶
The SCTP user has the option to request that an SCTP implementation does notdelay the sending of a user message just for this purpose.However, even if the SCTP user has chosen this option, the SCTP implementationmight delay the sending due to other reasons (for example, due to congestioncontrol or flow control) and might also bundle multiple DATA chunks, ifpossible.¶
A mandatory Verification Tag field and a 32-bit checksum field (seeAppendix A for a description of the 32-bit Cyclic Redundancy Check (CRC32c) checksum)are included in the SCTP common header.The Verification Tag value is chosen by each end of the association duringassociation startup.Packets received without the expected Verification Tag value are discarded,as a protection against blind masquerade attacks and against stale SCTPpackets from a previous association.The CRC32c checksum is set by the sender of each SCTP packet toprovide additional protection against data corruption in the network.The receiver of an SCTP packet with an invalid CRC32c checksum silentlydiscards the packet.¶
The sending SCTP user is able to manipulate the set of transportaddresses used as destinations for SCTP packets through theprimitives described inSection 11.The SCTP path management function monitors reachability through heartbeatswhen other packet traffic is inadequate to provide this information and advisesthe SCTP user when reachability of any transport address of the peer endpointchanges.The path management function chooses the destination transport addressfor each outgoing SCTP packet based on the SCTP user's instructions and thecurrently perceived reachability status of the eligible destination set.The path management function is also responsible for reporting the eligibleset of local transport addresses to the peer endpoint during association startupand for reporting the transport addresses returned from the peer endpoint to theSCTP user.¶
At association startup, a primary path is defined for each SCTPendpoint and is used to send SCTP packets normally.¶
On the receiving end, the path management is responsible forverifying the existence of a valid SCTP association to which theinbound SCTP packet belongs before passing it for further processing.¶
Note: Path Management and Packet Validation are done at the sametime; although described separately above, in reality, they cannotbe performed as separate items.¶
It is essential to remember that the actual Transmission SequenceNumber space is finite, though very large.This space ranges from 0 to 232 - 1.Since the space is finite, all arithmetic dealing with Transmission SequenceNumbersMUST be performed modulo 232.This unsigned arithmetic preserves the relationship of sequence numbers asthey cycle from 232 - 1 to 0 again.There are some subtleties to computer modulo arithmetic, so great care has tobe taken in programming the comparison of such values.When referring to TSNs, the symbol "<=" means"less than or equal" (modulo 232).¶
Comparisons and arithmetic on TSNs in this documentSHOULD use SerialNumber Arithmetic, as defined in[RFC1982],where SERIAL_BITS = 32.¶
An endpointSHOULD NOT transmit a DATA chunk with a TSN that is morethan 231 - 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 232 - 1.That is, the next TSN a DATA chunkMUST use after transmitting TSN =232 - 1 is TSN = 0.¶
Any arithmetic done on Stream Sequence NumbersSHOULD use SerialNumber Arithmetic, as defined in[RFC1982], where SERIAL_BITS = 16.All other arithmetic and comparisons in this document use normalarithmetic.¶
SCTP was originally defined in[RFC4960], which this documentobsoletes.Readers interested in the details of the various changes that this documentincorporates are asked to consult[RFC8540].¶
In addition to these and further editorial changes, the following changeshave been incorporated in this document:¶
Update references.¶
Improve the language related to requirements levels.¶
Allow the ASSOCIATE primitive to take multiple remote addresses; also refer to the socket API specification.¶
Refer to the Packetization Layer Path MTU Discovery (PLPMTUD) specification for path MTU discovery.¶
Move the description of ICMP handling from the Appendix to the main text.¶
Remove the Appendix describing Explicit Congestion Notification (ECN) handling from the document.¶
Describe the packet size handling more precisely by introducing PMTU, PMDCS, and AMDCS.¶
Add the definition of control chunk.¶
Improve the description of the handling of INIT and INIT ACK chunks with invalid mandatory parameters.¶
Allow using L > 1 for Appropriate Byte Counting (ABC) during slow start.¶
Explicitly describe the reinitialization of the congestion controller on route changes.¶
Improve the terminology to make it clear that this specification does not describe a full mesh architecture.¶
Improve the description of sequence number generation (Transmission Sequence Number and Stream Sequence Number).¶
Improve the description of reneging.¶
Don't require the change of the Cumulative TSN Ack anymore for increasing the congestion window. This improves the consistency with the handling in congestion avoidance.¶
Improve the description of the State Cookie.¶
Fix the API for retrieving messages in case of association failures.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and"OPTIONAL" in this document are to be interpreted as described in BCP 14[RFC2119][RFC8174] when,and only when, they appear in all capitals, as shown here.¶
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 |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
INIT, INIT ACK, and SHUTDOWN COMPLETE chunksMUST NOT be bundledwith any other chunk into an SCTP packet.All other chunksMAY be bundled to form an SCTP packet that does not exceedthe PMTU.SeeSection 6.10 for more details on chunk bundling.¶
If a user data message does not fit into one SCTP packet, it can befragmented into multiple chunks using the procedure defined inSection 6.9.¶
All integer fields in an SCTP packetMUST be transmitted in networkbyte order, unless otherwise stated.¶
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 |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
The receiver of an SCTP packet uses the Verification Tag to validatethe sender of this packet.On transmit, the value of the Verification TagMUST be set to the value ofthe Initiate Tag received from the peer endpoint during the associationinitialization, with the following exceptions:¶
The figure below illustrates the field format for the chunks to betransmitted in the SCTP packet.Each chunk is formatted with a Chunk Type field, a Chunk Flags field,a Chunk Length field, and a Chunk 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 /\ \+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
This field identifies the type of information contained in the Chunk Valuefield. 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 defined in this document are 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) |
| 12 | Reserved for Explicit Congestion Notification Echo (ECNE) |
| 13 | Reserved for Congestion Window Reduced (CWR) |
| 14 | Shutdown Complete (SHUTDOWN COMPLETE) |
| 15 to 62 | Unassigned |
| 63 | Reserved for IETF-defined Chunk Extensions |
| 64 to 126 | Unassigned |
| 127 | Reserved for IETF-defined Chunk Extensions |
| 128 to 190 | Unassigned |
| 191 | Reserved for IETF-defined Chunk Extensions |
| 192 to 254 | Unassigned |
| 255 | Reserved for IETF-defined Chunk Extensions |
Note: The ECNE and CWR chunk types are reserved for future use of ExplicitCongestion Notification (ECN).¶
Chunk Types are encoded such that the highest-order 2 bits specify the actionthat is taken if the processing endpoint does not recognize the Chunk Type.¶
| 00 | Stop processing this SCTP packet and discard the unrecognized chunk and all further chunks.¶ |
| 01 | Stop processing this SCTP packet, discard the unrecognized chunk and all further chunks, and report the unrecognized chunk in an ERROR chunk using the 'Unrecognized Chunk Type' error cause.¶ |
| 10 | Skip this chunk and continue processing.¶ |
| 11 | Skip this chunk and continue processing, but report it in an ERROR chunk using the 'Unrecognized Chunk Type' error cause.¶ |
The usage of these bits depends on the Chunk Type, as given by the Chunk Typefield.Unless otherwise specified, they are set to 0 on transmit and are ignoredon receipt.¶
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 beset to 4.The Chunk Length field does not count any chunk padding.However, it does include any padding of variable-length parameters other thanthe last parameter in the chunk.¶
Note: A robust implementation is expected to accept the chunk whether or notthe final padding has been included in the Chunk Length.¶
The Chunk Value field contains the actual information to be transferred in thechunk.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)MUSTbe a multiple of 4 bytes.If the length of the chunk is not a multiple of 4 bytes, the senderMUST padthe chunk with all zero bytes, and this padding is not included in theChunk Length field.The senderMUST NOT pad with more than 3 bytes.The receiverMUST ignore the padding bytes.¶
SCTP-defined chunks are described in detail inSection 3.3.The guidelines for IETF-defined chunk extensions can be found inSection 15.1 of this document.¶
Chunk values of SCTP control chunks consist of a chunk-type-specificheader of required fields, followed by zero or more parameters.The optional and variable-length parameters contained in a chunk aredefined 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 /\ \+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
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 arereserved for use by IETF.¶
The Parameter Value field contains the actual information to be transferred inthe parameter.¶
The total length of a parameter (including Parameter Type, Parameter Length,and Parameter 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 theparameter at the end (i.e., after the Parameter Value field) with all zerobytes.The length of the padding is not included in the Parameter Length field.A senderMUST NOT pad with more than 3 bytes.The receiverMUST ignore the padding bytes.¶
The Parameter Types are encoded such that the highest-order 2 bits specify theaction that is taken if the processing endpoint does not recognize theParameter Type.¶
| 00 | Stop processing this parameter and 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, as described inSection 3.2.2.¶ |
| 10 | Skip this parameter and continue processing.¶ |
| 11 | Skip this parameter and continue processing, but report the unrecognized parameter, as described inSection 3.2.2.¶ |
Please note that, when an INIT or INIT ACK chunk is received, in allfour cases, an INIT ACK or COOKIE ECHO chunk is sent in response, respectively.In the 00 or 01 case, the processing of the parameters after the unknownparameter 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 inSection 15.3.Parameter typesMUST be unique across all chunks.For example, the parameter type '5' is used to represent an IPv4 address(seeSection 3.3.2.1.1).The value '5' then is reserved across all chunks to represent an IPv4 addressandMUST NOT be reused with a different meaning in any other chunk.¶
If the receiver of an INIT chunk detects unrecognized parameters andhas to report them according toSection 3.2.1,itMUST put the "Unrecognized Parameter" parameter(s) in the INIT ACK chunksent in response to the INIT chunk.Note that, if the receiver of the INIT chunk is not going to establish anassociation (e.g., due to lack of resources), an "Unrecognized Parameters"error cause would not be included with any ABORT chunk being sent to the senderof the INIT chunk.¶
If the receiver of any other chunk (e.g., INIT ACK) detects unrecognizedparameters and has to report them according toSection 3.2.1, itSHOULD bundle the ERROR chunkcontaining the "Unrecognized Parameters" error cause with the chunk sentin response (e.g., COOKIE ECHO).If the receiver of an INIT ACK chunk cannot bundle the COOKIE ECHO chunk withthe ERROR chunk, the ERROR chunkMAY be sent separately but not before theCOOKIE ACK chunk has been received.¶
Any time a COOKIE ECHO chunk is sent in a packet, itMUST be the firstchunk.¶
This section defines the format of the different SCTP chunk types.¶
The following formatMUST 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 | Res |I|U|B|E| Length |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| TSN |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Stream Identifier S | Stream Sequence Number n |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Payload Protocol Identifier |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ \/ User Data (seq n of Stream S) /\ \+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
The (U)nordered bit, if set to 1, indicates that this is an unorderedDATA chunk, and there is no Stream Sequence Number assigned to this DATA chunk.Therefore, the receiverMUST ignore the Stream Sequence Number field.¶
After reassembly (if necessary), unordered DATA chunksMUST be dispatched tothe upper layer by the receiver without any attempt to reorder.¶
If an unordered user message is fragmented, each fragment of the messageMUSThave its U bit set to 1.¶
This field indicates the length of the DATA chunk in bytes fromthe beginning of the type field to the end of the User Data fieldexcluding any padding.A DATA chunk with one byte of user data will have the Length field set to 17(indicating 17 bytes).¶
A DATA chunk with a User Data field of length L will have the Length field setto (16 + L) (indicating 16 + L bytes) where LMUST be greater than 0.¶
This value represents the Stream Sequence Number of the following user datawithin the stream S.Valid range is 0 to 65535.¶
When a user message is fragmented by SCTP for transport, the sameStream Sequence NumberMUST be carried in each of the fragments of the message.¶
This value represents an application (or upper layer) specified protocolidentifier.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 beingcarried in this DATA chunk.This fieldMUST be sent even in fragmented DATA chunks (to make sure it isavailable for agents in the middle of the network).Note that this field is not touched by an SCTP implementation;the upper layer is responsible for the host to network byte order conversion ofthis field.¶
The value 0 indicates that no application identifier is specified by the upperlayer for this payload data.¶
An unfragmented user messageMUST 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-fragmentuser 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 |
When a user message is fragmented into multiple chunks, the TSNs areused by the receiver to reassemble the message. This means that theTSNs for each fragment of a fragmented user messageMUST be strictlysequential.¶
The TSNs of DATA chunks sentSHOULD be strictly sequential.¶
Note: The extension described in[RFC8260] can be usedto mitigate the head of line blocking when transferring large user messages.¶
This chunk is used to initiate an SCTP association between two endpoints.The format of the INIT 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 = 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 following parameters are specified for the INIT chunk.Unless otherwise noted, each parameterMUST only be included once in theINIT chunk.¶
| Fixed-Length Parameter | Status |
|---|---|
| Initiate Tag | Mandatory |
| Advertised Receiver Window Credit | Mandatory |
| Number of Outbound Streams | Mandatory |
| Number of Inbound Streams | Mandatory |
| Initial TSN | Mandatory |
| Variable-Length Parameter | 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) | Deprecated | 11 |
| Supported Address Types (Note 4) | Optional | 12 |
Note 1:The INIT chunks can contain multiple addresses that can be IPv4 and/or IPv6in any combination.¶
Note 2:The ECN Capable field is reserved for future use of Explicit CongestionNotification.¶
Note 3:An INIT chunkMUST NOT contain the Host Name Address parameter.The receiver of an INIT chunk containing a Host Name Address parameterMUSTsend an ABORT chunk andMAY include an "Unresolvable Address" error cause.¶
Note 4:This parameter, when present, specifies all the address types the sendingendpoint can support.The absence of this parameter indicates that the sending endpoint can supportany address type.¶
If an INIT chunk is received with all mandatory parameters that arespecified for the INIT chunk, then the receiverSHOULD process the INIT chunkand send back an INIT ACK.The receiver of the INIT chunkMAY bundle an ERROR chunk with the COOKIE ACKchunk later.However, restrictive implementationsMAY send back an ABORT chunk in responseto the INIT chunk.¶
The Chunk Flags field in INIT chunks is reserved, and all bits in itSHOULDbe set to 0 by the sender and ignored by the receiver.¶
The receiver of the INIT chunk (the responding end) records the value of theInitiate Tag parameter.This valueMUST be placed into the Verification Tag field of every SCTP packetthat the receiver of the INIT chunk transmits within this association.¶
The Initiate Tag is allowed to have any value except 0.SeeSection 5.3.1 for more on the selection ofthe tag value.¶
If the value of the Initiate Tag in a received INIT chunk is found to be 0,the receiverMUST silently discard the packet.¶
This value represents the dedicated buffer space, in number of bytes,the sender of the INIT chunk has reserved in association with this window.¶
The Advertised Receiver Window CreditMUST NOT be smaller than 1500.¶
A receiver of an INIT chunk with the a_rwnd value set to a value smaller than1500MUST discard the packet,SHOULD send a packet in response containingan ABORT chunk and using the Initiate Tag as the Verification Tag, andMUST NOTchange the state of any existing association.¶
During the life of the association, this buffer spaceSHOULD NOT be reduced(i.e., dedicated buffers ought not to be taken away from this association);however, an endpointMAY change the value of a_rwnd it sends in SACK chunks.¶
Defines the number of outbound streams the sender of this INIT chunk wishesto create in this association.The value of 0MUST NOT be used.¶
A receiver of an INIT chunk with the OS value set to 0MUST discard thepacket,SHOULD send a packet in response containing an ABORT chunk and usingthe Initiate Tag as the Verification Tag, andMUST NOT change the state of anyexisting association.¶
Defines the maximum number of streams the sender of this INIT chunk allowsthe peer end to create in this association.The value 0MUST NOT be used.¶
Note: There is no negotiation of the actual number of streams; instead, thetwo endpoints will use the min(requested, offered).SeeSection 5.1.1 for details.¶
A receiver of an INIT chunk with the MIS value set to 0MUST discard thepacket,SHOULD send a packet in response containing an ABORT chunk and usingthe Initiate Tag as the Verification Tag, andMUST NOT change the state of anyexisting association.¶
The following parameters follow the Type-Length-Value format as defined inSection 3.2.1.Any Type-Length-Value fieldsMUST be placed after the fixed-length fields.(The fixed-length fields are defined in the previous section.)¶
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 |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
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 || || |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
Contains an IPv6[RFC8200] address of the sending endpoint.It is binary encoded.¶
A senderMUST NOT use an IPv4-mapped IPv6 address[RFC4291]butSHOULD instead use an IPv4 Address parameter for an IPv4 address.¶
Combined with the Source Port Number in the SCTP common header, the valuepassed in an IPv4 or IPv6 Address parameter indicates a transport address thesender of the INIT chunk will support for the association being initiated.That is, during the life time of this association, this IP address can appearin the source address field of an IP datagram sent from the sender of the INITchunk and can be used as a destination address of an IP datagram sent from thereceiver of the INIT chunk.¶
More than one IP Address parameter can be included in an INIT chunk when thesender of the INIT chunk is multi-homed.Moreover, a multi-homed endpoint might 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 chunk contains at least one IP Address parameter, then thesource address of the IP datagram containing the INIT chunk and any additionaladdress(es) provided within the INIT can be used as destinations by the endpointreceiving the INIT chunk.If the INIT chunk does not contain any IP Address parameters, the endpointreceiving the INIT chunkMUST use the source address associated with thereceived IP datagram as its sole destination address for the association.¶
Note that not using any IP Address parameters in the INIT and INIT ACK chunkis a way to make an association more likely to work in combination with NetworkAddress Translation (NAT).¶
The sender of the INIT chunk uses this parameter to suggest to thereceiver of the INIT chunk a longer life span for 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.) |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
This parameter indicates to the receiver how much increment in millisecondsthe sender wishes the receiver to add to its default cookie life span.¶
This optional parameterMAY be added to the INIT chunk by the sender whenit reattempts establishing an association with a peer to which its previousattempt of establishing the association failed due to a stale cookie operationerror.The receiverMAY choose to ignore the suggested cookie life span increase forits own security reasons.¶
The sender of an INIT chunk or INIT ACK chunkMUST NOT include this parameter.The usage of the Host Name Address parameter is deprecated.The receiver of an INIT chunk or an INIT ACK containing a Host Name AddressparameterMUST send an ABORT chunk andMAY include an "Unresolvable Address"error cause.¶
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 /\ \+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
This field contains a host name in "host name syntax" perSection 2.1 of [RFC1123].The method for resolving the host name is out of scope of SCTP.¶
At least one null terminator is included in the Host Name string andMUST beincluded in the length.¶
The sender of the INIT chunk uses this parameter to list all the address typesit 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 |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| ...... |+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+¶
The INIT ACK chunk is used to acknowledge the initiation of an SCTPassociation.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 /\ \+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
The parameter part of INIT ACK is formatted similarly to the INIT chunk.The following parameters are specified for the INIT ACK chunk:¶
| Fixed-Length Parameter | Status |
|---|---|
| Initiate Tag | Mandatory |
| Advertised Receiver Window Credit | Mandatory |
| Number of Outbound Streams | Mandatory |
| Number of Inbound Streams | Mandatory |
| Initial TSN | Mandatory |
It uses two extra variable parameters: the State Cookie and the UnrecognizedParameter.¶
| Variable-Length Parameter | 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) | Deprecated | 11 |
Note 1:The INIT ACK chunks can contain any number of IP Address parameters thatcan be IPv4 and/or IPv6 in any combination.¶
Note 2:The ECN Capable field is reserved for future use of Explicit CongestionNotification.¶
Note 3:An INIT ACK chunkMUST NOT contain the Host Name Address parameter.The receiver of INIT ACK chunks containing a Host Name Address parameterMUST send an ABORT chunk andMAY include an "Unresolvable Address" error cause.¶
The Chunk Flags field in INIT ACK chunks is reserved, and all bits in itSHOULD be set to 0 by the sender and ignored by the receiver.¶
The receiver of the INIT ACK chunk records the value of the Initiate Tagparameter.This valueMUST be placed into the Verification Tag field of every SCTP packetthat the receiver of the INIT ACK chunk transmits within this association.¶
The Initiate TagMUST NOT take the value 0.SeeSection 5.3.1 for more on the selection ofthe Initiate Tag value.¶
If an endpoint in the COOKIE-WAIT state receives an INIT ACK chunk with theInitiate Tag set to 0, itMUST destroy the TCB andSHOULD send an ABORT chunkwith the T bit set.If such an INIT ACK chunk is received in any state other than CLOSED orCOOKIE-WAIT, itSHOULD be discarded silently(seeSection 5.2.3).¶
This value represents the dedicated buffer space, in number of bytes, thesender of the INIT ACK chunk has reserved in association with this window.¶
The Advertised Receiver Window CreditMUST NOT be smaller than 1500.¶
A receiver of an INIT ACK chunk with the a_rwnd value set to a value smallerthan 1500MUST discard the packet,SHOULD send a packet in responsecontaining an ABORT chunk and using the Initiate Tag as the Verification Tag,andMUST NOT change the state of any existing association.¶
During the life of the association, this buffer spaceSHOULD NOT be reduced(i.e., dedicated buffers ought not to be taken away from this association);however, an endpointMAY change the value of a_rwnd it sends in SACK chunks.¶
Defines the number of outbound streams the sender of this INIT ACK chunkwishes to create in this association.The value of 0MUST NOT be used, and the valueMUST NOT be greater than theMIS value sent in the INIT chunk.¶
If an endpoint in the COOKIE-WAIT state receives an INIT ACK chunk with theOS value set to 0, itMUST destroy the TCB andSHOULD send an ABORT chunk.If such an INIT ACK chunk is received in any state other than CLOSED orCOOKIE-WAIT, itSHOULD be discarded silently(seeSection 5.2.3).¶
Defines the maximum number of streams the sender of this INIT ACK chunkallows the peer end to create in this association.The value 0MUST NOT be used.¶
Note:There is no negotiation of the actual number of streams, but instead the twoendpoints will use the min(requested, offered).SeeSection 5.1.1 for details.¶
If an endpoint in the COOKIE-WAIT state receives an INIT ACK chunk with theMIS value set to 0, itMUST destroy the TCB andSHOULD send an ABORT chunk.If such an INIT ACK chunk is received in any state other than CLOSED orCOOKIE-WAIT, itSHOULD be discarded silently(seeSection 5.2.3).¶
Implementation Note:An implementationMUST be prepared to receive an INIT ACK chunk that is quitelarge (more than 1500 bytes) due to the variable size of the State Cookie andthe variable address list.For example, if a responder to the INIT chunk has 1000 IPv4 addresses it wishesto send, it would need at least 8,000 bytes to encode this in theINIT ACK chunk.¶
If an INIT ACK chunk is received with all mandatory parameters that arespecified for the INIT ACK chunk, then the receiverSHOULD process theINIT ACK chunk and send back a COOKIE ECHO chunk.The receiver of the INIT ACK chunkMAY bundle an ERROR chunk with theCOOKIE ECHO chunk.However, restrictive implementationsMAY send back an ABORT chunk inresponse to the INIT ACK chunk.¶
In combination with the Source Port Number carried in the SCTP common header,each IP Address parameter in the INIT ACK chunk indicates to the receiver ofthe INIT ACK chunk a valid transport address supported by the sender of theINIT ACK chunk for the life time of the association being initiated.¶
If the INIT ACK chunk contains at least one IP Address parameter, then thesource address of the IP datagram containing the INIT ACK chunk and anyadditional address(es) provided within the INIT ACK chunkMAY be used asdestinations by the receiver of the INIT ACK chunk.If the INIT ACK chunk does not contain any IP Address parameters, the receiverof the INIT ACK chunkMUST use the source address associated with the receivedIP datagram as its sole destination address for the association.¶
The State Cookie and Unrecognized Parameters use the Type-Length-Value formatas defined inSection 3.2.1 and are described below.The other fields are defined in the same way as their counterparts in theINIT chunk.¶
The State Cookie and Unrecognized Parameters use the Type-Length-Value format,as defined inSection 3.2.1, and are described below.The IPv4 Address parameter is described inSection 3.3.2.1.1, andthe IPv6 Address parameter is described inSection 3.3.2.1.2.The Host Name Address parameter is described inSection 3.3.2.1.4andMUST NOT be included in an INIT ACK chunk.Any Type-Length-Value fieldsMUST be placed after the fixed-length fields.(The fixed-length fields are defined in the previous section.)¶
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 | Length |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ Cookie /\ \+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
This parameter is returned to the originator of the INIT chunk when the INITchunk contains an unrecognized parameter that has a type that indicates itSHOULD be reported to 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 = 8 | Length |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ Unrecognized Parameter /\ \+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
This chunk is sent to the peer endpoint to acknowledge received DATA chunksand to inform the peer endpoint of gaps in the received subsequences of DATAchunks as represented by their TSNs.¶
The SACK chunkMUST contain the Cumulative TSN Ack, Advertised ReceiverWindow Credit (a_rwnd), Number of Gap Ack Blocks, and Number of Duplicate TSNsfields.¶
By definition, the value of the Cumulative TSN Ack parameter is thelast TSN received before a break in the sequence of received TSNsoccurs;the next TSN value following this one has not yet been received at the endpointsending the SACK chunk.This parameter therefore acknowledges receipt of all TSNs less than or equal toits value.¶
The handling of a_rwnd by the receiver of the SACK chunk is discussed indetail inSection 6.2.1.¶
The SACK chunk also contains zero or more Gap Ack Blocks.Each Gap Ack Block acknowledges a subsequence of TSNs received following a breakin the sequence of received TSNs.The Gap Ack BlocksSHOULD be isolated.This means that the TSN just before each Gap Ack Block and the TSN just aftereach Gap Ack Block have not been received.By definition, all TSNs acknowledged by Gap Ack Blocks are greater than thevalue of the Cumulative TSN Ack.¶
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 = M |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 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 M |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
Indicates the End offset TSN for this Gap Ack Block.To calculate the actual TSN number, the Cumulative TSN Ack is added to thisoffset number.This calculated TSN identifies the highest TSN in this Gap Ack Block that hasbeen received.¶
For example, assume that the receiver has the following DATA chunks newlyarrived 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 chunkMUST 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 start = 2 | block #1 end = 3 |+-------------------+-------------------+|block #2 start = 5 | block #2 end = 5 |+-------------------+-------------------+¶
Indicates the number of times a TSN was received in duplicate since the lastSACK chunk was sent.Every time a receiver gets a duplicate TSN (before sending the SACK chunk), itadds it to the list of duplicates.The duplicate count is reinitialized to zero after sending each SACK chunk.¶
For example, if a receiver were to get the TSN 19 three times, itwould list 19 twice in the outbound SACK chunk.After sending the SACK chunk, if it received yet one more TSN 19, it would list19 as a duplicate once in the next outgoing SACK chunk.¶
An endpointSHOULD send a HEARTBEAT (HB) chunk to its peer endpoint to probethe reachability of a particular destination transport address defined in thepresent association.¶
The parameter field contains the Heartbeat Information, which is avariable-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) /\ \+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
Defined as a variable-length parameter using the format describedinSection 3.2.1, that is:¶
| 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 fieldSHOULD includeinformation about the sender's current time when this HEARTBEATchunk is sent and the destination transport address to which thisHEARTBEAT chunk is sent (seeSection 8.3).This information is simply reflected back by the receiver in the HEARTBEAT ACKchunk (seeSection 3.3.6).Note also that the HEARTBEAT chunk is both for reachability checking and forpath verification (seeSection 5.4).When a HEARTBEAT chunk is being used for path verification purposes, itMUSTinclude a random nonce of length 64 bits or longer ([RFC4086]provides some information on randomness guidelines).¶
An endpointMUST send this chunk to its peer endpoint as a responseto a HEARTBEAT chunk (seeSection 8.3).A packet containing the HEARTBEAT ACK chunk is always sent to the sourceIP address of the IP datagram containing the HEARTBEAT chunk to which thisHEARTBEAT ACK chunk 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) /\ \+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
This fieldMUST contain the Heartbeat Info parameter (as defined inSection 3.3.5) of the Heartbeat Request to which thisHeartbeat Acknowledgement is responding.¶
| Variable Parameters | Status | Type Value |
|---|---|---|
| Heartbeat Info | Mandatory | 1 |
The ABORT chunk is sent to the peer of an association to close theassociation.The ABORT chunkMAY contain error causes to inform the receiver about thereason of the abort.DATA chunksMUST NOT be bundled with ABORT chunks.Control chunks (except for INIT, INIT ACK, and SHUTDOWN COMPLETE)MAY bebundled with an ABORT chunk, but theyMUST be placed before the ABORT chunkin the SCTP packet; otherwise, they will be ignored by the receiver.¶
If an endpoint receives an ABORT chunk with a format error or no TCB isfound, itMUST silently discard it.Moreover, under any circumstances, an endpoint that receives an ABORT chunkMUST NOT respond to that ABORT chunk by sending an ABORT chunk 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 /\ \+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
SeeSection 3.3.10 for Error Cause definitions.¶
Note: Special rules apply to this chunk for verification;please seeSection 8.5.1 fordetails.¶
An endpoint in an associationMUST use this chunk to initiate a gracefulclose 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 |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
Note: Since the SHUTDOWN chunk does not contain Gap Ack Blocks,it cannot be used to acknowledge TSNs received out of order.In a SACK chunk, lack of Gap Ack Blocks that were previously included indicatesthat the data receiver reneged on the associated DATA chunks.¶
Since the SHUTDOWN chunk does not contain Gap Ack Blocks, the receiver ofthe SHUTDOWN chunkMUST NOT interpret the lack of a Gap Ack Block as a renege.(SeeSection 6.2 forinformation on reneging.)¶
The sender of the SHUTDOWN chunkMAY bundle a SACK chunk to indicate anygaps in the received TSNs.¶
This chunkMUST be used to acknowledge the receipt of the SHUTDOWN chunk atthe completion of the shutdown process;seeSection 9.2 for details.¶
The SHUTDOWN ACK 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 = 8 | Chunk Flags | Length = 4 |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
An endpoint sends this chunk to its peer endpoint to notify it ofcertain error conditions.It contains one or more error causes.An Operation Error is not considered fatal in and of itself, but thecorresponding error causeMAY be used with an ABORT chunk to report a fatalcondition.An ERROR 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 = 9 | Chunk Flags | Length |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ \/ one or more Error Causes /\ \+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
Error causes are defined as variable-length parameters using theformat described inSection 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 /\ \+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
Defines the type of error conditions being reported.¶
| Value | Cause Code |
|---|---|
| 1 | Invalid Stream Identifier |
| 2 | Missing Mandatory Parameter |
| 3 | Stale Cookie |
| 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 |
Sections3.3.10.1 -3.3.10.13 define error causes for SCTP.Guidelines for the IETF to define new error cause values are discussed inSection 15.4.¶
Indicates that the endpoint received a DATA chunk sent using a nonexistentstream.¶
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 = 1 | Cause Length = 8 |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Stream Identifier | (Reserved) |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
Indicates that one or more mandatory TLVparameters are missing in a received INIT or INIT ACK 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+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 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 |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
Indicates the receipt of a valid State Cookie that has expired.¶
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 = 3 | Cause Length = 8 |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Measure of Staleness (usec.) |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
This field contains the difference, rounded up in microseconds, between thecurrent time and the time the State Cookie expired.¶
The sender of this error causeMAY choose to report how long pastexpiration the State Cookie is by including a non-zero value inthe Measure of Staleness field.If the sender does not wish to provide the Measure of Staleness, itSHOULD setthis field to the value of zero.¶
Indicates that the sender is out of resource.This is usually sent in combination with or within an ABORT 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+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Cause Code = 4 | Cause Length = 4 |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
Indicates that the sender is not able to resolve the specified addressparameter (e.g., type of address is not supported by the sender).This is usually sent in combination with or within an ABORT 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+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Cause Code = 5 | Cause Length |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ Unresolvable Address /\ \+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
This error cause is returned to the originator of the chunk if the receiverdoes not understand the chunk and the upper bits of the 'Chunk Type' are setto 01 or 11.¶
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 = 6 | Cause Length |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ Unrecognized Chunk /\ \+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
This error cause is returned to the originator of an INIT or INIT ACK chunkwhen one of the mandatory parameters is set to an invalid value.¶
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 = 7 | Cause Length = 4 |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
This error cause is returned to the originator of the INIT ACK chunk if thereceiver does not recognize one or more Optional TLV parameters in theINIT ACK 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+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Cause Code = 8 | Cause Length |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ Unrecognized Parameters /\ \+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
This error cause is returned to the originator of a DATA chunk if areceived DATA chunk has no user data.¶
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 = 9 | Cause Length = 8 |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| TSN |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
This cause code is normally returned in an ABORT chunk(seeSection 6.2).¶
A COOKIE ECHO chunk was received while the endpoint was in theSHUTDOWN-ACK-SENT state.This error is usually returned in an ERROR chunk bundled with theretransmitted SHUTDOWN ACK 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+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Cause Code = 10 | Cause Length = 4 |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
An INIT chunk was received on an existing association.But the INIT chunk added addresses to the association that were previouslynot part of the association.The new addresses are listed in the error cause.This error cause is normally sent as part of an ABORT chunk refusing theINIT chunk(seeSection 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 |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ New Address TLVs /\ \+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
Note: Each New Address TLV is an exact copy of the TLV that was foundin the INIT chunk that was new, including the Parameter Type and theParameter Length.¶
This error causeMAY be included in ABORT chunks that are sentbecause of an upper-layer request.The upper layer can specify an Upper Layer Abort Reason that is transported bySCTP transparently andMAY 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 |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ Upper Layer Abort Reason /\ \+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
This error causeMAY be included in ABORT chunks that are sentbecause an SCTP endpoint detects a protocol violation of the peerthat is not covered by the error causes described in Sections3.3.10.1 -3.3.10.12.An implementationMAY provide additional information specifying what kind ofprotocol 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 |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ Additional Information /\ \+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
This chunk is used only during the initialization of an association.It is sent by the initiator of an association to its peer to completethe initialization process.This chunkMUST precede any DATA chunk sent within the association butMAY bebundled 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 /\ \+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
This fieldMUST contain the exact cookie received in the State Cookie parameterfrom the previous INIT ACK chunk.¶
An implementationSHOULD make the cookie as small as possible to ensureinteroperability.¶
Note: A Cookie Echo does not contain a State Cookie parameter;instead, the data within the State Cookie's Parameter Value becomes the datawithin the Cookie Echo's Chunk Value.This allows an implementation to change only the first 2 bytes of theState Cookie parameter to become a COOKIE ECHO chunk.¶
This chunk is used only during the initialization of an association.It is used to acknowledge the receipt of a COOKIE ECHO chunk.This chunkMUST precede any DATA or SACK chunk sent within theassociation butMAY be bundled with one or more DATA chunks or SACKchunk'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 |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
This chunkMUST be used to acknowledge the receipt of the SHUTDOWN ACK chunkat the completion of the shutdown process;seeSection 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 |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
Note: Special rules apply to this chunk for verification; please seeSection 8.5.1 for details.¶
During the life time of an SCTP association, the SCTP endpoint'sassociation progresses from one state to another in response tovarious events.The events that might potentially advance an association's state include:¶
SCTP user primitive calls, e.g., [ASSOCIATE], [SHUTDOWN], or [ABORT],¶
reception of INIT, COOKIE ECHO, ABORT, SHUTDOWN, etc., and control chunks, or¶
some timeout events.¶
The state diagram in the figures below illustrates state changes, togetherwith 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 parameternames have the first letter capitalized, e.g., COOKIE ECHO chunk typevs. State Cookie parameter.If more than one event/message can occur that causes a state transition, itis labeled (A) or (B).¶
----- -------- (from any state) / \ /receive ABORT [ABORT] receive INIT | | |-------------- or -------------------------------| v v delete TCB send ABORTgenerate State Cookie \ +---------+ delete TCB send INIT ACK ---| CLOSED | +---------+ / \ / \ [ASSOCIATE] | |----------------- | | create TCB | | send INIT receive valid | | start T1-init timer COOKIE ECHO | v (1) -----------------| +-----------+ create TCB | |COOKIE-WAIT| (2) send COOKIE ACK | +-----------+ | | | | receive INIT ACK | |------------------- | | send COOKIE ECHO | | stop T1-init timer | | start T1-cookie timer | v | +-------------+ | |COOKIE-ECHOED| (3) | +-------------+ | | | | receive COOKIE ACK | |------------------- | | stop T1-cookie timer v v +---------------+ | ESTABLISHED | +---------------+ | | /--------+--------\ [SHUTDOWN] / \ -------------------| | check outstanding | | DATA chunks | | v | +----------------+ | |SHUTDOWN-PENDING| | receive SHUTDOWN +----------------+ |------------------ | check outstanding | | DATA chunksNo more outstanding | |-----------------------| |send SHUTDOWN | |start T2-shutdown timer| | v v +-------------+ +-----------------+ (4) |SHUTDOWN-SENT| |SHUTDOWN-RECEIVED| (5,6) +-------------+ +-----------------+ | \ |receive SHUTDOWN ACK | \ |-----------------------| \ |stop T2-shutdown timer | \ |send SHUTDOWN COMPLETE | \ |delete TCB | \ | | \ | No more outstanding | \ |-------------------- | \ | send SHUTDOWN ACKreceive SHUTDOWN -|- \ | start T2-shutdown timer--------------------/ | \----------\ |send SHUTDOWN ACK | \ |start T2-shutdown timer| \ | | \ | | | | | v v | +-----------------+ | |SHUTDOWN-ACK-SENT| (7) | +-----------------+ | | (A) | |receive SHUTDOWN COMPLETE | |------------------------- | | stop T2-shutdown timer | | delete TCB | | | | (B) | | receive SHUTDOWN ACK | |----------------------- | | stop T2-shutdown timer | | send SHUTDOWN COMPLETE | | delete TCB | | \ +---------+ / \-->| CLOSED |<--/ +---------+
The following applies:¶
If the State Cookie in the received COOKIE ECHO chunk is invalid (i.e.,failed to pass the integrity check), the receiverMUST silently discardthe packet.Or, if the received State Cookie is expired (seeSection 5.1.5), the receiverMUST send backan ERROR chunk.In either case, the receiver stays in the CLOSED state.¶
If the T1-init timer expires, the endpointMUSTretransmit the INIT chunk and restart the T1-init timer.The endpoint stays in the COOKIE-WAIT state.ThisMUST be repeated up to 'Max.Init.Retransmits' times.After that, the endpointMUST abort the initialization process and report theerror to the SCTP user.¶
If the T1-cookie timer expires, the endpointMUSTretransmit COOKIE ECHO chunk and restart the T1-cookie timer.The endpoint stays in the COOKIE-ECHOED state.ThisMUST be repeated up to 'Max.Init.Retransmits' times.After that, the endpointMUST abort the initialization process and report theerror to the SCTP user.¶
In the SHUTDOWN-SENT state, the endpointMUST acknowledge anyreceived DATA chunks without delay.¶
In the SHUTDOWN-RECEIVED state, the endpointMUST NOT accept anynew send requests from its SCTP user.¶
In the SHUTDOWN-RECEIVED state, the endpointMUST transmit or retransmitdata and leave this state when all data in queue is transmitted.¶
In the SHUTDOWN-ACK-SENT state, the endpointMUST NOT accept any new sendrequests from its SCTP user.¶
The CLOSED state is used to indicate that an association is not created(i.e., does not exist).¶
Before the first data transmission can take place from one SCTPendpoint ("A") to another SCTP endpoint ("Z"), the two endpointsMUSTcomplete an initialization process in order to set up an SCTPassociation between them.¶
The SCTP user at an endpoint can use the ASSOCIATE primitive toinitialize an SCTP association to another SCTP endpoint.¶
Implementation Note: From an SCTP user's point of view, anassociation might be implicitly opened, without an ASSOCIATE primitive(seeSection 11.1.2) being invoked, by the initiatingendpoint's sending of the first user data to the destination endpoint.The initiating SCTP will assume default values for all mandatory andoptional parameters for the INIT/INIT ACK chunk.¶
Once the association is established, unidirectional streams are openfor data transfer on both ends(seeSection 5.1.1).¶
The initialization process consists of the following steps (assuming thatSCTP endpoint "A" tries to set up an association with SCTP endpoint "Z" and"Z" accepts the new association):¶
"A" first builds a TCB and sends an INIT chunk to "Z".In the INIT chunk, "A"MUST provide its Verification Tag (Tag_A) in theInitiate Tag field.Tag_ASHOULD be a random number in the range of 1 to 4294967295(seeSection 5.3.1 for Tag value selection).After sending the INIT chunk, "A" starts the T1-init timer and enters theCOOKIE-WAIT state.¶
"Z" responds immediately with an INIT ACK chunk.The destination IP address of the INIT ACK chunkMUST be set to the sourceIP address of the INIT chunk to which this INIT ACK chunk is responding.In the response, besides filling in other parameters, "Z"MUST set theVerification Tag field to Tag_A and also provide its ownVerification Tag (Tag_Z) in the Initiate Tag field.¶
Moreover, "Z"MUST generate and send along with the INIT ACK chunk a State Cookie.SeeSection 5.1.3 for State Cookie generation.¶
After sending an INIT ACK chunk with the State Cookie parameter,"Z"MUST NOT allocate any resources or keep any states for the newassociation.Otherwise, "Z" will be vulnerable to resource attacks.¶
Upon reception of the INIT ACK chunk from "Z", "A" stops the T1-inittimer and leaves the COOKIE-WAIT state."A" then sends the State Cookie received in the INIT ACK chunk in aCOOKIE ECHO chunk, starts the T1-cookie timer, and enters the COOKIE-ECHOEDstate.¶
The COOKIE ECHO chunkMAY be bundled with any pending outbound DATAchunks, but itMUST be the first chunk in the packet and, until the COOKIE ACKchunk is returned, the senderMUST NOT send any other packets to the peer.¶
Upon reception of the COOKIE ECHO chunk, endpoint "Z" replieswith a COOKIE ACK chunk after building a TCB and moving to theESTABLISHED state.A COOKIE ACK chunkMAY be bundled with any pending DATA chunks(and/or SACK chunks), but the COOKIE ACK chunkMUST be the first chunk inthe packet.¶
Implementation Note: An implementation can choose to send theCOMMUNICATION UP notification to the SCTP user upon reception of avalid COOKIE ECHO chunk.¶
Upon reception of the COOKIE ACK chunk, endpoint "A" moves from theCOOKIE-ECHOED state to the ESTABLISHED state, stopping the T1-cookie timer.It can also notify its ULP about the successful establishment of theassociation with a COMMUNICATION UP notification(seeSection 11).¶
An INIT or INIT ACK chunkMUST NOT be bundled with any other chunk.TheyMUST be the only chunks present in the SCTP packets that carry them.¶
An endpointMUST send the INIT ACK chunk to the IP address from which itreceived the INIT chunk.¶
The T1-init timer and T1-cookie timerSHOULD follow the same rulesgiven inSection 6.3.If the application provided multiple IP addresses of the peer, thereSHOULDbe a T1-init and T1-cookie timer for each address of the peer. Retransmissionsof INIT chunks and COOKIE ECHO chunksSHOULD use all addresses of the peersimilar to retransmissions of DATA chunks.¶
If an endpoint receives an INIT, INIT ACK, or COOKIE ECHO chunk but decidesnot to establish the new association due to missing mandatory parameters in thereceived INIT or INIT ACK chunk, invalid parameter values, or lack of localresources, itSHOULD respond with an ABORT chunk.ItSHOULD also specify the cause of abort, such as the type of the missingmandatory parameters, etc., by including an error cause in the ABORT chunk.The Verification Tag field in the common header of the outbound SCTP packetcontaining the ABORT chunkMUST be set to the Initiate Tag value of thereceived INIT or INIT ACK chunk this ABORT chunk is responding to.¶
Note that a COOKIE ECHO chunk that does not pass the integrity checkis not considered an 'invalid mandatory parameter' and requires specialhandling; seeSection 5.1.5.¶
After the reception of the first DATA chunk in an association, theendpointMUST immediately respond with a SACK chunk to acknowledge the DATAchunk.Subsequent acknowledgementsSHOULD be done as described inSection 6.2.¶
When the TCB is created, each endpointMUST set its internalCumulative TSN Ack Point to the value of its transmitted Initial TSNminus one.¶
Implementation Note: The IP addresses and SCTP port are generallyused as the key to find the TCB within an SCTP instance.¶
In the INIT and INIT ACK chunks, the sender of the chunkMUSTindicate the number of outbound streams (OS) it wishes to have inthe association, as well as the maximum inbound streams (MIS) itwill accept from the other endpoint.¶
After receiving the stream configuration information from the otherside, each endpointMUST perform the following check:If the peer's MIS is less than the endpoint's OS, meaning that the peer isincapable of supporting all the outbound streams the endpoint wantsto configure, the endpointMUST use MIS outbound streams andMAYreport any shortage to the upper layer.The upper layer can then choose to abort the association if the resourceshortage is unacceptable.¶
After the association is initialized, the valid outbound stream identifierrange for either endpointMUST be 0 to min(local OS, remote MIS) - 1.¶
During the association initialization, an endpoint uses thefollowing rules to discover and collect the destination transport address(es)of its peer.¶
If there are no address parameters present in the received INIT orINIT ACK chunk, the endpointMUST take the source IP address fromwhich the chunk arrives and record it, in combination with theSCTP Source Port Number, as the only destination transport addressfor this peer.¶
If there is a Host Name Address parameter present in the received INIT orINIT ACK chunk, the endpointMUST immediately send an ABORT chunk andMAYinclude an "Unresolvable Address" error cause to its peer.The ABORT chunkSHOULD be sent to the source IP address from which the last peerpacket was received.¶
If there are only IPv4/IPv6 addresses present in the received INIT orINIT ACK chunk, the receiverMUST derive and record all the transport addressesfrom the received chunk AND the source IP address that sent the INIT orINIT ACK chunk.The transport addresses are derived by the combination of SCTP Source Port Number(from the common header) and the IP Address parameter(s) carried in the INITor INIT ACK chunk and the source IP address of the IP datagram.The receiverSHOULD use only these transport addresses as destinationtransport addresses when sending subsequent packets to its peer.¶
An INIT or INIT ACK chunkMUST be treated as belonging to an alreadyestablished association (or one in the process of being established) if theuse of any of the valid address parameters contained within the chunk wouldidentify an existing TCB.¶
Implementation Note: In some cases (e.g., when the implementation does notcontrol the source IP address that is used for transmitting), an endpointmight need to include in its INIT or INIT ACK chunk all possible IP addressesfrom which packets to the peer could be transmitted.¶
After all transport addresses are derived from the INIT or INIT ACK chunkusing the above rules, the endpoint selects one of the transport addressesas the initial primary path.¶
The packet containing the INIT ACK chunkMUST be sent to the source addressof the packet containing the INIT chunk.¶
The sender of INIT chunksMAY include a 'Supported Address Types' parameterin the INIT chunk to indicate what types of addresses are acceptable.¶
Implementation Note: In the case that the receiver of an INIT ACK chunkfails to resolve the address parameter due to an unsupported type, itcan abort the initiation process and then attempt a reinitiation byusing a 'Supported Address Types' parameter in the new INIT chunk to indicatewhat types of address it prefers.¶
If an SCTP endpoint that only supports either IPv4 orIPv6 receives IPv4 and IPv6 addresses in an INIT or INIT ACK chunk from itspeer, itMUST use all the addresses belonging to the supported address family.The other addressesMAY be ignored.The endpointSHOULD NOT respond with any kind of error indication.¶
If an SCTP endpoint lists in the 'Supported AddressTypes' parameter either IPv4 or IPv6 but uses the other family for sendingthe packet containing the INIT chunk, or if it also lists addresses of theother family in the INIT chunk, then the address family that is not listedin the 'Supported Address Types' parameterSHOULD also be considered assupported by the receiver of the INIT chunk.The receiver of the INIT chunkSHOULD NOT respond with any kind of errorindication.¶
When sending an INIT ACK chunk as a response to an INIT chunk, the senderof the INIT ACK chunk creates a State Cookie and sends it in the State Cookieparameter of the INIT ACK chunk.Inside this State Cookie, the senderMUST include a MAC(see[RFC2104] for an example) to provide integrity protectionon the State Cookie.The State CookieSHOULD also contain a timestamp on when theState Cookie is created and the lifespan of the State Cookie, along with allthe information necessary for it to establish the association, includingthe port numbers and the Verification Tags.¶
The method used to generate the MAC is strictly a private matter for thereceiver of the INIT chunk.The use of a MAC is mandatory to prevent denial-of-service attacks.MAC algorithms can have different performances depending on the platform.Choosing a high-performance MAC algorithm increases the resistance againstcookie flooding attacks.A MAC with acceptable security propertiesSHOULD be used.The secret keySHOULD be random ([RFC4086] provides someinformation on randomness guidelines).The secret keys need to have an appropriate size.The secret keySHOULD be changed reasonably frequently (e.g., hourly), and thetimestamp in the State CookieMAY be used to determine which key is used toverify the MAC.¶
If the State Cookie is not encrypted, itMUST NOT contain informationthat is not being envisioned to be shared.¶
An implementationSHOULD make the cookie as small as possible toensure interoperability.¶
When an endpoint (in the COOKIE-WAIT state) receives an INIT ACKchunk with a State Cookie parameter, itMUST immediately send aCOOKIE ECHO chunk to its peer with the received State Cookie.The senderMAY also add any pending DATA chunks to the packet after theCOOKIE ECHO chunk.¶
The endpointMUST also start the T1-cookie timer after sending theCOOKIE ECHO chunk.If the timer expires, the endpointMUST retransmit the COOKIE ECHO chunk andrestart the T1-cookie timer.This is repeated until either a COOKIE ACK chunk is received or'Max.Init.Retransmits' (seeSection 16) is reached,causing the peer endpoint to be marked unreachable (and thus the associationenters the CLOSED state).¶
When an endpoint receives a COOKIE ECHO chunk from another endpointwith which it has no association, it takes the following actions:¶
Compute a MAC using the information carried in the State Cookie andthe secret key.The timestamp in the State CookieMAY be used to determine which secret key touse.If secrets are kept only for a limited amount of time and the secret key to useis not available anymore, the packet containing the COOKIE ECHO chunkMUST besilently discarded.[RFC2104] can be used as a guideline for generating the MAC.¶
Authenticate the State Cookie as one that it previously generatedby comparing the computed MAC against the one carried in the State Cookie.If this comparison fails, the SCTP packet, including the COOKIE ECHO chunk andany DATA chunks,MUST be silently discarded.¶
Compare the port numbers and the Verification Tag contained within theCOOKIE ECHO chunk to the actual port numbers and the Verification Tag withinthe SCTP common header of the received packet.If these values do not match, the packetMUST be silently discarded.¶
Compare the creation timestamp in the State Cookie to the current localtime.If the elapsed time is longer than the lifespan carried in the State Cookie,then the packet, including the COOKIE ECHO chunk and any attached DATA chunks,SHOULD be discarded, and the endpointMUST transmit an ERROR chunk with a"Stale Cookie" error cause to the peer endpoint.¶
If the State Cookie is valid, create an association to the senderof the COOKIE ECHO chunk with the information in the State Cookiecarried in the COOKIE ECHO chunk and enter the ESTABLISHED state.¶
Send a COOKIE ACK chunk to the peer acknowledging receipt of theCOOKIE ECHO chunk.The COOKIE ACK chunkMAY be bundled with an outbound DATA chunk or SACK chunk;however, the COOKIE ACK chunkMUST be the first chunk in the SCTP packet.¶
Immediately acknowledge any DATA chunk bundled with the COOKIE ECHO chunkwith a SACK chunk (subsequent DATA chunk acknowledgementSHOULD follow the rulesdefined inSection 6.2).As mentioned in step 6, if the SACK chunk is bundled with the COOKIE ACK chunk,the COOKIE ACK chunkMUST appear first in the SCTP packet.¶
If a COOKIE ECHO chunk is received from an endpoint with which the receiverof the COOKIE ECHO chunk has an existing association, the procedures inSection 5.2SHOULD befollowed.¶
In the following example, "A" initiates the association and then sends auser message to "Z"; then, "Z" sends two user messages to "A" later(assuming no bundling or fragmentation occurs):¶
Endpoint A Endpoint Z{app sets association with Z}(build TCB)INIT [I-Tag=Tag_A & other info] ------\(Start T1-init timer) \(Enter COOKIE-WAIT state) \---> (compose Cookie_Z) /-- INIT ACK [Veri Tag=Tag_A, / I-Tag=Tag_Z,(Cancel T1-init timer) <------/ Cookie_Z, & other info]COOKIE ECHO [Cookie_Z] ------\(Start T1-cookie timer) \(Enter COOKIE-ECHOED state) \---> (build TCB, enter ESTABLISHED state) /---- COOKIE ACK /(Cancel T1-cookie timer, <---/ enter ESTABLISHED state){app sends 1st user data; strm 0}DATA [TSN=init TSN_A Strm=0,Seq=0 & user data]--\(Start T3-rtx timer) \ \-> /----- SACK [TSN Ack=init TSN_A, Block=0](Cancel T3-rtx timer) <------/ ... {app sends 2 messages;strm 0} /---- DATA / [TSN=init TSN_Z, <--/ Strm=0,Seq=0 & user data 1]SACK [TSN Ack=init TSN_Z, /---- DATA Block=0] --------\ / [TSN=init TSN_Z +1, \/ Strm=0,Seq=1 & user data 2] <------/\ \ \------>If the T1-init timer expires at "A" after the INIT or COOKIE ECHO chunksare sent, the same INIT or COOKIE ECHO chunk with the same Initiate Tag(i.e., Tag_A) or State Cookie is retransmitted and the timer is restarted.This is repeated 'Max.Init.Retransmits' times before "A" considers "Z"unreachable and reports the failure to its upper layer (and thus theassociation enters the CLOSED state).¶
When retransmitting the INIT chunk, the endpointMUST follow the rulesdefined inSection 6.3 to determinethe proper timer value.¶
During the life time of an association (in one of the possible states),an endpoint can receive from its peer endpoint one of the setup chunks (INIT,INIT ACK, COOKIE ECHO, or COOKIE ACK).The receiver treats such a setup chunk as a duplicate and process itas described in this section.¶
Note: An endpoint will not receive the chunk unless the chunk was sent toan SCTP transport address and is from an SCTP transport address associatedwith this endpoint.Therefore, the endpoint processes such a chunk as part of its currentassociation.¶
The following scenarios can cause duplicated or unexpected chunks:¶
the peer has crashed without being detected, restarted itself, andsent a new INIT chunk trying to restore the association,¶
both sides are trying to initialize the association at about the sametime,¶
the chunk is from a stale packet that was used to establish the presentassociation or a past association that is no longer in existence,¶
the chunk is a false packet generated by an attacker, or¶
the peer never received the COOKIE ACK chunk and is retransmitting itsCOOKIE ECHO chunk.¶
The rules in the following sections are applied in order to identifyand correctly handle these cases.¶
This usually indicates an initialization collision, i.e., each endpointis attempting, at about the same time, to establish an association with theother endpoint.¶
Upon receipt of an INIT chunk in the COOKIE-WAIT state, an endpointMUSTrespond with an INIT ACK chunk using the same parameters it sent in itsoriginal INIT chunk (including its Initiate Tag, unchanged).When responding, the following rulesMUST be applied:¶
The packet containing the INIT ACK chunkMUST only be sent to an addresspassed by the upper layer in the request to initialize the association.¶
The packet containing the INIT ACK chunkMUST only be sent to an addressreported in the incoming INIT chunk.¶
The packet containing the INIT ACK chunkSHOULD be sent to the sourceaddress of the received packet containing the INIT chunk.¶
Upon receipt of an INIT chunk in the COOKIE-ECHOED state, an endpointMUSTrespond with an INIT ACK chunk using the same parameters it sent in itsoriginal INIT chunk (including its Initiate Tag, unchanged), providedthat no new address has been added to the forming association.If the INIT chunk indicates that a new address has been added to theassociation, then the entire INIT chunkMUST be discarded, and the state ofthe existing associationSHOULD NOT be changed.An ABORT chunkSHOULD be sent in a response thatMAY include the"Restart of an Association with New Addresses" error cause.The errorSHOULD list the addresses that were added to the restartingassociation.¶
When responding in either state (COOKIE-WAIT or COOKIE-ECHOED) withan INIT ACK chunk, the original parameters are combined with those from thenewly received INIT chunk.The endpointMUST also generate a State Cookie with the INIT ACK chunk.The endpoint uses the parameters sent in its INIT chunk to calculate theState Cookie.¶
After that, the endpointMUST NOT change its state, the T1-init timerMUST be left running, and the corresponding TCBMUST NOT be destroyed.The normal procedures for handling State Cookies when aTCB exists will resolve the duplicate INIT chunks to a single association.¶
For an endpoint that is in the COOKIE-ECHOED state, itMUST populateits Tie-Tags within both the association TCB and inside the State Cookie (seeSection 5.2.2for a description of the Tie-Tags).¶
Unless otherwise stated, upon receipt of an unexpected INIT chunk for thisassociation, the endpointMUST generate an INIT ACK chunk with a State Cookie.Before responding, the endpointMUST check to see if the unexpected INIT chunkadds new addresses to the association.If new addresses are added to the association, the endpointMUST respond withan ABORT chunk, copying the 'Initiate Tag' of the unexpected INIT chunk into the'Verification Tag' of the outbound packet carrying the ABORT chunk.In the ABORT chunk, the error causeMAY be set to "Restart of anAssociation with New Addresses".The errorSHOULD list the addresses that were added to the restartingassociation.If no new addresses are added, when responding to the INIT chunk in the outboundINIT ACK chunk, the endpointMUST copy its current Tie-Tags to a reserved placewithin the State Cookie and the association's TCB.We refer to these locations inside the cookie as the Peer's-Tie-Tag andthe Local-Tie-Tag.We will refer to the copy within an association's TCB as the Local Tag andPeer's Tag.The outbound SCTP packet containing this INIT ACK chunkMUST carry aVerification Tag value equal to the Initiate Tag found in the unexpectedINIT chunk.And the INIT ACK chunkMUST contain a new Initiate Tag(randomly generated; seeSection 5.3.1).Other parameters for the endpointSHOULD be copied from the existingparameters of the association (e.g., number of outbound streams) into theINIT ACK chunk and cookie.¶
After sending the INIT ACK or ABORT chunk, the endpointMUST take nofurther actions,i.e., the existing association, including its current state, and thecorresponding TCBMUST NOT be changed.¶
Only when a TCB exists and the association is not in a COOKIE-WAITor SHUTDOWN-ACK-SENT state are the Tie-Tags populated with a random valueother than 0.For a normal association INIT chunk (i.e., the endpoint is in the CLOSED state),the Tie-TagsMUST be set to 0 (indicating that no previous TCB existed).¶
If an INIT ACK chunk is received by an endpoint in any state other than theCOOKIE-WAIT or CLOSED state, the endpointSHOULD discard the INIT ACK chunk.An unexpected INIT ACK chunk usually indicates the processing of an old orduplicated INIT chunk.¶
When a COOKIE ECHO chunk is received by an endpoint in any state for anexisting association (i.e., not in the CLOSED state), the following rulesare applied:¶
Compute a MAC as described in step 1 ofSection 5.1.5.¶
Authenticate the State Cookie as described in step 2 ofSection 5.1.5(this is case C or D above).¶
Compare the timestamp in the State Cookie to the current time.If the State Cookie is older than the lifespan carried in the State Cookieand the Verification Tags contained in the State Cookie do not match thecurrent association's Verification Tags, the packet, including the COOKIE ECHOchunk and any DATA chunks,SHOULD be discarded.The endpoint alsoMUST transmit an ERROR chunk with a "Stale Cookie" error causeto the peer endpoint (this is case C or D inSection 5.2).¶
If both Verification Tags in the State Cookie match the Verification Tags ofthe current association, consider the State Cookie valid (this is case E inSection 5.2), even if thelifespan is exceeded.¶
If the State Cookie proves to be valid, unpack the TCB into atemporary TCB.¶
Refer toTable 12 to determine thecorrect action to be taken.¶
| Local Tag | Peer's Tag | Local-Tie-Tag | Peer's-Tie-Tag | Action |
|---|---|---|---|---|
| X | X | M | M | (A) |
| M | X | A | A | (B) |
| M | 0 | A | A | (B) |
| X | M | 0 | 0 | (C) |
| M | M | A | A | (D) |
Legend:¶
For any case not shown inTable 12,the cookieSHOULD be silently discarded.¶
Action:¶
In this case, the peer might have restarted. When the endpointrecognizes this potential 'restart', the existing session istreated the same as if it received an ABORT chunk followed by a newCOOKIE ECHO chunk with the following exceptions:¶
Any SCTP DATA chunksMAY be retained (this is an implementation-specificoption).¶
A RESTART notificationSHOULD be sent to the ULP instead of aCOMMUNICATION LOST notification.¶
All the congestion control parameters (e.g., cwnd, ssthresh)related to this peerMUST be reset to their initial values(seeSection 6.2.1).¶
After this, the endpoint enters the ESTABLISHED state.¶
If the endpoint is in the SHUTDOWN-ACK-SENT state and recognizes that the peerhas restarted (Action A), itMUST NOT set up a new association but insteadresend the SHUTDOWN ACK chunk and send an ERROR chunk with a"Cookie Received While Shutting Down" error cause to its peer.¶
In this case, both sides might be attempting to start an associationat about the same time, but the peer endpoint sent its INIT chunkafter responding to the local endpoint's INIT chunk.Thus, it might have picked a new Verification Tag, not being aware of theprevious tag it had sent this endpoint.The endpointSHOULD stay in or enter the ESTABLISHED state, but itMUST updateits peer's Verification Tag from the State Cookie, stop any T1-init orT1-cookie timers that might be running, and send a COOKIE ACK chunk.¶
In this case, the local endpoint's cookie has arrived late.Before it arrived, the local endpoint sent an INIT chunk and received anINIT ACK chunk and finally sent a COOKIE ECHO chunk with the peer's same tagbut a new tag of its own.The cookieSHOULD be silently discarded.The endpointSHOULD NOT change states andSHOULD leave any timers running.¶
When both local and remote tags match, the endpointSHOULD enter theESTABLISHED state if it is in the COOKIE-ECHOED state.ItSHOULD stop any T1-cookie timer that is running and send a COOKIE ACK chunk.¶
Note: The "peer's Verification Tag" is the tag received in the Initiate Tagfield of the INIT or INIT ACK chunk.¶
In the following example, "A" initiates the association after a restarthas occurred.Endpoint "Z" had no knowledge of the restart until the exchange (i.e.,Heartbeats had not yet detected the failure of "A")(assuming no bundling or fragmentation occurs):¶
Endpoint A Endpoint Z<-------------- Association is established---------------------->Tag=Tag_A Tag=Tag_Z<--------------------------------------------------------------->{A crashes and restarts}{app sets up an association with Z}(build TCB)INIT [I-Tag=Tag_A' & other info] --------\(Start T1-init timer) \(Enter COOKIE-WAIT state) \---> (find an existing TCB, populate TieTags if needed, compose Cookie_Z with Tie-Tags and other info) /--- INIT ACK [Veri Tag=Tag_A', / I-Tag=Tag_Z',(Cancel T1-init timer) <------/ Cookie_Z] (leave original TCB in place)COOKIE ECHO [Veri=Tag_Z', Cookie_Z]-------\(Start T1-init timer) \(Enter COOKIE-ECHOED state) \---> (Find existing association, Tie-Tags in Cookie_Z match Tie-Tags in TCB, Tags do not match, i.e., case X X M M above, Announce Restart to ULP and reset association). /---- COOKIE ACK(Cancel T1-init timer, <------/ Enter ESTABLISHED state){app sends 1st user data; strm 0}DATA [TSN=Initial TSN_A Strm=0,Seq=0 & user data]--\(Start T3-rtx timer) \ \-> /--- SACK [TSN Ack=init TSN_A,Block=0](Cancel T3-rtx timer) <------/At any state other than COOKIE-ECHOED, an endpointSHOULD silentlydiscard a received COOKIE ACK chunk.¶
Receipt of an ERROR chunk with a "Stale Cookie" error cause indicatesone of a number of possible events:¶
The association failed to completely set up before the State Cookie issued bythe sender was processed.¶
An old State Cookie was processed after setup completed.¶
An old State Cookie is received from someone that the receiver is notinterested in having an association with and the ABORT chunk was lost.¶
When processing an ERROR chunk with a "Stale Cookie" error cause, an endpointSHOULD first examine if an association is in the process of being set up, i.e.,the association is in the COOKIE-ECHOED state.In all cases, if the association is not in the COOKIE-ECHOED state, theERROR chunkSHOULD be silently discarded.¶
If the association is in the COOKIE-ECHOED state, the endpointMAY electone of the following three alternatives.¶
Send a new INIT chunk to the endpoint to generate a new State Cookie andreattempt the setup procedure.¶
Discard the TCB and report to the upper layer the inability to set upthe association.¶
Send a new INIT chunk to the endpoint, adding a Cookie Preservativeparameter requesting an extension to the life time of the State Cookie.When calculating the time extension, an implementationSHOULD use the RTTinformation measured based on the previous COOKIE ECHO/ERROR chunk exchangeandSHOULD add no more than 1 second beyond the measured RTT, due to longState Cookie life times making the endpoint more subject to a replay attack.¶
Initiate Tag valuesSHOULD be selected from the range of 1 to 232 - 1.It is very important that the Initiate Tag value be randomized tohelp protect against off-path attacks.The methods described in[RFC4086] can be used for theInitiate Tag randomization.Careful selection of Initiate Tags is also necessary to prevent old duplicatepackets from previous associations being mistakenly processed as belongingto the current association.¶
Moreover, the Verification Tag value used by either endpoint in agiven associationMUST NOT change during the life time of an association.A new Verification Tag valueMUST be used each time the endpoint tears downand then reestablishes an association to the same peer.¶
During association establishment, the two peers exchange a list ofaddresses.In the predominant case, these lists accurately represent the addressesowned by each peer.However, a misbehaving peer might supply addresses that it does not own.To prevent this, the following rules are applied to all addresses of thenew association:¶
Any addresses passed to the sender of the INIT chunk by its upper layerin the request to initialize an association are automatically considered to beCONFIRMED.¶
For the receiver of the COOKIE ECHO chunk, the only CONFIRMED addressis the address to which the packet containing the INIT ACK chunk was sent.¶
All other addresses not covered by rules 1 and 2 are consideredUNCONFIRMED and are subject to probing for verification.¶
To probe an address for verification, an endpoint will sendHEARTBEAT chunks including a 64-bit random nonce and a path indicator (toidentify the address that the HEARTBEAT chunk is sent to) within the HeartbeatInfo parameter.¶
Upon receipt of the HEARTBEAT ACK chunk, a verification is made that thenonce included in the Heartbeat Info parameter is the one sent to theaddress indicated inside the Heartbeat Info parameter.When this match occurs, the address that the original HEARTBEAT was sent tois now considered CONFIRMED and available for normal data transfer.¶
These probing procedures are started when an association moves to theESTABLISHED state and are ended when all paths are confirmed.¶
In each RTO, a probeMAY be sent on an active UNCONFIRMED path in anattempt to move it to the CONFIRMED state.If during this probing the path becomes inactive, this rate is lowered to thenormal HEARTBEAT rate.At the expiration of the RTO timer, the error counter of any path that wasprobed but not CONFIRMED is incremented by one and subjected to path failuredetection, as defined inSection 8.2.When probing UNCONFIRMED addresses, however, the association overall errorcount is not incremented.¶
The number of packets containing HEARTBEAT chunks sent at each RTOSHOULDbe limited by the 'HB.Max.Burst' parameter.It is an implementation decision as to how to distribute packets containingHEARTBEAT chunks to the peer's addresses for path verification.¶
Whenever a path is confirmed, an indicationMAY be given to the upperlayer.¶
An endpointMUST NOT send any chunks to an UNCONFIRMED address, withthe following exceptions:¶
A HEARTBEAT chunk including a nonceMAY be sent to an UNCONFIRMED address.¶
A HEARTBEAT ACK chunkMAY be sent to an UNCONFIRMED address.¶
A COOKIE ACK chunkMAY be sent to an UNCONFIRMED address, but itMUST bebundled with a HEARTBEAT chunk including a nonce.An implementation that does not support bundlingMUST NOT send a COOKIE ACKchunk to an UNCONFIRMED address.¶
A COOKIE ECHO chunkMAY be sent to an UNCONFIRMED address, but itMUSTbe bundled with a HEARTBEAT chunk including a nonce, and the size of theSCTP packetMUST NOT exceed the PMTU.If the implementation does not support bundling or if the bundled COOKIE ECHOchunk plus HEARTBEAT chunk (including nonce) would result in an SCTP packetlarger than the PMTU, then the implementationMUST NOT send a COOKIE ECHO chunkto an UNCONFIRMED address.¶
Data transmissionMUST only happen in the ESTABLISHED, SHUTDOWN-PENDING,and SHUTDOWN-RECEIVED states.The only exception to this is that DATA chunks are allowed to be bundled withan outbound COOKIE ECHO chunk when in the COOKIE-WAIT state.¶
DATA chunksMUST only be received according to the rules below inESTABLISHED, SHUTDOWN-PENDING, and SHUTDOWN-SENT states.A DATA chunk received in CLOSED is out of the blue andSHOULD be handled perSection 8.4.A DATA chunk received in any other stateSHOULD be discarded.¶
A SACK chunkMUST be processed in ESTABLISHED, SHUTDOWN-PENDING, andSHUTDOWN-RECEIVED states.An incoming SACK chunkMAY be processed in COOKIE-ECHOED.A SACK chunk in the CLOSED state is out of the blue andSHOULD be processedaccording to the rules inSection 8.4.A SACK chunk received in any other stateSHOULD be discarded.¶
For transmission efficiency, SCTP defines mechanisms for bundling ofsmall user messages and fragmentation of large user messages.The following diagram depicts the flow of user messages through SCTP.¶
In this section, the term "data sender" refers to the endpoint thattransmits a DATA chunk, and the term "data receiver" refers to theendpoint that receives a DATA chunk.A data receiver will transmit SACK chunks.¶
+-------------------------+ | User Messages | +-------------------------+ SCTP user ^ |==================|==|======================================= | v (1) +------------------+ +---------------------+ | SCTP DATA Chunks | | SCTP Control Chunks | +------------------+ +---------------------+ ^ | ^ | | v (2) | v (2) +--------------------------+ | SCTP packets | +--------------------------+ SCTP ^ |===========================|==|=========================== | v Connectionless Packet Transfer Service (e.g., IP)
The following applies:¶
When converting user messages into DATA chunks, an endpointMUST fragment large user messages into multiple DATA chunks.The size of each DATA chunkSHOULD be smaller than or equal to theAssociation Maximum DATA Chunk Size (AMDCS).The data receiver will normally reassemble the fragmented message from DATAchunks before delivery to the user (seeSection 6.9for details).¶
Multiple DATA and control chunksMAY be bundled by the sender into a singleSCTP packet for transmission, as long as the final size of the SCTP packet doesnot exceed the current PMTU.The receiver will unbundle the packet back into the original chunks.Control chunksMUST come before DATA chunks in the packet.¶
The fragmentation and bundling mechanisms, as detailed in Sections6.9 and6.10, areOPTIONALto implement by the data sender, but theyMUST be implemented by the datareceiver, i.e., an endpointMUST properly receive and process bundled orfragmented data.¶
This section specifies the rules for sending DATA chunks.In particular, it defines zero window probing, which is required toavoid the indefinite stalling of an association in case of a loss ofpackets containing SACK chunks performing window updates.¶
This document is specified as if there is a single retransmission timerper destination transport address, but implementationsMAY have aretransmission timer for each DATA chunk.¶
The following general rulesMUST be applied by the data sender fortransmission and/or retransmission of outbound DATA chunks:¶
At any given time, the data senderMUST NOT transmit new data toany destination transport address if its peer's rwnd indicatesthat the peer has no buffer space (i.e., rwnd is smaller than the size of thenext DATA chunk; seeSection 6.2.1),except for zero window probes.¶
A zero window probe is a DATA chunk sent when the receiver has no bufferspace.This rule allows the sender to probe for a change in rwnd that the sendermissed due to the SACK chunks having been lost in transit from the datareceiver to the data sender.A zero window probeMUST only be sent when the cwnd allows (see rule B below).A zero window probeSHOULD only be sent when all outstanding DATA chunks havebeen cumulatively acknowledged and no DATA chunks are in flight.SendersMUST support zero window probing.¶
If the sender continues to receive SACK chunks from the peer while doing zero window probing, the unacknowledged window probesSHOULD NOT increment theerror counter for the association or any destination transport address.This is because the receiver could keep its window closed for an indefinite time.Section 6.2 describes thereceiver behavior when it advertises a zero window.The senderSHOULD send the first zero window probe after 1 RTO when it detectsthat the receiver has closed its window andSHOULD increase the probe intervalexponentially afterwards.Also note that the cwndSHOULD be adjusted according toSection 7.2.1.Zero window probing does not affect the calculation of cwnd.¶
The senderMUST also have an algorithm for sending new DATA chunks to avoidsilly window syndrome (SWS) as described in[RFC1122].The algorithm can be similar to the one described inSection 4.2.3.4 of [RFC1122].¶
At any given time, the senderMUST NOT transmit new data to a giventransport address if it has cwnd + (PMDCS - 1) or more bytes of data outstandingto that transport address.If data is available, the senderSHOULD exceed cwnd by up to (PMDCS - 1) byteson a new data transmission if the flightsize does not currently reach cwnd.The breach of cwndMUST constitute one packet only.¶
When the time comes for the sender to transmit, before sending newDATA chunks, the senderMUST first transmit any DATA chunks that are markedfor retransmission (limited by the current cwnd).¶
When the time comes for the sender to transmit new DATA chunks, theprotocol parameter 'Max.Burst'SHOULD be used to limit the number of packets sent.The limitMAY be applied by adjusting cwnd temporarily, as follows:¶
if ((flightsize + Max.Burst * PMDCS) < cwnd) cwnd = flightsize + Max.Burst * PMDCS¶
Or, itMAY be applied by strictly limiting the number of packets emitted bythe output routine.When calculating the number of packets to transmit, and particularly whenusing the formula above, cwndSHOULD NOT be changed permanently.¶
Then, the sender can send as many new DATA chunks as rule A and rule Ballow.¶
Multiple DATA chunks committed for transmissionMAY be bundled in asingle packet.Furthermore, DATA chunks being retransmittedMAY be bundled with newDATA chunks, as long as the resulting SCTP packet size does not exceed the PMTU.A ULP can request that no bundling is performed, but this only turns offany delays that an SCTP implementation might be using to increase bundlingefficiency.It does not in itself stop all bundling from occurring (i.e., in case ofcongestion or retransmission).¶
Before an endpoint transmits a DATA chunk, if any received DATAchunks have not been acknowledged (e.g., due to delayed ack), thesenderSHOULD create a SACK chunk and bundle it with the outbound DATAchunk, as long as the size of the final SCTP packet does not exceedthe current PMTU.SeeSection 6.2.¶
When the window is full (i.e., transmission isdisallowed by rule A and/or rule B), the senderMAY still accept sendrequests from its upper layer butMUST transmit no more DATA chunksuntil some or all of the outstanding DATA chunks are acknowledged andtransmission is allowed by rule A and rule B again.¶
Whenever a transmission or retransmission is made to any address, ifthe T3-rtx timer of that address is not currently running, the senderMUST start that timer.If the timer for that address is already running, the senderMUST restartthe timer if the earliest (i.e., lowest TSN) outstanding DATA chunk sent tothat address is being retransmitted.Otherwise, the data senderMUST NOT restart the timer.¶
When starting or restarting the T3-rtx timer, the timer valueSHOULD beadjusted according to the timer rules defined in Sections6.3.2 and6.3.3.¶
The data senderMUST NOT use a TSN that is more than 231 - 1 abovethe beginning TSN of the current send window.¶
For each stream, the data senderMUST NOT have more than 216 - 1ordered user messages in the current send window.¶
Whenever the sender of a DATA chunk can benefit from the correspondingSACK chunk being sent back without delay, the senderMAY set the I bit in theDATA chunk header.Please note that why the sender has set the I bit is irrelevant to thereceiver.¶
Reasons for setting the I bit include, but are not limited to, thefollowing (seeSection 4 of [RFC7053] for a discussion of thebenefits):¶
The application requests that the I bit of the last DATA chunk ofa user message be set when providing the user message to the SCTPimplementation (seeSection 11.1).¶
The sender is in the SHUTDOWN-PENDING state.¶
The sending of a DATA chunk fills the congestion or receiver window.¶
The SCTP endpointMUST always acknowledge the reception of each validDATA chunk when the DATA chunk received is inside its receive window.¶
When the receiver's advertised window is 0, the receiverMUST dropany new incoming DATA chunk with a TSN larger than the largest TSNreceived so far.Also, if the new incoming DATA chunk holds a TSN value less than the largestTSN received so far, then the receiverSHOULD drop the largest TSN held forreordering and accept the new incoming DATA chunk.In either case, if such a DATA chunk is dropped, the receiverMUST immediatelysend back a SACK chunk with the current receive window showing only DATA chunksreceived and accepted so far.The dropped DATA chunk(s)MUST NOT be included in the SACK chunk, as they werenot accepted.The receiverMUST also have an algorithm for advertising its receive windowto avoid receiver silly window syndrome (SWS), as described in[RFC1122].The algorithm can be similar to the one described inSection 4.2.3.3 of [RFC1122].¶
The guidelines on the delayed acknowledgement algorithm specified inSection 4.2 of [RFC5681]SHOULD be followed.Specifically, an acknowledgementSHOULD be generated for at least everysecond packet (not every second DATA chunk) received andSHOULD be generatedwithin 200 ms of the arrival of any unacknowledged DATA chunk.In some situations, it might be beneficial for an SCTP transmitter to bemore conservative than the algorithms detailed in this document allow.However, an SCTP transmitterMUST NOT be more aggressive in sending SACK chunksthan the following algorithms allow.¶
An SCTP receiverMUST NOT generate more than one SACK chunk for everyincoming packet, other than to update the offered window as thereceiving application consumes new data.When the window opens up, an SCTP receiverSHOULD send additional SACK chunksto update the window even if no new data is received.The receiverMUST avoid sending a large number of window updates -- inparticular, large bursts of them.One way to achieve this is to send a window update only if the window can beincreased by at least a quarter of the receive buffer size of theassociation.¶
Implementation Note: The maximum delay for generating an acknowledgementMAY be configured by the SCTP administrator, either statically or dynamically,in order to meet the specific timing requirement of the protocol beingcarried.¶
An implementationMUST NOT allow the maximum delay (protocol parameter'SACK.Delay') to be configured to be more than 500 ms.In other words, an implementationMAY lower the value of 'SACK.Delay'below 500 ms butMUST NOT raise it above 500 ms.¶
AcknowledgementsMUST be sent in SACK chunks unless shutdown wasrequested by the ULP, in which case an endpointMAY send anacknowledgement in the SHUTDOWN chunk.A SACK chunk can acknowledge the reception of multiple DATA chunks.SeeSection 3.3.4 for SACK chunk format.In particular, the SCTP endpointMUST fill in the Cumulative TSN Ack field toindicate the latest sequential TSN (of a valid DATA chunk) it has received.Any received DATA chunks with TSN greater than the value in theCumulative TSN Ack field are reported in the Gap Ack Block fields.The SCTP endpointMUST report as many Gap Ack Blocks as can fit in a single SACKchunk such that the size of the SCTP packet does not exceed the current PMTU.¶
The SHUTDOWN chunk does not contain Gap Ack Block fields.Therefore, the endpointSHOULD use a SACK chunk instead of the SHUTDOWNchunk to acknowledge DATA chunks received out of order.¶
Upon receipt of an SCTP packet containing a DATA chunk with the I bit set,the receiverSHOULD NOT delay the sending of the corresponding SACK chunk, i.e.,the receiverSHOULD immediately respond with the corresponding SACK chunk.¶
When a packet arrives with duplicate DATA chunk(s) and with no newDATA chunk(s), the endpointMUST immediately send a SACK chunk with nodelay.If a packet arrives with duplicate DATA chunk(s) bundled withnew DATA chunks, the endpointMAY immediately send a SACK chunk.Normally, receipt of duplicate DATA chunks will occur when the original SACKchunk was lost and the peer's RTO has expired.The duplicate TSN number(s)SHOULD be reported in the SACK chunk as duplicate.¶
When an endpoint receives a SACK chunk, itMAY use the duplicate TSNinformation to determine if SACK chunk loss is occurring.Further use of this data is for future study.¶
The data receiver is responsible for maintaining its receive buffers.The data receiverSHOULD notify the data sender in a timely manner ofchanges in its ability to receive data.How an implementation manages its receive buffers is dependent on manyfactors (e.g., operating system, memory management system, amount of memory,etc.).However, the data sender strategy defined inSection 6.2.1 is based on the assumption ofreceiver operation similar to the following:¶
At initialization of the association, the endpoint tells the peerhow much receive buffer space it has allocated to the associationin the INIT or INIT ACK chunk.The endpoint sets a_rwnd to this value.¶
As DATA chunks are received and buffered, decrement a_rwnd by thenumber of bytes received and buffered.This is, in effect, closing rwnd at the data sender and restricting the amountof data it can transmit.¶
As DATA chunks are delivered to the ULP and released from thereceive buffers, increment a_rwnd by the number of bytes deliveredto the upper layer.This is, in effect, opening up rwnd on the data sender and allowing it tosend more data.The data receiverSHOULD NOT increment a_rwnd unless it has released bytesfrom its receive buffer.For example, if the receiver is holding fragmented DATA chunks in a reassemblyqueue, itSHOULD NOT increment a_rwnd.¶
When sending a SACK chunk, the data receiverSHOULD place the currentvalue of a_rwnd into the a_rwnd field.The data receiverSHOULD take into account that the data sender will notretransmit DATA chunks that are acked via the Cumulative TSN Ack (i.e., willdrop from its retransmit queue).¶
Under certain circumstances, the data receiverMAY drop DATAchunks that it has received but has not released from its receivebuffers (i.e., delivered to the ULP).These DATA chunks might have been acked in Gap Ack Blocks.For example, the data receiver might be holding data in its receive bufferswhile reassembling a fragmented user message from its peer when it runs out ofreceive buffer space.ItMAY drop these DATA chunks even though it has acknowledged them inGap Ack Blocks.If a data receiver drops DATA chunks, itMUST NOT include them in Gap Ack Blocksin subsequent SACK chunks until they are received again via retransmission.In addition, the endpointSHOULD take into account the dropped data whencalculating its a_rwnd.¶
An endpointSHOULD NOT revoke a SACK chunk and discard data.Only in extreme circumstances might an endpoint use this procedure (such asout of buffer space).The data receiverSHOULD take into account that dropping data that has beenacked in Gap Ack Blocks can result in suboptimal retransmission strategies inthe data sender and thus in suboptimal performance.¶
The following example illustrates the use of delayed acknowledgements:¶
Endpoint A Endpoint Z{App sends 3 messages; strm 0}DATA [TSN=7,Strm=0,Seq=3] ------------> (ack delayed)(Start T3-rtx timer)DATA [TSN=8,Strm=0,Seq=4] ------------> (send ack) /------- SACK [TSN Ack=8,block=0](cancel T3-rtx timer) <-----/DATA [TSN=9,Strm=0,Seq=5] ------------> (ack delayed)(Start T3-rtx timer) ... {App sends 1 message; strm 1} (bundle SACK with DATA) /----- SACK [TSN Ack=9,block=0] \ / DATA [TSN=6,Strm=1,Seq=2](cancel T3-rtx timer) <------/ (Start T3-rtx timer)(ack delayed)(send ack)SACK [TSN Ack=6,block=0] -------------> (cancel T3-rtx timer)If an endpoint receives a DATA chunk with no user data (i.e., theLength field is set to 16), itSHOULD send an ABORT chunk with a "No User Data"error cause.¶
An endpointSHOULD NOT send a DATA chunk with no user data part.This avoids the need to be able to return a zero-length usermessage in the API, especially in the socket API as specified in[RFC6458] for details.¶
Each SACK chunk an endpoint receives contains an a_rwnd value.This value represents the amount of buffer space the data receiver, at the timeof transmitting the SACK chunk, has left of its total receive buffer space(as specified in the INIT/INIT ACK chunk).Using a_rwnd, Cumulative TSN Ack, and Gap Ack Blocks, the data sender candevelop a representation of the peer's receive buffer space.¶
One of the problems the data sender takes into account whenprocessing a SACK chunk is that a SACK chunk can be received out of order.That is, a SACK chunk sent by the data receiver can pass an earlier SACK chunkand be received first by the data sender.If a SACK chunk is received out of order, the data sender can develop anincorrect view of the peer's receive buffer space.¶
Since there is no explicit identifier that can be used to detect out-of-orderSACK chunks, the data sender uses heuristics to determine if a SACK chunk isnew.¶
An endpointSHOULD use the following rules to calculate the rwnd,using the a_rwnd value, the Cumulative TSN Ack, and Gap Ack Blocks ina received SACK chunk.¶
At the establishment of the association, the endpoint initializesthe rwnd to the Advertised Receiver Window Credit (a_rwnd) the peer specifiedin the INIT or INIT ACK chunk.¶
Any time a DATA chunk is transmitted (or retransmitted) to a peer, theendpoint subtracts the data size of the chunk from the rwnd of that peer.¶
Any time a DATA chunk is marked for retransmission, either via T3-rtx timerexpiration (Section 6.3.3) orvia Fast Retransmit (Section 7.2.4),add the data size of those chunks to the rwnd.¶
Any time a SACK chunk arrives, the endpoint performs the following:¶
If Cumulative TSN Ack is less than the Cumulative TSN Ack Point,then drop the SACK chunk.Since Cumulative TSN Ack is monotonically increasing, a SACK chunk whoseCumulative TSN Ack is less than the Cumulative TSN Ack Point indicates anout-of-order SACK chunk.¶
Set rwnd equal to the newly received a_rwnd minus the number of bytes stilloutstanding after processing the Cumulative TSN Ack and the Gap Ack Blocks.¶
If the SACK chunk is missing a TSN that was previously acknowledged viaa Gap Ack Block (e.g., the data receiver reneged on the data), then considerthe corresponding DATA that might be possibly missing:Count one miss indication towards Fast Retransmit as described inSection 7.2.4,and if no retransmit timer is running for the destination address to which theDATA chunk was originally transmitted, then T3-rtx is started for thatdestination address.¶
If the Cumulative TSN Ack matches or exceeds the Fast Recovery exit point(Section 7.2.4),Fast Recovery is exited.¶
An SCTP endpoint uses a retransmission timer T3-rtx to ensure datadelivery in the absence of any feedback from its peer.The duration of this timer is referred to as RTO (retransmission timeout).¶
When an endpoint's peer is multi-homed, the endpoint will calculate aseparate RTO for each different destination transport address of itspeer endpoint.¶
The computation and management of RTO in SCTP follow closely how TCPmanages its retransmission timer.To compute the current RTO, an endpoint maintains two state variables perdestination transport address: SRTT (smoothed round-trip time) andRTTVAR (round-trip time variation).¶
The rules governing the computation of SRTT, RTTVAR, and RTO are as follows:¶
Until an RTT measurement has been made for a packet sent to the givendestination transport address, set RTO to the protocol parameter'RTO.Initial'.¶
When the first RTT measurement R is made, perform:¶
SRTT = RRTTVAR = R/2RTO = SRTT + 4 * RTTVAR¶
When a new RTT measurement R' is made, perform:¶
RTTVAR = (1 - RTO.Beta) * RTTVAR + RTO.Beta * |SRTT - R'|SRTT = (1 - RTO.Alpha) * SRTT + RTO.Alpha * R'¶
Note: The value of SRTT used in the update to RTTVAR is itsvalue before updating SRTT itself using the second assignment.¶
After the computation, update:¶
RTO = SRTT + 4 * RTTVAR¶
When data is in flight and when allowed by rule C5 below, a newRTT measurementMUST be made each round trip.Furthermore, new RTT measurementsSHOULD be made no more than once perround trip for a given destination transport address.There are two reasons for this recommendation:First, it appears that measuring more frequently often does not in practiceyield any significant benefit[ALLMAN99];second, if measurements are made more often, then the values of 'RTO.Alpha' and'RTO.Beta' in rule C3 aboveSHOULD be adjusted so that SRTT and RTTVAR stilladjust to changes at roughly the same rate (in terms of how many roundtrips it takes them to reflect new values) as they would if making only onemeasurement per round trip and using 'RTO.Alpha' and 'RTO.Beta' as given in rule C3.However, the exact nature of these adjustments remains a research issue.¶
Karn's algorithm: RTT measurementsMUST NOT be made using chunks thatwere retransmitted (and thus for which it is ambiguous whether the reply wasfor the first instance of the chunk or for a later instance).¶
RTT measurementsSHOULD only be made using a DATA chunk with TSN r if noDATA chunk with TSN less than or equal to r was retransmitted since the DATAchunk with TSN r was sent first.¶
Whenever RTO is computed, if it is less than 'RTO.Min' seconds, then it isrounded up to 'RTO.Min' seconds.The reason for this rule is that RTOs that do not have a high minimum value aresusceptible to unnecessary timeouts[ALLMAN99].¶
A maximum valueMAY be placed on RTO, provided it is at least'RTO.Max' seconds.¶
There is no requirement for the clock granularity G used for computingRTT measurements and the different state variables, other than:¶
Whenever RTTVAR is computed, if RTTVAR == 0, then adjust RTTVAR = G.¶
Experience[ALLMAN99] has shown that finer clock granularities(less than 100 msec) perform somewhat better than more coarse granularities.¶
SeeSection 16 for suggested parameter values.¶
The rules for managing the retransmission timer are as follows:¶
Every time a DATA chunk is sent to any address (including a retransmission),if the T3-rtx timer of that address is not running, start it running so thatit will expire after the RTO of that address. The RTO used here is that obtained after any doubling due to previousT3-rtx timer expirations on the corresponding destination address as discussedin rule E2 below.¶
Whenever all outstanding data sent to an address have been acknowledged,turn off the T3-rtx timer of that address.¶
Whenever a SACK chunk is received that acknowledges the DATA chunk withthe earliest outstanding TSN for that address, restart the T3-rtx timer for thataddress with its current RTO (if there is still outstanding data on thataddress).¶
Whenever a SACK chunk is received missing a TSN that was previouslyacknowledged via a Gap Ack Block, start the T3-rtx for the destination addressto which the DATA chunk was originally transmitted if it is not alreadyrunning.¶
The following example shows the use of various timer rules (assumingthat the receiver uses delayed acks).¶
Endpoint A Endpoint Z{App begins to send}Data [TSN=7,Strm=0,Seq=3] ------------> (ack delayed)(Start T3-rtx timer) {App sends 1 message; strm 1} (bundle ack with data)DATA [TSN=8,Strm=0,Seq=4] ----\ /-- SACK [TSN Ack=7,Block=0] \ / DATA [TSN=6,Strm=1,Seq=2] \ / (Start T3-rtx timer) \ / \(Restart T3-rtx timer) <------/ \--> (ack delayed)(ack delayed){send ack}SACK [TSN Ack=6,Block=0] --------------> (Cancel T3-rtx timer) .. (send ack)(Cancel T3-rtx timer) <-------------- SACK [TSN Ack=8,Block=0]Whenever the retransmission timer T3-rtx expires for a destination address,do the following:¶
For the destination address for which the timer expires, adjust its ssthreshwith rules defined inSection 7.2.3 and setcwnd = PMDCS.¶
For the destination address for which the timer expires, setRTO = RTO * 2 ("back off the timer").The maximum value discussed in rule C7 above ('RTO.Max')MAY be used to providean upper bound to this doubling operation.¶
Determine how many of the earliest (i.e., lowest TSN) outstandingDATA chunks for the address for which the T3-rtx has expired will fit into asingle SCTP packet, subject to the PMTU corresponding to thedestination transport address to which the retransmission is being sent(this might be different from the address for which the timer expires;seeSection 6.4).Call this value K.Bundle and retransmit those K DATA chunks in a single packet to the destinationendpoint.¶
Start the retransmission timer T3-rtx on the destination address to whichthe retransmission is sent if rule R1 above indicates to do so.The RTO to be used for starting T3-rtxSHOULD be the one for the destinationaddress to which the retransmission is sent, which, when the receiver ismulti-homed, might be different from the destination address for which thetimer expired (seeSection 6.4 below).¶
After retransmitting, once a new RTT measurement is obtained (which canhappen only when new data has been sent and acknowledged, per rule C5,or for a measurement made from a HEARTBEAT chunk;seeSection 8.3), the computation in rule C3 isperformed, including the computation of RTO, which might result in "collapsing"RTO back down after it has been subject to doubling (rule E2).¶
Any DATA chunks that were sent to the address for which theT3-rtx timer expired but did not fit in an SCTP packet of size smaller than orequal to the PMTU (rule E3 above)SHOULD be marked for retransmission and sentas soon as cwnd allows (normally, when a SACK chunk arrives).¶
The final rule for managing the retransmission timer concerns failover(seeSection 6.4.1):¶
Whenever an endpoint switches from the current destinationtransport address to a different one, the current retransmissiontimers are left running.As soon as the endpoint transmits a packet containing DATA chunk(s) to thenew transport address, start the timer on that transport address, using theRTO value of the destination address to which the data is being sent, ifrule R1 indicates to do so.¶
An SCTP endpoint is considered multi-homed if there is more than onetransport address that can be used as a destination address to reach thatendpoint.¶
Moreover, the ULP of an endpoint selects one of the multipledestination addresses of a multi-homed peer endpoint as the primarypath (see Sections5.1.2 and11.1 for details).¶
By default, an endpointSHOULD always transmit to the primary path,unless the SCTP user explicitly specifies the destination transportaddress (and possibly source transport address) to use.¶
An endpointSHOULD transmit reply chunks (e.g., INIT ACK, COOKIE ACK, andHEARTBEAT ACK) in response to control chunks to the same destinationtransport address from which it received the control chunk to whichit is replying.¶
The selection of the destination transport address for packetscontaining SACK chunks is implementation dependent.However, an endpointSHOULD NOT vary the destination transport address ofa SACK chunk when it receives DATA chunks coming from the same sourceaddress.¶
When acknowledging multiple DATA chunks received in packetsfrom different source addresses in a single SACK chunk, the SACK chunkMAYbe transmitted to one of the destination transport addresses fromwhich the DATA or control chunks being acknowledged were received.¶
When a receiver of a duplicate DATA chunk sends a SACK chunk to a multi-homedendpoint, itMAY be beneficial to vary the destination addressand not use the source address of the DATA chunk.The reason is that receiving a duplicate from a multi-homed endpoint mightindicate that the return path (as specified in the source address of the DATAchunk) for the SACK chunk is broken.¶
Furthermore, when its peer is multi-homed, an endpointSHOULD try toretransmit a chunk that timed out to an active destination transportaddress that is different from the last destination address to whichthe chunk was sent.¶
When its peer is multi-homed, an endpointSHOULD send fast retransmissionsto the same destination transport address to which the original data was sent.If the primary path has been changed and the original data was sent to theold primary path before the Fast Retransmit, the implementationMAY send it tothe new primary path.¶
Retransmissions do not affect the total outstanding data count.However, if the DATA chunk is retransmitted onto a different destinationaddress, both the outstanding data counts on the new destination address andthe old destination address to which the data chunk was last sent isadjusted accordingly.¶
Some of the transport addresses of a multi-homed SCTP endpoint might becomeinactive due to either the occurrence of certain error conditions(seeSection 8.2) or adjustments from theSCTP user.¶
When there is outbound data to send and the primary path becomes inactive(e.g., due to failures) or where the SCTP user explicitly requests to send datato an inactive destination transport address before reporting an error to itsULP, the SCTP endpointSHOULD try to send the data to an alternate activedestination transport address if one exists.¶
When retransmitting data that timed out, if the endpoint is multi-homed,it needs to consider each source-destination address pair in itsretransmission selection policy.When retransmitting timed-out data, the endpointSHOULD attempt to pick themost divergent source-destination pair from the original source-destinationpair to which the packet was transmitted.¶
Note: Rules for picking the most divergent source-destination pairare an implementation decision and are not specified within this document.¶
Every DATA chunkMUST carry a valid stream identifier.If an endpoint receives a DATA chunk with an invalid stream identifier, itSHOULD acknowledge the reception of the DATA chunk following thenormal procedure, immediately send an ERROR chunk with cause set to"Invalid Stream Identifier" (seeSection 3.3.10),and discard the DATA chunk.The endpointMAY bundle the ERROR chunk and the SACK chunk in the samepacket.¶
The Stream Sequence Number in all the outgoing streamsMUST start from 0 whenthe association is established.The Stream Sequence Number of an outgoing streamMUST be incremented by 1 foreach ordered user message sent on that outgoing stream.In particular, when the Stream Sequence Number reaches the value 65535, thenext Stream Sequence NumberMUST be set to 0.For unordered user messages, the Stream Sequence NumberMUST NOT be changed.¶
Within a stream, an endpointMUST deliver DATA chunks received withthe U flag set to 0 to the upper layer according to the order oftheir Stream Sequence Number.If DATA chunks arrive out of order of their Stream Sequence Number,the endpointMUST hold the received DATA chunks from delivery to the ULP untilthey are reordered.¶
However, an SCTP endpoint can indicate that no ordered delivery isrequired for a particular DATA chunk transmitted within the stream bysetting the U flag of the DATA chunk to 1.¶
When an endpoint receives a DATA chunk with the U flag set to 1, itbypasses the ordering mechanism and immediately deliver the datato the upper layer (after reassembly if the user data is fragmentedby the data sender).¶
This provides an effective way of transmitting "out-of-band" data ina given stream.Also, a stream can be used as an "unordered" stream by simply setting theU flag to 1 in all DATA chunks sent through that stream.¶
Implementation Note: When sending an unordered DATA chunk, an implementationMAY choose to place the DATA chunk in an outbound packet that is at the head ofthe outbound transmission queue if possible.¶
The 'Stream Sequence Number' field in a DATA chunk with U flag set to1 has no significance.The sender can fill the 'Stream Sequence Number' with arbitrary value, butthe receiverMUST ignore the field.¶
Note: When transmitting ordered and unordered data, an endpoint doesnot increment its Stream Sequence Number when transmitting a DATA chunk withU flag set to 1.¶
Upon the reception of a new DATA chunk, an endpoint examines thecontinuity of the TSNs received.If the endpoint detects a gap in the received DATA chunk sequence, itSHOULDsend a SACK chunk with Gap Ack Blocks immediately.The data receiver continues sending a SACK chunk after receipt of eachSCTP packet that does not fill the gap.¶
Based on the Gap Ack Block from the received SACK chunk, the endpoint cancalculate the missing DATA chunks and make decisions on whether toretransmit them (seeSection 6.2.1for details).¶
Multiple gaps can be reported in one single SACK chunk(seeSection 3.3.4).¶
When its peer is multi-homed, the SCTP endpointSHOULD always try tosend the SACK chunk to the same destination address from which the lastDATA chunk was received.¶
Upon the reception of a SACK chunk, the endpointMUST remove all DATA chunksthat have been acknowledged by the SACK chunk's Cumulative TSN Ack from itstransmit queue.All DATA chunks with TSNs not included in the Gap Ack Blocks that are smallerthan the highest-acknowledged TSN reported in the SACK chunkMUST be treated as"missing" by the sending endpoint.The number of "missing" reports for each outstanding DATA chunkMUST berecorded by the data sender to make retransmission decisions.SeeSection 7.2.4 for details.¶
The following example shows the use of SACK chunk to report a gap.¶
Endpoint A Endpoint Z{App sends 3 messages; strm 0}DATA [TSN=6,Strm=0,Seq=2] ---------------> (ack delayed)(Start T3-rtx timer)DATA [TSN=7,Strm=0,Seq=3] --------> X (lost)DATA [TSN=8,Strm=0,Seq=4] ---------------> (gap detected, immediately send ack) /----- SACK [TSN Ack=6,Block=1, / Start=2,End=2] <-----/(remove 6 from out-queue, and mark 7 as "1" missing report)The maximum number of Gap Ack Blocks that can be reported within asingle SACK chunk is limited by the current PMTU.When a single SACK chunk cannot cover all the Gap Ack Blocks needed to bereported due to the PMTU limitation, the endpointMUST send only one SACK chunk.This single SACK chunkMUST report the Gap Ack Blocks from the lowest tohighest TSNs, within the size limit set by the PMTU, and leave the remaininghighest TSN numbers unacknowledged.¶
When sending an SCTP packet, the endpointMUST strengthen the data integrityof the transmission by including the CRC32c checksum value calculated on thepacket, as described below.¶
After the packet is constructed (containing the SCTP common headerand one or more control or DATA chunks), the transmitterMUST:¶
fill in the proper Verification Tag in the SCTP common header and initializethe checksum field to 0,¶
calculate the CRC32c checksum of the whole packet, including the SCTP commonheader and all the chunks (refer toAppendix A for details ofthe CRC32c algorithm), and¶
put the resultant value into the checksum field in the common header andleave the rest of the bits unchanged.¶
When an SCTP packet is received, the receiverMUST first check the CRC32cchecksum as follows:¶
Store the received CRC32c checksum value aside.¶
Replace the 32 bits of the checksum field in the received SCTP packet with0 and calculate a CRC32c checksum value of the whole received packet.¶
Verify that the calculated CRC32c checksum is the same as the receivedCRC32c checksum.If it is not, the receiverMUST treat the packet as an invalid SCTP packet.¶
The default procedure for handling invalid SCTP packets is to silentlydiscard them.¶
Any hardware implementationSHOULD permit alternative verification of theCRC in software.¶
An endpointMAY support fragmentation when sending DATA chunks, butitMUST support reassembly when receiving DATA chunks.If an endpoint supports fragmentation, itMUST fragment a user message ifthe size of the user message to be sent causes the outbound SCTPpacket size to exceed the current PMTU.An endpoint that does not support fragmentation and is requested to send auser message such that the outbound SCTP packet size would exceed thecurrent PMTUMUST return an error to its upper layer andMUST NOT attempt tosend the user message.¶
An SCTP implementationMAY provide a mechanism to the upper layer thatdisables fragmentation when sending DATA chunks.When fragmentation of DATA chunks is disabled, the SCTP implementationMUSTbehave in the same way an implementation that does not support fragmentation,i.e., it rejects calls that would result in sending SCTP packets that exceedthe current PMTU.¶
Implementation Note: In this error case, the SEND primitive discussedinSection 11.1.5 would need to return an error to theupper layer.¶
If its peer is multi-homed, the endpointSHOULD choose a DATA chunk sizesmaller than or equal to the AMDCS.¶
Once a user message is fragmented, it cannot be re-fragmented.Instead, if the PMTU has been reduced, then IP fragmentationMUST be used.Therefore, an SCTP association can fail if IP fragmentation is not working onany path.Please seeSection 7.3 for details ofPMTU discovery.¶
When determining when to fragment, the SCTP implementationMUST takeinto account the SCTP packet header as well as the DATA chunk header(s).The implementationMUST also take into account the space required for a SACKchunk if bundling a SACK chunk with the DATA chunk.¶
Fragmentation takes the following steps:¶
The data senderMUST break the user message into a series of DATA chunks.The senderSHOULD choose a size of DATA chunks that is smaller than or equalto the AMDCS.¶
The transmitterMUST then assign, in sequence, a separate TSN to each of theDATA chunks in the series.The transmitter assigns the same Stream Sequence Number to each of theDATA chunks.If the user indicates that the user message is to be delivered using unordereddelivery, then the U flag of each DATA chunk of the user messageMUST be setto 1.¶
The transmitterMUST also set the B/E bits of the first DATA chunk in theseries to 10, the B/E bits of the last DATA chunk in the series to 01,and the B/E bits of all other DATA chunks in the series to 00.¶
An endpointMUST recognize fragmented DATA chunks by examining the B/E bitsin each of the received DATA chunks and queue the fragmented DATA chunks forreassembly.Once the user message is reassembled, SCTP passes the reassembled usermessage to the specific stream for possible reordering and finaldispatching.¶
If the data receiver runs out of buffer space while still waiting formore fragments to complete the reassembly of the message, itSHOULD dispatchpart of its inbound message through a partial delivery API(seeSection 11), freeing some of its receive buffer space sothat the rest of the message can be received.¶
An endpoint bundles chunks by simply including multiple chunks in oneoutbound SCTP packet.The total size of the resultant SCTP packetMUST be less that or equal to thecurrent PMTU.¶
If its peer endpoint is multi-homed, the sending endpointSHOULD choose asize no larger than the PMTU of the current primary path.¶
When bundling control chunks with DATA chunks, an endpointMUST placecontrol chunks first in the outbound SCTP packet.The transmitterMUST transmit DATA chunks within an SCTP packet in increasingorder of TSN.¶
Note: Since control chunks are placed first in a packet and sinceDATA chunks are transmitted before SHUTDOWN or SHUTDOWN ACKchunks, DATA chunks cannot be bundled with SHUTDOWN or SHUTDOWN ACKchunks.¶
Partial chunksMUST NOT be placed in an SCTP packet.A partial chunk is a chunk that is not completely contained in the SCTP packet;i.e., the SCTP packet is too short to contain all the bytes of the chunk asindicated by the chunk length.¶
An endpointMUST process received chunks in their order in the packet.The receiver uses the Chunk Length field to determine the end of a chunkand beginning of the next chunk, taking account of thefact that all chunks end on a 4-byte boundary.If the receiver detects a partial chunk, itMUST drop the chunk.¶
An endpointMUST NOT bundle INIT, INIT ACK, or SHUTDOWN COMPLETE chunkswith any other chunks.¶
Congestion control is one of the basic functions in SCTP.To manage congestion, the mechanisms and algorithms in this section are to beemployed.¶
Implementation Note: As far as its specific performance requirementsare met, an implementation is always allowed to adopt a more conservativecongestion control algorithm than the one defined below.¶
The congestion control algorithms used by SCTP are based on[RFC5681].This section describes how the algorithms defined in[RFC5681]are adapted for use in SCTP.We first list differences in protocol designs between TCP and SCTP and thendescribe SCTP's congestion control scheme.The description will use the same terminology as in TCP congestion controlwhenever appropriate.¶
SCTP congestion control is always applied to the entire associationand not to individual streams.¶
Gap Ack Blocks in the SCTP SACK chunk carry the same semantic meaning as theTCP SACK.TCP considers the information carried in the SACK as advisory information only.SCTP considers the information carried in the Gap Ack Blocks in the SACK chunkas advisory.In SCTP, any DATA chunk that has been acknowledged by a SACK chunk, includingDATA that arrived at the receiving end out of order, is not considered fullydelivered until the Cumulative TSN Ack Point passes the TSN of the DATA chunk(i.e., the DATA chunk has been acknowledged by the Cumulative TSN Ackfield in the SACK chunk).Consequently, the value of cwnd controls the amount of outstanding data,rather than (as in the case of non-SACK TCP) the upper bound between thehighest acknowledged sequence number and the latest DATA chunk that can besent within the congestion window.SCTP SACK leads to different implementations of Fast Retransmit and FastRecovery than non-SACK TCP.As an example, see[FALL96].¶
The biggest difference between SCTP and TCP, however, is multi-homing.SCTP is designed to establish robust communication associations betweentwo endpoints, each of which might be reachable by more than one transport address.Potentially different addresses might lead to different data paths between thetwo endpoints;thus, ideally, one needs a separate set of congestion control parameters foreach of the paths.The treatment here of congestion control for multi-homed receivers is new withSCTP and might require refinement in the future.The current algorithms make the following assumptions:¶
The sender usually uses the same destination address until being instructedby the upper layer to do otherwise; however, SCTPMAY change to an alternatedestination in the event an address is marked inactive(seeSection 8.2).Also, SCTPMAY retransmit to a different transport address than the originaltransmission.¶
The sender keeps a separate congestion control parameter set for each ofthe destination addresses it can send to (not each source-destination pair butfor each destination).The parametersSHOULD decay if the address is not used for a long enough timeperiod.[RFC5681] specifies this period of time as a retransmissiontimeout.¶
For each of the destination addresses, an endpoint does slow start uponthe first transmission to that address.¶
Note: TCP guarantees in-sequence delivery of data to its upper-layerprotocol within a single TCP session.This means that when TCP notices a gap in the received sequence number, itwaits until the gap is filled before delivering the data that was receivedwith sequence numbers higher than that of the missing data.On the other hand, SCTP can deliver data to its upper-layer protocol, even ifthere is a gap in TSN if the Stream Sequence Numbers are in sequence for aparticular stream (i.e., the missing DATA chunks are for a different stream)or if unordered delivery is indicated.Although this does not affect cwnd, it might affect rwnd calculation.¶
The slow-start and congestion avoidance algorithmsMUST be used by anendpoint to control the amount of data being injected into the network.The congestion control in SCTP is employed in regard to the association, notto an individual stream.In some situations, it might be beneficial for an SCTP sender to be moreconservative than the algorithms allow;however, an SCTP senderMUST NOT be more aggressive than the followingalgorithms allow.¶
Like TCP, an SCTP endpoint uses the following three control variablesto regulate its transmission rate.¶
Receiver advertised window size (rwnd, in bytes), which is set by thereceiver based on its available buffer space for incoming packets.¶
Note: This variable is kept on the entire association.¶
Congestion control window (cwnd, in bytes), which is adjusted by the senderbased on observed network conditions.¶
Note: This variable is maintained on a per-destination-address basis.¶
Slow-start threshold (ssthresh, in bytes), which is used by thesender to distinguish slow-start and congestion avoidance phases.¶
Note: This variable is maintained on a per-destination-address basis.¶
SCTP also requires one additional control variable, partial_bytes_acked,which is used during the congestion avoidance phase to facilitate cwndadjustment.¶
Unlike TCP, an SCTP senderMUST keep a set of the control variablescwnd, ssthresh, and partial_bytes_acked for EACH destination addressof its peer (when its peer is multi-homed).When calculating one of these variables, the length of the DATA chunk, includingthe padding,SHOULD be used.¶
Only one rwnd is kept for the whole association (no matter if the peer ismulti-homed or has a single address).¶
Beginning data transmission into a network with unknown conditions orafter a sufficiently long idle period requires SCTP to probe thenetwork to determine the available capacity.The slow-start algorithm is used for this purpose at the beginning of atransfer or after repairing loss detected by the retransmission timer.¶
The initial cwnd before data transmissionMUST be set tomin(4 * PMDCS, max(2 * PMDCS, 4404)) bytes if the peer address is an IPv4 addressand to min(4 * PMDCS, max(2 * PMDCS, 4344)) bytes if the peer address is anIPv6 address.¶
The initial cwnd after a retransmission timeoutMUST be no more thanPMDCS, and only one packet is allowed to be in flight until successfulacknowledgement.¶
The initial value of ssthreshSHOULD be arbitrarily high (e.g.,the size of the largest-possible advertised window).¶
Whenever cwnd is greater than zero, the endpoint is allowed to have cwndbytes of data outstanding on that transport address.A limited overbooking as described in rule B inSection 6.1SHOULD be supported.¶
When cwnd is less than or equal to ssthresh, an SCTP endpointMUSTuse the slow-start algorithm to increase cwnd only if the currentcongestion window is being fully utilized and the data sender is not inFast Recovery.Only when these two conditions are met can the cwnd be increased;otherwise, the cwndMUST NOT be increased.If these conditions are met, then cwndMUST be increased by, at most, thelesser of¶
the total size of the previously outstanding DATA chunk(s) acknowledged and¶
L times the destination's PMDCS.¶
The first upper bound protects against the ACK-Splitting attack outlined in[SAVAGE99].The positive integer LSHOULD be 1 andMAY be larger than 1.See[RFC3465] for details of choosing L.¶
In instances where its peer endpoint is multi-homed, if an endpointreceives a SACK chunk that results in updating the cwnd, then itSHOULD updateits cwnd (or cwnds) apportioned to the destination addresses to which ittransmitted the acknowledged data.¶
While the endpoint does not transmit data on a given transport address,the cwnd of the transport addressSHOULD be adjusted to max(cwnd / 2, 4 * PMDCS)once per RTO.Before the first cwnd adjustment, the ssthresh of the transport addressSHOULDbe set to the cwnd.¶
When cwnd is greater than ssthresh, cwndSHOULD be incremented by PMDCS perRTT if the sender has cwnd or more bytes of data outstanding for thecorresponding transport address.The basic recommendations for incrementing cwnd during congestion avoidanceare as follows:¶
SCTPMAY increment cwnd by PMDCS.¶
SCTPSHOULD increment cwnd by PMDCS once per RTT when the sender has cwndor more bytes of data outstanding for the corresponding transport address.¶
SCTPMUST NOT increment cwnd by more than PMDCS per RTT.¶
In practice, an implementation can achieve this goal in the following way:¶
partial_bytes_acked is initialized to 0.¶
Whenever cwnd is greater than ssthresh, upon each SACK chunk arrival,increase partial_bytes_acked by the total number of bytes (including the chunkheader and the padding) of all new DATA chunks acknowledged in that SACK chunk,including chunks acknowledged by the new Cumulative TSN Ack, by Gap Ack Blocks,and by the number of bytes of duplicated chunks reported inDuplicate TSNs.¶
When (1) partial_bytes_acked is greater than cwnd and (2) before the arrivalof the SACK chunk the sender had less than cwnd bytes of data outstanding (i.e.,before the arrival of the SACK chunk, flightsize was less than cwnd), resetpartial_bytes_acked to cwnd.¶
When (1) partial_bytes_acked is equal to or greater than cwnd and (2) beforethe arrival of the SACK chunk the sender had cwnd or more bytes of data outstanding(i.e., before the arrival of the SACK chunk, flightsize was greater than or equal tocwnd), partial_bytes_acked is reset to (partial_bytes_acked - cwnd).Next, cwnd is increased by PMDCS.¶
Same as in the slow start, when the sender does not transmit DATA chunkson a given transport address, the cwnd of the transport addressSHOULD beadjusted to max(cwnd / 2, 4 * PMDCS) per RTO.¶
When all of the data transmitted by the sender has been acknowledged by thereceiver, partial_bytes_acked is initialized to 0.¶
Upon detection of packet losses from SACK chunks(seeSection 7.2.4), an endpointSHOULDdo the following:¶
ssthresh = max(cwnd / 2, 4 * PMDCS)cwnd = ssthreshpartial_bytes_acked = 0¶
Basically, a packet loss causes cwnd to be cut in half.¶
When the T3-rtx timer expires on an address, SCTPSHOULD perform slow startby:¶
ssthresh = max(cwnd / 2, 4 * PMDCS)cwnd = PMDCSpartial_bytes_acked = 0¶
and ensure that no more than one SCTP packet will be in flight for that addressuntil the endpoint receives acknowledgement for successful delivery of data tothat address.¶
In the absence of data loss, an endpoint performs delayed acknowledgement.However, whenever an endpoint notices a hole in the arriving TSN sequence, itSHOULD start sending a SACK chunk back every time a packet arrives carrying datauntil the hole is filled.¶
Whenever an endpoint receives a SACK chunk that indicates that some TSNs aremissing, itSHOULD wait for two further miss indications (via subsequent SACKchunks for a total of three missing reports) on the same TSNs before taking action with regard to Fast Retransmit.¶
Miss indicationsSHOULD follow the Highest TSN Newly Acknowledged (HTNA)algorithm.For each incoming SACK chunk, miss indications are incremented only formissing TSNs prior to the HTNA in the SACK chunk.A newly acknowledged DATA chunk is one not previously acknowledged in aSACK chunk.If an endpoint is in Fast Recovery and a SACK chunks arrives that advances theCumulative TSN Ack Point, the miss indications are incremented for all TSNsreported missing in the SACK chunk.¶
When the third consecutive miss indication is received for one or more TSNs,the data sender does the following:¶
Mark the DATA chunk(s) with three miss indications for retransmission.¶
If not in Fast Recovery, adjust the ssthresh and cwnd of the destinationaddress(es) to which the missing DATA chunks were last sent, according to theformula described inSection 7.2.3.¶
If not in Fast Recovery, determine how many of the earliest(i.e., lowest TSN) DATA chunks marked for retransmission will fitinto a single packet, subject to constraint of the PMTU ofthe destination transport address to which the packet is being sent.Call this value K.Retransmit those K DATA chunks in a single packet.When a Fast Retransmit is being performed, the senderSHOULD ignore the valueof cwnd andSHOULD NOT delay retransmission for this single packet.¶
Restart the T3-rtx timer only if the last SACK chunk acknowledged thelowest outstanding TSN number sent to that address or the endpoint isretransmitting the first outstanding DATA chunk sent to that address.¶
Mark the DATA chunk(s) as being fast retransmitted and thus ineligible for asubsequent Fast Retransmit. Those TSNs marked for retransmission due to the Fast-Retransmit algorithm thatdid not fit in the sent datagram carrying K other TSNs are also marked asineligible for a subsequent Fast Retransmit.However, as they are marked for retransmission, they will be retransmittedlater on as soon as cwnd allows.¶
If not in Fast Recovery, enter Fast Recovery and mark the highestoutstanding TSN as the Fast Recovery exit point.When a SACK chunk acknowledges all TSNs up to and including this exit point,Fast Recovery is exited.While in Fast Recovery, the ssthresh and cwndSHOULD NOT change for anydestinations due to a subsequent Fast Recovery event (i.e., oneSHOULD NOTreduce the cwnd further due to a subsequent Fast Retransmit).¶
Note: Before the above adjustments, if the received SACK chunk alsoacknowledges new DATA chunks and advances the Cumulative TSN Ack Point,the cwnd adjustment rules defined in Sections7.2.1 and7.2.2MUST be applied first.¶
During the lifetime of an SCTP association, events can happen that resultin using the network under unknown new conditions.When detected by an SCTP implementation, the congestion controlMUST bereinitialized.¶
SCTP implementationsMAY allow an application to configure theDifferentiated Services Code Point (DSCP) used for sending packets.If a DSCP change might result in outgoing packets being queued indifferent queues, the congestion control parameters for all affecteddestination addressesMUST be reset to their initial values.¶
SCTP implementationsMAY be aware of routing changes affecting packetssent to a destination address.In particular, this includes the selection of a different source address usedfor sending packets to a destination address.If such a routing change happens, the congestion control parameters for theaffected destination addressesMUST be reset to their initial values.¶
[RFC8899],[RFC8201], and[RFC1191] specify"Packetization Layer Path MTU Discovery",whereby an endpoint maintains an estimate of PMTU along a given Internet pathand refrains from sending packets along that path that exceed the PMTU, otherthan occasional attempts to probe for a change in the PMTU.[RFC8899] is thorough in itsdiscussion of the PMTU discovery mechanism and strategies for determining thecurrent end-to-end PMTU setting as well as detecting changes in this value.¶
An endpointSHOULD apply these techniques andSHOULD do so on aper-destination-address basis.¶
There are two important SCTP-specific points regarding PMTU discovery:¶
SCTP associations can span multiple addresses.An endpointMUST maintain separate PMTU estimates for each destination addressof its peer.¶
The senderSHOULD track an AMDCS that will be thesmallest PMDCS discovered for all of the peer's destination addresses.When fragmenting messages into multiple parts, this AMDCSSHOULDbe used to calculate the size of each DATA chunk.This will allow retransmissions to be seamlessly sent to an alternate addresswithout encountering IP fragmentation.¶
An endpointSHOULD keep a counter on the total number of consecutiveretransmissions to its peer (this includes data retransmissions to all thedestination transport addresses of the peer if it is multi-homed), includingthe number of unacknowledged HEARTBEAT chunks observed on the path that iscurrently used for data transfer.Unacknowledged HEARTBEAT chunks observed on paths different from thepath currently used for data transferSHOULD NOT increment the associationerror counter, as this could lead to association closure even if the paththat is currently used for data transfer is available (but idle).If the value of this counter exceeds the limit indicated in the protocolparameter 'Association.Max.Retrans', the endpointSHOULD consider the peerendpoint unreachable andSHALL stop transmitting any more data to it(and thus the association enters the CLOSED state).In addition, the endpointSHOULD report the failure to the upper layer andoptionally report back all outstanding user data remaining in its outboundqueue.The association is automatically closed when the peer endpoint becomesunreachable.¶
The counter used for endpoint failure detectionMUST be reset each time aDATA chunk sent to that peer endpoint is acknowledged (by the reception ofa SACK chunk).When a HEARTBEAT ACK chunk is received from the peer endpoint, the counterSHOULD also be reset.The receiver of the HEARTBEAT ACK chunkMAY choose not to clear the counterif there is outstanding data on the association.This allows for handling the possible difference in reachability based onDATA chunks and HEARTBEAT chunks.¶
When its peer endpoint is multi-homed, an endpointSHOULD keep anerror counter for each of the destination transport addresses of thepeer endpoint.¶
Each time the T3-rtx timer expires on any address, or when aHEARTBEAT chunk sent to an idle address is not acknowledged within an RTO,the error counter of that destination address will be incremented.When the value in the error counter exceeds the protocol parameter'Path.Max.Retrans' of that destination address, the endpointSHOULDmark the destination transport address as inactive, and anotificationSHOULD be sent to the upper layer.¶
When an outstanding TSN is acknowledged or a HEARTBEAT chunk sent to thataddress is acknowledged with a HEARTBEAT ACK chunk, the endpointSHOULDclear the error counter of the destination transport address to whichthe DATA chunk was last sent (or HEARTBEAT chunk was sent) andSHOULD alsoreport to the upper layer when an inactive destination address ismarked as active.When the peer endpoint is multi-homed and the last chunk sent to it was aretransmission to an alternate address, there exists an ambiguity as to whether or not the acknowledgement could be credited to theaddress of the last chunk sent.However, this ambiguity does not seem to have significant consequences forSCTP behavior.If this ambiguity is undesirable, the transmitterMAY choose not to clear theerror counter if the last chunk sent was a retransmission.¶
Note: When configuring the SCTP endpoint, the user ought to avoid having thevalue of 'Association.Max.Retrans' larger than the summation of the'Path.Max.Retrans' of all the destination addresses for the remote endpoint.Otherwise, all the destination addresses might become inactive while the endpointstill considers the peer endpoint reachable.When this condition occurs, how SCTP chooses to function is implementationspecific.¶
When the primary path is marked inactive (due to excessive retransmissions,for instance), the senderMAY automatically transmit new packets to analternate destination address if one exists and is active.If more than one alternate address is active when the primary path is markedinactive, only ONE transport addressSHOULD be chosen and used as the newdestination transport address.¶
By default, an SCTP endpointSHOULD monitor the reachability of theidle destination transport address(es) of its peer by sending aHEARTBEAT chunk periodically to the destination transport address(es).The sending of HEARTBEAT chunksMAY begin upon reaching the ESTABLISHED stateand is discontinued after sending either a SHUTDOWN chunk or SHUTDOWN ACK chunk.A receiver of a HEARTBEAT chunkMUST respond to a HEARTBEAT chunk with aHEARTBEAT ACK chunk after entering the COOKIE-ECHOED state (sender of theINIT chunk) or the ESTABLISHED state (receiver of the INIT chunk), up untilreaching the SHUTDOWN-SENT state (sender of the SHUTDOWN chunk)or the SHUTDOWN-ACK-SENT state (receiver of the SHUTDOWN chunk).¶
A destination transport address is considered "idle" if no new chunkthat can be used for updating path RTT (usually including first transmissionDATA, INIT, COOKIE ECHO, or HEARTBEAT chunks, etc.) and no HEARTBEAT chunkhas been sent to it within the current heartbeat period of that address.This applies to both active and inactive destination addresses.¶
The upper layer can optionally initiate the following functions:¶
Disable heartbeat on a specific destination transport address of agiven association,¶
Change the 'HB.interval',¶
Re-enable heartbeat on a specific destination transport address of a givenassociation, and¶
Request the sending of an on-demand HEARTBEAT chunk on a specificdestination transport address of a given association.¶
The endpointSHOULD increment the respective error counter of the destinationtransport address each time a HEARTBEAT chunk is sent to that address and notacknowledged within one RTO.¶
When the value of this counter exceeds the protocol parameter'Path.Max.Retrans', the endpointSHOULD mark the corresponding destinationaddress as inactive if it is not so marked andSHOULD also report tothe upper layer the change in reachability of this destination address.After this, the endpointSHOULD continue sending HEARTBEAT chunks on thisdestination address butSHOULD stop increasing the counter.¶
The sender of the HEARTBEAT chunkSHOULD include in the Heartbeat Informationfield of the chunk the current time when the packet is sent and thedestination address to which the packet is sent.¶
Implementation Note: An alternative implementation of the heartbeatmechanism that can be used is to increment the error counter variable every timea HEARTBEAT chunk is sent to a destination.Whenever a HEARTBEAT ACK chunk arrives, the senderSHOULD clear the errorcounter of the destination that the HEARTBEAT chunk was sent to.This, in effect, would clear the previously stroked error (and any other errorcounts as well).¶
The receiver of the HEARTBEAT chunkSHOULD immediately respond with aHEARTBEAT ACK chunk that contains the Heartbeat Information TLV, together withany other received TLVs, copied unchanged from the received HEARTBEAT chunk.¶
Upon the receipt of the HEARTBEAT ACK chunk, the sender of the HEARTBEATchunkSHOULD clear the error counter of the destination transport addressto which the HEARTBEAT chunk was sent and mark the destination transportaddress as active if it is not so marked.The endpointSHOULD report to the upper layer when an inactivedestination address is marked as active due to the reception of the latestHEARTBEAT ACK chunk.The receiver of the HEARTBEAT ACK chunkSHOULD also clear the associationoverall error count (as defined inSection 8.1).¶
The receiver of the HEARTBEAT ACK chunkSHOULD also perform an RTTmeasurement for that destination transport address using the time value carriedin the HEARTBEAT ACK chunk.¶
On an idle destination address that is allowed to heartbeat, it isRECOMMENDED that a HEARTBEAT chunk is sent once per RTO of that destinationaddress plus the protocol parameter 'HB.interval', with jittering of +/- 50% ofthe RTO value and exponential backoff of the RTO if the previous HEARTBEATchunk is unanswered.¶
A primitive is provided for the SCTP user to change the 'HB.interval' and turnon or off the heartbeat on a given destination address.The 'HB.interval' set by the SCTP user is added to the RTO of thatdestination (including any exponential backoff).Only one heartbeatSHOULD be sent each time the heartbeat timer expires (ifmultiple destinations are idle).It is an implementation decision on how to choose which of the candidate idledestinations to heartbeat to (if more than one destination is idle).¶
When tuning the 'HB.interval', there is a side effect thatSHOULD be taken into account.When this value is increased, i.e., the time between the sending of HEARTBEATchunks is longer, the detection of lost ABORT chunks takes longer as well.If a peer endpoint sends an ABORT chunk for any reason and the ABORT chunk islost, the local endpoint will only discover the lost ABORT chunk by sending aDATA chunk or HEARTBEAT chunk (thus causing the peer to send another ABORT chunk).This is to be considered when tuning the heartbeat timer.If the sending of HEARTBEAT chunks is disabled, only sending DATA chunks to theassociation will discover a lost ABORT chunk from the peer.¶
An SCTP packet is called an "Out of the Blue" (OOTB) packet if it iscorrectly formed (i.e., passed the receiver's CRC32c check;seeSection 6.8),but the receiver is not able to identify the association to which thispacket belongs.¶
The receiver of an OOTB packet does the following:¶
If the OOTB packet is to or from a non-unicast address, a receiverSHOULDsilently discard the packet.Otherwise,¶
If the OOTB packet contains an ABORT chunk, the receiverMUST silentlydiscard the OOTB packet and take no further action.Otherwise,¶
If the packet contains an INIT chunk with a Verification Tag setto 0, itSHOULD be processed as described inSection 5.1.If, for whatever reason, the INIT chunk cannot be processed normally and anABORT chunk has to be sent in response, the Verification Tag of the packetcontaining the ABORT chunkMUST be the Initiate Tag of the received INIT chunk,and the T bit of the ABORT chunk has to be set to 0, indicating that theVerification Tag is not reflected.Otherwise,¶
If the packet contains a COOKIE ECHO chunk as the first chunk, itMUST beprocessed as described inSection 5.1.Otherwise,¶
If the packet contains a SHUTDOWN ACK chunk, the receiverSHOULD respond tothe sender of the OOTB packet with a SHUTDOWN COMPLETE chunk.When sending the SHUTDOWN COMPLETE chunk, the receiver of the OOTB packetMUSTfill in the Verification Tag field of the outbound packet with theVerification Tag received in the SHUTDOWN ACK chunk and set the T bit in theChunk Flags to indicate that the Verification Tag is reflected.Otherwise,¶
If the packet contains a SHUTDOWN COMPLETE chunk, the receiverSHOULDsilently discard the packet and take no further action.Otherwise,¶
If the packet contains an ERROR chunk with the "Stale Cookie" error causeor a COOKIE ACK chunk, the SCTP packetSHOULD be silently discarded.Otherwise,¶
The receiverSHOULD respond to the sender of the OOTB packet with anABORT chunk.When sending the ABORT chunk, the receiver of the OOTB packetMUST fill in theVerification Tag field of the outbound packet with the value found in theVerification Tag field of the OOTB packet and set the T bit in the Chunk Flagsto indicate that the Verification Tag is reflected.After sending this ABORT chunk, the receiver of the OOTB packetMUST discard theOOTB packet andMUST NOT take any further action.¶
The Verification Tag rules defined in this section apply when sending orreceiving SCTP packets that do not contain an INIT, SHUTDOWN COMPLETE,COOKIE ECHO (seeSection 5.1),ABORT, or SHUTDOWN ACK chunk.The rules for sending and receiving SCTP packets containing one of these chunktypes are discussed separately inSection 8.5.1.¶
When sending an SCTP packet, the endpointMUST fill in the Verification Tagfield of the outbound packet with the tag value in the Initiate Tag parameterof the INIT or INIT ACK chunk received from its peer.¶
When receiving an SCTP packet, the endpointMUST ensure that the value inthe Verification Tag field of the received SCTP packet matches its own tag.If the received Verification Tag value does not match the receiver's own tagvalue, the receiverMUST silently discard the packet andMUST NOT process itany further, except for those cases listed inSection 8.5.1 below.¶
An endpointSHOULD terminate its association when it exits from service.An association can be terminated by either abort or shutdown.An abort of an association is abortive by definition in that any data pendingon either end of the association is discarded and not delivered to the peer.A shutdown of an association is considered a graceful close where all data inqueue by either endpoint is delivered to the respective peers.However, in the case of a shutdown, SCTP does not support a half-open state(like TCP), wherein one side might continue sending data while the other end isclosed.When either endpoint performs a shutdown, the association on each peer willstop accepting new data from its user and only deliver data in queue at the timeof sending or receiving the SHUTDOWN chunk.¶
When an endpoint decides to abort an existing association, itMUST send anABORT chunk to its peer endpoint.The senderMUST fill in the peer's Verification Tag in the outbound packet andMUST NOT bundle any DATA chunk with the ABORT chunk.If the association is aborted on request of the upper layer, a"User-Initiated Abort" error cause(seeSection 3.3.10.12)SHOULD be present inthe ABORT chunk.¶
An endpointMUST NOT respond to any received packet that contains an ABORTchunk (also seeSection 8.4).¶
An endpoint receiving an ABORT chunkMUST apply the special Verification Tag checkrules described inSection 8.5.1.¶
After checking the Verification Tag, the receiving endpointMUST remove theassociation from its record andSHOULD report the termination to its upperlayer.If a "User-Initiated Abort" error cause is present in the ABORT chunk, the UpperLayer Abort ReasonSHOULD be made available to the upper layer.¶
Using the SHUTDOWN primitive (seeSection 11.1), theupper layer of an endpoint in an association can gracefully close theassociation.This will allow all outstanding DATA chunks from the peer of theshutdown initiator to be delivered before the association terminates.¶
Upon receipt of the SHUTDOWN primitive from its upper layer, the endpointenters the SHUTDOWN-PENDING state and remains there until all outstanding datahas been acknowledged by its peer.The endpoint accepts no new data from its upper layer but retransmits data tothe peer endpoint if necessary to fill gaps.¶
Once all its outstanding data has been acknowledged, the endpoint sendsa SHUTDOWN chunk to its peer, including in the Cumulative TSN Ack field the lastsequential TSN it has received from the peer.ItSHOULD then start the T2-shutdown timer and enter the SHUTDOWN-SENT state.If the timer expires, the endpointMUST resend the SHUTDOWN chunk with theupdated last sequential TSN received from its peer.¶
The rules inSection 6.3MUST befollowed to determine the proper timer value for T2-shutdown.To indicate any gaps in TSN, the endpointMAY also bundle a SACK chunk with theSHUTDOWN chunk in the same SCTP packet.¶
An endpointSHOULD limit the number of retransmissions of the SHUTDOWN chunkto the protocol parameter 'Association.Max.Retrans'.If this threshold is exceeded, the endpointSHOULD destroy the TCB andSHOULDreport the peer endpoint unreachable to the upper layer (and thus theassociation enters the CLOSED state).The reception of any packet from its peer (i.e., as the peer sends all of itsqueued DATA chunks)SHOULD clear the endpoint's retransmission count and restartthe T2-shutdown timer, giving its peer ample opportunity to transmit all of itsqueued DATA chunks that have not yet been sent.¶
Upon reception of the SHUTDOWN chunk, the peer endpoint does the following:¶
enter the SHUTDOWN-RECEIVED state,¶
stop accepting new data from its SCTP user, and¶
verify, by checking the Cumulative TSN Ack field of the chunk, that all itsoutstanding DATA chunks have been received by the SHUTDOWN chunk sender.¶
Once an endpoint has reached the SHUTDOWN-RECEIVED state, itMUST ignoreULP shutdown requests butMUST continue responding to SHUTDOWN chunks from itspeer.¶
If there are still outstanding DATA chunks left, the SHUTDOWN chunk receiverMUST continue to follow normal data transmission procedures defined inSection 6, until all outstanding DATA chunks areacknowledged; however, the SHUTDOWN chunk receiverMUST NOT accept new datafrom its SCTP user.¶
While in the SHUTDOWN-SENT state, the SHUTDOWN chunk senderMUST immediatelyrespond to each received packet containing one or more DATA chunks with aSHUTDOWN chunk and restart the T2-shutdown timer.If a SHUTDOWN chunk by itself cannot acknowledge all of the received DATA chunks(i.e., there are TSNs that can be acknowledged that are larger than thecumulative TSN and thus gaps exist in the TSN sequence) or if duplicate TSNshave been received, then a SACK chunkMUST also be sent.¶
The sender of the SHUTDOWN chunkMAY also start an overall guard timerT5-shutdown-guard to bound the overall time for the shutdown sequence.At the expiration of this timer, the senderSHOULD abort the association bysending an ABORT chunk. If the T5-shutdown-guard timer is used, itSHOULDbe set to theRECOMMENDED value of 5 times 'RTO.Max'.¶
If the receiver of the SHUTDOWN chunk has no more outstanding DATA chunks,the SHUTDOWN chunk receiverMUST send a SHUTDOWN ACK chunk and start aT2-shutdown timer of its own, entering the SHUTDOWN-ACK-SENT state.If the timer expires, the endpointMUST resend the SHUTDOWN ACK chunk.¶
The sender of the SHUTDOWN ACK chunkSHOULD limit the number ofretransmissions of the SHUTDOWN ACK chunk to the protocol parameter'Association.Max.Retrans'.If this threshold is exceeded, the endpointSHOULD destroy the TCB andSHOULDreport the peer endpoint unreachable to the upper layer (and thus theassociation enters the CLOSED state).¶
Upon the receipt of the SHUTDOWN ACK chunk, the sender of the SHUTDOWN chunkMUST stop the T2-shutdown timer, send a SHUTDOWN COMPLETE chunk to its peer, andremove all record of the association.¶
Upon reception of the SHUTDOWN COMPLETE chunk, the endpoint verifies thatit is in the SHUTDOWN-ACK-SENT state;if it is not, the chunkSHOULD be discarded.If the endpoint is in the SHUTDOWN-ACK-SENT state, the endpointSHOULD stopthe T2-shutdown timer and remove all knowledge of the association (and thus theassociation enters the CLOSED state).¶
An endpointSHOULD ensure that all its outstanding DATA chunks have beenacknowledged before initiating the shutdown procedure.¶
An endpointSHOULD reject any new data request from its upper layer if it isin the SHUTDOWN-PENDING, SHUTDOWN-SENT, SHUTDOWN-RECEIVED, or SHUTDOWN-ACK-SENTstate.¶
If an endpoint is in the SHUTDOWN-ACK-SENT state and receives an INITchunk (e.g., if the SHUTDOWN COMPLETE chunk was lost) with source and destinationtransport addresses (either in the IP addresses or in the INIT chunk) thatbelong to this association, itSHOULD discard the INIT chunk and retransmitthe SHUTDOWN ACK chunk.¶
Note: Receipt of a packet containing an INIT chunk with the same source anddestination IP addresses as used in transport addresses assigned to an endpointbut with a different port number indicates the initialization of a separateassociation.¶
The sender of the INIT or COOKIE ECHO chunkSHOULD respond to the receipt ofa SHUTDOWN ACK chunk with a stand-alone SHUTDOWN COMPLETE chunk in anSCTP packet with the Verification Tag field of its common header set to thesame tag that was received in the packet containing the SHUTDOWN ACK chunk.This is considered an OOTB packet as defined inSection 8.4.The sender of the INIT chunk lets T1-init continue running and remains in theCOOKIE-WAIT or COOKIE-ECHOED state.Normal T1-init timer expiration will cause the INIT or COOKIE chunk to beretransmitted and thus start a new association.¶
If a SHUTDOWN chunk is received in the COOKIE-WAIT or COOKIE ECHOED state,the SHUTDOWN chunkSHOULD be silently discarded.¶
If an endpoint is in the SHUTDOWN-SENT state and receives a SHUTDOWN chunkfrom its peer, the endpointSHOULD respond immediately with a SHUTDOWN ACK chunkto its peer and move into the SHUTDOWN-ACK-SENT state, restarting itsT2-shutdown timer.¶
If an endpoint is in the SHUTDOWN-ACK-SENT state and receives a SHUTDOWN ACK,itMUST stop the T2-shutdown timer, send a SHUTDOWN COMPLETE chunk to its peer,and remove all record of the association.¶
Whenever an ICMP message is received by an SCTP endpoint, the followingproceduresMUST be followed to ensure proper utilization of the informationbeing provided by layer 3.¶
An implementationMAY ignore all ICMPv4 messages where the type field is notset to "Destination Unreachable".¶
An implementationMAY ignore all ICMPv6 messages where the type field isnot "Destination Unreachable", "Parameter Problem", or "Packet Too Big".¶
An implementationSHOULD ignore any ICMP messages where the code indicates"Port Unreachable".¶
An implementationMAY ignore all ICMPv6 messages of type "Parameter Problem"if the code is not "Unrecognized Next Header Type Encountered".¶
An implementationMUST use the payload of the ICMP message (v4 or v6) tolocate the association that sent the message to which ICMP is responding.If the association cannot be found, an implementationSHOULD ignore theICMP message.¶
An implementationMUST validate that the Verification Tag contained in theICMP message matches the Verification Tag of the peer.If the Verification Tag is not 0 and does not match, discard the ICMP message.If it is 0 and the ICMP message contains enough bytes to verify that thechunk type is an INIT chunk and that the Initiate Tag matches the tag of thepeer, continue with ICMP7.If the ICMP message is too short or the chunk type or the Initiate Tag doesnot match, silently discard the packet.¶
If the ICMP message is either an ICMPv6 message of type "Packet Too Big"or an ICMPv4 message of type "Destination Unreachable" and code"Fragmentation Needed", an implementationSHOULD process this information asdefined for PMTU discovery.¶
If the ICMP code is "Unrecognized Next Header Type Encountered" or"Protocol Unreachable", an implementationMUST treat this message as an abortwith the T bit set if it does not contain an INIT chunk.If it does contain an INIT chunk and the association is in theCOOKIE-WAIT state, handle the ICMP message like an ABORT chunk.¶
If the ICMP type is "Destination Unreachable", the implementationMAY movethe destination to the unreachable state or, alternatively, increment thepath error counter.SCTPMAY provide information to the upper layer indicating the reception ofICMP messages when reporting a network status change.¶
These procedures differ from[RFC1122] and from itsrequirements for processing of port-unreachable messages and the requirementsthat an implementationMUST abort associations in response to aprotocol unreachable message.Port-unreachable messages are not processed, since an implementation will sendan ABORT chunk, not a port-unreachable message. The stricter handling of theprotocol unreachable message is due to security concerns for hosts that donot support SCTP.¶
The Upper Layer Protocols (ULPs) request services by passing primitivesto SCTP and receive notifications from SCTP for various events.¶
The primitives and notifications described in this section can beused as a guideline for implementing SCTP.The following functional description of ULP interface primitives is shown forillustrative purposes.Different SCTP implementations can have different ULP interfaces.However, all SCTP implementations are expected to provide a certain minimum setof services to guarantee that all SCTP implementations can support the sameprotocol hierarchy.¶
Please note that this section is informational only.¶
[RFC6458] and Section7 ("Socket API Considerations") of[RFC7053] define an extension of the socket API for SCTP asdescribed in this document.¶
The following sections functionally characterize a ULP/SCTP interface.The notation used is similar to most procedure or function calls in high-levellanguages.¶
The ULP primitives described below specify the basic functions thatSCTP performs to support inter-process communication.Individual implementations define their own exact format and providecombinations or subsets of the basic functions in single calls.¶
INITIALIZE ([local port],[local eligible address list])-> local SCTP instance name¶
This primitive allows SCTP to initialize its internal data structuresand allocate necessary resources for setting up its operationenvironment.Once SCTP is initialized, ULP can communicate directly with other endpointswithout re-invoking this primitive.¶
SCTP will return a local SCTP instance name to the ULP.¶
Implementation Note: If this optional attribute is supported by animplementation, it will be the responsibility of the implementationto enforce that the IP source address field of any SCTP packets sentby this endpoint contains one of the IP addresses indicated in the localeligible address list.¶
ASSOCIATE(local SCTP instance name,initial destination transport addr list, outbound stream count)-> association id [,destination transport addr list][,outbound stream count]¶
This primitive allows the upper layer to initiate an association to a specificpeer endpoint.¶
The peer endpoint is specified by one or more of the transportaddresses that defines the endpoint (seeSection 1.3).If the local SCTP instance has not been initialized, the ASSOCIATE is consideredan error.¶
An association id, which is a local handle to the SCTP association,will be returned on successful establishment of the association.If SCTP is not able to open an SCTP association with the peer endpoint,an error is returned.¶
Other association parameters can be returned, including the completedestination transport addresses of the peer as well as the outboundstream count of the local endpoint.One of the transport addresses from the returned destination addresses willbe selected by the local endpoint as the default primary path for sendingSCTP packets to this peer.The returned "destination transport addr list" can be used by the ULP to changethe default primary path or to force sending a packet to a specifictransport address.¶
Implementation Note: If the ASSOCIATE primitive is implemented as ablocking function call, the ASSOCIATE primitive can returnassociation parameters in addition to the association id uponsuccessful establishment.If ASSOCIATE primitive is implemented as a non-blocking call, only theassociation id is returned and association parameters are passedusing the COMMUNICATION UP notification.¶
SHUTDOWN(association id) -> result¶
Gracefully closes an association.Any locally queued user data will be delivered to the peer.The association will be terminated only after the peer acknowledges all theSCTP packets sent.A success code will be returned on successful termination of the association.If attempting to terminate the association results in a failure, an error codeis returned.¶
ABORT(association id [, Upper Layer Abort Reason]) -> result¶
Ungracefully closes an association.Any locally queued user data will be discarded, and an ABORT chunk is sent tothe peer.A success code will be returned on successful abort of the association.If attempting to abort the association results in a failure, an error codeis returned.¶
SEND(association id, buffer address, byte count [,context][,stream id] [,life time] [,destination transport address][,unordered flag] [,no-bundle flag] [,payload protocol-id][,sack-immediately flag]) -> result¶
This is the main method to send user data via SCTP.¶
specifies the life time of the user data.The user data will not be sent by SCTP after the life time expires.This parameter can be used to avoid efforts to transmit stale user messages.SCTP notifies the ULP if the data cannot be initiated to transport (i.e., sentto the destination via SCTP's SEND primitive) within the life time variable.However, the user data will be transmitted if SCTP has attempted to transmita chunk before the life time expired.¶
Implementation Note: In order to better support the data life timeoption, the transmitter can hold back the assigning of the TSN numberto an outbound DATA chunk to the last moment.And, for implementation simplicity, once a TSN number has been assigned, thesender considers the send of this DATA chunk as committed,overriding any life time option attached to the DATA chunk.¶
SETPRIMARY(association id, destination transport address,[source transport address]) -> result¶
Instructs the local SCTP to use the specified destination transport address asthe primary path for sending packets.¶
The result of attempting this operation is returned.If the specified destination transport address is not present in the"destination transport address list" returned earlier in an ASSOCIATEprimitive or COMMUNICATION UP notification, an error is returned.¶
RECEIVE(association id, buffer address, buffer size [,stream id])-> byte count [,transport address] [,stream id][,stream sequence number] [,partial flag] [,payload protocol-id]¶
This primitive reads the first user message in the SCTP in-queueinto the buffer specified by ULP, if there is one available.The size of the message read, in bytes, will be returned.It might, depending on the specific implementation, also return otherinformation, such as the sender's address, the stream id on which itis received, whether there are more messages available for retrieval,etc.For ordered messages, their Stream Sequence Number might also be returned.¶
Depending upon the implementation, if this primitive is invoked when nomessage is available, the implementation returns an indication of this conditionor blocks the invoking process until data does become available.¶
STATUS(association id) -> status data¶
This primitive returns a data block containing the following information:¶
association connection state,¶
destination transport address list,¶
destination transport address reachability states,¶
current receiver window size,¶
current congestion window sizes,¶
number of unacknowledged DATA chunks,¶
number of DATA chunks pending receipt,¶
primary path,¶
most recent SRTT on primary path,¶
RTO on primary path,¶
SRTT and RTO on other destination addresses, etc.¶
CHANGE HEARTBEAT(association id, destination transport address,new state [,interval]) -> result¶
Instructs the local endpoint to enable or disable heartbeat on thespecified destination transport address.¶
The result of attempting this operation is returned.¶
Note: Even when enabled, heartbeat will not take place if the destinationtransport address is not idle.¶
REQUESTHEARTBEAT(association id, destination transport address)-> result¶
Instructs the local endpoint to perform a heartbeat on the specifieddestination transport address of the given association.The returned result indicates whether the transmission of the HEARTBEATchunk to the destination address is successful.¶
GETSRTTREPORT(association id, destination transport address)-> srtt result¶
Instructs the local SCTP to report the current SRTT measurement on thespecified destination transport address of the given association.The returned result can be an integer containing the most recent SRTT inmilliseconds.¶
SETFAILURETHRESHOLD(association id, destination transport address,failure threshold) -> result¶
This primitive allows the local SCTP to customize the reachability failuredetection threshold 'Path.Max.Retrans' for the specified destination address.Note that this can also be done using the SETPROTOCOLPARAMETERS primitive(Section 11.1.13).¶
None.¶
SETPROTOCOLPARAMETERS(association id,[destination transport address,] protocol parameter list)-> result¶
This primitive allows the local SCTP to customize the protocol parameters.¶
RECEIVE_UNSENT(data retrieval id, buffer address, buffer size[,stream id] [, stream sequence number] [,partial flag][,payload protocol-id])¶
This primitive reads a user message that has never been sentinto the buffer specified by ULP.¶
RECEIVE_UNACKED(data retrieval id, buffer address, buffer size,[,stream id] [,stream sequence number] [,partial flag][,payload protocol-id])¶
This primitive reads a user message that has been sent and has not beenacknowledged by the peer into the buffer specified by ULP.¶
DESTROY(local SCTP instance name)¶
It is assumed that the operating system or application environmentprovides a means for the SCTP to asynchronously signal the ULP process.When SCTP does signal a ULP process, certain information is passed tothe ULP.¶
Implementation Note: In some cases, this might be done through a separatesocket or error channel.¶
SCTP invokes this notification on the ULP when a user message issuccessfully received and ready for retrieval.¶
The following might optionally be passed with the notification:¶
If a message cannot be delivered, SCTP invokes this notificationon the ULP.¶
The following might optionally be passed with the notification:¶
When a destination transport address is marked inactive (e.g., when SCTPdetects a failure) or marked active (e.g., when SCTP detects a recovery),SCTP invokes this notification on the ULP.¶
The following is passed with the notification:¶
This notification is used when SCTP becomes ready to send or receiveuser messages or when a lost communication to an endpoint is restored.¶
Implementation Note: If the ASSOCIATE primitive is implemented as ablocking function call, the association parameters are returned as aresult of the ASSOCIATE primitive itself.In that case, the COMMUNICATION UP notification is optional at the associationinitiator's side.¶
The following is passed with the notification:¶
When SCTP loses communication to an endpoint completely (e.g., via Heartbeats)or detects that the endpoint has performed an abort operation, it invokesthis notification on the ULP.¶
The following is passed with the notification:¶
The following might be passed with the notification:¶
When SCTP receives an ERROR chunk from its peer and decides to notify its ULP,it can invoke this notification on the ULP.¶
The following can be passed with the notification:¶
When SCTP detects that the peer has restarted, it might send this notificationto its ULP.¶
The following can be passed with the notification:¶
When SCTP completes the shutdown procedures(Section 9.2), this notification is passedto the upper layer.¶
The following can be passed with the notification:¶
As a common transport protocol designed to reliably carry time-sensitiveuser messages, such as billing or signaling messages for telephony services,between two networked endpoints, SCTP has the following security objectives:¶
SCTP could potentially be used in a wide variety of risk situations.It is important for operators of systems running SCTP to analyzetheir particular situations and decide on the appropriate counter-measures.¶
Operators of systems running SCTP might consult[RFC2196] forguidance in securing their site.¶
The principles of[RFC2196] might be applied to minimize therisk of theft of information or sabotage by insiders.Such procedures include publication of security policies, control of access atthe physical, software, and network levels, and separation of services.¶
Where the risk of undetected errors in datagrams delivered by the lower-layertransport services is considered to be too great, additional integrityprotection is required.If this additional protection were provided in the application layer, theSCTP header would remain vulnerable to deliberate integrity attacks.While the existing SCTP mechanisms for detection of packet replays areconsidered sufficient for normal operation, stronger protections are needed toprotect SCTP when the operating environment contains significant risk ofdeliberate attacks from a sophisticated adversary.¶
The SCTP Authentication extension SCTP-AUTH[RFC4895]MAY beused when the threat environment requires stronger integrity protectionsbut does not require confidentiality.¶
In most cases, the risk of breach of confidentiality applies to thesignaling data payload, not to the SCTP or lower-layer protocol overheads.If that is true, encryption of the SCTP user data only might be considered.As with the supplementary checksum service, user data encryptionMAY beperformed by the SCTP user application.[RFC6083]MAY be used for this.Alternately, the user applicationMAY use an implementation-specific API torequest that the IP Encapsulating Security Payload (ESP)[RFC4303] be used to provide confidentiality and integrity.¶
Particularly for mobile users, the requirement for confidentiality mightinclude the masking of IP addresses and ports.In this case, ESPSHOULD be used instead of application-level confidentiality.If ESP is used to protect confidentiality of SCTP traffic, an ESP cryptographictransform that includes cryptographic integrity protectionMUST be used, because,if there is a confidentiality threat, there will also be a strong integritythreat.¶
Regardless of where confidentiality is provided, the Internet KeyExchange Protocol version 2 (IKEv2)[RFC7296]SHOULD be used forkey management of ESP.¶
Operators might consult[RFC4301] for more information on thesecurity services available at and immediately above the Internet Protocollayer.¶
A blind attack is one where the attacker is unable to intercept or otherwisesee the content of data flows passing to and from the target SCTP node.Blind denial-of-service attacks can take the form of flooding, masquerade,or improper monopolization of services.¶
The objective of flooding is to cause loss of service and incorrectbehavior at target systems through resource exhaustion, interferencewith legitimate transactions, and exploitation of buffer-relatedsoftware bugs.Flooding can be directed either at the SCTP node or at resources in theintervening IP Access Links or the Internet.Where the latter entities are the target, flooding will manifest itself as lossof network services, including potentially the breach of any firewalls inplace.¶
In general, protection against flooding begins at the equipmentdesign level, where it includes measures such as:¶
avoiding commitment of limited resources before determining that the requestfor service is legitimate.¶
giving priority to completion of processing in progress over the acceptanceof new work.¶
identification and removal of duplicate or stale queued requests forservice.¶
not responding to unexpected packets sent to non-unicast addresses.¶
Network equipment is expected to be capable of generating an alarm and log if asuspicious increase in traffic occurs.The log provides information, such as the identity of the incoming linkand source address(es) used, which will help the network or SCTP system operatorto take protective measures.Procedures are expected to be in place for the operator to act on such alarms if a clearpattern of abuse emerges.¶
The design of SCTP is resistant to flooding attacks, particularly in its useof a four-way startup handshake, its use of a cookie to defer commitment ofresources at the responding SCTP node until the handshake is completed, and itsuse of a Verification Tag to prevent insertion of extraneous packets into theflow of an established association.¶
ESP might be useful in reducing the risk of certain kinds ofdenial-of-service attacks.¶
Support for the Host Name Address parameter has been removed from theprotocol.Endpoints receiving INIT or INIT ACK chunks containing the Host Name AddressparameterMUST send an ABORT chunk in response andMAY include an"Unresolvable Address" error cause.¶
Masquerade can be used to deny service in several ways:¶
by tying up resources at the target SCTP node to which the impersonated nodehas limited access.For example, the target node can by policy permit a maximum of oneSCTP association with the impersonated SCTP node.The masquerading attacker can attempt to establish an association purporting tocome from the impersonated node so that the latter cannot do so when it requiresit.¶
by deliberately allowing the impersonation to be detected, therebyprovoking counter-measures that cause the impersonated node to be locked out ofthe target SCTP node.¶
by interfering with an established association by inserting extraneouscontent such as a SHUTDOWN chunk.¶
SCTP reduces the risk of blind masquerade attacks through IP spoofingby use of the four-way startup handshake.Because the initial exchange is memoryless, no lockout mechanism is triggeredby blind masquerade attacks.In addition, the packet containing the INIT ACK chunk with the State Cookieis transmitted back to the IP address from which it received the packetcontaining the INIT chunk.Thus, the attacker would not receive the INIT ACK chunk containing theState Cookie.SCTP protects against insertion of extraneous packets into the flow of anestablished association by use of the Verification Tag.¶
Logging of received INIT chunks and abnormalities, such as unexpectedINIT ACK chunks, might be considered as a way to detect patterns of hostileactivity.However, the potential usefulness of such logging has to be weighed against theincreased SCTP startup processing it implies, rendering the SCTP node morevulnerable to flooding attacks.Logging is pointless without the establishment of operating procedures toreview and analyze the logs on a routine basis.¶
Attacks under this heading are performed openly and legitimately by theattacker.They are directed against fellow users of the target SCTP node or of the sharedresources between the attacker and the target node.Possible attacks include the opening of a large number of associations betweenthe attacker's node and the target or transfer of large volumes of informationwithin a legitimately established association.¶
Policy limits are expected to be placed on the number of associations peradjoining SCTP node.SCTP user applications are expected to be capable of detecting large volumes ofillegitimate or "no-op" messages within a given association and either loggingor terminating the association as a result, based on local policy.¶
It is helpful for some firewalls if they can inspect just the firstfragment of a fragmented SCTP packet and unambiguously determine whether itcorresponds to an INIT chunk (for further information, please refer to[RFC1858]).Accordingly, we stress the requirements, as stated inSection 3.1, that(1) an INIT chunkMUST NOT be bundled with any other chunk in a packet and(2) a packet containing an INIT chunkMUST have a zero Verification Tag.The receiver of an INIT chunkMUST silently discard the INIT chunk and allfurther chunks if the INIT chunk is bundled with other chunks or the packethas a non-zero Verification Tag.¶
To provide a non-SCTP-capable host with the same level of protectionagainst attacks as for SCTP-capable ones, all SCTP implementationsMUSTimplement the ICMP handling described inSection 10.¶
When an SCTP implementation receives a packet containing multiple control orDATA chunks and the processing of the packet would result in sending multiplechunks in response, the sender of the response chunk(s)MUST NOT send more thanone packet containing chunks other than DATA chunks.This requirement protects the network for triggering a packet burst in responseto a single packet.If bundling is supported, multiple response chunks that fit into a singlepacketMAY be bundled together into one single response packet.If bundling is not supported, then the senderMUST NOT send more than oneresponse chunk andMUST discard all other responses.Note that this rule does not apply to a SACK chunk, since a SACK chunk is,in itself, a response to DATA chunks, and a SACK chunk does not require aresponse of more DATA chunks.¶
An SCTP implementationMUST abort the association if it receives a SACKchunk acknowledging a TSN that has not been sent.¶
An SCTP implementation that receives an INIT chunk that would require a largepacket in response, due to the inclusion of multiple "Unrecognized Parameter"parameters,MAY (at its discretion) elect to omit some or all of the"Unrecognized Parameter" parameters to reduce the size of the INIT ACK chunk.Due to a combination of the size of the State Cookie parameter and the number ofaddresses a receiver of an INIT chunk indicates to a peer, it is alwayspossible that the INIT ACK chunk will be larger than the original INIT chunk.An SCTP implementationSHOULD attempt to make the INIT ACK chunk as small aspossible to reduce the possibility of byte amplification attacks.¶
The MIB module for SCTP defined in[RFC3873] applies for theversion of the protocol specified in this document.¶
This section details a set of parameters that are expected to be containedwithin the TCB for an implementation.This section is for illustrative purposes and is not considered to berequirements on an implementation or as an exhaustive list of all parametersinside an SCTP TCB.Each implementation might need its own additional parameters for optimization.¶
COOKIE-WAIT, COOKIE-ECHOED, ESTABLISHED, SHUTDOWN-PENDING, SHUTDOWN-SENT,SHUTDOWN-RECEIVED, SHUTDOWN-ACK-SENT.¶
Note: No "CLOSED" state is illustrated, since, if an association is "CLOSED",its TCBSHOULD be removed.¶
For each destination transport address in the peer's address listderived from the INIT or INIT ACK chunk, a number of data elements need to bemaintained, including:¶
This document defines five registries that IANA maintains:¶
through definition of additional chunk types,¶
through definition of additional chunk flags,¶
through definition of additional parameter types,¶
through definition of additional cause codes within ERROR chunks, or¶
through definition of additional payload protocol identifiers.¶
IANA has performed the following updates for the above fiveregistries:¶
In the "Chunk Types" registry, IANA has replaced the registryreference to[RFC4960] and[RFC6096] with areference to this document.¶
In addition, in the Notes section, the reference toSection 3.2 of [RFC6096] has been updated with a reference toSection 15.2 of this document.¶
Finally, each reference to[RFC4960] has been replaced with a reference tothis document for the following chunk types:¶
Payload Data (DATA)¶
Initiation (INIT)¶
Initiation Acknowledgement (INIT ACK)¶
Selective Acknowledgement (SACK)¶
Heartbeat Request (HEARTBEAT)¶
Heartbeat Acknowledgement (HEARTBEAT ACK)¶
Abort (ABORT)¶
Shutdown (SHUTDOWN)¶
Shutdown Acknowledgement (SHUTDOWN ACK)¶
Operation Error (ERROR)¶
State Cookie (COOKIE ECHO)¶
Cookie Acknowledgement (COOKIE ACK)¶
Reserved for Explicit Congestion Notification Echo (ECNE)¶
Reserved for Congestion Window Reduced (CWR)¶
Shutdown Complete (SHUTDOWN COMPLETE)¶
Reserved for IETF-defined Chunk Extensions¶
In the "Chunk Parameter Types" registry, IANA has replacedthe registry reference to[RFC4960] with a reference to this document.¶
IANA has changed the name of the "Unrecognized Parameters" chunk parameter type to"Unrecognized Parameter" in the "Chunk Parameter Types" registry.¶
In addition, each reference to[RFC4960] has been replaced with a reference tothis document for the following chunk parameter types:¶
Heartbeat Info¶
IPv4 Address¶
IPv6 Address¶
State Cookie¶
Unrecognized Parameter¶
Cookie Preservative¶
Host Name Address¶
Supported Address Types¶
IANA has added a reference to this document for the following chunk parameter type:¶
Reserved for ECN Capable (0x8000)¶
Also, IANA has added the value 65535 to be reserved for IETF-defined extensions.¶
In the "Chunk Flags" registry, IANA replacedthe registry reference to[RFC6096] with a reference to this document.¶
In addition, each reference to[RFC4960] has been replaced with a reference tothis document for the following DATA chunk flags:¶
IANA has also replaced the reference to[RFC7053] with a reference tothis document for the following DATA chunk flag:¶
I bit¶
IANA has replaced the reference to[RFC4960] with a reference tothis document for the following ABORT chunk flag:¶
T bit¶
IANA has replaced the reference to[RFC4960] with a reference tothis document for the following SHUTDOWN COMPLETE chunk flag:¶
T bit¶
In the "Error Cause Codes" registry, IANA has replacedthe registry reference to[RFC4960] with a reference to this document.¶
IANA has changed the name of the "User Initiated Abort" error cause to"User-Initiated Abort" and the name of the "Stale Cookie Error" error causeto "Stale Cookie" in the "Error Cause Codes" registry.¶
In addition, each reference to[RFC4960] has been replaced with a reference tothis document for the following cause codes:¶
Invalid Stream Identifier¶
Missing Mandatory Parameter¶
Stale Cookie¶
Out of Resource¶
Unresolvable Address¶
Unrecognized Chunk Type¶
Invalid Mandatory Parameter¶
Unrecognized Parameters¶
No User Data¶
Cookie Received While Shutting Down¶
Restart of an Association with New Addresses¶
IANA has also replaced each reference to[RFC4460] with a reference tothis document for the following cause codes:¶
In the "SCTP Payload Protocol Identifiers" registry, IANA hasreplaced the registry reference to[RFC4960] with a referenceto this document.¶
IANA has replaced the reference to[RFC4960] with a reference tothis document for the following SCTP payload protocol identifier:¶
Reserved by SCTP¶
SCTP requires that the IANA "Port Numbers" registry be opened for SCTP portregistrations;Section 15.6 describes how.An IESG-appointed Expert Reviewer supports IANA in evaluating SCTP portallocation requests.¶
In the "Service Name and Transport Protocol Port Number Registry", IANA has replaced each reference to[RFC4960] with a reference tothis document for the following SCTP port numbers:¶
Furthermore, in the "Hypertext Transfer Protocol (HTTP) Digest Algorithm Values"registry, IANA has replaced the reference toAppendix B of [RFC4960] with a reference toAppendix A of this document.¶
In addition, in the "ONC RPC Netids (Standards Action)" registry, IANA has replaced eachreference to[RFC4960] with a reference tothis document for the following netids:¶
In the "IPFIX Information Elements" registry, IANA has replaced each reference to[RFC4960] with a reference tothis document for the following elements with the name:¶
sourceTransportPort¶
destinationTransportPort¶
collectorTransportPort¶
exporterTransportPort¶
postNAPTSourceTransportPort¶
postNAPTDestinationTransportPort¶
The assignment of new chunk type codes is done through an IETFReview action, as defined in[RFC8126].Documentation for a new chunkMUST contain the following information:¶
A long and short name for the new chunk type.¶
A detailed description of the structure of the chunk, whichMUST conform tothe basic structure defined inSection 3.2.¶
A detailed definition and description of intended use of each field withinthe chunk, including the chunk flags if any.Defined chunk flags will be used as initial entries in the chunk flags tablefor the new chunk type.¶
A detailed procedural description of the use of the new chunk type withinthe operation of the protocol.¶
The last chunk type (255) is reserved for future extension if necessary.¶
For each new chunk type, IANA creates a registration table for thechunk flags of that type.The procedure for registering particular chunk flags is described inSection 15.2.¶
The assignment of new chunk flags is done through an RFC Required action,as defined in[RFC8126].Documentation for the chunk flagsMUST contain the following information:¶
A name for the new chunk flag.¶
A detailed procedural description of the use of the new chunk flag withinthe operation of the protocol.ItMUST be considered that implementations not supporting the flag will send 0on transmit and just ignore it on receipt.¶
IANA selects a chunk flags value.ThisMUST be one of 0x01, 0x02, 0x04, 0x08, 0x10, 0x20, 0x40, or 0x80, whichMUST be unique within the chunk flag values for the specific chunk type.¶
The assignment of new chunk parameter type codes is done through an IETFReview action, as defined in[RFC8126].Documentation of the chunk parameterMUST contain the following information:¶
Name of the parameter type.¶
Detailed description of the structure of the parameter field.This structureMUST conform to the general Type-Length-Value format describedinSection 3.2.1.¶
Detailed definition of each component of the parameter value.¶
Detailed description of the intended use of this parameter type and anindication of whether and under what circumstances multiple instances of thisparameter type can be found within the same chunk.¶
Each parameter typeMUST be unique across all chunks.¶
Additional cause codes can be allocated through a Specification Required action as defined in[RFC8126].Provided documentationMUST include the following information:¶
Name of the error condition.¶
Detailed description of the conditions under which an SCTP endpointissues an ERROR (or ABORT) chunk with this cause code.¶
Expected action by the SCTP endpoint that receives an ERROR (or ABORT) chunkcontaining this cause code.¶
Detailed description of the structure and content of data fields thataccompany this cause code.¶
The initial word (32 bits) of a cause code parameterMUST conform to theformat shown inSection 3.3.10, that is:¶
The assignment of payload protocol identifiers is done using the First ComeFirst Served policy, as defined in[RFC8126].¶
Except for value 0, which is reserved to indicate an unspecified payloadprotocol identifier in a DATA chunk, an SCTP implementation will not beresponsible for standardizing or verifying any payload protocol identifiers.An SCTP implementation simply receives the identifier from the upper layerand carries it with the corresponding payload data.¶
The upper layer, i.e., the SCTP user,SHOULD standardize any specificprotocol identifier with IANA if it is so desired.The use of any specific payload protocol identifier is out of the scope ofthis specification.¶
SCTP services can use contact port numbers to provide service to unknowncallers, as in TCP and UDP.An IESG-appointed Expert Reviewer supports IANA in evaluating SCTP portallocation requests, according to the procedure defined in[RFC8126].The details of this process are defined in[RFC6335].¶
The following protocol parameters areRECOMMENDED:¶
1 second¶
1 second¶
60 seconds¶
4¶
1/8¶
1/4¶
60 seconds¶
10 attempts¶
5 attempts (per destination address)¶
8 attempts¶
30 seconds¶
1¶
200 milliseconds¶
Implementation Note: The SCTP implementation can allow ULP to customize someof these protocol parameters (seeSection 11).¶
'RTO.Min'SHOULD be set as described above in this section.¶
We define a 'reflected value' as one that is the opposite of the normalbit order of the machine.The 32-bit CRC (Cyclic Redundancy Check) is calculated, as described for CRC32cand uses the polynomial code 0x11EDC6F41 (Castagnoli93) orx32+x28+x27+x26+x25+x23+x22+x20+x19+x18+x14+x13+x11+x10+x9+x8+x6+x0.The CRC is computed using a procedure similar toETHERNET CRC[ITU.V42.1994], modified to reflecttransport-level usage.¶
CRC computation uses polynomial division. A message bit-string M istransformed to a polynomial, M(X), and the CRC is calculated from M(X) usingpolynomial arithmetic.¶
When CRCs are used at the link layer, the polynomial is derived fromon-the-wire bit ordering: the first bit 'on the wire' is the high-ordercoefficient.Since SCTP is a transport-level protocol, it cannot know the actualserial-media bit ordering.Moreover, different links in the path between SCTP endpoints can use differentlink-level bit orders.¶
A convention therefore is established for mapping SCTP transportmessages to polynomials for purposes of CRC computation.The bit-ordering for mapping SCTP messages to polynomials is that bytes aretaken most-significant first, but, within each byte, bits are takenleast-significant first.The first byte of the message provides the eight highest coefficients.Within each byte, the least-significant SCTP bit gives the most-significantpolynomial coefficient within that byte, and the most-significant SCTP bit isthe least-significant polynomial coefficient in that byte.(This bit ordering is sometimes called 'mirrored' or 'reflected'[WILLIAMS93].)CRC polynomials are to be transformed back into SCTP transport-levelbyte values, using a consistent mapping.¶
The SCTP transport-level CRC value can be calculated as follows:¶
CRC input data is assigned to a byte stream, numbered from 0 to N-1.¶
The transport-level byte stream is mapped to a polynomial value.An N-byte PDU with j bytes numbered 0 to N-1 is considered ascoefficients of a polynomial M(x) of order 8*N-1, with bit 0 ofbyte j being coefficient x8*(N-j)-8 and bit 7 of byte j beingcoefficient x8*(N-j)-1.¶
The CRC remainder register is initialized with all 1s and the CRC is computedwith an algorithm that simultaneously multiplies by x32 and divides by theCRC polynomial.¶
The polynomial is multiplied by x32 and divided by G(x), the generatorpolynomial, producing a remainder R(x) of degree less than or equal to 31.¶
The coefficients of R(x) are considered a 32-bit sequence.¶
The bit sequence is complemented.The result is the CRC polynomial.¶
The CRC polynomial is mapped back into SCTP transport-level bytes.The coefficient of x31 gives the value of bit 7 of SCTP byte 0,and the coefficient of x24 gives the value of bit 0 of byte 0.The coefficient of x7 gives bit 7 of byte 3, and the coefficientof x0 gives bit 0 of byte 3.The resulting 4-byte transport-level sequence is the 32-bit SCTP checksumvalue.¶
Implementation Note: Standards documents, textbooks, and vendorliterature on CRCs often follow an alternative formulation, in which theregister used to hold the remainder of the long-division algorithm isinitialized to zero rather than all ones, and instead the first 32 bits of themessage are complemented.The long-division algorithm used in our formulation is specified such that theinitial multiplication by 232 and the long-division are combined into onesimultaneous operation.For such algorithms, and for messages longer than 64 bits, the twospecifications are precisely equivalent.That equivalence is the intent of this document.¶
Implementors of SCTP are warned that both specifications are to befound in the literature, sometimes with no restriction on the long-divisionalgorithm.The choice of formulation in this document is to permit non-SCTP usage, wherethe same CRC algorithm can be used to protect messages shorter than 64 bits.¶
There can be a computational advantage in validating the associationagainst the Verification Tag, prior to performing a checksum, as invalid tagswill result in the same action as a bad checksum in most cases.The exceptions for this technique would be packets containing INIT chunks andsome SHUTDOWN-COMPLETE chunks, as well as a stale COOKIE ECHO chunks.These special-case exchanges represent small packets and will minimizethe effect of the checksum calculation.¶
The following non-normative sample code is taken from an open-sourceCRC generator[WILLIAMS93], using the "mirroring" technique andyielding a lookup table for SCTP CRC32c with 256 entries, each 32 bits wide.While neither especially slow nor especially fast, as software table-lookupCRCs go, it has the advantage of working on both big-endian and little-endianCPUs, using the same (host-order) lookup tables, and using only thepredefined ntohl() and htonl() operations.The code is somewhat modified from[WILLIAMS93] to ensureportability between big-endian and little-endian architectures, use fixed-sizedtypes to allow portability between 32-bit and 64-bit platforms, and usegeneral C code improvements.(Note that, if the byte endian-ness of the target architecture is known to belittle endian, the final bit-reversal and byte-reversal steps can be foldedinto a single operation.)¶
<CODE BEGINS>/****************************************************************//* Note: The definitions for Ross Williams's table generator *//* would be TB_WIDTH=4, TB_POLY=0x1EDC6F41, TB_REVER=TRUE. *//* For Mr. Williams's direct calculation code, use the settings *//* cm_width=32, cm_poly=0x1EDC6F41, cm_init=0xFFFFFFFF, *//* cm_refin=TRUE, cm_refot=TRUE, cm_xorot=0x00000000. *//****************************************************************//* Example of the crc table file */#ifndef __crc32cr_h__#define __crc32cr_h__#define CRC32C_POLY 0x1EDC6F41UL#define CRC32C(c,d) (c=(c>>8)^crc_c[(c^(d))&0xFF])uint32_t crc_c[256] = { 0x00000000UL, 0xF26B8303UL, 0xE13B70F7UL, 0x1350F3F4UL, 0xC79A971FUL, 0x35F1141CUL, 0x26A1E7E8UL, 0xD4CA64EBUL, 0x8AD958CFUL, 0x78B2DBCCUL, 0x6BE22838UL, 0x9989AB3BUL, 0x4D43CFD0UL, 0xBF284CD3UL, 0xAC78BF27UL, 0x5E133C24UL, 0x105EC76FUL, 0xE235446CUL, 0xF165B798UL, 0x030E349BUL, 0xD7C45070UL, 0x25AFD373UL, 0x36FF2087UL, 0xC494A384UL, 0x9A879FA0UL, 0x68EC1CA3UL, 0x7BBCEF57UL, 0x89D76C54UL, 0x5D1D08BFUL, 0xAF768BBCUL, 0xBC267848UL, 0x4E4DFB4BUL, 0x20BD8EDEUL, 0xD2D60DDDUL, 0xC186FE29UL, 0x33ED7D2AUL, 0xE72719C1UL, 0x154C9AC2UL, 0x061C6936UL, 0xF477EA35UL, 0xAA64D611UL, 0x580F5512UL, 0x4B5FA6E6UL, 0xB93425E5UL, 0x6DFE410EUL, 0x9F95C20DUL, 0x8CC531F9UL, 0x7EAEB2FAUL, 0x30E349B1UL, 0xC288CAB2UL, 0xD1D83946UL, 0x23B3BA45UL, 0xF779DEAEUL, 0x05125DADUL, 0x1642AE59UL, 0xE4292D5AUL, 0xBA3A117EUL, 0x4851927DUL, 0x5B016189UL, 0xA96AE28AUL, 0x7DA08661UL, 0x8FCB0562UL, 0x9C9BF696UL, 0x6EF07595UL, 0x417B1DBCUL, 0xB3109EBFUL, 0xA0406D4BUL, 0x522BEE48UL, 0x86E18AA3UL, 0x748A09A0UL, 0x67DAFA54UL, 0x95B17957UL, 0xCBA24573UL, 0x39C9C670UL, 0x2A993584UL, 0xD8F2B687UL, 0x0C38D26CUL, 0xFE53516FUL, 0xED03A29BUL, 0x1F682198UL, 0x5125DAD3UL, 0xA34E59D0UL, 0xB01EAA24UL, 0x42752927UL, 0x96BF4DCCUL, 0x64D4CECFUL, 0x77843D3BUL, 0x85EFBE38UL, 0xDBFC821CUL, 0x2997011FUL, 0x3AC7F2EBUL, 0xC8AC71E8UL, 0x1C661503UL, 0xEE0D9600UL, 0xFD5D65F4UL, 0x0F36E6F7UL, 0x61C69362UL, 0x93AD1061UL, 0x80FDE395UL, 0x72966096UL, 0xA65C047DUL, 0x5437877EUL, 0x4767748AUL, 0xB50CF789UL, 0xEB1FCBADUL, 0x197448AEUL, 0x0A24BB5AUL, 0xF84F3859UL, 0x2C855CB2UL, 0xDEEEDFB1UL, 0xCDBE2C45UL, 0x3FD5AF46UL, 0x7198540DUL, 0x83F3D70EUL, 0x90A324FAUL, 0x62C8A7F9UL, 0xB602C312UL, 0x44694011UL, 0x5739B3E5UL, 0xA55230E6UL, 0xFB410CC2UL, 0x092A8FC1UL, 0x1A7A7C35UL, 0xE811FF36UL, 0x3CDB9BDDUL, 0xCEB018DEUL, 0xDDE0EB2AUL, 0x2F8B6829UL, 0x82F63B78UL, 0x709DB87BUL, 0x63CD4B8FUL, 0x91A6C88CUL, 0x456CAC67UL, 0xB7072F64UL, 0xA457DC90UL, 0x563C5F93UL, 0x082F63B7UL, 0xFA44E0B4UL, 0xE9141340UL, 0x1B7F9043UL, 0xCFB5F4A8UL, 0x3DDE77ABUL, 0x2E8E845FUL, 0xDCE5075CUL, 0x92A8FC17UL, 0x60C37F14UL, 0x73938CE0UL, 0x81F80FE3UL, 0x55326B08UL, 0xA759E80BUL, 0xB4091BFFUL, 0x466298FCUL, 0x1871A4D8UL, 0xEA1A27DBUL, 0xF94AD42FUL, 0x0B21572CUL, 0xDFEB33C7UL, 0x2D80B0C4UL, 0x3ED04330UL, 0xCCBBC033UL, 0xA24BB5A6UL, 0x502036A5UL, 0x4370C551UL, 0xB11B4652UL, 0x65D122B9UL, 0x97BAA1BAUL, 0x84EA524EUL, 0x7681D14DUL, 0x2892ED69UL, 0xDAF96E6AUL, 0xC9A99D9EUL, 0x3BC21E9DUL, 0xEF087A76UL, 0x1D63F975UL, 0x0E330A81UL, 0xFC588982UL, 0xB21572C9UL, 0x407EF1CAUL, 0x532E023EUL, 0xA145813DUL, 0x758FE5D6UL, 0x87E466D5UL, 0x94B49521UL, 0x66DF1622UL, 0x38CC2A06UL, 0xCAA7A905UL, 0xD9F75AF1UL, 0x2B9CD9F2UL, 0xFF56BD19UL, 0x0D3D3E1AUL, 0x1E6DCDEEUL, 0xEC064EEDUL, 0xC38D26C4UL, 0x31E6A5C7UL, 0x22B65633UL, 0xD0DDD530UL, 0x0417B1DBUL, 0xF67C32D8UL, 0xE52CC12CUL, 0x1747422FUL, 0x49547E0BUL, 0xBB3FFD08UL, 0xA86F0EFCUL, 0x5A048DFFUL, 0x8ECEE914UL, 0x7CA56A17UL, 0x6FF599E3UL, 0x9D9E1AE0UL, 0xD3D3E1ABUL, 0x21B862A8UL, 0x32E8915CUL, 0xC083125FUL, 0x144976B4UL, 0xE622F5B7UL, 0xF5720643UL, 0x07198540UL, 0x590AB964UL, 0xAB613A67UL, 0xB831C993UL, 0x4A5A4A90UL, 0x9E902E7BUL, 0x6CFBAD78UL, 0x7FAB5E8CUL, 0x8DC0DD8FUL, 0xE330A81AUL, 0x115B2B19UL, 0x020BD8EDUL, 0xF0605BEEUL, 0x24AA3F05UL, 0xD6C1BC06UL, 0xC5914FF2UL, 0x37FACCF1UL, 0x69E9F0D5UL, 0x9B8273D6UL, 0x88D28022UL, 0x7AB90321UL, 0xAE7367CAUL, 0x5C18E4C9UL, 0x4F48173DUL, 0xBD23943EUL, 0xF36E6F75UL, 0x0105EC76UL, 0x12551F82UL, 0xE03E9C81UL, 0x34F4F86AUL, 0xC69F7B69UL, 0xD5CF889DUL, 0x27A40B9EUL, 0x79B737BAUL, 0x8BDCB4B9UL, 0x988C474DUL, 0x6AE7C44EUL, 0xBE2DA0A5UL, 0x4C4623A6UL, 0x5F16D052UL, 0xAD7D5351UL,};#endif/* Example of table build routine */#include <stdio.h>#include <stdlib.h>#define OUTPUT_FILE "crc32cr.h"#define CRC32C_POLY 0x1EDC6F41ULstatic FILE *tf;static uint32_treflect_32(uint32_t b){ int i; uint32_t rw = 0UL; for (i = 0; i < 32; i++) { if (b & 1) rw |= 1UL << (31 - i); b >>= 1; } return (rw);}static uint32_tbuild_crc_table (int index){ int i; uint32_t rb; rb = reflect_32(index); for (i = 0; i < 8; i++) { if (rb & 0x80000000UL) rb = (rb << 1) ^ (uint32_t)CRC32C_POLY; else rb <<= 1; } return (reflect_32(rb));}intmain (void){ int i; printf("\nGenerating CRC32c table file <%s>.\n", OUTPUT_FILE); if ((tf = fopen(OUTPUT_FILE, "w")) == NULL) { printf("Unable to open %s.\n", OUTPUT_FILE); exit (1); } fprintf(tf, "#ifndef __crc32cr_h__\n"); fprintf(tf, "#define __crc32cr_h__\n\n"); fprintf(tf, "#define CRC32C_POLY 0x%08XUL\n", (uint32_t)CRC32C_POLY); fprintf(tf, "#define CRC32C(c,d) (c=(c>>8)^crc_c[(c^(d))&0xFF])\n"); fprintf(tf, "\nuint32_t crc_c[256] =\n{\n"); for (i = 0; i < 256; i++) { fprintf(tf, "0x%08XUL,", build_crc_table (i)); if ((i & 3) == 3) fprintf(tf, "\n"); else fprintf(tf, " "); } fprintf(tf, "};\n\n#endif\n"); if (fclose(tf) != 0) printf("Unable to close <%s>.\n", OUTPUT_FILE); else printf("\nThe CRC32c table has been written to <%s>.\n", OUTPUT_FILE); return (0);}/* Example of crc insertion */#include "crc32cr.h"uint32_tgenerate_crc32c(unsigned char *buffer, unsigned int length){ unsigned int i; uint32_t crc32 = 0xffffffffUL; uint32_t result; uint32_t byte0, byte1, byte2, byte3; for (i = 0; i < length; i++) { CRC32C(crc32, buffer[i]); } result = ~crc32; /* result now holds the negated polynomial remainder, * since the table and algorithm are "reflected" [williams95]. * That is, result has the same value as if we mapped the message * to a polynomial, computed the host-bit-order polynomial * remainder, performed final negation, and then did an * end-for-end bit-reversal. * Note that a 32-bit bit-reversal is identical to four in-place * 8-bit bit-reversals followed by an end-for-end byteswap. * In other words, the bits of each byte are in the right order, * but the bytes have been byteswapped. So, we now do an explicit * byteswap. On a little-endian machine, this byteswap and * the final ntohl cancel out and could be elided. */ byte0 = result & 0xff; byte1 = (result>>8) & 0xff; byte2 = (result>>16) & 0xff; byte3 = (result>>24) & 0xff; crc32 = ((byte0 << 24) | (byte1 << 16) | (byte2 << 8) | byte3); return (crc32);}intinsert_crc32(unsigned char *buffer, unsigned int length){ SCTP_message *message; uint32_t crc32; message = (SCTP_message *)buffer; message->common_header.checksum = 0UL; crc32 = generate_crc32c(buffer,length); /* and insert it into the message */ message->common_header.checksum = htonl(crc32); return (1);}intvalidate_crc32(unsigned char *buffer, unsigned int length){ SCTP_message *message; unsigned int i; uint32_t original_crc32; uint32_t crc32; /* save and zero checksum */ message = (SCTP_message *)buffer; original_crc32 = ntohl(message->common_header.checksum); message->common_header.checksum = 0L; crc32 = generate_crc32c(buffer, length); return ((original_crc32 == crc32) ? 1 : -1);}<CODE ENDS>¶An undertaking represented by this updated document is not a smallfeat and represents the summation of the initial coauthors of[RFC2960]:Q. Xie,K. Morneault,C. Sharp,H. Schwarzbauer,T. Taylor,I. Rytina,M. Kalla,L. Zhang,andV. Paxson.¶
Add to that, the comments from everyone who contributed to[RFC2960]:Mark Allman,R. J. Atkinson,Richard Band,Scott Bradner,Steve Bellovin,Peter Butler,Ram Dantu,R. Ezhirpavai,Mike Fisk,Sally Floyd,Atsushi Fukumoto,Matt Holdrege,Henry Houh,Christian Huitema,Gary Lehecka,Jonathan Lee,David Lehmann,John Loughney,Daniel Luan,Barry Nagelberg,Thomas Narten,Erik Nordmark,Lyndon Ong,Shyamal Prasad,Kelvin Porter,Heinz Prantner,Jarno Rajahalme,Raymond E. Reeves,Renee Revis,Ivan Arias Rodriguez,A. Sankar,Greg Sidebottom,Brian Wyld,La Monte Yarroll,and many others for their invaluable comments.¶
Then, add the coauthors of[RFC4460]:I. Arias-Rodriguez,K. Poon,andA. Caro.¶
Then, add to these the efforts of all the subsequent sevenSCTP interoperability tests and those who commented on[RFC4460],as shown in its acknowledgements:Barry Zuckerman,La Monte Yarroll,Qiaobing Xie,Wang Xiaopeng,Jonathan Wood,Jeff Waskow,Mike Turner,John Townsend,Sabina Torrente,Cliff Thomas,Yuji Suzuki,Manoj Solanki,Sverre Slotte,Keyur Shah,Jan Rovins,Ben Robinson,Renee Revis,Ian Periam,RC Monee,Sanjay Rao,Sujith Radhakrishnan,Heinz Prantner,Biren Patel,Nathalie Mouellic,Mitch Miers,Bernward Meyknecht,Stan McClellan,Oliver Mayor,Tomas Orti Martin,Sandeep Mahajan,David Lehmann,Jonathan Lee,Philippe Langlois,Karl Knutson,Joe Keller,Gareth Keily,Andreas Jungmaier,Janardhan Iyengar,Mutsuya Irie,John Hebert,Kausar Hassan,Fred Hasle,Dan Harrison,Jon Grim,Laurent Glaude,Steven Furniss,Atsushi Fukumoto,Ken Fujita,Steve Dimig,Thomas Curran,Serkan Cil,Melissa Campbell,Peter Butler,Rob Brennan,Harsh Bhondwe,Brian Bidulock,Caitlin Bestler,Jon Berger,Robby Benedyk,Stephen Baucke,Sandeep Balani,andRonnie Sellar.¶
A special thanks toMark Allman, who actually shouldhave been a coauthor of[RFC4460] for his work on the max-burst but managed to wiggle out due to atechnicality.¶
Also, we would like to acknowledgeLyndon Ong andPhil Conrad for their valuable input and manycontributions.¶
Furthermore, you have[RFC4960] and those who have commentedupon that, includingAlfred Hönes andRonnie Sellars.¶
Then, add the coauthor of[RFC8540]:Maksim Proshin.¶
And people who have commented on[RFC8540]:Pontus Andersson,Eric W. Biederman,Cedric Bonnet,Spencer Dawkins,Gorry Fairhurst,Benjamin Kaduk,Mirja Kühlewind,Peter Lei,Gyula Marosi,Lionel Morand,Jeff Morriss,Tom Petch,Kacheong Poon,Julien Pourtet,Irene Rüngeler,Michael Welzl,andQiaobing Xie.¶
And, finally, the people who have provided comments for this document, includingGorry Fairhurst,Martin Duke,Benjamin Kaduk,Tero Kivinen,Eliot Lear,Marcelo Ricardo Leitner,David Mandelberg,John Preuß Mattsson,Claudio Porfiri,Maksim Proshin,Ines Robles,Timo Völker,Magnus Westerlund,andZhouming.¶
Our thanks cannot be adequately expressed to all of you who have participatedin the coding, testing, and updating process of this document.All we can say is, Thank You!¶