RFC Errata
Found 10 records.
Status: Verified (10)
RFC 4960, "Stream Control Transmission Protocol", September 2007
Note: This RFC has been obsoleted by RFC 9260
Note: This RFC has been updated by RFC 6096, RFC 6335, RFC 7053, RFC 8899
Source of RFC: tsvwg (wit)
Errata ID: 3788
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Karen Nielsen
Date Reported: 2013-11-06
Verifier Name: Martin Stiemerling
Date Verified: 2014-01-13
Section 8.1 says:
An endpoint shall keep a counter on the total number of consecutive retransmissions to its peer (this includes retransmissions to all the destination transport addresses of the peer if it is multi-homed), including unacknowledged HEARTBEAT chunks.
It should say:
An endpoint shall keep a counter on the total number of consecutive retransmissions to its peer (this includes data retransmissions to all the destination transport addresses of the peer if it is multi-homed),including the number of unacknowledged HEARTBEAT chunks observed on the path which currently is used for data transfer. Unacknowledged HEARTBEAT chunks observed on paths different from the path currently used for data transfer shall not increment the association error counter, as this could lead to association closure even if the path which currently is used for data transfer is available (but idle).
Notes:
RFC4960 Endpoint Failure detection mechanism is deficient in that
HB failures on some failing paths may take the association down, even
if other paths are working perfectly, but simply at the time no data
or HBs are being sent on the working paths.
The situation occurs when the association is idle
(no data is being transmitted) and the HBI settings on
the failing paths are much more aggressive than the HBI
set on the working paths. RFC6458 allows for specification
of the HBI on a per destination address whereby
such in-homogeneous setting of the HBI can occur.
The solution proposed to the issue is to demand that
HB failures observed on paths different from the path
currently used for data transfer do
not contribute to the association error counter.
HB failures observed on the path currently used for
data transfer, when this path is idle,
shall contribute to the association error counter.
Thereby supporting Endpoint Failure detection when the
association is idle. When the association is transmitting data,
the fate of the data transmissions and retransmissions
will serve to instantiate Endpoint Failure detection.
Errata ID: 1440
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Michael Tüxen
Date Reported: 2008-06-12
Verifier Name: Lars Eggert
Date Verified: 2008-07-16
Section 8.3 says:
When the value of this counter reaches the protocol parameter 'Path.Max.Retrans', the endpoint should mark the corresponding destination address as inactive if it is not so marked, and may also optionally report to the upper layer the change of reachability of this destination address. After this, the endpoint should continue HEARTBEAT on this destination address but should stop increasing the counter.
It should say:
When the value of this counter exceeds the protocol parameter 'Path.Max.Retrans', the endpoint should mark the corresponding destination address as inactive if it is not so marked, and may also optionally report to the upper layer the change of reachability of this destination address. After this, the endpoint should continue HEARTBEAT on this destination address but should stop increasing the counter.
Notes:
The path should be considered inactive, when the error counter exceeds
the threshold. This is stated correctly in 8.2.
Errata ID: 3423
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Pontus Andersson
Date Reported: 2012-12-01
Verifier Name: Martin Stiemerling
Date Verified: 2013-03-06
Section B says:
unsigned long
generate_crc32c(unsigned char *buffer, unsigned int length)
{
unsigned int i;
unsigned long crc32 = ~0L;
It should say:
unsigned long
generate_crc32c(unsigned char *buffer, unsigned int length)
{
unsigned int i;
unsigned long crc32 = 0xffffffffL;
Notes:
The remainder register (crc32) should be initialized to 0xffffffffL rather than ~0L, for correct operation on platforms where unisigned long is longer than 32 bits. I.e., 64-bit platforms.
Errata ID: 4400
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Julien Pourtet
Date Reported: 2015-06-25
Verifier Name: Martin Stiemerling
Date Verified: 2015-07-16
Section 5.1.6. says:
/-- INIT ACK [Veri Tag=Tag_A,
/ I-Tag=Tag_Z,
(Cancel T1-init timer) <------/ Cookie_Z, & other info]
(destroy temp TCB)
COOKIE ECHO [Cookie_Z] ------\
(Start T1-init timer) \
(Enter COOKIE-ECHOED state) \---> (build TCB enter ESTABLISHED
state)
/---- COOKIE-ACK
/
(Cancel T1-init timer, <-----/
It should say:
/-- INIT ACK [Veri Tag=Tag_A,
/ I-Tag=Tag_Z,
(Cancel T1-init timer) <------/ Cookie_Z, & other info]
(destroy temp TCB)
COOKIE ECHO [Cookie_Z] ------\
(Start T1-cookie timer) \
(Enter COOKIE-ECHOED state) \---> (build TCB enter ESTABLISHED
state)
/---- COOKIE-ACK
/
(Cancel T1-cookie timer, <---/
Notes:
Upon reception of an INIT ACK Endpoint A should start the T1-cookie timer, not the T1-init timer. Reception of a COOKIE-ACK cancels The T1-cookie timer, not the T1-init timer.
Errata ID: 4656
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Lionel Morand
Date Reported: 2016-04-06
Verifier Name: Spencer Dawkins
Date Verified: 2018-07-10
Throughout the document, when it says:
6.2. Acknowledgement on Reception of DATA Chunks
The SCTP endpoint MUST always acknowledge the reception of each valid
DATA chunk when the DATA chunk received is inside its receive window.
When the receiver's advertised window is 0, the receiver MUST drop
any new incoming DATA chunk with a TSN larger than the largest TSN
received so far. If the new incoming DATA chunk holds a TSN value
less than the largest TSN received so far, then the receiver SHOULD
drop the largest TSN held for reordering and accept the new incoming
DATA chunk. In either case, if such a DATA chunk is dropped, the
receiver MUST immediately send back a SACK with the current receive
window showing only DATA chunks received and accepted so far. The
dropped DATA chunk(s) MUST NOT be included in the SACK, as they were
not accepted. The receiver MUST also have an algorithm for
advertising its receive window to avoid receiver silly window
syndrome (SWS), as described in [RFC0813]. The algorithm can be
similar to the one described in Section 4.2.3.3 of [RFC1122].
The guidelines on delayed acknowledgement algorithm specified in
Section 4.2 of [RFC2581] SHOULD be followed. Specifically, an
acknowledgement SHOULD be generated for at least every second packet
(not every second DATA chunk) received, and SHOULD be generated
within 200 ms of the arrival of any unacknowledged DATA chunk. In
some situations, it may be beneficial for an SCTP transmitter to be
more conservative than the algorithms detailed in this document
allow. However, an SCTP transmitter MUST NOT be more aggressive than
the following algorithms allow.
An SCTP receiver MUST NOT generate more than one SACK for every
incoming packet, other than to update the offered window as the
receiving application consumes new data.
IMPLEMENTATION NOTE: The maximum delay for generating an
acknowledgement may be configured by the SCTP administrator, either
statically or dynamically, in order to meet the specific timing
requirement of the protocol being carried.
An implementation MUST NOT allow the maximum delay to be configured
to be more than 500 ms. In other words, an implementation MAY lower
this value below 500 ms but MUST NOT raise it above 500 ms.
[ remaining of the section unchanged ]
***********************************************************************
15. Suggested SCTP Protocol Parameter Values
The following protocol parameters are RECOMMENDED:
RTO.Initial - 3 seconds
RTO.Min - 1 second
RTO.Max - 60 seconds
Max.Burst - 4
RTO.Alpha - 1/8
RTO.Beta - 1/4
Valid.Cookie.Life - 60 seconds
Association.Max.Retrans - 10 attempts
Path.Max.Retrans - 5 attempts (per destination address)
Max.Init.Retransmits - 8 attempts
HB.interval - 30 seconds
HB.Max.Burst - 1
IMPLEMENTATION NOTE: The SCTP implementation may allow ULP to
customize some of these protocol parameters (see Section 10).
Note: RTO.Min SHOULD be set as recommended above.
It should say:
6.2. Acknowledgement on Reception of DATA Chunks
The SCTP endpoint MUST always acknowledge the reception of each valid
DATA chunk when the DATA chunk received is inside its receive window.
When the receiver's advertised window is 0, the receiver MUST drop
any new incoming DATA chunk with a TSN larger than the largest TSN
received so far. If the new incoming DATA chunk holds a TSN value
less than the largest TSN received so far, then the receiver SHOULD
drop the largest TSN held for reordering and accept the new incoming
DATA chunk. In either case, if such a DATA chunk is dropped, the
receiver MUST immediately send back a SACK with the current receive
window showing only DATA chunks received and accepted so far. The
dropped DATA chunk(s) MUST NOT be included in the SACK, as they were
not accepted. The receiver MUST also have an algorithm for
advertising its receive window to avoid receiver silly window
syndrome (SWS), as described in [RFC0813]. The algorithm can be
similar to the one described in Section 4.2.3.3 of [RFC1122].
The guidelines on delayed acknowledgement algorithm specified in
Section 4.2 of [RFC2581] SHOULD be followed. Specifically, an
acknowledgement SHOULD be generated for at least every second packet
(not every second DATA chunk) received, and SHOULD be generated
within 200 ms of the arrival of any unacknowledged DATA chunk. In
some situations, it may be beneficial for an SCTP transmitter to be
more conservative than the algorithms detailed in this document
allow. However, an SCTP transmitter MUST NOT be more aggressive than
the following algorithms allow.
An SCTP receiver MUST NOT generate more than one SACK for every
incoming packet, other than to update the offered window as the
receiving application consumes new data.
IMPLEMENTATION NOTE: The maximum delay for generating an
acknowledgement may be configured by the SCTP administrator, either
statically or dynamically, in order to meet the specific timing
requirement of the protocol being carried.
An implementation MUST NOT allow the maximum delay (protocol
parameter 'SACK.Delay') to be configured to be more than 500 ms.
In other words, an implementation MAY lower the value of
'SACK.Delay' below 500 ms but MUST NOT raise it above 500 ms.
[ remaining of the section unchanged ]
***********************************************************************
15. Suggested SCTP Protocol Parameter Values
The following protocol parameters are RECOMMENDED:
RTO.Initial - 3 seconds
RTO.Min - 1 second
RTO.Max - 60 seconds
Max.Burst - 4
RTO.Alpha - 1/8
RTO.Beta - 1/4
Valid.Cookie.Life - 60 seconds
Association.Max.Retrans - 10 attempts
Path.Max.Retrans - 5 attempts (per destination address)
Max.Init.Retransmits - 8 attempts
HB.interval - 30 seconds
HB.Max.Burst - 1
SACK.Delay - 200 milliseconds
IMPLEMENTATION NOTE: The SCTP implementation may allow ULP to
customize some of these protocol parameters (see Section 10).
Note: RTO.Min SHOULD be set as recommended above.
Notes:
In section 6.2, the name 'SACK.Delay' is given to the protocol parameter that indicate themaximum delay for generating a SACK.
In section 15, the list of SCTP protocol parameters and associated recommended value is not complete. The maximum delay for generating an acknowledgement ('SACK.Delay') is missing from this list.
Errata ID: 5202
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Nicholas Wilson
Date Reported: 2017-12-13
Verifier Name: Spencer Dawkins
Date Verified: 2018-07-10
Section 3.3.4. says:
The SACK also contains zero or more Gap Ack Blocks. Each Gap Ack Block acknowledges a subsequence of TSNs received following a break in the sequence of received TSNs. By definition, all TSNs acknowledged by Gap Ack Blocks are greater than the value of the Cumulative TSN Ack.
It should say:
The SACK also contains zero or more Gap Ack Blocks. Each Gap Ack Block acknowledges a subsequence of TSNs received following a break in the sequence of received TSNs. By definition, all TSNs acknowledged by Gap Ack Blocks are greater than the value of the Cumulative TSN Ack. The sequence of Gap Ack Blocks MUST be an increasing sequence of ranges, non-intersecting, and with at least one TSN as a gap between each Block and between the Cumulative TSN Ack and the first Block.
Notes:
It seems clear that the Gap Ack sequence must be sent in its "canonical" form (monotonic non-overlapping ranges) but I can't find anywhere where this is actually stated.
It is implied (but not stated) by the following sentence on the next page, which implies that there is no freedom of choice in how the Gap Ack sequence is encoded:
"For example, assume that ...
then the parameter part of the SACK MUST be constructed as follows"
Verifier Notes:
This errata suggests two corrections:
(1) Ensure that the gap ack blocks are not overlapping.
(2) Ensure that the gap ack blocks are monotonic.
Subsequent discussion in TSVWG, as documented in
https://tools.ietf.org/html/draft-ietf-tsvwg-rfc4960-errata-06#section-3.47,
has converged on this resolution:
* The intention actually was to have the gap blocks isolated. So (1) ought
to be included in the next revision of SCTP.
* In some cases gap blocks might not be monotonic. This is the same as with
the handling of gap reports in TCP SACK. Therefore (2) ought not be
included in the next revision of SCTP.
Errata ID: 1574
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Randall Stewart
Date Reported: 2008-10-14
Verifier Name: Magnus Westerlund
Date Verified: 2009-04-03
Section 9.2 says:
Once an endpoint has reached the SHUTDOWN-RECEIVED state, it MUST NOT send a SHUTDOWN in response to a ULP request, and should discard subsequent SHUTDOWN chunks.
It should say:
Once an endpoint has reached the SHUTDOWN-RECEIVED state, it MUST NOT send a SHUTDOWN in response to a ULP request, and should discard subsequent ULP shutdown requests.
Notes:
The text never intended the SCTP endpoint to ignore SHUTDOWN
chunks from its peer. If it did the endpoints could never gracefully
terminate a associations in some cases.
Errata ID: 2592
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: tom petch
Date Reported: 2010-10-29
Verifier Name: Lars Eggert
Date Verified: 2010-10-31
Section 14.1 says:
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:
It should say:
14.1. IETF-Defined Chunk Extension The assignment of new chunk type codes is done through an IETF Consensus action, as defined in [RFC2434]. Documentation of the chunk type MUST contain the following information:
Notes:
The OLD text relates to parameter types, and not chunk types, and already appears, correctly, in section 14.2. Section 14.1 is about chunk types,as the NEW text says.
Errata ID: 5003
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Max Mattes
Date Reported: 2017-04-24
Verifier Name: Spencer Dawkins
Date Verified: 2018-07-10
Section 10.1 says:
o Receive Unacknowledged Message
Format: RECEIVE_UNACKED(data retrieval id, buffer address, buffer
size, [,stream id] [, stream sequence number] [,partial
flag] [,payload protocol-id])
It should say:
O) Receive Unacknowledged Message
Format: RECEIVE_UNACKED(data retrieval id, buffer address, buffer
size, [,stream id] [, stream sequence number] [,partial
flag] [,payload protocol-id])
Notes:
This is part of a lettered list of items, and surrounding sublists use lowercase "o" as a bullet. This item appears to have been mis-corrected to an "o" sublist item when it should be item "O)" of the primary list, as evidenced by the preceding item "N)" and following "P)"
Errata ID: 5957
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Földvári Zoltán
Date Reported: 2020-01-13
Verifier Name: Mirja Kühlewind
Date Verified: 2020-01-13
Section 10.1 says:
D) Abort
Format: ABORT(association id [, Upper Layer Abort Reason]) ->
result
Ungracefully closes an association. Any locally queued user data
will be discarded, and an ABORT chunk is sent to the peer. A success
code will be returned on successful abort of the association. If
attempting to abort the association results in a failure, an error
code shall be returned.
Mandatory attributes:
o association id - local handle to the SCTP association.
Optional attributes:
o Upper Layer Abort Reason - reason of the abort to be passed to the
peer.
None.
It should say:
D) Abort
Format: ABORT(association id [, Upper Layer Abort Reason]) ->
result
Ungracefully closes an association. Any locally queued user data
will be discarded, and an ABORT chunk is sent to the peer. A success
code will be returned on successful abort of the association. If
attempting to abort the association results in a failure, an error
code shall be returned.
Mandatory attributes:
o association id - local handle to the SCTP association.
Optional attributes:
o Upper Layer Abort Reason - reason of the abort to be passed to the
peer.
Notes:
There is an extra "None." at the end but it is not necessary because there is an optional attribute.