RFC 4960
Stream Control Transmission Protocol
Pages: 152
Obsoletes: 2960 3309
Obsoleted by: 9260
Updated by: 6096 6335 7053 8899
Obsoletes: 2960 3309
Obsoleted by: 9260
Updated by: 6096 6335 7053 8899
Part 7 of 7 – Pages 129 to 152
13. Recommended Transmission Control Block (TCB) Parameters
This section details a recommended set of parameters that should be contained within the TCB for an implementation. This section is for illustrative purposes and should not be deemed as requirements on an implementation or as an exhaustive list of all parameters inside an SCTP TCB. Each implementation may need its own additional parameters for optimization.13.1. Parameters Necessary for the SCTP Instance
Associations: A list of current associations and mappings to the data consumers for each association. This may be in the form of a hash table or other implementation-dependent structure. The data consumers may be process identification information such as file descriptors, named pipe pointer, or table pointers dependent on how SCTP is implemented. Secret Key: A secret key used by this endpoint to compute the MAC. This SHOULD be a cryptographic quality random number with a sufficient length. Discussion in RFC 4086 can be helpful in selection of the key. Address List: The list of IP addresses that this instance has bound. This information is passed to one's peer(s) in INIT and INIT ACK chunks. SCTP Port: The local SCTP port number to which the endpoint is bound.13.2. Parameters Necessary per Association (i.e., the TCB)
Peer : Tag value to be sent in every packet and is received Verification: in the INIT or INIT ACK chunk. Tag : My : Tag expected in every inbound packet and sent in the Verification: INIT or INIT ACK chunk. Tag : State : A state variable indicating what state the association : is in, i.e., COOKIE-WAIT, COOKIE-ECHOED, ESTABLISHED, : SHUTDOWN-PENDING, SHUTDOWN-SENT, SHUTDOWN-RECEIVED, : SHUTDOWN-ACK-SENT. Note: No "CLOSED" state is illustrated since if a association is "CLOSED" its TCB SHOULD be removed.
Peer : A list of SCTP transport addresses to which the peer
Transport : is bound. This information is derived from the INIT or
Address : INIT ACK and is used to associate an inbound packet
List : with a given association. Normally, this information
: is hashed or keyed for quick lookup and access of the
: TCB.
Primary : This is the current primary destination transport
Path : address of the peer endpoint. It may also specify a
: source transport address on this endpoint.
Overall : The overall association error count.
Error Count :
Overall : The threshold for this association that if the Overall
Error : Error Count reaches will cause this association to be
Threshold : torn down.
Peer Rwnd : Current calculated value of the peer's rwnd.
Next TSN : The next TSN number to be assigned to a new DATA chunk.
: This is sent in the INIT or INIT ACK chunk to the peer
: and incremented each time a DATA chunk is assigned a
: TSN (normally just prior to transmit or during
: fragmentation).
Last Rcvd : This is the last TSN received in sequence. This value
TSN : is set initially by taking the peer's initial TSN,
: received in the INIT or INIT ACK chunk, and
: subtracting one from it.
Mapping : An array of bits or bytes indicating which out-of-
Array : order TSNs have been received (relative to the
: Last Rcvd TSN). If no gaps exist, i.e., no out-of-
: order packets have been received, this array will
: be set to all zero. This structure may be in the
: form of a circular buffer or bit array.
Ack State : This flag indicates if the next received packet
: is to be responded to with a SACK. This is initialized
: to 0. When a packet is received it is incremented.
: If this value reaches 2 or more, a SACK is sent and the
: value is reset to 0. Note: This is used only when no
: DATA chunks are received out of order. When DATA
: chunks are out of order, SACKs are not delayed (see
: Section 6).
Inbound : An array of structures to track the inbound streams,
Streams : normally including the next sequence number expected
: and possibly the stream number.
Outbound : An array of structures to track the outbound streams,
Streams : normally including the next sequence number to
: be sent on the stream.
Reasm Queue : A reassembly queue.
Local : The list of local IP addresses bound in to this
Transport : association.
Address :
List :
Association : The smallest PMTU discovered for all of the
PMTU : peer's transport addresses.
13.3. Per Transport Address Data
For each destination transport address in the peer's address list
derived from the INIT or INIT ACK chunk, a number of data elements
need to be maintained including:
Error Count : The current error count for this destination.
Error : Current error threshold for this destination, i.e.,
Threshold : what value marks the destination down if error count
: reaches this value.
cwnd : The current congestion window.
ssthresh : The current ssthresh value.
RTO : The current retransmission timeout value.
SRTT : The current smoothed round-trip time.
RTTVAR : The current RTT variation.
partial : The tracking method for increase of cwnd when in
bytes acked : congestion avoidance mode (see Section 7.2.2).
state : The current state of this destination, i.e., DOWN, UP,
: ALLOW-HB, NO-HEARTBEAT, etc.
PMTU : The current known path MTU.
Per : A timer used by each destination.
Destination :
Timer :
RTO-Pending : A flag used to track if one of the DATA chunks sent to
: this address is currently being used to compute an
: RTT. If this flag is 0, the next DATA chunk sent to
: this destination should be used to compute an RTT and
: this flag should be set. Every time the RTT
: calculation completes (i.e., the DATA chunk is SACK'd),
: clear this flag.
last-time : The time to which this destination was last sent.
: This can be to determine if a HEARTBEAT is needed.
13.4. General Parameters Needed
Out Queue : A queue of outbound DATA chunks.
In Queue : A queue of inbound DATA chunks.
14. IANA Considerations
SCTP defines three registries that IANA maintains:
- through definition of additional chunk types,
- through definition of additional parameter types, or
- through definition of additional cause codes within ERROR chunks.
SCTP requires that the IANA Port Numbers registry be opened for SCTP
port registrations, Section 14.5 describes how. An IESG-appointed
Expert Reviewer supports IANA in evaluating SCTP port allocation
requests.
14.1. IETF-Defined Chunk Extension
The assignment of new chunk parameter type codes is done through an
IETF Consensus action, as defined in [RFC2434]. Documentation of the
chunk parameter MUST contain the following information:
a) A long and short name for the new chunk type.
b) A detailed description of the structure of the chunk, which MUST
conform to the basic structure defined in Section 3.2.
c) A detailed definition and description of intended use of each
field within the chunk, including the chunk flags if any.
d) A detailed procedural description of the use of the new chunk type
within the operation of the protocol.
The last chunk type (255) is reserved for future extension if
necessary.
14.2. IETF-Defined Chunk Parameter Extension
The assignment of new chunk parameter type codes is done through an
IETF Consensus action as defined in [RFC2434]. Documentation of the
chunk parameter MUST contain the following information:
a) Name of the parameter type.
b) Detailed description of the structure of the parameter field.
This structure MUST conform to the general Type-Length-Value
format described in Section 3.2.1.
c) Detailed definition of each component of the parameter value.
d) Detailed description of the intended use of this parameter type,
and an indication of whether and under what circumstances multiple
instances of this parameter type may be found within the same
chunk.
e) Each parameter type MUST be unique across all chunks.
14.3. IETF-Defined Additional Error Causes
Additional cause codes may be allocated in the range 11 to 65535
through a Specification Required action as defined in [RFC2434].
Provided documentation must include the following information:
a) Name of the error condition.
b) Detailed description of the conditions under which an SCTP
endpoint should issue an ERROR (or ABORT) with this cause code.
c) Expected action by the SCTP endpoint that receives an ERROR (or
ABORT) chunk containing this cause code.
d) Detailed description of the structure and content of data fields
that accompany this cause code.
The initial word (32 bits) of a cause code parameter MUST conform to the format shown in Section 3.3.10, i.e.: - first 2 bytes contain the cause code value - last 2 bytes contain the length of the cause parameter.14.4. Payload Protocol Identifiers
Except for value 0, which is reserved by SCTP to indicate an unspecified payload protocol identifier in a DATA chunk, SCTP will not be responsible for standardizing or verifying any payload protocol identifiers; SCTP simply receives the identifier from the upper layer and carries it with the corresponding payload data. The upper layer, i.e., the SCTP user, SHOULD standardize any specific protocol identifier with IANA if it is so desired. The use of any specific payload protocol identifier is out of the scope of SCTP.14.5. Port Numbers Registry
SCTP services may use contact port numbers to provide service to unknown callers, as in TCP and UDP. IANA is therefore requested to open the existing Port Numbers registry for SCTP using the following rules, which we intend to mesh well with existing Port Numbers registration procedures. An IESG-appointed Expert Reviewer supports IANA in evaluating SCTP port allocation requests, according to the procedure defined in [RFC2434]. Port numbers are divided into three ranges. The Well Known Ports are those from 0 through 1023, the Registered Ports are those from 1024 through 49151, and the Dynamic and/or Private Ports are those from 49152 through 65535. Well Known and Registered Ports are intended for use by server applications that desire a default contact point on a system. On most systems, Well Known Ports can only be used by system (or root) processes or by programs executed by privileged users, while Registered Ports can be used by ordinary user processes or programs executed by ordinary users. Dynamic and/or Private Ports are intended for temporary use, including client-side ports, out-of- band negotiated ports, and application testing prior to registration of a dedicated port; they MUST NOT be registered. The Port Numbers registry should accept registrations for SCTP ports in the Well Known Ports and Registered Ports ranges. Well Known and Registered Ports SHOULD NOT be used without registration. Although in some cases -- such as porting an application from TCP to SCTP -- it may seem natural to use an SCTP port before registration completes, we emphasize that IANA will not guarantee registration of
particular Well Known and Registered Ports. Registrations should be
requested as early as possible.
Each port registration SHALL include the following information:
o A short port name, consisting entirely of letters (A-Z and a-z),
digits (0-9), and punctuation characters from "-_+./*" (not
including the quotes).
o The port number that is requested for registration.
o A short English phrase describing the port's purpose.
o Name and contact information for the person or entity performing
the registration, and possibly a reference to a document defining
the port's use. Registrations coming from IETF working groups
need only name the working group, but indicating a contact person
is recommended.
Registrants are encouraged to follow these guidelines when submitting
a registration.
o A port name SHOULD NOT be registered for more than one SCTP port
number.
o A port name registered for TCP MAY be registered for SCTP as well.
Any such registration SHOULD use the same port number as the
existing TCP registration.
o Concrete intent to use a port SHOULD precede port registration.
For example, existing TCP ports SHOULD NOT be registered in
advance of any intent to use those ports for SCTP.
This document registers the following ports. (These registrations
should be considered models to follow for future allocation
requests.)
discard 9/sctp Discard # IETF TSVWG
# Randall Stewart <rrs@cisco.com>
# [RFC4960]
The discard service, which accepts SCTP connections on port
9, discards all incoming application data and sends no data
in response. Thus, SCTP's discard port is analogous to
TCP's discard port, and might be used to check the health
of an SCTP stack.
ftp-data 20/sctp FTP # IETF TSVWG
# Randall Stewart <rrs@cisco.com>
# [RFC4960]
ftp 21/sctp FTP # IETF TSVWG
# Randall Stewart <rrs@cisco.com>
# [RFC4960]
File Transfer Protocol (FTP) data (20) and control ports
(21).
ssh 22/sctp SSH # IETF TSVWG
# Randall Stewart <rrs@cisco.com>
# [RFC4960]
The Secure Shell (SSH) remote login service, which allows
secure shell logins to a host.
http 80/sctp HTTP # IETF TSVWG
# Randall Stewart <rrs@cisco.com>
# [RFC4960]
World Wide Web HTTP over SCTP.
bgp 179/sctp BGP # IETF TSVWG
# Randall Stewart <rrs@cisco.com>
# [RFC4960]
Border Gateway Protocol over SCTP.
https 443/sctp HTTPS # IETF TSVWG
# Randall Stewart <rrs@cisco.com>
# [RFC4960]
World Wide Web HTTP over TLS/SSL over SCTP.
15. Suggested SCTP Protocol Parameter Values
The following protocol parameters are RECOMMENDED:
RTO.Initial - 3 seconds
RTO.Min - 1 second
RTO.Max - 60 seconds
Max.Burst - 4
RTO.Alpha - 1/8
RTO.Beta - 1/4
Valid.Cookie.Life - 60 seconds
Association.Max.Retrans - 10 attempts
Path.Max.Retrans - 5 attempts (per destination address)
Max.Init.Retransmits - 8 attempts
HB.interval - 30 seconds
HB.Max.Burst - 1
IMPLEMENTATION NOTE: The SCTP implementation may allow ULP to
customize some of these protocol parameters (see Section 10).
Note: RTO.Min SHOULD be set as recommended above.
16. Acknowledgements
An undertaking represented by this updated document is not a small
feat and represents the summation of the initial authors of RFC 2960:
Q. Xie, K. Morneault, C. Sharp, H. Schwarzbauer, T. Taylor, I.
Rytina, M. Kalla, L. Zhang, and V. Paxson.
Add to that, the comments from everyone who contributed to the
original RFC:
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 authors of the SCTP implementor's guide, I. Arias-
Rodriguez, K. Poon, A. Caro, and M. Tuexen.
Then add to these the efforts of all the subsequent seven SCTP
interoperability tests and those who commented on RFC 4460 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, and Ronnie Sellar. A special thanks to Mark Allman, who should actually be a co-author for his work on the max-burst, but managed to wiggle out due to a technicality. Also, we would like to acknowledge Lyndon Ong and Phil Conrad for their valuable input and many contributions. And finally, you have this document, and those who have commented upon that including Alfred Hoenes and Ronnie Sellars. My thanks cannot be adequately expressed to all of you who have participated in the coding, testing, and updating process of this document. All I can say is, Thank You! Randall Stewart - Editor
Appendix A. Explicit Congestion Notification
ECN [RFC3168] describes a proposed extension to IP that details a method to become aware of congestion outside of datagram loss. This is an optional feature that an implementation MAY choose to add to SCTP. This appendix details the minor differences implementers will need to be aware of if they choose to implement this feature. In general, [RFC3168] should be followed with the following exceptions. Negotiation: [RFC3168] details negotiation of ECN during the SYN and SYN-ACK stages of a TCP connection. The sender of the SYN sets 2 bits in the TCP flags, and the sender of the SYN-ACK sets only 1 bit. The reasoning behind this is to ensure that both sides are truly ECN capable. For SCTP, this is not necessary. To indicate that an endpoint is ECN capable, an endpoint SHOULD add to the INIT and or INIT ACK chunk the TLV reserved for ECN. This TLV contains no parameters, and thus 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Parameter Type = 32768 | Parameter Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ECN-Echo: [RFC3168] details a specific bit for a receiver to send back in its TCP acknowledgements to notify the sender of the Congestion Experienced (CE) bit having arrived from the network. For SCTP, this same indication is made by including the ECNE chunk. This chunk contains one data element, i.e., the lowest TSN associated with the IP datagram marked with the CE bit, and looks as follows: 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=12 | Flags=00000000| Chunk Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lowest TSN Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Note: The ECNE is considered a Control chunk.
CWR: [RFC3168] details a specific bit for a sender to send in the header of its next outbound TCP segment to indicate to its peer that it has reduced its congestion window. This is termed the CWR bit. For SCTP, the same indication is made by including the CWR chunk. This chunk contains one data element, i.e., the TSN number that was sent in the ECNE chunk. This element represents the lowest TSN number in the datagram that was originally marked with the CE bit. 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=13 | Flags=00000000| Chunk Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lowest TSN Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Note: The CWR is considered a Control chunk.Appendix B. CRC32c Checksum Calculation
We define a 'reflected value' as one that is the opposite of the normal bit order of the machine. The 32-bit CRC (Cyclic Redundancy Check) is calculated as described for CRC32c and uses the polynomial code 0x11EDC6F41 (Castagnoli93) or x^32+x^28+x^27+x^26+x^25 +x^23+x^22+x^20+x^19+x^18+ x^14+x^13+x^11+x^10+x^9+x^8+x^6+x^0. The CRC is computed using a procedure similar to ETHERNET CRC [ITU32], modified to reflect transport-level usage. CRC computation uses polynomial division. A message bit-string M is transformed to a polynomial, M(X), and the CRC is calculated from M(X) using polynomial arithmetic. When CRCs are used at the link layer, the polynomial is derived from on-the-wire bit ordering: the first bit 'on the wire' is the high- order coefficient. Since SCTP is a transport-level protocol, it cannot know the actual serial-media bit ordering. Moreover, different links in the path between SCTP endpoints may use different link-level bit orders. A convention must therefore be established for mapping SCTP transport messages to polynomials for purposes of CRC computation. The bit- ordering for mapping SCTP messages to polynomials is that bytes are taken most-significant first, but within each byte, bits are taken least-significant first. The first byte of the message provides the eight highest coefficients. Within each byte, the least-significant SCTP bit gives the most-significant polynomial coefficient within
that byte, and the most-significant SCTP bit is the 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-level byte values, using a consistent mapping. The SCTP transport-level CRC value should be calculated as follows: - CRC input data are 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 as coefficients of a polynomial M(x) of order 8N-1, with bit 0 of byte j being coefficient x^(8(N-j)-8), and bit 7 of byte j being coefficient x^(8(N-j)-1). - The CRC remainder register is initialized with all 1s and the CRC is computed with an algorithm that simultaneously multiplies by x^32 and divides by the CRC polynomial. - The polynomial is multiplied by x^32 and divided by G(x), the generator polynomial, 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 x^31 gives the value of bit 7 of SCTP byte 0, and the coefficient of x^24 gives the value of bit 0 of byte 0. The coefficient of x^7 gives bit 7 of byte 3, and the coefficient of x^0 gives bit 0 of byte 3. The resulting 4-byte transport- level sequence is the 32-bit SCTP checksum value. IMPLEMENTATION NOTE: Standards documents, textbooks, and vendor literature on CRCs often follow an alternative formulation, in which the register used to hold the remainder of the long-division algorithm is initialized to zero rather than all-1s, and instead the first 32 bits of the message are complemented. The long-division algorithm used in our formulation is specified such that the initial multiplication by 2^32 and the long-division are combined into one simultaneous operation. For such algorithms, and for messages longer than 64 bits, the two specifications are precisely equivalent. That equivalence is the intent of this document.
Implementors of SCTP are warned that both specifications are to be found in the literature, sometimes with no restriction on the long- division algorithm. The choice of formulation in this document is to permit non-SCTP usage, where the same CRC algorithm may be used to protect messages shorter than 64 bits. There may be a computational advantage in validating the association against the Verification Tag, prior to performing a checksum, as invalid tags will result in the same action as a bad checksum in most cases. The exceptions for this technique would be INIT and some SHUTDOWN-COMPLETE exchanges, as well as a stale COOKIE ECHO. These special-case exchanges must represent small packets and will minimize the effect of the checksum calculation.Appendix C. ICMP Handling
Whenever an ICMP message is received by an SCTP endpoint, the following procedures MUST be followed to ensure proper utilization of the information being provided by layer 3. ICMP1) An implementation MAY ignore all ICMPv4 messages where the type field is not set to "Destination Unreachable". ICMP2) An implementation MAY ignore all ICMPv6 messages where the type field is not "Destination Unreachable", "Parameter Problem",, or "Packet Too Big". ICMP3) An implementation MAY ignore any ICMPv4 messages where the code does not indicate "Protocol Unreachable" or "Fragmentation Needed". ICMP4) An implementation MAY ignore all ICMPv6 messages of type "Parameter Problem" if the code is not "Unrecognized Next Header Type Encountered". ICMP5) An implementation MUST use the payload of the ICMP message (v4 or v6) to locate the association that sent the message to which ICMP is responding. If the association cannot be found, an implementation SHOULD ignore the ICMP message. ICMP6) An implementation MUST validate that the Verification Tag contained in the ICMP 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 the chunk type is an INIT chunk and that the Initiate Tag matches the tag of the
peer, continue with ICMP7. If the ICMP message is too short
or the chunk type or the Initiate Tag does not match, silently
discard the packet.
ICMP7) If the ICMP message is either a v6 "Packet Too Big" or a v4
"Fragmentation Needed", an implementation MAY process this
information as defined for PATH MTU discovery.
ICMP8) If the ICMP code is an "Unrecognized Next Header Type
Encountered" or a "Protocol Unreachable", an implementation
MUST treat this message as an abort with the T bit set if it
does not contain an INIT chunk. If it does contain an INIT
chunk and the association is in the COOKIE-WAIT state, handle
the ICMP message like an ABORT.
ICMP9) If the ICMPv6 code is "Destination Unreachable", the
implementation MAY mark the destination into the unreachable
state or alternatively increment the path error counter.
Note that these procedures differ from [RFC1122] and from its
requirements for processing of port-unreachable messages and the
requirements that an implementation MUST abort associations in
response to a "protocol unreachable" message. Port-unreachable
messages are not processed, since an implementation will send an
ABORT, not a port unreachable. The stricter handling of the
"protocol unreachable" message is due to security concerns for hosts
that do NOT support SCTP.
The following non-normative sample code is taken from an open-source
CRC generator [WILLIAMS93], using the "mirroring" technique and
yielding a lookup table for SCTP CRC32c with 256 entries, each 32
bits wide. While neither especially slow nor especially fast, as
software table-lookup CRCs go, it has the advantage of working on
both big-endian and little-endian CPUs, using the same (host-order)
lookup tables, and using only the predefined ntohl() and htonl()
operations. The code is somewhat modified from [WILLIAMS93], to
ensure portability between big-endian and little-endian
architectures. (Note that if the byte endian-ness of the target
architecture is known to be little-endian, the final bit-reversal and
byte-reversal steps can be folded into a single operation.)
/*************************************************************/
/* Note Definition for Ross Williams table generator would */
/* be: TB_WIDTH=4, TB_POLLY=0x1EDC6F41, TB_REVER=TRUE */
/* For Mr. Williams direct calculation code use the settings */
/* cm_width=32, cm_poly=0x1EDC6F41, cm_init=0xFFFFFFFF, */
/* cm_refin=TRUE, cm_refot=TRUE, cm_xorort=0x00000000 */
/*************************************************************/
/* Example of the crc table file */
#ifndef __crc32cr_table_h__
#define __crc32cr_table_h__
#define CRC32C_POLY 0x1EDC6F41
#define CRC32C(c,d) (c=(c>>8)^crc_c[(c^(d))&0xFF])
unsigned long crc_c[256] =
{
0x00000000L, 0xF26B8303L, 0xE13B70F7L, 0x1350F3F4L,
0xC79A971FL, 0x35F1141CL, 0x26A1E7E8L, 0xD4CA64EBL,
0x8AD958CFL, 0x78B2DBCCL, 0x6BE22838L, 0x9989AB3BL,
0x4D43CFD0L, 0xBF284CD3L, 0xAC78BF27L, 0x5E133C24L,
0x105EC76FL, 0xE235446CL, 0xF165B798L, 0x030E349BL,
0xD7C45070L, 0x25AFD373L, 0x36FF2087L, 0xC494A384L,
0x9A879FA0L, 0x68EC1CA3L, 0x7BBCEF57L, 0x89D76C54L,
0x5D1D08BFL, 0xAF768BBCL, 0xBC267848L, 0x4E4DFB4BL,
0x20BD8EDEL, 0xD2D60DDDL, 0xC186FE29L, 0x33ED7D2AL,
0xE72719C1L, 0x154C9AC2L, 0x061C6936L, 0xF477EA35L,
0xAA64D611L, 0x580F5512L, 0x4B5FA6E6L, 0xB93425E5L,
0x6DFE410EL, 0x9F95C20DL, 0x8CC531F9L, 0x7EAEB2FAL,
0x30E349B1L, 0xC288CAB2L, 0xD1D83946L, 0x23B3BA45L,
0xF779DEAEL, 0x05125DADL, 0x1642AE59L, 0xE4292D5AL,
0xBA3A117EL, 0x4851927DL, 0x5B016189L, 0xA96AE28AL,
0x7DA08661L, 0x8FCB0562L, 0x9C9BF696L, 0x6EF07595L,
0x417B1DBCL, 0xB3109EBFL, 0xA0406D4BL, 0x522BEE48L,
0x86E18AA3L, 0x748A09A0L, 0x67DAFA54L, 0x95B17957L,
0xCBA24573L, 0x39C9C670L, 0x2A993584L, 0xD8F2B687L,
0x0C38D26CL, 0xFE53516FL, 0xED03A29BL, 0x1F682198L,
0x5125DAD3L, 0xA34E59D0L, 0xB01EAA24L, 0x42752927L,
0x96BF4DCCL, 0x64D4CECFL, 0x77843D3BL, 0x85EFBE38L,
0xDBFC821CL, 0x2997011FL, 0x3AC7F2EBL, 0xC8AC71E8L,
0x1C661503L, 0xEE0D9600L, 0xFD5D65F4L, 0x0F36E6F7L,
0x61C69362L, 0x93AD1061L, 0x80FDE395L, 0x72966096L,
0xA65C047DL, 0x5437877EL, 0x4767748AL, 0xB50CF789L,
0xEB1FCBADL, 0x197448AEL, 0x0A24BB5AL, 0xF84F3859L,
0x2C855CB2L, 0xDEEEDFB1L, 0xCDBE2C45L, 0x3FD5AF46L,
0x7198540DL, 0x83F3D70EL, 0x90A324FAL, 0x62C8A7F9L,
0xB602C312L, 0x44694011L, 0x5739B3E5L, 0xA55230E6L,
0xFB410CC2L, 0x092A8FC1L, 0x1A7A7C35L, 0xE811FF36L,
0x3CDB9BDDL, 0xCEB018DEL, 0xDDE0EB2AL, 0x2F8B6829L,
0x82F63B78L, 0x709DB87BL, 0x63CD4B8FL, 0x91A6C88CL,
0x456CAC67L, 0xB7072F64L, 0xA457DC90L, 0x563C5F93L,
0x082F63B7L, 0xFA44E0B4L, 0xE9141340L, 0x1B7F9043L,
0xCFB5F4A8L, 0x3DDE77ABL, 0x2E8E845FL, 0xDCE5075CL,
0x92A8FC17L, 0x60C37F14L, 0x73938CE0L, 0x81F80FE3L,
0x55326B08L, 0xA759E80BL, 0xB4091BFFL, 0x466298FCL,
0x1871A4D8L, 0xEA1A27DBL, 0xF94AD42FL, 0x0B21572CL,
0xDFEB33C7L, 0x2D80B0C4L, 0x3ED04330L, 0xCCBBC033L,
0xA24BB5A6L, 0x502036A5L, 0x4370C551L, 0xB11B4652L,
0x65D122B9L, 0x97BAA1BAL, 0x84EA524EL, 0x7681D14DL,
0x2892ED69L, 0xDAF96E6AL, 0xC9A99D9EL, 0x3BC21E9DL,
0xEF087A76L, 0x1D63F975L, 0x0E330A81L, 0xFC588982L,
0xB21572C9L, 0x407EF1CAL, 0x532E023EL, 0xA145813DL,
0x758FE5D6L, 0x87E466D5L, 0x94B49521L, 0x66DF1622L,
0x38CC2A06L, 0xCAA7A905L, 0xD9F75AF1L, 0x2B9CD9F2L,
0xFF56BD19L, 0x0D3D3E1AL, 0x1E6DCDEEL, 0xEC064EEDL,
0xC38D26C4L, 0x31E6A5C7L, 0x22B65633L, 0xD0DDD530L,
0x0417B1DBL, 0xF67C32D8L, 0xE52CC12CL, 0x1747422FL,
0x49547E0BL, 0xBB3FFD08L, 0xA86F0EFCL, 0x5A048DFFL,
0x8ECEE914L, 0x7CA56A17L, 0x6FF599E3L, 0x9D9E1AE0L,
0xD3D3E1ABL, 0x21B862A8L, 0x32E8915CL, 0xC083125FL,
0x144976B4L, 0xE622F5B7L, 0xF5720643L, 0x07198540L,
0x590AB964L, 0xAB613A67L, 0xB831C993L, 0x4A5A4A90L,
0x9E902E7BL, 0x6CFBAD78L, 0x7FAB5E8CL, 0x8DC0DD8FL,
0xE330A81AL, 0x115B2B19L, 0x020BD8EDL, 0xF0605BEEL,
0x24AA3F05L, 0xD6C1BC06L, 0xC5914FF2L, 0x37FACCF1L,
0x69E9F0D5L, 0x9B8273D6L, 0x88D28022L, 0x7AB90321L,
0xAE7367CAL, 0x5C18E4C9L, 0x4F48173DL, 0xBD23943EL,
0xF36E6F75L, 0x0105EC76L, 0x12551F82L, 0xE03E9C81L,
0x34F4F86AL, 0xC69F7B69L, 0xD5CF889DL, 0x27A40B9EL,
0x79B737BAL, 0x8BDCB4B9L, 0x988C474DL, 0x6AE7C44EL,
0xBE2DA0A5L, 0x4C4623A6L, 0x5F16D052L, 0xAD7D5351L,
};
#endif
/* Example of table build routine */
#include <stdio.h>
#include <stdlib.h>
#define OUTPUT_FILE "crc32cr.h"
#define CRC32C_POLY 0x1EDC6F41L
FILE *tf;
unsigned long
reflect_32 (unsigned long b)
{
int i;
unsigned long rw = 0L;
for (i = 0; i < 32; i++){
if (b & 1)
rw |= 1 << (31 - i);
b >>= 1;
}
return (rw);
}
unsigned long
build_crc_table (int index)
{
int i;
unsigned long rb;
rb = reflect_32 (index);
for (i = 0; i < 8; i++){
if (rb & 0x80000000L)
rb = (rb << 1) ^ CRC32C_POLY;
else
rb <<= 1;
}
return (reflect_32 (rb));
}
main ()
{
int i;
printf ("\nGenerating CRC-32c 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_table_h__\n");
fprintf (tf, "#define __crc32cr_table_h__\n\n");
fprintf (tf, "#define CRC32C_POLY 0x%08lX\n",
CRC32C_POLY);
fprintf (tf,
"#define CRC32C(c,d) (c=(c>>8)^crc_c[(c^(d))&0xFF])\n");
fprintf (tf, "\nunsigned long crc_c[256] =\n{\n");
for (i = 0; i < 256; i++){
fprintf (tf, "0x%08lXL, ", build_crc_table (i));
if ((i & 3) == 3)
fprintf (tf, "\n");
}
fprintf (tf, "};\n\n#endif\n");
if (fclose (tf) != 0)
printf ("Unable to close <%s>." OUTPUT_FILE);
else
printf ("\nThe CRC-32c table has been written to <%s>.\n",
OUTPUT_FILE);
}
/* Example of crc insertion */
#include "crc32cr.h"
unsigned long
generate_crc32c(unsigned char *buffer, unsigned int length)
{
unsigned int i;
unsigned long crc32 = ~0L;
unsigned long result;
unsigned char 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 is "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, then did an end-for-end
* bit-reversal.
* Note that a 32-bit bit-reversal is identical to four inplace
* 8-bit reversals followed by an end-for-end byteswap.
* In other words, the bytes of each bit 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 );
}
int
insert_crc32(unsigned char *buffer, unsigned int length)
{
SCTP_message *message;
unsigned long crc32;
message = (SCTP_message *) buffer;
message->common_header.checksum = 0L;
crc32 = generate_crc32c(buffer,length);
/* and insert it into the message */
message->common_header.checksum = htonl(crc32);
return 1;
}
int
validate_crc32(unsigned char *buffer, unsigned int length)
{
SCTP_message *message;
unsigned int i;
unsigned long original_crc32;
unsigned long crc32 = ~0L;
/* 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);
}
References
Normative References
[ITU32] "ITU-T Recommendation V.42, "Error-correcting procedures for DCEs using asynchronous-to-synchronous conversion".", ITU-T section 8.1.1.6.2. [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980. [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989. [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989. [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990. [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996. [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, August 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999. [RFC3873] Pastor, J. and M. Belinchon, "Stream Control Transmission Protocol (SCTP) Management Information Base (MIB)", RFC 3873, September 2004. [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005. [RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, March 2007.Informative References
[FALL96] Fall, K. and S. Floyd, "Simulation-based Comparisons of Tahoe, Reno, and SACK TCP", SIGCOMM'99 V. 26 N. 3 pp 5- 21, July 1996. [SAVAGE99] Savage, S., Cardwell, N., Wetherall, D., and T. Anderson, "TCP Congestion Control with a Misbehaving Receiver", ACM Computer Communications Review 29(5), October 1999. [ALLMAN99] Allman, M. and V. Paxson, "On Estimating End-to-End Network Path Properties", SIGCOMM'99 , 1999. [WILLIAMS93] Williams, R., "A PAINLESS GUIDE TO CRC ERROR DETECTION ALGORITHMS", Internet publication, http://www.geocities.com/SiliconValley/Pines/ 8659/crc.htm, August 1993. [RFC0813] Clark, D., "Window and Acknowledgement Strategy in TCP", RFC 813, July 1982. [RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security Considerations for IP Fragment Filtering", RFC 1858, October 1995. [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997. [RFC2196] Fraser, B., "Site Security Handbook", FYI 8, RFC 2196, September 1997. [RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management Protocol", RFC 2522, March 1999.
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000. [RFC3309] Stone, J., Stewart, R., and D. Otis, "Stream Control Transmission Protocol (SCTP) Checksum Change", RFC 3309, September 2002. [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001. [RFC4086] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005. [RFC4460] Stewart, R., Arias-Rodriguez, I., Poon, K., Caro, A., and M. Tuexen, "Stream Control Transmission Protocol (SCTP) Specification Errata and Issues", RFC 4460, April 2006. [RFC4895] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla, "Authenticated Chunks for Stream Control Transmission Protocol (SCTP)", RFC 4895, August 2007. Editor's Address Randall R. Stewart 4875 Forest Drive Suite 200 Columbia, SC 29206 US EMail: rrs@cisco.com
Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.