draft-ietf-tsvwg-rfc4960-errata-02.txt   draft-ietf-tsvwg-rfc4960-errata-03.txt 
Network Working Group R. Stewart Network Working Group R. Stewart
Internet-Draft Netflix, Inc. Internet-Draft Netflix, Inc.
Intended status: Informational M. Tuexen Intended status: Informational M. Tuexen
Expires: January 4, 2018 Muenster Univ. of Appl. Sciences Expires: May 3, 2018 Muenster Univ. of Appl. Sciences
M. Proshin M. Proshin
Ericsson Ericsson
July 3, 2017 October 30, 2017
RFC 4960 Errata and Issues RFC 4960 Errata and Issues
draft-ietf-tsvwg-rfc4960-errata-02.txt draft-ietf-tsvwg-rfc4960-errata-03.txt
Abstract Abstract
This document is a compilation of issues found since the publication This document is a compilation of issues found since the publication
of RFC4960 in September 2007 based on experience with implementing, of RFC4960 in September 2007 based on experience with implementing,
testing, and using SCTP along with the suggested fixes. This testing, and using SCTP along with the suggested fixes. This
document provides deltas to RFC4960 and is organized in a time based document provides deltas to RFC4960 and is organized in a time based
way. The issues are listed in the order they were brought up. way. The issues are listed in the order they were brought up.
Because some text is changed several times the last delta in the text Because some text is changed several times the last delta in the text
is the one which should be applied. In addition to the delta a is the one which should be applied. In addition to the delta a
skipping to change at page 1, line 34 skipping to change at page 1, line 34
provided. provided.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 4, 2018. This Internet-Draft will expire on May 3, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Corrections to RFC 4960 . . . . . . . . . . . . . . . . . . . 4 3. Corrections to RFC 4960 . . . . . . . . . . . . . . . . . . . 4
3.1. Path Error Counter Threshold Handling . . . . . . . . . . 4 3.1. Path Error Counter Threshold Handling . . . . . . . . . . 4
3.2. Upper Layer Protocol Shutdown Request Handling . . . . . 5 3.2. Upper Layer Protocol Shutdown Request Handling . . . . . 5
3.3. Registration of New Chunk Types . . . . . . . . . . . . . 5 3.3. Registration of New Chunk Types . . . . . . . . . . . . . 5
3.4. Variable Parameters for INIT Chunks . . . . . . . . . . . 6 3.4. Variable Parameters for INIT Chunks . . . . . . . . . . . 6
3.5. CRC32c Sample Code on 64-bit Platforms . . . . . . . . . 7 3.5. CRC32c Sample Code on 64-bit Platforms . . . . . . . . . 7
3.6. Endpoint Failure Detection . . . . . . . . . . . . . . . 8 3.6. Endpoint Failure Detection . . . . . . . . . . . . . . . 8
3.7. Data Transmission Rules . . . . . . . . . . . . . . . . . 9 3.7. Data Transmission Rules . . . . . . . . . . . . . . . . . 9
3.8. T1-Cookie Timer . . . . . . . . . . . . . . . . . . . . . 10 3.8. T1-Cookie Timer . . . . . . . . . . . . . . . . . . . . . 10
3.9. Miscellaneous Typos . . . . . . . . . . . . . . . . . . . 11 3.9. Miscellaneous Typos . . . . . . . . . . . . . . . . . . . 11
skipping to change at page 3, line 5 skipping to change at page 3, line 5
3.27. Refresh of cwnd and ssthresh after Idle Period . . . . . 41 3.27. Refresh of cwnd and ssthresh after Idle Period . . . . . 41
3.28. Window Updates After Receiver Window Opens Up . . . . . . 42 3.28. Window Updates After Receiver Window Opens Up . . . . . . 42
3.29. Path of DATA and Reply Chunks . . . . . . . . . . . . . . 43 3.29. Path of DATA and Reply Chunks . . . . . . . . . . . . . . 43
3.30. Outstanding Data, Flightsize and Data In Flight Key Terms 45 3.30. Outstanding Data, Flightsize and Data In Flight Key Terms 45
3.31. CWND Degradation due to Max.Burst . . . . . . . . . . . . 46 3.31. CWND Degradation due to Max.Burst . . . . . . . . . . . . 46
3.32. Reduction of RTO.Initial . . . . . . . . . . . . . . . . 47 3.32. Reduction of RTO.Initial . . . . . . . . . . . . . . . . 47
3.33. Ordering of Bundled SACK and ERROR Chunks . . . . . . . . 49 3.33. Ordering of Bundled SACK and ERROR Chunks . . . . . . . . 49
3.34. Undefined Parameter Returned by RECEIVE Primitive . . . . 49 3.34. Undefined Parameter Returned by RECEIVE Primitive . . . . 49
3.35. DSCP Changes . . . . . . . . . . . . . . . . . . . . . . 50 3.35. DSCP Changes . . . . . . . . . . . . . . . . . . . . . . 50
3.36. Inconsistent Handling of ICMPv4 and ICMPv6 Messages . . . 52 3.36. Inconsistent Handling of ICMPv4 and ICMPv6 Messages . . . 52
3.37. Handling of Soft Errors . . . . . . . . . . . . . . . . . 54 3.37. Handling of Soft Errors . . . . . . . . . . . . . . . . . 53
3.38. Honoring CWND . . . . . . . . . . . . . . . . . . . . . . 55 3.38. Honoring CWND . . . . . . . . . . . . . . . . . . . . . . 54
3.39. Zero Window Probing . . . . . . . . . . . . . . . . . . . 56 3.39. Zero Window Probing . . . . . . . . . . . . . . . . . . . 55
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 58 3.40. Updating References Regarding ECN . . . . . . . . . . . . 57
5. Security Considerations . . . . . . . . . . . . . . . . . . . 58 3.41. Host Name Address Parameter Deprecated . . . . . . . . . 59
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 58 3.42. Conflicting Text Regarding the Supported Address Types
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 58 Parameter . . . . . . . . . . . . . . . . . . . . . . . . 62
7.1. Normative References . . . . . . . . . . . . . . . . . . 58 3.43. Integration of RFC 6096 . . . . . . . . . . . . . . . . . 63
7.2. Informative References . . . . . . . . . . . . . . . . . 58 3.44. Integration of RFC 6335 . . . . . . . . . . . . . . . . . 65
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 59 3.45. Integration of RFC 7053 . . . . . . . . . . . . . . . . . 67
3.46. CRC32c Code Improvements . . . . . . . . . . . . . . . . 70
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 80
5. Security Considerations . . . . . . . . . . . . . . . . . . . 80
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 80
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 80
7.1. Normative References . . . . . . . . . . . . . . . . . . 80
7.2. Informative References . . . . . . . . . . . . . . . . . 81
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 82
1. Introduction 1. Introduction
This document contains a compilation of all defects found up until This document contains a compilation of all defects found up until
the publishing of this document for [RFC4960] specifying the Stream the publishing of this document for [RFC4960] specifying the Stream
Control Transmission Protocol (SCTP). These defects may be of an Control Transmission Protocol (SCTP). These defects may be of an
editorial or technical nature. This document may be thought of as a editorial or technical nature. This document may be thought of as a
companion document to be used in the implementation of SCTP to companion document to be used in the implementation of SCTP to
clarify errors in the original SCTP document. clarify errors in the original SCTP document.
skipping to change at page 15, line 22 skipping to change at page 15, line 22
--------- ---------
New text: (Appendix C) New text: (Appendix C)
--------- ---------
ICMP2) An implementation MAY ignore all ICMPv6 messages where the ICMP2) An implementation MAY ignore all ICMPv6 messages where the
type field is not "Destination Unreachable", "Parameter type field is not "Destination Unreachable", "Parameter
Problem", or "Packet Too Big". Problem", or "Packet Too Big".
--------- ---------
Old text: (Appendix C)
---------
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.
---------
New text: (Appendix C)
---------
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.
---------
Old text: (Section 5.4) Old text: (Section 5.4)
--------- ---------
2) For the receiver of the COOKIE ECHO, the only CONFIRMED address 2) For the receiver of the COOKIE ECHO, the only CONFIRMED address
is the one to which the INIT-ACK was sent. is the one to which the INIT-ACK was sent.
--------- ---------
New text: (Section 5.4) New text: (Section 5.4)
--------- ---------
skipping to change at page 39, line 21 skipping to change at page 39, line 21
--------- ---------
It is helpful for some firewalls if they can inspect just the first It is helpful for some firewalls if they can inspect just the first
fragment of a fragmented SCTP packet and unambiguously determine fragment of a fragmented SCTP packet and unambiguously determine
whether it corresponds to an INIT chunk (for further information, whether it corresponds to an INIT chunk (for further information,
please refer to [RFC1858]). Accordingly, we stress the requirements, please refer to [RFC1858]). Accordingly, we stress the requirements,
stated in Section 3.1, that (1) an INIT chunk MUST NOT be bundled stated in Section 3.1, that (1) an INIT chunk MUST NOT be bundled
with any other chunk in a packet, and (2) a packet containing an INIT with any other chunk in a packet, and (2) a packet containing an INIT
chunk MUST have a zero Verification Tag. Furthermore, we require chunk MUST have a zero Verification Tag. Furthermore, we require
that the receiver of an INIT chunk MUST enforce these rules by that the receiver of an INIT chunk MUST enforce these rules by
silently discarding an arriving packet with an INIT chunk that is silently discarding an arriving packet with an INIT chunk that is
bundled with other chunks or has a non-zero verification tag and bundled with other chunks or has a non-zero verification tag and
contains an INIT-chunk. contains an INIT-chunk.
--------- ---------
New text: (Section 11.3) New text: (Section 11.3)
--------- ---------
It is helpful for some firewalls if they can inspect just the first It is helpful for some firewalls if they can inspect just the first
fragment of a fragmented SCTP packet and unambiguously determine fragment of a fragmented SCTP packet and unambiguously determine
whether it corresponds to an INIT chunk (for further information, whether it corresponds to an INIT chunk (for further information,
skipping to change at page 44, line 42 skipping to change at page 44, line 42
--------- ---------
New text: (Section 6.4) New text: (Section 6.4)
--------- ---------
An endpoint SHOULD transmit reply chunks (e.g., INIT ACK, COOKIE ACK, An endpoint SHOULD transmit reply chunks (e.g., INIT ACK, COOKIE ACK,
HEARTBEAT ACK, etc.) in response to control chunks to the same HEARTBEAT ACK, etc.) in response to control chunks to the same
destination transport address from which it received the control destination transport address from which it received the control
chunk to which it is replying. chunk to which it is replying.
The selection of the destination transport address for packets containing The selection of the destination transport address for packets
SACK chunks is implementation dependent. However, an endpoint SHOULD NOT vary containing SACK chunks is implementation dependent. However, an endpoint
the destination transport address of a SACK when it receives DATA chunks SHOULD NOT vary the destination transport address of a SACK when it
from the same source address. receives DATA chunks from the same source address.
When acknowledging multiple DATA chunks received in packets When acknowledging multiple DATA chunks received in packets
from different source addresses in a single SACK, the SACK chunk MAY from different source addresses in a single SACK, the SACK chunk MAY
be transmitted to one of the destination transport addresses from be transmitted to one of the destination transport addresses from
which the DATA or control chunks being acknowledged were received. which the DATA or control chunks being acknowledged were received.
3.29.3. Solution Description 3.29.3. Solution Description
The SACK transmission policy is left implementation dependent but it The SACK transmission policy is left implementation dependent but it
is specified to not vary the destination address of a packet is specified to not vary the destination address of a packet
skipping to change at page 51, line 7 skipping to change at page 51, line 7
3.35.1. Description of the Problem 3.35.1. Description of the Problem
The upper layer can change the Differentiated Services Code Point The upper layer can change the Differentiated Services Code Point
(DSCP) used for packets being sent. A change of the DSCP can result (DSCP) used for packets being sent. A change of the DSCP can result
in packets hitting different queues on the path and therefore the in packets hitting different queues on the path and therefore the
congestion control should be initialized when the DSCP is changed by congestion control should be initialized when the DSCP is changed by
the upper layer. This is not described in [RFC4960]. the upper layer. This is not described in [RFC4960].
3.35.2. Text Changes to the Document 3.35.2. Text Changes to the Document
New text: (Section 7.2.5) ---------
New text: (Section 7.2.5)
---------
SCTP implementations MAY allow an application to configure the SCTP implementations MAY allow an application to configure the
Differentiated Services Code Point (DSCP) used for sending packets. Differentiated Services Code Point (DSCP) used for sending packets.
If a DSCP change might result in outgoing packets being queued in different If a DSCP change might result in outgoing packets being queued in
queues, the congestion control parameters for all affected destination different queues, the congestion control parameters for all affected
addresses MUST be reset to their initial values. destination addresses MUST be reset to their initial values.
Old text: (Section 10.1) ---------
Old text: (Section 10.1)
---------
M) Set Protocol Parameters M) Set Protocol Parameters
Format: SETPROTOCOLPARAMETERS(association id, Format: SETPROTOCOLPARAMETERS(association id,
[,destination transport address,] [,destination transport address,]
protocol parameter list) protocol parameter list)
-> result -> result
This primitive allows the local SCTP to customize the protocol This primitive allows the local SCTP to customize the protocol
parameters. parameters.
Mandatory attributes: Mandatory attributes:
o association id - local handle to the SCTP association. o association id - local handle to the SCTP association.
o protocol parameter list - the specific names and values of the o protocol parameter list - the specific names and values of the
protocol parameters (e.g., Association.Max.Retrans; see Section protocol parameters (e.g., Association.Max.Retrans; see Section
15) that the SCTP user wishes to customize. 15) that the SCTP user wishes to customize.
Old text: (Section 10.1) ---------
Old text: (Section 10.1)
---------
M) Set Protocol Parameters M) Set Protocol Parameters
Format: SETPROTOCOLPARAMETERS(association id, Format: SETPROTOCOLPARAMETERS(association id,
[,destination transport address,] [,destination transport address,]
protocol parameter list) protocol parameter list)
-> result -> result
This primitive allows the local SCTP to customize the protocol This primitive allows the local SCTP to customize the protocol
parameters. parameters.
Mandatory attributes: Mandatory attributes:
o association id - local handle to the SCTP association. o association id - local handle to the SCTP association.
o protocol parameter list - the specific names and values of the o protocol parameter list - the specific names and values of the
protocol parameters (e.g., Association.Max.Retrans; see Section protocol parameters (e.g., Association.Max.Retrans; see Section
15, or other parameters like the DSCP) that the SCTP user wishes 15, or other parameters like the DSCP) that the SCTP user wishes
to customize. to customize.
3.35.3. Solution Description 3.35.3. Solution Description
Text describing the required action on DSCP changes has been added. Text describing the required action on DSCP changes has been added.
3.36. Inconsistent Handling of ICMPv4 and ICMPv6 Messages 3.36. Inconsistent Handling of ICMPv4 and ICMPv6 Messages
3.36.1. Description of the Problem 3.36.1. Description of the Problem
Appendix C of [RFC4960] describes the handling of ICMPv4 and ICMPv6 Appendix C of [RFC4960] describes the handling of ICMPv4 and ICMPv6
skipping to change at page 52, line 28 skipping to change at page 53, line 4
3.36. Inconsistent Handling of ICMPv4 and ICMPv6 Messages 3.36. Inconsistent Handling of ICMPv4 and ICMPv6 Messages
3.36.1. Description of the Problem 3.36.1. Description of the Problem
Appendix C of [RFC4960] describes the handling of ICMPv4 and ICMPv6 Appendix C of [RFC4960] describes the handling of ICMPv4 and ICMPv6
messages. The text explicitly describes the handling of ICMPv6 messages. The text explicitly describes the handling of ICMPv6
packets indicating reachability problems, but does not do the same packets indicating reachability problems, but does not do the same
for the corresponding ICMPv4 packets. for the corresponding ICMPv4 packets.
3.36.2. Text Changes to the Document 3.36.2. Text Changes to the Document
--------- ---------
Old text: (Appendix C) Old text: (Appendix C)
--------- ---------
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 ICMP3) An implementation MAY ignore any ICMPv4 messages where the
code does not indicate "Protocol Unreachable" or code does not indicate "Protocol Unreachable" or
"Fragmentation Needed". "Fragmentation Needed".
ICMP4) An implementation MAY ignore all ICMPv6 messages of type ---------
"Parameter Problem" if the code is not "Unrecognized Next New text:
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 ICMP3) An implementation SHOULD ignore any ICMPv4 messages where the
"Fragmentation Needed", an implementation MAY process this code indicates "Port Unreachable".
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 Old text: (Appendix C)
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 ICMP9) If the ICMPv6 code is "Destination Unreachable", the
implementation MAY mark the destination into the unreachable implementation MAY mark the destination into the unreachable
state or alternatively increment the path error counter. state or alternatively increment the path error counter.
--------- ---------
New text: (Appendix C) New text:
--------- ---------
ICMP1) An implementation MAY ignore all ICMPv4 messages where the ICMP9) If the ICMP type is "Destination Unreachable", 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 all ICMPv6 messages of type
"Parameter Problem" if the code is not "Unrecognized Next
Header Type Encountered".
ICMP4) 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.
ICMP5) 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.
ICMP6) 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.
ICMP7) 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.
ICMP8) If the ICMP code is "Destination Unreachable", the
implementation MAY mark the destination into the unreachable implementation MAY mark the destination into the unreachable
state or alternatively increment the path error counter. state or alternatively increment the path error counter.
3.36.3. Solution Description 3.36.3. Solution Description
The text has been changed to not limit the processing of ICMPv4 The text has been changed to not limit the processing of ICMPv4
packets with type "Destination Unreachable" by removing the third packets with type "Destination Unreachable" by rewording the third
rule. Furthermore, remove in the ninth rule the limitation to rule. Furthermore, remove in the ninth rule the limitation to
ICMPv6. ICMPv6.
3.37. Handling of Soft Errors 3.37. Handling of Soft Errors
3.37.1. Description of the Problem 3.37.1. Description of the Problem
[RFC1122] defines the handling of soft errors and hard errors for [RFC1122] defines the handling of soft errors and hard errors for
TCP. Appendix C of [RFC4960] only deals with hard errors. TCP. Appendix C of [RFC4960] only deals with hard errors.
3.37.2. Text Changes to the Document 3.37.2. Text Changes to the Document
Old text: (Appendix C)
ICMP8) If the ICMP code is "Destination Unreachable", the ---------
implementation MAY mark the destination into the unreachable Old text: (Appendix C)
state or alternatively increment the path error counter. ---------
New text: (Appendix C) ICMP8) If the ICMP type is "Destination Unreachable", the
implementation MAY mark the destination into the unreachable
state or alternatively increment the path error counter.
ICMP8) If the ICMP code is "Destination Unreachable", the ---------
implementation MAY mark the destination into the unreachable New text: (Appendix C)
state or alternatively increment the path error counter. ---------
SCTP MAY provide information to the upper layer indicating the reception
of ICMP messages when reporting a network status change. ICMP8) If the ICMP type is "Destination Unreachable", the
implementation MAY mark the destination into the unreachable
state or alternatively increment the path error counter.
SCTP MAY provide information to the upper layer indicating
the reception of ICMP messages when reporting a network status
change.
3.37.3. Solution Description 3.37.3. Solution Description
Text has been added allowing the SCTP to notify the application in Text has been added allowing the SCTP to notify the application in
case of soft errors. case of soft errors.
3.38. Honoring CWND 3.38. Honoring CWND
3.38.1. Description of the Problem 3.38.1. Description of the Problem
When using the slow start algorithm, SCTP increases the congestion When using the slow start algorithm, SCTP increases the congestion
window only when it is being fully utilized. Since SCTP uses DATA window only when it is being fully utilized. Since SCTP uses DATA
chunks and does not use the congestion window to fragment user chunks and does not use the congestion window to fragment user
messages, this requires that some overbooking of the congestion messages, this requires that some overbooking of the congestion
window is allowed. window is allowed.
3.38.2. Text Changes to the Document 3.38.2. Text Changes to the Document
Old text: (Section 6.1) ---------
Old text: (Section 6.1)
---------
B) At any given time, the sender MUST NOT transmit new data to a B) At any given time, the sender MUST NOT transmit new data to a
given transport address if it has cwnd or more bytes of data given transport address if it has cwnd or more bytes of data
outstanding to that transport address. outstanding to that transport address.
New text: (Section 6.1) ---------
New text: (Section 6.1)
---------
B) At any given time, the sender MUST NOT transmit new data to a B) At any given time, the sender MUST NOT transmit new data to a
given transport address if it has cwnd + (PMTU - 1) or more bytes of data given transport address if it has cwnd + (PMTU - 1) or more bytes
outstanding to that transport address. If data is available the of data outstanding to that transport address. If data is
sender SHOULD exceed cwnd by up to (PMTU-1) bytes on a new data available the sender SHOULD exceed cwnd by up to (PMTU-1) bytes on
transmission if the flightsize does not currently reach cwnd. a new data transmission if the flightsize does not currently reach
The breach of cwnd MUST constitute one packet only. cwnd. The breach of cwnd MUST constitute one packet only.
Old text: (Section 7.2.1) ---------
Old text: (Section 7.2.1)
---------
o Whenever cwnd is greater than zero, the endpoint is allowed to o Whenever cwnd is greater than zero, the endpoint is allowed to
have cwnd bytes of data outstanding on that transport address. have cwnd bytes of data outstanding on that transport address.
New text: (Section 7.2.1) ---------
o Whenever cwnd is greater than zero, the endpoint is allowed to New text: (Section 7.2.1)
have cwnd bytes of data outstanding on that transport address. ---------
A limited overbooking as described in B) of Section 6.1 should o Whenever cwnd is greater than zero, the endpoint is allowed to
be supported. have cwnd bytes of data outstanding on that transport address.
A limited overbooking as described in B) of Section 6.1 should
be supported.
3.38.3. Solution Description 3.38.3. Solution Description
Text was added that to clarify how the CWND limit should be handled. Text was added that to clarify how the CWND limit should be handled.
3.39. Zero Window Probing 3.39. Zero Window Probing
3.39.1. Description of the Problem 3.39.1. Description of the Problem
The text describing zero window probing was not clearly handling the The text describing zero window probing was not clearly handling the
skipping to change at page 58, line 9 skipping to change at page 57, line 5
When the receiver has no buffer space, this probe is When the receiver has no buffer space, this probe is
called a zero window probe. Note that a zero window probe SHOULD called a zero window probe. Note that a zero window probe SHOULD
only be sent when all outstanding DATA chunks have been only be sent when all outstanding DATA chunks have been
cumulatively acknowledged and no DATA chunks are in flight. Zero cumulatively acknowledged and no DATA chunks are in flight. Zero
window probing MUST be supported. window probing MUST be supported.
3.39.3. Solution Description 3.39.3. Solution Description
The terminology is used in a cleaner way. The terminology is used in a cleaner way.
3.40. Updating References Regarding ECN
3.40.1. Description of the Problem
[RFC4960] refers for ECN only to [RFC3168], which will be updated by
[I-D.ietf-tsvwg-ecn-experimentation]. This needs to be reflected
when referring to ECN.
3.40.2. Text Changes to the Document
---------
Old text: (Appendix A)
---------
ECN [RFC3168] describes a proposed extension to IP that details a
method to become aware of congestion outside of datagram loss.
---------
New text: (Appendix A)
---------
ECN as specified in [RFC3168] updated by
[I-D.ietf-tsvwg-ecn-experimentation] describes a proposed extension
to IP that details a method to become aware of congestion outside
of datagram loss.
---------
Old text: (Appendix A)
---------
In general, [RFC3168] should be followed with the following
exceptions.
---------
New text: (Appendix A)
---------
In general, [RFC3168] updated by [I-D.ietf-tsvwg-ecn-experimentation]
should be followed with the following exceptions.
---------
Old text: (Appendix A)
---------
[RFC3168] details negotiation of ECN during the SYN and SYN-ACK
stages of a TCP connection.
---------
New text: (Appendix A)
---------
[RFC3168] updated by [I-D.ietf-tsvwg-ecn-experimentation] details
negotiation of ECN during the SYN and SYN-ACK stages of a TCP
connection.
---------
Old text: (Appendix A)
---------
[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.
---------
New text: (Appendix A)
---------
[RFC3168] updated by [I-D.ietf-tsvwg-ecn-experimentation]
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.
---------
Old text: (Appendix A)
---------
[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.
---------
New text: (Appendix A)
---------
[RFC3168] updated by [I-D.ietf-tsvwg-ecn-experimentation]
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.
3.40.3. Solution Description
References to [I-D.ietf-tsvwg-ecn-experimentation] have been added.
3.41. Host Name Address Parameter Deprecated
3.41.1. Description of the Problem
[RFC4960] defines three types of address parameters to be used with
INIT and INIT ACK chunks:
1. IPv4 Address parameters.
2. IPv6 Address parameters.
3. Host Name Address parameters.
The first two are supported by the SCTP kernel implementations of
FreeBSD, Linux and Solaris, but the third one is not. In addition,
the first two where successfully tested in all nine interoperability
tests for SCTP, but the third one has never been successfully tested.
Therefore, the Host Name Address parameter should be deprecated.
3.41.2. Text Changes to the Document
---------
Old text: (Section 3.3.2)
---------
Note 3: An INIT chunk MUST NOT contain more than one Host Name
Address parameter. Moreover, the sender of the INIT MUST NOT combine
any other address types with the Host Name Address in the INIT. The
receiver of INIT MUST ignore any other address types if the Host Name
Address parameter is present in the received INIT chunk.
---------
New text: (Section 3.3.2)
---------
Note 3: An INIT chunk MUST NOT contain the Host Name Address
parameter. The receiver of an INIT chunk containing an Host Name
Address parameter MUST send an ABORT and MAY include an Error Cause
indicating an Unresolvable Address.
---------
Old text: (Section 3.3.2.1)
---------
The sender of INIT uses this parameter to pass its Host Name (in
place of its IP addresses) to its peer. The peer is responsible for
resolving the name. Using this parameter might make it more likely
for the association to work across a NAT box.
---------
New text: (Section 3.3.2.1)
---------
The sender of an INIT chunk MUST NOT include this parameter. The
usage of the Host Name Address parameter is deprecated.
---------
Old text: (Section 3.3.2.1)
---------
Address Type: 16 bits (unsigned integer)
This is filled with the type value of the corresponding address
TLV (e.g., IPv4 = 5, IPv6 = 6, Host name = 11).
---------
New text: (Section 3.3.2.1)
---------
Address Type: 16 bits (unsigned integer)
This is filled with the type value of the corresponding address
TLV (e.g., IPv4 = 5, IPv6 = 6). The value indicating the Host
Name Address parameter (Host name = 11) MUST NOT be used.
---------
Old text: (Section 3.3.3)
---------
Note 3: The INIT ACK chunks MUST NOT contain more than one Host Name
Address parameter. Moreover, the sender of the INIT ACK MUST NOT
combine any other address types with the Host Name Address in the
INIT ACK. The receiver of the INIT ACK MUST ignore any other address
types if the Host Name Address parameter is present.
---------
New text: (Section 3.3.3)
---------
Note 3: An INIT ACK chunk MUST NOT contain the Host Name Address
parameter. The receiver of INIT ACK chunks containing an Host Name
Address parameter MUST send an ABORT and MAY include an Error Cause
indicating an Unresolvable Address.
---------
Old text: (Section 5.1.2)
---------
B) If there is a Host Name parameter present in the received INIT or
INIT ACK chunk, the endpoint shall resolve that host name to a
list of IP address(es) and derive the transport address(es) of
this peer by combining the resolved IP address(es) with the SCTP
source port.
The endpoint MUST ignore any other IP Address parameters if they
are also present in the received INIT or INIT ACK chunk.
The time at which the receiver of an INIT resolves the host name
has potential security implications to SCTP. If the receiver of
an INIT resolves the host name upon the reception of the chunk,
and the mechanism the receiver uses to resolve the host name
involves potential long delay (e.g., DNS query), the receiver may
open itself up to resource attacks for the period of time while it
is waiting for the name resolution results before it can build the
State Cookie and release local resources.
Therefore, in cases where the name translation involves potential
long delay, the receiver of the INIT MUST postpone the name
resolution till the reception of the COOKIE ECHO chunk from the
peer. In such a case, the receiver of the INIT SHOULD build the
State Cookie using the received Host Name (instead of destination
transport addresses) and send the INIT ACK to the source IP
address from which the INIT was received.
The receiver of an INIT ACK shall always immediately attempt to
resolve the name upon the reception of the chunk.
The receiver of the INIT or INIT ACK MUST NOT send user data
(piggy-backed or stand-alone) to its peer until the host name is
successfully resolved.
If the name resolution is not successful, the endpoint MUST
immediately send an ABORT with "Unresolvable Address" error cause
to its peer. The ABORT shall be sent to the source IP address
from which the last peer packet was received.
---------
New text: (Section 5.1.2)
---------
B) If there is a Host Name parameter present in the received INIT or
INIT ACK chunk, the endpoint MUST immediately send an ABORT and
MAY include an Error Cause indicating an Unresolvable Address to
its peer. The ABORT shall be sent to the source IP address
from which the last peer packet was received.
---------
Old text: (Section 11.2.4.1)
---------
The use of the host name feature in the INIT chunk could be used to
flood a target DNS server. A large backlog of DNS queries, resolving
the host name received in the INIT chunk to IP addresses, could be
accomplished by sending INITs to multiple hosts in a given domain.
In addition, an attacker could use the host name feature in an
indirect attack on a third party by sending large numbers of INITs to
random hosts containing the host name of the target. In addition to
the strain on DNS resources, this could also result in large numbers
of INIT ACKs being sent to the target. One method to protect against
this type of attack is to verify that the IP addresses received from
DNS include the source IP address of the original INIT. If the list
of IP addresses received from DNS does not include the source IP
address of the INIT, the endpoint MAY silently discard the INIT.
This last option will not protect against the attack against the DNS.
---------
New text: (Section 11.2.4.1)
---------
The support of the Host Name Address parameter has been removed from
the protocol. Endpoints receiving INIT or INIT ACK chunks containing
the Host Name Address parameter MUST send an ABORT chunk in response
an MAY include an Error Cause indicating an Unresolvable Address.
3.41.3. Solution Description
The usage of the Host Name Address parameter has been deprecated.
3.42. Conflicting Text Regarding the Supported Address Types Parameter
3.42.1. Description of the Problem
When receiving an SCTP packet containing an INIT chunk sent from an
address for which the corresponding address type is not listed in the
Supported Address Types, there is conflicting text in Section 5.1.2
of [RFC4960]. It is stated that the association MUST be aborted and
also that the association SHOULD be established and there SHOULD NOT
be any error indication.
3.42.2. Text Changes to the Document
---------
Old text: (Section 5.1.2)
---------
The sender of INIT may include a 'Supported Address Types' parameter
in the INIT to indicate what types of address are acceptable. When
this parameter is present, the receiver of INIT (initiate) MUST
either use one of the address types indicated in the Supported
Address Types parameter when responding to the INIT, or abort the
association with an "Unresolvable Address" error cause if it is
unwilling or incapable of using any of the address types indicated by
its peer.
---------
New text: (Section 5.1.2)
---------
The sender of INIT may include a 'Supported Address Types' parameter
in the INIT to indicate what types of address are acceptable.
3.42.3. Solution Description
The conflicting text has been removed.
3.43. Integration of RFC 6096
3.43.1. Description of the Problem
[RFC6096] updates [RFC4960] by adding a Chunk Flags Registry. This
should be integrated into the base specification.
3.43.2. Text Changes to the Document
---------
Old text: (Section 14.1)
---------
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.
---------
New text: (Section 14.1)
---------
14.1. IETF-Defined Chunk Extension
The assignment of new chunk type codes is done through an IETF Review
action, as defined in [RFC5226]. Documentation of a new chunk 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 of
[RFC4960];
c) A detailed definition and description of intended use of each
field within the chunk, including the chunk flags if any.
Defined chunk flags will be used as initial entries in the chunk
flags table for the new chunk type;
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.
For each new chunk type, IANA creates a registration table for the
chunk flags of that type. The procedure for registering particular
chunk flags is described in the following Section 14.2.
---------
New text: (Section 14.2)
---------
14.2. New IETF Chunk Flags Registration
The assignment of new chunk flags is done through an RFC required
action, as defined in [RFC5226]. Documentation of the chunk flags
MUST contain the following information:
a) A name for the new chunk flag;
b) A detailed procedural description of the use of the new chunk
flag within the operation of the protocol. It MUST be considered
that implementations not supporting the flag will send '0' on
transmit and just ignore it on receipt.
IANA selects a chunk flags value. This must be one of 0x01, 0x02,
0x04, 0x08, 0x10, 0x20, 0x40, or 0x80, which MUST be unique within
the chunk flag values for the specific chunk type.
Please note that Sections 14.2, 14.3, 14.4, and 14.5 need to be
renumbered.
3.43.3. Solution Description
[RFC6096] was integrated.
3.44. Integration of RFC 6335
3.44.1. Description of the Problem
[RFC6335] updates [RFC4960] by updating Procedures for the Port
Numbers Registry. This should be integrated into the base
specification. While there, update the reference to the RFC giving
guidelines for writing IANA sections to [RFC8126].
3.44.2. Text Changes to the Document
---------
Old text: (Section 14.5)
---------
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.
---------
New text: (Section 14.5)
---------
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 [RFC8126]. The details of this process are
defined in [RFC6335].
3.44.3. Solution Description
[RFC6335] was integrated and the reference was updated to [RFC8126].
3.45. Integration of RFC 7053
3.45.1. Description of the Problem
[RFC7053] updates [RFC4960] by adding the I bit to the DATA chunk.
This should be integrated into the base specification.
3.45.2. Text Changes to the Document
---------
Old text: (Section 3.3.1)
---------
The following format MUST be used for the DATA chunk:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0 | Reserved|U|B|E| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TSN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream Identifier S | Stream Sequence Number n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Protocol Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ User Data (seq n of Stream S) /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved: 5 bits
Should be set to all '0's and ignored by the receiver.
---------
New text: (Section 3.3.1)
---------
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0 | Res |I|U|B|E| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TSN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream Identifier S | Stream Sequence Number n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Protocol Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ User Data (seq n of Stream S) /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Res: 4 bits
Should be set to all '0's and ignored by the receiver.
I bit: 1 bit
The (I)mmediate Bit MAY be set by the sender, whenever the sender of
a DATA chunk can benefit from the corresponding SACK chunk being sent
back without delay. See [RFC7053] for a discussion about
---------
New text: (Append to Section 6.1)
---------
Whenever the sender of a DATA chunk can benefit from the
corresponding SACK chunk being sent back without delay, the sender
MAY set the I bit in the DATA chunk header. Please note that why the
sender has set the I bit is irrelevant to the receiver.
Reasons for setting the I bit include, but are not limited to (see
Section 4 of [RFC7053] for the benefits):
o The application requests to set the I bit of the last DATA chunk
of a user message when providing the user message to the SCTP
implementation (see Section 7).
o The sender is in the SHUTDOWN-PENDING state.
o The sending of a DATA chunk fills the congestion or receiver
window.
---------
Old text: (Section 6.2)
---------
Note: The SHUTDOWN chunk does not contain Gap Ack Block fields.
Therefore, the endpoint should use a SACK instead of the SHUTDOWN
chunk to acknowledge DATA chunks received out of order.
---------
New text: (Section 6.2)
---------
Note: The SHUTDOWN chunk does not contain Gap Ack Block fields.
Therefore, the endpoint should use a SACK instead of the SHUTDOWN
chunk to acknowledge DATA chunks received out of order.
Upon receipt of an SCTP packet containing a DATA chunk with the I bit
set, the receiver SHOULD NOT delay the sending of the corresponding
SACK chunk, i.e., the receiver SHOULD immediately respond with the
corresponding SACK chunk.
---------
Old text: (Section 10.1)
---------
E) Send
Format: SEND(association id, buffer address, byte count [,context]
[,stream id] [,life time] [,destination transport address]
[,unordered flag] [,no-bundle flag] [,payload protocol-id] )
-> result
---------
New text: (Section 10.1)
---------
E) Send
Format: SEND(association id, buffer address, byte count [,context]
[,stream id] [,life time] [,destination transport address]
[,unordered flag] [,no-bundle flag] [,payload protocol-id]
[,sack immediately] )
-> result
---------
New text: (Append optional parameter in Subsection E of Section 10.1)
---------
o sack immediately - set the I bit on the last DATA chunk used for
sending buffer.
Please note that the change in Section 6.2 is only about adding a
paragraph.
3.45.3. Solution Description
[RFC7053] was integrated.
3.46. CRC32c Code Improvements
3.46.1. Description of the Problem
The code given for the CRC32c computations uses types like long which
may have different length on different operating systems or
processors. Therefore the code is changed to use specific types like
uint32_t.
While there, fix also some syntax errors.
3.46.2. Text Changes to the Document
---------
Old text: (Appendix B)
---------
/* 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
---------
New text: (Appendix B)
---------
/* Example of the crc table file */
#ifndef __crc32cr_h__
#define __crc32cr_h__
#define CRC32C_POLY 0x1EDC6F41UL
#define CRC32C(c,d) (c=(c>>8)^crc_c[(c^(d))&0xFF])
uint32_t crc_c[256] =
{
0x00000000UL, 0xF26B8303UL, 0xE13B70F7UL, 0x1350F3F4UL,
0xC79A971FUL, 0x35F1141CUL, 0x26A1E7E8UL, 0xD4CA64EBUL,
0x8AD958CFUL, 0x78B2DBCCUL, 0x6BE22838UL, 0x9989AB3BUL,
0x4D43CFD0UL, 0xBF284CD3UL, 0xAC78BF27UL, 0x5E133C24UL,
0x105EC76FUL, 0xE235446CUL, 0xF165B798UL, 0x030E349BUL,
0xD7C45070UL, 0x25AFD373UL, 0x36FF2087UL, 0xC494A384UL,
0x9A879FA0UL, 0x68EC1CA3UL, 0x7BBCEF57UL, 0x89D76C54UL,
0x5D1D08BFUL, 0xAF768BBCUL, 0xBC267848UL, 0x4E4DFB4BUL,
0x20BD8EDEUL, 0xD2D60DDDUL, 0xC186FE29UL, 0x33ED7D2AUL,
0xE72719C1UL, 0x154C9AC2UL, 0x061C6936UL, 0xF477EA35UL,
0xAA64D611UL, 0x580F5512UL, 0x4B5FA6E6UL, 0xB93425E5UL,
0x6DFE410EUL, 0x9F95C20DUL, 0x8CC531F9UL, 0x7EAEB2FAUL,
0x30E349B1UL, 0xC288CAB2UL, 0xD1D83946UL, 0x23B3BA45UL,
0xF779DEAEUL, 0x05125DADUL, 0x1642AE59UL, 0xE4292D5AUL,
0xBA3A117EUL, 0x4851927DUL, 0x5B016189UL, 0xA96AE28AUL,
0x7DA08661UL, 0x8FCB0562UL, 0x9C9BF696UL, 0x6EF07595UL,
0x417B1DBCUL, 0xB3109EBFUL, 0xA0406D4BUL, 0x522BEE48UL,
0x86E18AA3UL, 0x748A09A0UL, 0x67DAFA54UL, 0x95B17957UL,
0xCBA24573UL, 0x39C9C670UL, 0x2A993584UL, 0xD8F2B687UL,
0x0C38D26CUL, 0xFE53516FUL, 0xED03A29BUL, 0x1F682198UL,
0x5125DAD3UL, 0xA34E59D0UL, 0xB01EAA24UL, 0x42752927UL,
0x96BF4DCCUL, 0x64D4CECFUL, 0x77843D3BUL, 0x85EFBE38UL,
0xDBFC821CUL, 0x2997011FUL, 0x3AC7F2EBUL, 0xC8AC71E8UL,
0x1C661503UL, 0xEE0D9600UL, 0xFD5D65F4UL, 0x0F36E6F7UL,
0x61C69362UL, 0x93AD1061UL, 0x80FDE395UL, 0x72966096UL,
0xA65C047DUL, 0x5437877EUL, 0x4767748AUL, 0xB50CF789UL,
0xEB1FCBADUL, 0x197448AEUL, 0x0A24BB5AUL, 0xF84F3859UL,
0x2C855CB2UL, 0xDEEEDFB1UL, 0xCDBE2C45UL, 0x3FD5AF46UL,
0x7198540DUL, 0x83F3D70EUL, 0x90A324FAUL, 0x62C8A7F9UL,
0xB602C312UL, 0x44694011UL, 0x5739B3E5UL, 0xA55230E6UL,
0xFB410CC2UL, 0x092A8FC1UL, 0x1A7A7C35UL, 0xE811FF36UL,
0x3CDB9BDDUL, 0xCEB018DEUL, 0xDDE0EB2AUL, 0x2F8B6829UL,
0x82F63B78UL, 0x709DB87BUL, 0x63CD4B8FUL, 0x91A6C88CUL,
0x456CAC67UL, 0xB7072F64UL, 0xA457DC90UL, 0x563C5F93UL,
0x082F63B7UL, 0xFA44E0B4UL, 0xE9141340UL, 0x1B7F9043UL,
0xCFB5F4A8UL, 0x3DDE77ABUL, 0x2E8E845FUL, 0xDCE5075CUL,
0x92A8FC17UL, 0x60C37F14UL, 0x73938CE0UL, 0x81F80FE3UL,
0x55326B08UL, 0xA759E80BUL, 0xB4091BFFUL, 0x466298FCUL,
0x1871A4D8UL, 0xEA1A27DBUL, 0xF94AD42FUL, 0x0B21572CUL,
0xDFEB33C7UL, 0x2D80B0C4UL, 0x3ED04330UL, 0xCCBBC033UL,
0xA24BB5A6UL, 0x502036A5UL, 0x4370C551UL, 0xB11B4652UL,
0x65D122B9UL, 0x97BAA1BAUL, 0x84EA524EUL, 0x7681D14DUL,
0x2892ED69UL, 0xDAF96E6AUL, 0xC9A99D9EUL, 0x3BC21E9DUL,
0xEF087A76UL, 0x1D63F975UL, 0x0E330A81UL, 0xFC588982UL,
0xB21572C9UL, 0x407EF1CAUL, 0x532E023EUL, 0xA145813DUL,
0x758FE5D6UL, 0x87E466D5UL, 0x94B49521UL, 0x66DF1622UL,
0x38CC2A06UL, 0xCAA7A905UL, 0xD9F75AF1UL, 0x2B9CD9F2UL,
0xFF56BD19UL, 0x0D3D3E1AUL, 0x1E6DCDEEUL, 0xEC064EEDUL,
0xC38D26C4UL, 0x31E6A5C7UL, 0x22B65633UL, 0xD0DDD530UL,
0x0417B1DBUL, 0xF67C32D8UL, 0xE52CC12CUL, 0x1747422FUL,
0x49547E0BUL, 0xBB3FFD08UL, 0xA86F0EFCUL, 0x5A048DFFUL,
0x8ECEE914UL, 0x7CA56A17UL, 0x6FF599E3UL, 0x9D9E1AE0UL,
0xD3D3E1ABUL, 0x21B862A8UL, 0x32E8915CUL, 0xC083125FUL,
0x144976B4UL, 0xE622F5B7UL, 0xF5720643UL, 0x07198540UL,
0x590AB964UL, 0xAB613A67UL, 0xB831C993UL, 0x4A5A4A90UL,
0x9E902E7BUL, 0x6CFBAD78UL, 0x7FAB5E8CUL, 0x8DC0DD8FUL,
0xE330A81AUL, 0x115B2B19UL, 0x020BD8EDUL, 0xF0605BEEUL,
0x24AA3F05UL, 0xD6C1BC06UL, 0xC5914FF2UL, 0x37FACCF1UL,
0x69E9F0D5UL, 0x9B8273D6UL, 0x88D28022UL, 0x7AB90321UL,
0xAE7367CAUL, 0x5C18E4C9UL, 0x4F48173DUL, 0xBD23943EUL,
0xF36E6F75UL, 0x0105EC76UL, 0x12551F82UL, 0xE03E9C81UL,
0x34F4F86AUL, 0xC69F7B69UL, 0xD5CF889DUL, 0x27A40B9EUL,
0x79B737BAUL, 0x8BDCB4B9UL, 0x988C474DUL, 0x6AE7C44EUL,
0xBE2DA0A5UL, 0x4C4623A6UL, 0x5F16D052UL, 0xAD7D5351UL,
};
#endif
---------
Old text: (Appendix B)
---------
/* 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);
}
---------
New text: (Appendix B)
---------
/* Example of table build routine */
#include <stdio.h>
#include <stdlib.h>
#define OUTPUT_FILE "crc32cr.h"
#define CRC32C_POLY 0x1EDC6F41UL
static FILE *tf;
static uint32_t
reflect_32(uint32_t b)
{
int i;
uint32_t rw = 0UL;
for (i = 0; i < 32; i++) {
if (b & 1)
rw |= 1 << (31 - i);
b >>= 1;
}
return (rw);
}
static uint32_t
build_crc_table(int index)
{
int i;
uint32_t rb;
rb = reflect_32(index);
for (i = 0; i < 8; i++) {
if (rb & 0x80000000UL)
rb = (rb << 1) ^ (uint32_t)CRC32C_POLY;
else
rb <<= 1;
}
return (reflect_32 (rb));
}
int
main (void)
{
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_h__\n");
fprintf(tf, "#define __crc32cr_h__\n\n");
fprintf(tf, "#define CRC32C_POLY 0x%08XUL\n",
(uint32_t)CRC32C_POLY);
fprintf(tf,
"#define CRC32C(c,d) (c=(c>>8)^crc_c[(c^(d))&0xFF])\n");
fprintf(tf, "\nuint32_t crc_c[256] =\n{\n");
for (i = 0; i < 256; i++) {
fprintf(tf, "0x%08XUL,", build_crc_table (i));
if ((i & 3) == 3)
fprintf(tf, "\n");
else
fprintf(tf, " ");
}
fprintf(tf, "};\n\n#endif\n");
if (fclose (tf) != 0)
printf("Unable to close <%s>.", OUTPUT_FILE);
else
printf("\nThe CRC-32c table has been written to <%s>.\n",
OUTPUT_FILE);
}
---------
Old text: (Appendix B)
---------
/* 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);
}
---------
New text: (Appendix B)
---------
/* Example of crc insertion */
#include "crc32cr.h"
unsigned long
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 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;
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);
}
3.46.3. Solution Description
The code was changed to use platform independent types.
4. IANA Considerations 4. IANA Considerations
This document does not require any actions from IANA. This document does not require any actions from IANA.
5. Security Considerations 5. Security Considerations
This document does not add any security considerations to those given This document does not add any security considerations to those given
in [RFC4960]. in [RFC4960].
6. Acknowledgments 6. Acknowledgments
skipping to change at page 58, line 32 skipping to change at page 80, line 47
Tom Petch, Julien Pourtet, and Michael Welzl for their invaluable Tom Petch, Julien Pourtet, and Michael Welzl for their invaluable
comments. comments.
7. References 7. References
7.1. Normative References 7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol",
RFC 4960, DOI 10.17487/RFC4960, September 2007, RFC 4960, DOI 10.17487/RFC4960, September 2007,
<http://www.rfc-editor.org/info/rfc4960>. <https://www.rfc-editor.org/info/rfc4960>.
7.2. Informative References 7.2. Informative References
[I-D.ietf-tsvwg-ecn-experimentation]
Black, D., "Relaxing Restrictions on Explicit Congestion
Notification (ECN) Experimentation", draft-ietf-tsvwg-ecn-
experimentation-07 (work in progress), October 2017.
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, Communication Layers", STD 3, RFC 1122,
DOI 10.17487/RFC1122, October 1989, DOI 10.17487/RFC1122, October 1989,
<http://www.rfc-editor.org/info/rfc1122>. <https://www.rfc-editor.org/info/rfc1122>.
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
Zhang, L., and V. Paxson, "Stream Control Transmission Zhang, L., and V. Paxson, "Stream Control Transmission
Protocol", RFC 2960, DOI 10.17487/RFC2960, October 2000, Protocol", RFC 2960, DOI 10.17487/RFC2960, October 2000,
<http://www.rfc-editor.org/info/rfc2960>. <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>.
[RFC4460] Stewart, R., Arias-Rodriguez, I., Poon, K., Caro, A., and [RFC4460] Stewart, R., Arias-Rodriguez, I., Poon, K., Caro, A., and
M. Tuexen, "Stream Control Transmission Protocol (SCTP) M. Tuexen, "Stream Control Transmission Protocol (SCTP)
Specification Errata and Issues", RFC 4460, Specification Errata and Issues", RFC 4460,
DOI 10.17487/RFC4460, April 2006, DOI 10.17487/RFC4460, April 2006,
<http://www.rfc-editor.org/info/rfc4460>. <https://www.rfc-editor.org/info/rfc4460>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 5226,
DOI 10.17487/RFC5226, May 2008,
<https://www.rfc-editor.org/info/rfc5226>.
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, Control", RFC 5681, DOI 10.17487/RFC5681, September 2009,
<http://www.rfc-editor.org/info/rfc5681>. <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, [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent,
"Computing TCP's Retransmission Timer", RFC 6298, "Computing TCP's Retransmission Timer", RFC 6298,
DOI 10.17487/RFC6298, June 2011, DOI 10.17487/RFC6298, June 2011,
<http://www.rfc-editor.org/info/rfc6298>. <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>.
Authors' Addresses Authors' Addresses
Randall R. Stewart Randall R. Stewart
Netflix, Inc. Netflix, Inc.
Chapin, SC 29036 Chapin, SC 29036
United States United States
Email: randall@lakerest.net Email: randall@lakerest.net
 End of changes. 55 change blocks. 
166 lines changed or deleted 1297 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/