Stream Control Transmission Protocol: Errata and Issues in RFC 4960
RFC 8540

quot;,
         OUTPUT_FILE);
   }

   This text has been modified by multiple errata.  It includes
   modifications from Section 3.10.  It is in final form and is not
   further updated in this document.

   ---------
   Old text: (Appendix C)
   ---------

   /* 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,

Stewart, et al.               Informational                    [Page 84]
RFC 8540           SCTP: Errata and Issues in RFC 4960     February 2019

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

Stewart, et al.               Informational                    [Page 85]
RFC 8540           SCTP: Errata and Issues in RFC 4960     February 2019

   ---------
   New text: (Appendix B)
   ---------

   /* Example of crc insertion */

   #include "crc32cr.h"

   uint32_t
   generate_crc32c(unsigned char *buffer, unsigned int length)
   {
     unsigned int i;
     uint32_t crc32 = 0xffffffffUL;
     uint32_t result;
     uint8_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);
   }

   int

Stewart, et al.               Informational                    [Page 86]
RFC 8540           SCTP: Errata and Issues in RFC 4960     February 2019

   insert_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;
   }

   int
   validate_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>

   This text has been modified by multiple errata.  It includes
   modifications from Sections 3.5 and 3.10.  It is in final form and is
   not further updated in this document.

3.46.3.  Solution Description

   The code was changed to use platform-independent types.

3.47.  Clarification of Gap Ack Blocks in SACK Chunks

3.47.1.  Description of the Problem

   The Gap Ack Blocks in the SACK chunk are intended to be isolated.
   However, this is not mentioned with normative text.

   This issue was reported as part of an errata for [RFC4960] with
   Errata ID 5202.

Stewart, et al.               Informational                    [Page 87]
RFC 8540           SCTP: Errata and Issues in RFC 4960     February 2019

3.47.2.  Text Changes to the Document

   ---------
   Old text: (Section 3.3.4)
   ---------

   The SACK also contains zero or more Gap Ack Blocks.  Each Gap Ack
   Block acknowledges a subsequence of TSNs received following a break
   in the sequence of received TSNs.  By definition, all TSNs
   acknowledged by Gap Ack Blocks are greater than the value of the
   Cumulative TSN Ack.

   ---------
   New text: (Section 3.3.4)
   ---------

   The SACK also contains zero or more Gap Ack Blocks.  Each Gap Ack
   Block acknowledges a subsequence of TSNs received following a break
   in the sequence of received TSNs.  The Gap Ack Blocks SHOULD be
   isolated.  This means that the TSN just before each Gap Ack Block and
   the TSN just after each Gap Ack Block have not been received.  By
   definition, all TSNs acknowledged by Gap Ack Blocks are greater than
   the value of the Cumulative TSN Ack.

   This text is in final form and is not further updated in this
   document.

   ---------
   Old text: (Section 3.3.4)
   ---------

   Gap Ack Blocks:

      These fields contain the Gap Ack Blocks.  They are repeated for
      each Gap Ack Block up to the number of Gap Ack Blocks defined in
      the Number of Gap Ack Blocks field.  All DATA chunks with TSNs
      greater than or equal to (Cumulative TSN Ack + Gap Ack Block
      Start) and less than or equal to (Cumulative TSN Ack + Gap Ack
      Block End) of each Gap Ack Block are assumed to have been received
      correctly.

Stewart, et al.               Informational                    [Page 88]
RFC 8540           SCTP: Errata and Issues in RFC 4960     February 2019

   ---------
   New text: (Section 3.3.4)
   ---------

   Gap Ack Blocks:

      These fields contain the Gap Ack Blocks.  They are repeated for
      each Gap Ack Block up to the number of Gap Ack Blocks defined in
      the Number of Gap Ack Blocks field.  All DATA chunks with TSNs
      greater than or equal to (Cumulative TSN Ack + Gap Ack Block
      Start) and less than or equal to (Cumulative TSN Ack + Gap Ack
      Block End) of each Gap Ack Block are assumed to have been received
      correctly.  Gap Ack Blocks SHOULD be isolated.  This means that
      the DATA chunks with TSNs equal to (Cumulative TSN Ack + Gap Ack
      Block Start - 1) and (Cumulative TSN Ack + Gap Ack Block End + 1)
      have not been received.

   This text is in final form and is not further updated in this
   document.

