tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 4960


Stream Control Transmission Protocol

Part 7 of 7, p. 129 to 152
Prev RFC Part


prevText      Top      Up      ToC       Page 129 
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

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-ACK-SENT.

                 Note: No "CLOSED" state is illustrated since if a
                 association is "CLOSED" its TCB SHOULD be removed.

Top      Up      ToC       Page 130 
   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).

Top      Up      ToC       Page 131 
   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.

Top      Up      ToC       Page 132 
   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

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.

Top      Up      ToC       Page 133 
   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

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

   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.

Top      Up      ToC       Page 134 
   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

Top      Up      ToC       Page 135 
   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

   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

         discard    9/sctp  Discard  # IETF TSVWG
                                     # Randall Stewart <>
                                     # [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.

Top      Up      ToC       Page 136 
         ftp-data  20/sctp  FTP      # IETF TSVWG
                                     # Randall Stewart <>
                                     # [RFC4960]

         ftp       21/sctp  FTP      # IETF TSVWG
                                     # Randall Stewart <>
                                     # [RFC4960]

            File Transfer Protocol (FTP) data (20) and control ports

         ssh       22/sctp  SSH      # IETF TSVWG
                                     # Randall Stewart <>
                                     # [RFC4960]

            The Secure Shell (SSH) remote login service, which allows
            secure shell logins to a host.

         http      80/sctp  HTTP     # IETF TSVWG
                                     # Randall Stewart <>
                                     # [RFC4960]

            World Wide Web HTTP over SCTP.

         bgp      179/sctp  BGP      # IETF TSVWG
                                     # Randall Stewart <>
                                     # [RFC4960]

            Border Gateway Protocol over SCTP.

         https    443/sctp  HTTPS    # IETF TSVWG
                                     # Randall Stewart <>
                                     # [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

Top      Up      ToC       Page 137 
      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,

Top      Up      ToC       Page 138 
   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

Top      Up      ToC       Page 139 
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.


   [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      |


   [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.

Top      Up      ToC       Page 140 

   [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

Top      Up      ToC       Page 141 
   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

   -  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

   -  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.

Top      Up      ToC       Page 142 
   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

Top      Up      ToC       Page 143 
          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        */

Top      Up      ToC       Page 144 
   /* 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,

Top      Up      ToC       Page 145 
   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,


    /* 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);

Top      Up      ToC       Page 146 
         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;
          rb <<= 1;
     return (reflect_32 (rb));

   main ()
     int i;

     printf ("\nGenerating CRC-32c table file <%s>\n",
     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",
     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);

Top      Up      ToC       Page 147 
       printf ("\nThe CRC-32c table has been written to <%s>.\n",

   /* 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)  |
     return ( crc32 );

Top      Up      ToC       Page 148 
   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;

   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);

Top      Up      ToC       Page 149 

Normative References

   [ITU32]      "ITU-T Recommendation V.42, "Error-correcting procedures
                for DCEs using asynchronous-to-synchronous
                conversion".", ITU-T section

   [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.

Top      Up      ToC       Page 150 
   [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.

                ALGORITHMS", Internet publication,
                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.

Top      Up      ToC       Page 151 
   [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

   [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


Top      Up      ToC       Page 152 
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

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

   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