draft-ietf-tsvwg-rfc4960-errata-05.txt   draft-ietf-tsvwg-rfc4960-errata-06.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: September 6, 2018 Muenster Univ. of Appl. Sciences Expires: November 22, 2018 Muenster Univ. of Appl. Sciences
M. Proshin M. Proshin
Ericsson Ericsson
March 5, 2018 May 21, 2018
RFC 4960 Errata and Issues RFC 4960 Errata and Issues
draft-ietf-tsvwg-rfc4960-errata-05.txt draft-ietf-tsvwg-rfc4960-errata-06.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 document provides deltas to RFC4960 and is organized in a time
ordered way. The issues are listed in the order they were brought ordered way. The issues are listed in the order they were brought
up. Because some text is changed several times the last delta in the up. 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 text is the one which should be applied. In addition to the delta a
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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 https://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 September 6, 2018. This Internet-Draft will expire on November 22, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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
(https://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
skipping to change at page 2, line 28 skipping to change at page 2, line 28
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 . . . . . . . . . . . . . 6 3.3. Registration of New Chunk Types . . . . . . . . . . . . . 6
3.4. Variable Parameters for INIT Chunks . . . . . . . . . . . 7 3.4. Variable Parameters for INIT Chunks . . . . . . . . . . . 7
3.5. CRC32c Sample Code on 64-bit Platforms . . . . . . . . . 8 3.5. CRC32c Sample Code on 64-bit Platforms . . . . . . . . . 8
3.6. Endpoint Failure Detection . . . . . . . . . . . . . . . 9 3.6. Endpoint Failure Detection . . . . . . . . . . . . . . . 9
3.7. Data Transmission Rules . . . . . . . . . . . . . . . . . 10 3.7. Data Transmission Rules . . . . . . . . . . . . . . . . . 10
3.8. T1-Cookie Timer . . . . . . . . . . . . . . . . . . . . . 11 3.8. T1-Cookie Timer . . . . . . . . . . . . . . . . . . . . . 11
3.9. Miscellaneous Typos . . . . . . . . . . . . . . . . . . . 12 3.9. Miscellaneous Typos . . . . . . . . . . . . . . . . . . . 12
3.10. CRC32c Sample Code . . . . . . . . . . . . . . . . . . . 19 3.10. CRC32c Sample Code . . . . . . . . . . . . . . . . . . . 19
3.11. partial_bytes_acked after T3-rtx Expiration . . . . . . . 20 3.11. partial_bytes_acked after T3-rtx Expiration . . . . . . . 20
3.12. Order of Adjustments of partial_bytes_acked and cwnd . . 20 3.12. Order of Adjustments of partial_bytes_acked and cwnd . . 21
3.13. HEARTBEAT ACK and the association error counter . . . . . 21 3.13. HEARTBEAT ACK and the association error counter . . . . . 21
3.14. Path for Fast Retransmission . . . . . . . . . . . . . . 23 3.14. Path for Fast Retransmission . . . . . . . . . . . . . . 23
3.15. Transmittal in Fast Recovery . . . . . . . . . . . . . . 24 3.15. Transmittal in Fast Recovery . . . . . . . . . . . . . . 24
3.16. Initial Value of ssthresh . . . . . . . . . . . . . . . . 24 3.16. Initial Value of ssthresh . . . . . . . . . . . . . . . . 24
3.17. Automatically Confirmed Addresses . . . . . . . . . . . . 25 3.17. Automatically Confirmed Addresses . . . . . . . . . . . . 25
3.18. Only One Packet after Retransmission Timeout . . . . . . 26 3.18. Only One Packet after Retransmission Timeout . . . . . . 26
3.19. INIT ACK Path for INIT in COOKIE-WAIT State . . . . . . . 27 3.19. INIT ACK Path for INIT in COOKIE-WAIT State . . . . . . . 27
3.20. Zero Window Probing and Unreachable Primary Path . . . . 28 3.20. Zero Window Probing and Unreachable Primary Path . . . . 28
3.21. Normative Language in Section 10 . . . . . . . . . . . . 29 3.21. Normative Language in Section 10 . . . . . . . . . . . . 29
3.22. Increase of partial_bytes_acked in Congestion Avoidance . 33 3.22. Increase of partial_bytes_acked in Congestion Avoidance . 33
skipping to change at page 3, line 17 skipping to change at page 3, line 17
3.39. Zero Window Probing . . . . . . . . . . . . . . . . . . . 57 3.39. Zero Window Probing . . . . . . . . . . . . . . . . . . . 57
3.40. Updating References Regarding ECN . . . . . . . . . . . . 59 3.40. Updating References Regarding ECN . . . . . . . . . . . . 59
3.41. Host Name Address Parameter Deprecated . . . . . . . . . 60 3.41. Host Name Address Parameter Deprecated . . . . . . . . . 60
3.42. Conflicting Text Regarding the Supported Address Types 3.42. Conflicting Text Regarding the Supported Address Types
Parameter . . . . . . . . . . . . . . . . . . . . . . . . 64 Parameter . . . . . . . . . . . . . . . . . . . . . . . . 64
3.43. Integration of RFC 6096 . . . . . . . . . . . . . . . . . 65 3.43. Integration of RFC 6096 . . . . . . . . . . . . . . . . . 65
3.44. Integration of RFC 6335 . . . . . . . . . . . . . . . . . 67 3.44. Integration of RFC 6335 . . . . . . . . . . . . . . . . . 67
3.45. Integration of RFC 7053 . . . . . . . . . . . . . . . . . 69 3.45. Integration of RFC 7053 . . . . . . . . . . . . . . . . . 69
3.46. CRC32c Code Improvements . . . . . . . . . . . . . . . . 72 3.46. CRC32c Code Improvements . . . . . . . . . . . . . . . . 72
3.47. Clarification of Gap Ack Blocks in SACK Chunks . . . . . 82 3.47. Clarification of Gap Ack Blocks in SACK Chunks . . . . . 82
3.48. Handling of SSN Wrap Arounds . . . . . . . . . . . . . . 83 3.48. Handling of SSN Wrap Arounds . . . . . . . . . . . . . . 84
3.49. Update RFC 2119 Boilerplate . . . . . . . . . . . . . . . 84 3.49. Update RFC 2119 Boilerplate . . . . . . . . . . . . . . . 85
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 85 3.50. Missed Text Removal . . . . . . . . . . . . . . . . . . . 85
5. Security Considerations . . . . . . . . . . . . . . . . . . . 85 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 86
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 85 5. Security Considerations . . . . . . . . . . . . . . . . . . . 86
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 85 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 86
7.1. Normative References . . . . . . . . . . . . . . . . . . 85 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 86
7.2. Informative References . . . . . . . . . . . . . . . . . 86 7.1. Normative References . . . . . . . . . . . . . . . . . . 87
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 87 7.2. Informative References . . . . . . . . . . . . . . . . . 87
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 88
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 publication of this document for [RFC4960] specifying the Stream the publication 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 3, line 49 skipping to change at page 3, line 50
Each error will be detailed within this document in the form of: Each error will be detailed within this document in the form of:
o The problem description, o The problem description,
o The text quoted from [RFC4960], o The text quoted from [RFC4960],
o The replacement text that should be placed into an upcoming BIS o The replacement text that should be placed into an upcoming BIS
document, document,
o A description of the solution. o A description of the solution.
Note that when reading this document one must use care to assure that Note that when reading this document one must use care to assure that
a field or item is not updated further on within the document. Each a field or item is not updated further on within the document. Since
section should be applied in sequence to the original [RFC4960] since
this document is a historical record of the sequential changes that this document is a historical record of the sequential changes that
have been found necessary at various inter-op events and through have been found necessary at various inter-op events and through
discussion on the list. discussion on the list, the last delta in the text is the one which
should be applied.
2. Conventions 2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Corrections to RFC 4960 3. Corrections to RFC 4960
[NOTE to RFC-Editor:
References to obsoleted RFCs are in OLD TEXT sections and have the
corresponding references to the obsoleting RFCs in the NEW TEXT
sections. In addition to this, there are some references to the
obsoleted [RFC2960], which are intended.
]
3.1. Path Error Counter Threshold Handling 3.1. Path Error Counter Threshold Handling
3.1.1. Description of the Problem 3.1.1. Description of the Problem
The handling of the 'Path.Max.Retrans' parameter is described in The handling of the 'Path.Max.Retrans' parameter is described in
Section 8.2 and Section 8.3 of [RFC4960] in an Inconsistent way. Section 8.2 and Section 8.3 of [RFC4960] in an inconsistent way.
Whereas Section 8.2 describes that a path is marked inactive when the Whereas Section 8.2 describes that a path is marked inactive when the
path error counter exceeds the threshold, Section 8.3 says the path path error counter exceeds the threshold, Section 8.3 says the path
is marked inactive when the path error counter reaches the threshold. is marked inactive when the path error counter reaches the threshold.
This issue was reported as an Errata for [RFC4960] with Errata ID This issue was reported as an Errata for [RFC4960] with Errata ID
1440. 1440.
3.1.2. Text Changes to the Document 3.1.2. Text Changes to the Document
--------- ---------
Old text: (Section 8.3) Old text: (Section 8.3)
skipping to change at page 7, line 17 skipping to change at page 7, line 17
The assignment of new chunk parameter type codes is done through an The assignment of new chunk parameter type codes is done through an
IETF Consensus action, as defined in [RFC2434]. Documentation of the IETF Consensus action, as defined in [RFC2434]. Documentation of the
chunk parameter MUST contain the following information: chunk parameter MUST contain the following information:
--------- ---------
New text: (Section 14.1) New text: (Section 14.1)
--------- ---------
The assignment of new chunk type codes is done through an The assignment of new chunk type codes is done through an
IETF Consensus action, as defined in [RFC5226]. Documentation of the IETF Consensus action, as defined in [RFC8126]. Documentation of the
chunk type MUST contain the following information: chunk type MUST contain the following information:
3.3.3. Solution Description 3.3.3. Solution Description
Refer to chunk types as intended. Refer to chunk types as intended and change reference to [RFC8126].
3.4. Variable Parameters for INIT Chunks 3.4. Variable Parameters for INIT Chunks
3.4.1. Description of the Problem 3.4.1. Description of the Problem
Newlines in wrong places break the layout of the table of variable Newlines in wrong places break the layout of the table of variable
parameters for the INIT chunk in Section 3.3.2 of [RFC4960]. parameters for the INIT chunk in Section 3.3.2 of [RFC4960].
This issue was reported as an Errata for [RFC4960] with Errata ID This issue was reported as an Errata for [RFC4960] with Errata ID
3291 and Errata ID 3804. 3291 and Errata ID 3804.
skipping to change at page 11, line 25 skipping to change at page 11, line 25
receiver if allowed by cwnd (see rule B below). This rule allows receiver if allowed by cwnd (see rule B below). This rule allows
the sender to probe for a change in rwnd that the sender missed the sender to probe for a change in rwnd that the sender missed
due to the SACK having been lost in transit from the data receiver due to the SACK having been lost in transit from the data receiver
to the data sender. to the data sender.
--------- ---------
New text: (Section 6.1 A)) New text: (Section 6.1 A))
--------- ---------
The sender MUST also have an algorithm for sending new DATA chunks The sender MUST also have an algorithm for sending new DATA chunks
to avoid silly window syndrome (SWS) as described in [RFC0813]. to avoid silly window syndrome (SWS) as described in [RFC1122].
The algorithm can be similar to the one described in Section The algorithm can be similar to the one described in Section
4.2.3.4 of [RFC1122]. 4.2.3.4 of [RFC1122].
3.7.3. Solution Description 3.7.3. Solution Description
Last paragraph of Section 6.1 A) removed as intended in Last paragraph of Section 6.1 A) removed as intended in
Section 2.15.2 of [RFC4460]. Section 2.15.2 of [RFC4460].
3.8. T1-Cookie Timer 3.8. T1-Cookie Timer
skipping to change at page 19, line 48 skipping to change at page 19, line 48
3.10. CRC32c Sample Code 3.10. CRC32c Sample Code
3.10.1. Description of the Problem 3.10.1. Description of the Problem
The CRC32c computation is described in Appendix B of [RFC4960]. The CRC32c computation is described in Appendix B of [RFC4960].
However, the corresponding sample code and its explanation appears at However, the corresponding sample code and its explanation appears at
the end of Appendix C, which deals with ICMP handling. the end of Appendix C, which deals with ICMP handling.
3.10.2. Text Changes to the Document 3.10.2. Text Changes to the Document
Move the sample code related to CRC32c computation and its Move all of Appendix C starting with the following sentence to the
explanation from the end of Appendix C to the end of Appendix B. end of Appendix B.
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.
3.10.3. Solution Description 3.10.3. Solution Description
Text moved to the appropriate location. Text moved to the appropriate location.
3.11. partial_bytes_acked after T3-rtx Expiration 3.11. partial_bytes_acked after T3-rtx Expiration
3.11.1. Description of the Problem 3.11.1. Description of the Problem
Section 7.2.3 of [RFC4960] explicitly states that partial_bytes_acked Section 7.2.3 of [RFC4960] explicitly states that partial_bytes_acked
skipping to change at page 20, line 49 skipping to change at page 21, line 9
3.11.3. Solution Description 3.11.3. Solution Description
Specify that partial_bytes_acked should be reset to 0 after T3-rtx Specify that partial_bytes_acked should be reset to 0 after T3-rtx
timer expiration. timer expiration.
3.12. Order of Adjustments of partial_bytes_acked and cwnd 3.12. Order of Adjustments of partial_bytes_acked and cwnd
3.12.1. Description of the Problem 3.12.1. Description of the Problem
Section 7.2.2 of [RFC4960] is unclear about the order of adjustments Section 7.2.2 of [RFC4960] likely implies the wrong order of of
applied to partial_bytes_acked and cwnd in the congestion avoidance adjustments applied to partial_bytes_acked and cwnd in the congestion
phase. avoidance phase.
3.12.2. Text Changes to the Document 3.12.2. Text Changes to the Document
--------- ---------
Old text: (Section 7.2.2) Old text: (Section 7.2.2)
--------- ---------
o When partial_bytes_acked is equal to or greater than cwnd and o When partial_bytes_acked is equal to or greater than cwnd and
before the arrival of the SACK the sender had cwnd or more bytes before the arrival of the SACK the sender had cwnd or more bytes
of data outstanding (i.e., before arrival of the SACK, flightsize of data outstanding (i.e., before arrival of the SACK, flightsize
skipping to change at page 22, line 16 skipping to change at page 22, line 19
--------- ---------
The counter shall be reset each time a DATA chunk sent to that peer The counter shall be reset each time a DATA chunk sent to that peer
endpoint is acknowledged (by the reception of a SACK) or a HEARTBEAT endpoint is acknowledged (by the reception of a SACK) or a HEARTBEAT
ACK is received from the peer endpoint. ACK is received from the peer endpoint.
--------- ---------
New text: (Section 8.1) New text: (Section 8.1)
--------- ---------
The counter SHOULD be reset each time a DATA chunk sent to that peer The counter MUST be reset each time a DATA chunk sent to that peer
endpoint is acknowledged (by the reception of a SACK). When a endpoint is acknowledged (by the reception of a SACK). When a
HEARTBEAT ACK is received from the peer endpoint, the counter SHOULD HEARTBEAT ACK is received from the peer endpoint, the counter SHOULD
also be reset. The receiver of the HEARTBEAT ACK MAY choose not to also be reset. The receiver of the HEARTBEAT ACK MAY choose not to
clear the counter if there is outstanding data on the association. clear the counter if there is outstanding data on the association.
This allows for handling the possible difference in reachability This allows for handling the possible difference in reachability
based on DATA chunks and HEARTBEAT chunks. based on DATA chunks and HEARTBEAT chunks.
--------- ---------
Old text: (Section 8.3) Old text: (Section 8.3)
--------- ---------
skipping to change at page 22, line 42 skipping to change at page 22, line 45
optionally report to the upper layer when an inactive destination optionally report to the upper layer when an inactive destination
address is marked as active due to the reception of the latest address is marked as active due to the reception of the latest
HEARTBEAT ACK. The receiver of the HEARTBEAT ACK must also clear the HEARTBEAT ACK. The receiver of the HEARTBEAT ACK must also clear the
association overall error count as well (as defined in Section 8.1). association overall error count as well (as defined in Section 8.1).
--------- ---------
New text: (Section 8.3) New text: (Section 8.3)
--------- ---------
Upon the receipt of the HEARTBEAT ACK, the sender of the HEARTBEAT Upon the receipt of the HEARTBEAT ACK, the sender of the HEARTBEAT
SHOULD clear the error counter of the destination transport address MUST clear the error counter of the destination transport address
to which the HEARTBEAT was sent, and mark the destination transport to which the HEARTBEAT was sent, and mark the destination transport
address as active if it is not so marked. The endpoint MAY address as active if it is not so marked. The endpoint MAY
optionally report to the upper layer when an inactive destination optionally report to the upper layer when an inactive destination
address is marked as active due to the reception of the latest address is marked as active due to the reception of the latest
HEARTBEAT ACK. The receiver of the HEARTBEAT ACK SHOULD also clear HEARTBEAT ACK. The receiver of the HEARTBEAT ACK SHOULD also clear
the association overall error counter (as defined in Section 8.1). the association overall error counter (as defined in Section 8.1).
3.13.3. Solution Description 3.13.3. Solution Description
The new text provides a possibility to not reset the association The new text provides a possibility to not reset the association
skipping to change at page 29, line 46 skipping to change at page 29, line 46
3.21. Normative Language in Section 10 3.21. Normative Language in Section 10
3.21.1. Description of the Problem 3.21.1. Description of the Problem
Section 10 of [RFC4960] is informative and, therefore, normative Section 10 of [RFC4960] is informative and, therefore, normative
language such as MUST and MAY cannot be used there. However, there language such as MUST and MAY cannot be used there. However, there
are several places in Section 10 where MUST and MAY are used. are several places in Section 10 where MUST and MAY are used.
3.21.2. Text Changes to the Document 3.21.2. Text Changes to the Document
--------- ---------
Old text: (Section 10.1) Old text: (Section 10.1)
--------- ---------
E) Send E) Send
Format: SEND(association id, buffer address, byte count [,context] Format: SEND(association id, buffer address, byte count [,context]
[,stream id] [,life time] [,destination transport address] [,stream id] [,life time] [,destination transport address]
[,unordered flag] [,no-bundle flag] [,payload protocol-id] ) [,unordered flag] [,no-bundle flag] [,payload protocol-id] )
-> result -> result
... ...
o no-bundle flag - instructs SCTP not to bundle this user data with o no-bundle flag - instructs SCTP not to bundle this user data with
other outbound DATA chunks. SCTP MAY still bundle even when this other outbound DATA chunks. SCTP MAY still bundle even when this
flag is present, when faced with network congestion. flag is present, when faced with network congestion.
--------- ---------
New text: (Section 10.1) New text: (Section 10.1)
--------- ---------
E) Send E) Send
Format: SEND(association id, buffer address, byte count [,context] Format: SEND(association id, buffer address, byte count [,context]
[,stream id] [,life time] [,destination transport address] [,stream id] [,life time] [,destination transport address]
[,unordered flag] [,no-bundle flag] [,payload protocol-id] ) [,unordered flag] [,no-bundle flag] [,payload protocol-id] )
-> result -> result
... ...
o no-bundle flag - instructs SCTP not to bundle this user data with o no-bundle flag - instructs SCTP not to bundle this user data with
other outbound DATA chunks. SCTP may still bundle even when this other outbound DATA chunks. SCTP may still bundle even when this
flag is present, when faced with network congestion. flag is present, when faced with network congestion.
--------- ---------
Old text: (Section 10.1) Old text: (Section 10.1)
--------- ---------
G) Receive G) Receive
Format: RECEIVE(association id, buffer address, buffer size Format: RECEIVE(association id, buffer address, buffer size
[,stream id]) [,stream id])
-> byte count [,transport address] [,stream id] [,stream sequence -> byte count [,transport address] [,stream id] [,stream sequence
number] [,partial flag] [,delivery number] [,payload protocol-id] number] [,partial flag] [,delivery number] [,payload protocol-id]
... ...
o partial flag - if this returned flag is set to 1, then this o Stream Sequence Number - the Stream Sequence Number assigned by
Receive contains a partial delivery of the whole message. When the sending SCTP peer.
this flag is set, the stream id and Stream Sequence Number MUST
accompany this receive. When this flag is set to 0, it indicates
that no more deliveries will be received for this Stream Sequence
Number.
--------- o partial flag - if this returned flag is set to 1, then this
New text: (Section 10.1) Receive contains a partial delivery of the whole message. When
--------- this flag is set, the stream id and Stream Sequence Number MUST
accompany this receive. When this flag is set to 0, it indicates
that no more deliveries will be received for this Stream Sequence
Number.
G) Receive ---------
New text: (Section 10.1)
---------
Format: RECEIVE(association id, buffer address, buffer size G) Receive
[,stream id])
-> byte count [,transport address] [,stream id] [,stream sequence
number] [,partial flag] [,delivery number] [,payload protocol-id]
... Format: RECEIVE(association id, buffer address, buffer size
[,stream id])
-> byte count [,transport address] [,stream id] [,stream sequence
number] [,partial flag] [,delivery number] [,payload protocol-id]
o partial flag - if this returned flag is set to 1, then this ...
Receive contains a partial delivery of the whole message. When
this flag is set, the stream id and Stream Sequence Number must
accompany this receive. When this flag is set to 0, it indicates
that no more deliveries will be received for this Stream Sequence
Number.
--------- o stream sequence number - the Stream Sequence Number assigned by
Old text: (Section 10.1) the sending SCTP peer.
---------
N) Receive Unsent Message o partial flag - if this returned flag is set to 1, then this
primitive contains a partial delivery of the whole message. When
this flag is set, the stream id and stream sequence number must
accompany this primitive. When this flag is set to 0, it indicates
that no more deliveries will be received for this stream sequence
number.
Format: RECEIVE_UNSENT(data retrieval id, buffer address, buffer ---------
size [,stream id] [, stream sequence number] [,partial Old text: (Section 10.1)
flag] [,payload protocol-id]) ---------
... N) Receive Unsent Message
o partial flag - if this returned flag is set to 1, then this Format: RECEIVE_UNSENT(data retrieval id, buffer address, buffer
message is a partial delivery of the whole message. When this size [,stream id] [, stream sequence number] [,partial
flag is set, the stream id and Stream Sequence Number MUST flag] [,payload protocol-id])
accompany this receive. When this flag is set to 0, it indicates
that no more deliveries will be received for this Stream Sequence
Number.
--------- ...
New text: (Section 10.1)
---------
N) Receive Unsent Message o Stream Sequence Number - this value is returned indicating the
Stream Sequence Number that was associated with the message.
Format: RECEIVE_UNSENT(data retrieval id, buffer address, buffer o partial flag - if this returned flag is set to 1, then this
size [,stream id] [, stream sequence number] [,partial message is a partial delivery of the whole message. When this
flag] [,payload protocol-id]) flag is set, the stream id and Stream Sequence Number MUST
accompany this receive. When this flag is set to 0, it indicates
that no more deliveries will be received for this Stream Sequence
Number.
... ---------
New text: (Section 10.1)
---------
o partial flag - if this returned flag is set to 1, then this N) Receive Unsent Message
message is a partial delivery of the whole message. When this
flag is set, the stream id and Stream Sequence Number must
accompany this receive. When this flag is set to 0, it indicates
that no more deliveries will be received for this Stream Sequence
Number.
--------- Format: RECEIVE_UNSENT(data retrieval id, buffer address, buffer
Old text: (Section 10.1) size [,stream id] [, stream sequence number] [,partial
--------- flag] [,payload protocol-id])
O) Receive Unacknowledged Message ...
Format: RECEIVE_UNACKED(data retrieval id, buffer address, buffer o stream sequence number - this value is returned indicating the
size [,stream id] [,stream sequence number] [,partial Stream Sequence Number that was associated with the message.
flag] [,payload protocol-id])
... o partial flag - if this returned flag is set to 1, then this
message is a partial delivery of the whole message. When this
flag is set, the stream id and stream sequence number must
accompany this primitive. When this flag is set to 0, it indicates
that no more deliveries will be received for this stream sequence
number.
o partial flag - if this returned flag is set to 1, then this ---------
message is a partial delivery of the whole message. When this Old text: (Section 10.1)
flag is set, the stream id and Stream Sequence Number MUST ---------
accompany this receive. When this flag is set to 0, it indicates
that no more deliveries will be received for this Stream Sequence
Number.
--------- O) Receive Unacknowledged Message
New text: (Section 10.1)
---------
O) Receive Unacknowledged Message Format: RECEIVE_UNACKED(data retrieval id, buffer address, buffer
size [,stream id] [,stream sequence number] [,partial
flag] [,payload protocol-id])
Format: RECEIVE_UNACKED(data retrieval id, buffer address, buffer ...
size [,stream id] [,stream sequence number] [,partial
flag] [,payload protocol-id])
... o Stream Sequence Number - this value is returned indicating the
Stream Sequence Number that was associated with the message.
o partial flag - if this returned flag is set to 1, then this o partial flag - if this returned flag is set to 1, then this
message is a partial delivery of the whole message. When this message is a partial delivery of the whole message. When this
flag is set, the stream id and Stream Sequence Number must flag is set, the stream id and Stream Sequence Number MUST
accompany this receive. When this flag is set to 0, it indicates accompany this receive. When this flag is set to 0, it indicates
that no more deliveries will be received for this Stream Sequence that no more deliveries will be received for this Stream Sequence
Number. Number.
---------
New text: (Section 10.1)
---------
O) Receive Unacknowledged Message
Format: RECEIVE_UNACKED(data retrieval id, buffer address, buffer
size [,stream id] [,stream sequence number] [,partial
flag] [,payload protocol-id])
...
o stream sequence number - this value is returned indicating the
Stream Sequence Number that was associated with the message.
o partial flag - if this returned flag is set to 1, then this
message is a partial delivery of the whole message. When this
flag is set, the stream id and stream sequence number must
accompany this primitive. When this flag is set to 0, it indicates
that no more deliveries will be received for this stream sequence
number.
3.21.3. Solution Description 3.21.3. Solution Description
The normative language is removed from Section 10. The normative language is removed from Section 10. In addition, the
consistency of the text has been improved.
3.22. Increase of partial_bytes_acked in Congestion Avoidance 3.22. Increase of partial_bytes_acked in Congestion Avoidance
3.22.1. Description of the Problem 3.22.1. Description of the Problem
Two issues have been discovered with the partial_bytes_acked handling Two issues have been discovered with the partial_bytes_acked handling
described in Section 7.2.2 of [RFC4960]: described in Section 7.2.2 of [RFC4960]:
o If the Cumulative TSN Ack Point is not advanced but the SACK chunk o If the Cumulative TSN Ack Point is not advanced but the SACK chunk
acknowledges new TSNs in the Gap Ack Blocks, these newly acknowledges new TSNs in the Gap Ack Blocks, these newly
skipping to change at page 40, line 35 skipping to change at page 40, line 35
unclear whether the receiver has to rollback state changes already unclear whether the receiver has to rollback state changes already
performed while processing the packet or not. performed while processing the packet or not.
The intention of [RFC4960] is to process an incoming packet chunk by The intention of [RFC4960] is to process an incoming packet chunk by
chunk and not to perform any prescreening of chunks in the received chunk and not to perform any prescreening of chunks in the received
packet. Thus, by discarding one chunk the receiver also causes packet. Thus, by discarding one chunk the receiver also causes
discarding of all further chunks. discarding of all further chunks.
3.25.2. Text Changes to the Document 3.25.2. Text Changes to the Document
Old text: (Section 3.2) ---------
Old text: (Section 3.2)
---------
00 - Stop processing this SCTP packet and discard it, do not 00 - Stop processing this SCTP packet and discard it, do not
process any further chunks within it. process any further chunks within it.
01 - Stop processing this SCTP packet and discard it, do not 01 - Stop processing this SCTP packet and discard it, do not
process any further chunks within it, and report the process any further chunks within it, and report the
unrecognized chunk in an 'Unrecognized Chunk Type'. unrecognized chunk in an 'Unrecognized Chunk Type'.
New text: (Section 3.2) ---------
New text: (Section 3.2)
---------
00 - Stop processing this SCTP packet, discard the unrecognized 00 - Stop processing this SCTP packet, discard the unrecognized
chunk and all further chunks. chunk and all further chunks.
01 - Stop processing this SCTP packet, discard the unrecognized 01 - Stop processing this SCTP packet, discard the unrecognized
chunk and all further chunks, and report the unrecognized chunk and all further chunks, and report the unrecognized
chunk in an 'Unrecognized Chunk Type'. chunk in an 'Unrecognized Chunk Type'.
Old text: (Section 11.3) ---------
Old 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,
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,
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. chunk MUST have a zero Verification Tag.
The receiver of an INIT chunk MUST silently discard the INIT chunk and all The receiver of an INIT chunk MUST silently discard the INIT chunk and
further chunks if the INIT chunk is bundled with other chunks or the packet all further chunks if the INIT chunk is bundled with other chunks or
has a non-zero verification tag. the packet has a non-zero verification tag.
3.25.3. Solution Description 3.25.3. Solution Description
The new text makes it clear that chunks can be processed from the The new text makes it clear that chunks can be processed from the
beginning to the end and no rollback or pre-screening is required. beginning to the end and no rollback or pre-screening is required.
3.26. CWND Increase in Congestion Avoidance Phase 3.26. CWND Increase in Congestion Avoidance Phase
3.26.1. Description of the Problem 3.26.1. Description of the Problem
[RFC4960] in Section 7.2.2 prescribes to increase cwnd by 1*MTU per [RFC4960] in Section 7.2.2 prescribes to increase cwnd by 1*MTU per
RTT if the sender has cwnd or more bytes of data outstanding to the RTT if the sender has cwnd or more bytes of data outstanding to the
corresponding address in the Congestion Avoidance phase. However, corresponding address in the Congestion Avoidance phase. However,
this is described without normative language. Moreover, this is described without normative language. Moreover,
Section 7.2.2 includes an algorithm how an implementation can achieve Section 7.2.2 includes an algorithm how an implementation can achieve
this but this algorithm is underspecified and actually allows this but this algorithm is underspecified and actually allows
increasing cwnd by more than 1*MTU per RTT. increasing cwnd by more than 1*MTU per RTT.
3.26.2. Text Changes to the Document 3.26.2. Text Changes to the Document
Old text: (Section 7.2.2) ---------
Old text: (Section 7.2.2)
---------
When cwnd is greater than ssthresh, cwnd should be incremented by When cwnd is greater than ssthresh, cwnd should be incremented by
1*MTU per RTT if the sender has cwnd or more bytes of data 1*MTU per RTT if the sender has cwnd or more bytes of data
outstanding for the corresponding transport address. outstanding for the corresponding transport address.
New text: (Section 7.2.2) ---------
New text: (Section 7.2.2)
---------
When cwnd is greater than ssthresh, cwnd SHOULD be incremented by When cwnd is greater than ssthresh, cwnd SHOULD be incremented by
1*MTU per RTT if the sender has cwnd or more bytes of data 1*MTU per RTT if the sender has cwnd or more bytes of data
outstanding for the corresponding transport address. The basic outstanding for the corresponding transport address. The basic
guidelines for incrementing cwnd during congestion avoidance are: guidelines for incrementing cwnd during congestion avoidance are:
o SCTP MAY increment cwnd by 1*MTU. o SCTP MAY increment cwnd by 1*MTU.
o SCTP SHOULD increment cwnd by one 1*MTU once per RTT when o SCTP SHOULD increment cwnd by one 1*MTU once per RTT when
the sender has cwnd or more bytes of data outstanding for the sender has cwnd or more bytes of data outstanding for
the corresponding transport address. the corresponding transport address.
o SCTP MUST NOT increment cwnd by more than 1*MTU per RTT. o SCTP MUST NOT increment cwnd by more than 1*MTU per RTT.
Old text: (Section 7.2.2) ---------
Old text: (Section 7.2.2)
---------
o Whenever cwnd is greater than ssthresh, upon each SACK arrival o Whenever cwnd is greater than ssthresh, upon each SACK arrival
that advances the Cumulative TSN Ack Point, increase that advances the Cumulative TSN Ack Point, increase
partial_bytes_acked by the total number of bytes of all new chunks partial_bytes_acked by the total number of bytes of all new chunks
acknowledged in that SACK including chunks acknowledged by the new acknowledged in that SACK including chunks acknowledged by the new
Cumulative TSN Ack and by Gap Ack Blocks. Cumulative TSN Ack and by Gap Ack Blocks.
o When partial_bytes_acked is equal to or greater than cwnd and o When partial_bytes_acked is equal to or greater than cwnd and
before the arrival of the SACK the sender had cwnd or more bytes before the arrival of the SACK the sender had cwnd or more bytes
of data outstanding (i.e., before arrival of the SACK, flightsize of data outstanding (i.e., before arrival of the SACK, flightsize
was greater than or equal to cwnd), increase cwnd by MTU, and was greater than or equal to cwnd), increase cwnd by MTU, and
reset partial_bytes_acked to (partial_bytes_acked - cwnd). reset partial_bytes_acked to (partial_bytes_acked - cwnd).
New text: (Section 7.2.2) ---------
New text: (Section 7.2.2)
---------
o Whenever cwnd is greater than ssthresh, upon each SACK arrival, o Whenever cwnd is greater than ssthresh, upon each SACK arrival,
increase partial_bytes_acked by the total number of bytes of all increase partial_bytes_acked by the total number of bytes of all
new chunks acknowledged in that SACK including chunks acknowledged new chunks acknowledged in that SACK including chunks acknowledged
by the new Cumulative TSN Ack, by Gap Ack Blocks and by the number by the new Cumulative TSN Ack, by Gap Ack Blocks and by the number
of bytes of duplicated chunks reported in Duplicate TSNs. of bytes of duplicated chunks reported in Duplicate TSNs.
o When partial_bytes_acked is greater than cwnd and before the o When partial_bytes_acked is greater than cwnd and before the
arrival of the SACK the sender had less than cwnd bytes of data outstanding arrival of the SACK the sender had less than cwnd bytes of data
(i.e., before arrival of the SACK, flightsize was less outstanding (i.e., before arrival of the SACK, flightsize was less
than cwnd), reset partial_bytes_acked to cwnd. than cwnd), reset partial_bytes_acked to cwnd.
o When partial_bytes_acked is equal to or greater than cwnd and o When partial_bytes_acked is equal to or greater than cwnd and
before the arrival of the SACK the sender had cwnd or more bytes before the arrival of the SACK the sender had cwnd or more bytes
of data outstanding (i.e., before arrival of the SACK, flightsize of data outstanding (i.e., before arrival of the SACK, flightsize
was greater than or equal to cwnd), partial_bytes_acked is reset was greater than or equal to cwnd), partial_bytes_acked is reset
to (partial_bytes_acked - cwnd). Next, cwnd is increased by 1*MTU. to (partial_bytes_acked - cwnd). Next, cwnd is increased by 1*MTU.
3.26.3. Solution Description 3.26.3. Solution Description
The basic guidelines for incrementing cwnd during the congestion The basic guidelines for incrementing cwnd during the congestion
avoidance phase are added into Section 7.2.2. The guidelines include avoidance phase are added into Section 7.2.2. The guidelines include
the normative language and are aligned with [RFC5681]. the normative language and are aligned with [RFC5681].
The algorithm from Section 7.2.2 is improved to not allow increasing The algorithm from Section 7.2.2 is improved to not allow increasing
cwnd by more than 1*MTU per RTT. cwnd by more than 1*MTU per RTT.
skipping to change at page 65, line 4 skipping to change at page 65, line 4
3.42.1. Description of the Problem 3.42.1. Description of the Problem
When receiving an SCTP packet containing an INIT chunk sent from an When receiving an SCTP packet containing an INIT chunk sent from an
address for which the corresponding address type is not listed in the address for which the corresponding address type is not listed in the
Supported Address Types, there is conflicting text in Section 5.1.2 Supported Address Types, there is conflicting text in Section 5.1.2
of [RFC4960]. It is stated that the association MUST be aborted and of [RFC4960]. It is stated that the association MUST be aborted and
also that the association SHOULD be established and there SHOULD NOT also that the association SHOULD be established and there SHOULD NOT
be any error indication. be any error indication.
3.42.2. Text Changes to the Document 3.42.2. Text Changes to the Document
Old text: (Section 5.1.2) ---------
Old text: (Section 5.1.2)
---------
The sender of INIT may include a 'Supported Address Types' parameter The sender of INIT may include a 'Supported Address Types' parameter
in the INIT to indicate what types of address are acceptable. When in the INIT to indicate what types of address are acceptable. When
this parameter is present, the receiver of INIT (initiate) MUST this parameter is present, the receiver of INIT (initiate) MUST
either use one of the address types indicated in the Supported either use one of the address types indicated in the Supported
Address Types parameter when responding to the INIT, or abort the Address Types parameter when responding to the INIT, or abort the
association with an "Unresolvable Address" error cause if it is association with an "Unresolvable Address" error cause if it is
unwilling or incapable of using any of the address types indicated by unwilling or incapable of using any of the address types indicated by
its peer. its peer.
New text: (Section 5.1.2) ---------
New text: (Section 5.1.2)
---------
The sender of INIT chunks MAY include a 'Supported Address Types' parameter The sender of INIT chunks MAY include a 'Supported Address Types'
in the INIT to indicate what types of addresses are acceptable. parameter in the INIT to indicate what types of addresses are
acceptable.
3.42.3. Solution Description 3.42.3. Solution Description
The conflicting text has been removed. The conflicting text has been removed.
3.43. Integration of RFC 6096 3.43. Integration of RFC 6096
3.43.1. Description of the Problem 3.43.1. Description of the Problem
[RFC6096] updates [RFC4960] by adding a Chunk Flags Registry. This [RFC6096] updates [RFC4960] by adding a Chunk Flags Registry. This
skipping to change at page 66, line 21 skipping to change at page 66, line 22
The last chunk type (255) is reserved for future extension if The last chunk type (255) is reserved for future extension if
necessary. necessary.
--------- ---------
New text: (Section 14.1) New text: (Section 14.1)
--------- ---------
14.1. IETF-Defined Chunk Extension 14.1. IETF-Defined Chunk Extension
The assignment of new chunk type codes is done through an IETF Review The assignment of new chunk type codes is done through an IETF Review
action, as defined in [RFC5226]. Documentation of a new chunk MUST action, as defined in [RFC8126]. Documentation of a new chunk MUST
contain the following information: contain the following information:
a) A long and short name for the new chunk type; a) A long and short name for the new chunk type;
b) A detailed description of the structure of the chunk, which MUST b) A detailed description of the structure of the chunk, which MUST
conform to the basic structure defined in Section 3.2 of conform to the basic structure defined in Section 3.2 of
[RFC4960]; [RFC4960];
c) A detailed definition and description of the intended use of each c) A detailed definition and description of the intended use of each
field within the chunk, including the chunk flags if any. field within the chunk, including the chunk flags if any.
skipping to change at page 66, line 50 skipping to change at page 67, line 4
For each new chunk type, IANA creates a registration table for the For each new chunk type, IANA creates a registration table for the
chunk flags of that type. The procedure for registering particular chunk flags of that type. The procedure for registering particular
chunk flags is described in the following Section 14.2. chunk flags is described in the following Section 14.2.
--------- ---------
New text: (Section 14.2) New text: (Section 14.2)
--------- ---------
14.2. New IETF Chunk Flags Registration 14.2. New IETF Chunk Flags Registration
The assignment of new chunk flags is done through an RFC required The assignment of new chunk flags is done through an RFC required
action, as defined in [RFC5226]. Documentation of the chunk flags action, as defined in [RFC8126]. Documentation of the chunk flags
MUST contain the following information: MUST contain the following information:
a) A name for the new chunk flag; a) A name for the new chunk flag;
b) A detailed procedural description of the use of the new chunk b) A detailed procedural description of the use of the new chunk
flag within the operation of the protocol. It MUST be considered flag within the operation of the protocol. It MUST be considered
that implementations not supporting the flag will send '0' on that implementations not supporting the flag will send '0' on
transmit and just ignore it on receipt. transmit and just ignore it on receipt.
IANA selects a chunk flags value. This MUST be one of 0x01, 0x02, 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 0x04, 0x08, 0x10, 0x20, 0x40, or 0x80, which MUST be unique within
the chunk flag values for the specific chunk type. 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 Please note that Sections 14.2, 14.3, 14.4, and 14.5 need to be
renumbered. renumbered.
3.43.3. Solution Description 3.43.3. Solution Description
[RFC6096] was integrated. [RFC6096] was integrated and the reference updated to [RFC8126].
3.44. Integration of RFC 6335 3.44. Integration of RFC 6335
3.44.1. Description of the Problem 3.44.1. Description of the Problem
[RFC6335] updates [RFC4960] by updating Procedures for the Port [RFC6335] updates [RFC4960] by updating Procedures for the Port
Numbers Registry. This should be integrated into the base Numbers Registry. This should be integrated into the base
specification. While there, update the reference to the RFC giving specification. While there, update the reference to the RFC giving
guidelines for writing IANA sections to [RFC8126]. guidelines for writing IANA sections to [RFC8126].
skipping to change at page 72, line 30 skipping to change at page 72, line 32
3.46. CRC32c Code Improvements 3.46. CRC32c Code Improvements
3.46.1. Description of the Problem 3.46.1. Description of the Problem
The code given for the CRC32c computations uses types like long which The code given for the CRC32c computations uses types like long which
may have different length on different operating systems or may have different length on different operating systems or
processors. Therefore, the code is changed to use specific types processors. Therefore, the code is changed to use specific types
like uint32_t. like uint32_t.
While there, fix also some syntax errors. While there, fix also some syntax errors and a comment.
3.46.2. Text Changes to the Document 3.46.2. Text Changes to the Document
--------- ---------
Old text: (Appendix B) Old text: (Appendix B)
--------- ---------
/*************************************************************/
/* Note Definition for Ross Williams table generator would */
/* be: TB_WIDTH=4, TB_POLLY=0x1EDC6F41, TB_REVER=TRUE */
/* For Mr. Williams direct calculation code use the settings */
/* cm_width=32, cm_poly=0x1EDC6F41, cm_init=0xFFFFFFFF, */
/* cm_refin=TRUE, cm_refot=TRUE, cm_xorort=0x00000000 */
/*************************************************************/
/* Example of the crc table file */ /* Example of the crc table file */
#ifndef __crc32cr_table_h__ #ifndef __crc32cr_table_h__
#define __crc32cr_table_h__ #define __crc32cr_table_h__
#define CRC32C_POLY 0x1EDC6F41 #define CRC32C_POLY 0x1EDC6F41
#define CRC32C(c,d) (c=(c>>8)^crc_c[(c^(d))&0xFF]) #define CRC32C(c,d) (c=(c>>8)^crc_c[(c^(d))&0xFF])
unsigned long crc_c[256] = unsigned long crc_c[256] =
{ {
0x00000000L, 0xF26B8303L, 0xE13B70F7L, 0x1350F3F4L, 0x00000000L, 0xF26B8303L, 0xE13B70F7L, 0x1350F3F4L,
skipping to change at page 74, line 24 skipping to change at page 74, line 34
0x79B737BAL, 0x8BDCB4B9L, 0x988C474DL, 0x6AE7C44EL, 0x79B737BAL, 0x8BDCB4B9L, 0x988C474DL, 0x6AE7C44EL,
0xBE2DA0A5L, 0x4C4623A6L, 0x5F16D052L, 0xAD7D5351L, 0xBE2DA0A5L, 0x4C4623A6L, 0x5F16D052L, 0xAD7D5351L,
}; };
#endif #endif
--------- ---------
New text: (Appendix B) New text: (Appendix B)
--------- ---------
<CODE BEGINS>
/*************************************************************/
/* Note Definition for Ross Williams table generator would */
/* be: TB_WIDTH=4, TB_POLLY=0x1EDC6F41, TB_REVER=TRUE */
/* For Mr. Williams direct calculation code use the settings */
/* cm_width=32, cm_poly=0x1EDC6F41, cm_init=0xFFFFFFFF, */
/* cm_refin=TRUE, cm_refot=TRUE, cm_xorort=0x00000000 */
/*************************************************************/
/* Example of the crc table file */ /* Example of the crc table file */
#ifndef __crc32cr_h__ #ifndef __crc32cr_h__
#define __crc32cr_h__ #define __crc32cr_h__
#define CRC32C_POLY 0x1EDC6F41UL #define CRC32C_POLY 0x1EDC6F41UL
#define CRC32C(c,d) (c=(c>>8)^crc_c[(c^(d))&0xFF]) #define CRC32C(c,d) (c=(c>>8)^crc_c[(c^(d))&0xFF])
uint32_t crc_c[256] = uint32_t crc_c[256] =
{ {
0x00000000UL, 0xF26B8303UL, 0xE13B70F7UL, 0x1350F3F4UL, 0x00000000UL, 0xF26B8303UL, 0xE13B70F7UL, 0x1350F3F4UL,
skipping to change at page 81, line 23 skipping to change at page 81, line 42
result = ~crc32; result = ~crc32;
/* result now holds the negated polynomial remainder; /* result now holds the negated polynomial remainder;
* since the table and algorithm is "reflected" [williams95]. * since the table and algorithm is "reflected" [williams95].
* That is, result has the same value as if we mapped the message * That is, result has the same value as if we mapped the message
* to a polynomial, computed the host-bit-order polynomial * to a polynomial, computed the host-bit-order polynomial
* remainder, performed final negation, then did an end-for-end * remainder, performed final negation, then did an end-for-end
* bit-reversal. * bit-reversal.
* Note that a 32-bit bit-reversal is identical to four inplace * Note that a 32-bit bit-reversal is identical to four inplace
* 8-bit reversals followed by an end-for-end byteswap. * 8-bit reversals followed by an end-for-end byteswap.
* In other words, the bytes of each bit are in the right order, * 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 * but the bytes have been byteswapped. So we now do an explicit
* byteswap. On a little-endian machine, this byteswap and * byteswap. On a little-endian machine, this byteswap and
* the final ntohl cancel out and could be elided. * the final ntohl cancel out and could be elided.
*/ */
byte0 = result & 0xff; byte0 = result & 0xff;
byte1 = (result>>8) & 0xff; byte1 = (result>>8) & 0xff;
byte2 = (result>>16) & 0xff; byte2 = (result>>16) & 0xff;
byte3 = (result>>24) & 0xff; byte3 = (result>>24) & 0xff;
crc32 = ((byte0 << 24) | crc32 = ((byte0 << 24) |
skipping to change at page 82, line 19 skipping to change at page 82, line 39
uint32_t original_crc32; uint32_t original_crc32;
uint32_t crc32; uint32_t crc32;
/* save and zero checksum */ /* save and zero checksum */
message = (SCTP_message *)buffer; message = (SCTP_message *)buffer;
original_crc32 = ntohl(message->common_header.checksum); original_crc32 = ntohl(message->common_header.checksum);
message->common_header.checksum = 0L; message->common_header.checksum = 0L;
crc32 = generate_crc32c(buffer, length); crc32 = generate_crc32c(buffer, length);
return ((original_crc32 == crc32)? 1 : -1); return ((original_crc32 == crc32)? 1 : -1);
} }
<CODE ENDS>
3.46.3. Solution Description 3.46.3. Solution Description
The code was changed to use platform independent types. The code was changed to use platform independent types.
3.47. Clarification of Gap Ack Blocks in SACK Chunks 3.47. Clarification of Gap Ack Blocks in SACK Chunks
3.47.1. Description of the Problem 3.47.1. Description of the Problem
The Gap Ack Blocks in the SACK chunk are intended to be isolated. The Gap Ack Blocks in the SACK chunk are intended to be isolated.
However, this is not mentioned with normative text. However, this is not mentioned with normative text.
3.47.2. Text Changes to the Document 3.47.2. Text Changes to the Document
--------- ---------
Old text: (Section 3.3.4) Old text: (Section 3.3.4)
--------- ---------
skipping to change at page 82, line 50 skipping to change at page 83, line 28
acknowledged by Gap Ack Blocks are greater than the value of the acknowledged by Gap Ack Blocks are greater than the value of the
Cumulative TSN Ack. Cumulative TSN Ack.
--------- ---------
New text: (Section 3.3.4) New text: (Section 3.3.4)
--------- ---------
The SACK also contains zero or more Gap Ack Blocks. Each Gap Ack The SACK also contains zero or more Gap Ack Blocks. Each Gap Ack
Block acknowledges a subsequence of TSNs received following a break Block acknowledges a subsequence of TSNs received following a break
in the sequence of received TSNs. The Gap Ack Blocks SHOULD be isolated. 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 This means that the TSN just before each Gap Ack Block and the TSN just
each Gap Ack Block has not been received. By definition, all TSNs after each Gap Ack Block has not been received. By definition, all TSNs
acknowledged by Gap Ack Blocks are greater than the value of the acknowledged by Gap Ack Blocks are greater than the value of the
Cumulative TSN Ack. Cumulative TSN Ack.
--------- ---------
Old text: (Section 3.3.4) Old text: (Section 3.3.4)
--------- ---------
Gap Ack Blocks: Gap Ack Blocks:
These fields contain the Gap Ack Blocks. They are repeated for These fields contain the Gap Ack Blocks. They are repeated for
skipping to change at page 85, line 26 skipping to change at page 85, line 41
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3.49.3. Solution Description 3.49.3. Solution Description
The text has been updated to the one specified in [RFC8174]. The text has been updated to the one specified in [RFC8174].
3.50. Missed Text Removal
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)
---------
3.50.3. Solution Description
The text has finally been removed.
4. IANA Considerations 4. IANA Considerations
Section 3.44 of this document updates the port number registry for Section 3.44 of this document updates the port number registry for
SCTP to be consistent with [RFC6335]. IANA is requested to review SCTP to be consistent with [RFC6335]. IANA is requested to review
Section 3.44. Section 3.44.
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
The authors wish to thank Pontus Andersson, Eric W. Biederman, The authors wish to thank Pontus Andersson, Eric W. Biederman,
Cedric Bonnet, Gorry Fairhurst, Peter Lei, Lionel Morand, Jeff Cedric Bonnet, Spencer Dawkins, Gorry Fairhurst, Peter Lei, Gyula
Morriss, Karen E. E. Nielsen, Tom Petch, Kacheong Poon, Julien Marosi, Lionel Morand, Jeff Morriss, Karen E. E. Nielsen, Tom
Pourtet, Irene Ruengeler, Michael Welzl, and Qiaobing Xie for their Petch, Kacheong Poon, Julien Pourtet, Irene Ruengeler, Michael Welzl,
invaluable comments. and Qiaobing Xie for their invaluable 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,
<https://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,
<https://www.rfc-editor.org/info/rfc4960>. <https://www.rfc-editor.org/info/rfc4960>.
skipping to change at page 86, line 21 skipping to change at page 87, line 22
RFC 4960, DOI 10.17487/RFC4960, September 2007, RFC 4960, DOI 10.17487/RFC4960, September 2007,
<https://www.rfc-editor.org/info/rfc4960>. <https://www.rfc-editor.org/info/rfc4960>.
7.2. Informative References 7.2. Informative References
[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,
<https://www.rfc-editor.org/info/rfc1122>. <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., [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,
<https://www.rfc-editor.org/info/rfc2960>. <https://www.rfc-editor.org/info/rfc2960>.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP", of Explicit Congestion Notification (ECN) to IP",
RFC 3168, DOI 10.17487/RFC3168, September 2001, RFC 3168, DOI 10.17487/RFC3168, September 2001,
<https://www.rfc-editor.org/info/rfc3168>. <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,
<https://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,
<https://www.rfc-editor.org/info/rfc5681>. <https://www.rfc-editor.org/info/rfc5681>.
[RFC6096] Tuexen, M. and R. Stewart, "Stream Control Transmission [RFC6096] Tuexen, M. and R. Stewart, "Stream Control Transmission
Protocol (SCTP) Chunk Flags Registration", RFC 6096, Protocol (SCTP) Chunk Flags Registration", RFC 6096,
DOI 10.17487/RFC6096, January 2011, DOI 10.17487/RFC6096, January 2011,
<https://www.rfc-editor.org/info/rfc6096>. <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,
 End of changes. 103 change blocks. 
245 lines changed or deleted 344 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/