3.47.3.  Solution Description

   Normative text describing the intended usage of Gap Ack Blocks has
   been added.

3.48.  Handling of SSN Wraparounds

3.48.1.  Description of the Problem

   The Stream Sequence Number (SSN) is used for preserving the ordering
   of user messages within each SCTP stream.  The SSN is limited to
   16 bits.  Therefore, multiple wraparounds of the SSN might happen
   within the current send window.  To allow the receiver to deliver
   ordered user messages in the correct sequence, the sender should
   limit the number of user messages per stream.

3.48.2.  Text Changes to the Document

   ---------
   Old text: (Section 6.1)
   ---------

   Note: The data sender SHOULD NOT use a TSN that is more than 2**31 -
   1 above the beginning TSN of the current send window.

Stewart, et al.               Informational                    [Page 89]
RFC 8540           SCTP: Errata and Issues in RFC 4960     February 2019

   ---------
   New text: (Section 6.1)
   ---------

   Note: The data sender SHOULD NOT use a TSN that is more than
   2**31 - 1 above the beginning TSN of the current send window.
   Note: For each stream, the data sender SHOULD NOT have more than
   2**16 - 1 ordered user messages in the current send window.

   This text is in final form and is not further updated in this
   document.

3.48.3.  Solution Description

   The data sender is required to limit the number of ordered user
   messages within the current send window.

3.49.  Update to RFC 2119 Boilerplate Text

3.49.1.  Description of the Problem

   The text to be used to refer to the terms ("key words") defined in
   [RFC2119] has been updated by [RFC8174].  This needs to be integrated
   into the base specification.

3.49.2.  Text Changes to the Document

   ---------
   Old text: (Section 2)
   ---------

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

   ---------
   New text: (Section 2)
   ---------

   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.

   This text is in final form and is not further updated in this
   document.

Stewart, et al.               Informational                    [Page 90]
RFC 8540           SCTP: Errata and Issues in RFC 4960     February 2019

3.49.3.  Solution Description

   The text has been updated to the text specified in [RFC8174].

3.50.  Removal of Text (Previously Missed in RFC 4960)

3.50.1.  Description of the Problem

   When integrating the changes to Section 7.2.4 of [RFC2960] as
   described in Section 2.8.2 of [RFC4460], some text was not removed
   and is therefore still in [RFC4960].

3.50.2.  Text Changes to the Document

   ---------
   Old text: (Section 7.2.4)
   ---------

   A straightforward implementation of the above keeps a counter for
   each TSN hole reported by a SACK.  The counter increments for each
   consecutive SACK reporting the TSN hole.  After reaching 3 and
   starting the Fast-Retransmit procedure, the counter resets to 0.
   Because cwnd in SCTP indirectly bounds the number of outstanding
   TSN's, the effect of TCP Fast Recovery is achieved automatically with
   no adjustment to the congestion control window size.

   ---------
   New text: (Section 7.2.4)
   ---------

   This text is in final form and is not further updated in this
   document.

3.50.3.  Solution Description

   The text has finally been removed.

4.  IANA Considerations

   Section 3.44 of this document suggests new text that would update the
   "Service Name and Transport Protocol Port Number Registry" for SCTP
   to be consistent with [RFC6335].

   IANA has confirmed that it is OK to make the proposed text change in
   an upcoming Standards Track document that will update [RFC4960].
   IANA is not asked to perform any other action, and this document does
   not request that IANA make a change to any registry.

Stewart, et al.               Informational                    [Page 91]
RFC 8540           SCTP: Errata and Issues in RFC 4960     February 2019

5.  Security Considerations

   This document does not add any security considerations to those given
   in [RFC4960].

6.  References

6.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC4960]  Stewart, R., Ed., "Stream Control Transmission Protocol",
              RFC 4960, DOI 10.17487/RFC4960, September 2007,
              <https://www.rfc-editor.org/info/rfc4960>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

6.2.  Informative References

   [RFC1122]  Braden, R., Ed., "Requirements for Internet Hosts -
              Communication Layers", STD 3, RFC 1122,
              DOI 10.17487/RFC1122, October 1989,
              <https://www.rfc-editor.org/info/rfc1122>.

   [RFC1858]  Ziemba, G., Reed, D., and P. Traina, "Security
              Considerations for IP Fragment Filtering", RFC 1858,
              DOI 10.17487/RFC1858, October 1995,
              <https://www.rfc-editor.org/info/rfc1858>.

   [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, DOI 10.17487/RFC2960, October 2000,
              <https://www.rfc-editor.org/info/rfc2960>.

   [RFC3168]  Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
              of Explicit Congestion Notification (ECN) to IP",
              RFC 3168, DOI 10.17487/RFC3168, September 2001,
              <https://www.rfc-editor.org/info/rfc3168>.

Stewart, et al.               Informational                    [Page 92]
RFC 8540           SCTP: Errata and Issues in RFC 4960     February 2019

   [RFC4460]  Stewart, R., Arias-Rodriguez, I., Poon, K., Caro, A., and
              M. Tuexen, "Stream Control Transmission Protocol (SCTP)
              Specification Errata and Issues", RFC 4460,
              DOI 10.17487/RFC4460, April 2006,
              <https://www.rfc-editor.org/info/rfc4460>.

   [RFC5681]  Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
              Control", RFC 5681, DOI 10.17487/RFC5681, September 2009,
              <https://www.rfc-editor.org/info/rfc5681>.

   [RFC6096]  Tuexen, M. and R. Stewart, "Stream Control Transmission
              Protocol (SCTP) Chunk Flags Registration", RFC 6096,
              DOI 10.17487/RFC6096, January 2011,
              <https://www.rfc-editor.org/info/rfc6096>.

   [RFC6298]  Paxson, V., Allman, M., Chu, J., and M. Sargent,
              "Computing TCP's Retransmission Timer", RFC 6298,
              DOI 10.17487/RFC6298, June 2011,
              <https://www.rfc-editor.org/info/rfc6298>.

   [RFC6335]  Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
              Cheshire, "Internet Assigned Numbers Authority (IANA)
              Procedures for the Management of the Service Name and
              Transport Protocol Port Number Registry", BCP 165,
              RFC 6335, DOI 10.17487/RFC6335, August 2011,
              <https://www.rfc-editor.org/info/rfc6335>.

   [RFC7053]  Tuexen, M., Ruengeler, I., and R. Stewart, "SACK-
              IMMEDIATELY Extension for the Stream Control Transmission
              Protocol", RFC 7053, DOI 10.17487/RFC7053, November 2013,
              <https://www.rfc-editor.org/info/rfc7053>.

   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
              Writing an IANA Considerations Section in RFCs", BCP 26,
              RFC 8126, DOI 10.17487/RFC8126, June 2017,
              <https://www.rfc-editor.org/info/rfc8126>.

   [RFC8311]  Black, D., "Relaxing Restrictions on Explicit Congestion
              Notification (ECN) Experimentation", RFC 8311,
              DOI 10.17487/RFC8311, January 2018,
              <https://www.rfc-editor.org/info/rfc8311>.

Stewart, et al.               Informational                    [Page 93]
RFC 8540           SCTP: Errata and Issues in RFC 4960     February 2019

Acknowledgements

   The authors wish to thank Pontus Andersson, Eric W. Biederman, Cedric
   Bonnet, Spencer Dawkins, Gorry Fairhurst, Benjamin Kaduk, Mirja
   Kuehlewind, Peter Lei, Gyula Marosi, Lionel Morand, Jeff Morriss,
   Karen E. E. Nielsen, Tom Petch, Kacheong Poon, Julien Pourtet, Irene
   Ruengeler, Michael Welzl, and Qiaobing Xie for their invaluable
   comments.

Authors' Addresses

   Randall R. Stewart
   Netflix, Inc.
   Chapin, SC  29036
   United States of America

   Email: randall@lakerest.net

   Michael Tuexen
   Muenster University of Applied Sciences
   Stegerwaldstrasse 39
   48565 Steinfurt
   Germany

   Email: tuexen@fh-muenster.de

   Maksim Proshin
   Ericsson
   Kistavaegen 25
   Stockholm  164 80
   Sweden

   Email: mproshin@tieto.mera.ru

Stewart, et al.               Informational                    [Page 94]