RFC Errata
Found 14 records.
Status: Verified (6)
RFC 6458, "Sockets API Extensions for the Stream Control Transmission Protocol (SCTP)", December 2011
Source of RFC: tsvwg (wit)
Errata ID: 6111
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Michael Tuexen
Date Reported: 2020-04-20
Verifier Name: Martin Duke
Date Verified: 2020-04-27
Throughout the document, when it says:
in Section 5.3.2
SCTP_EOF: Setting this flag invokes the SCTP graceful shutdown
procedure on the specified association. Graceful shutdown
assures that all data queued by both endpoints is
successfully transmitted before closing the association.
SCTP_SENDALL: This flag, if set, will cause a one-to-many
style socket to send the message to all associations that
are currently established on this socket. For the one-to-
one style socket, this flag has no effect.
in Section 5.3.4
SCTP_EOF: Setting this flag invokes the SCTP graceful shutdown
procedures on the specified association. Graceful shutdown
assures that all data queued by both endpoints is successfully
transmitted before closing the association.
SCTP_SENDALL: This flag, if set, will cause a one-to-many style
socket to send the message to all associations that are
currently established on this socket. For the one-to-one style
socket, this flag has no effect.
in Section 8.1.13
The sinfo_flags field is composed of a bitwise OR
of SCTP_UNORDERED, SCTP_EOF, and SCTP_SENDALL.
in Section 8.1.31
The snd_flags parameter is composed of a bitwise OR
of SCTP_UNORDERED, SCTP_EOF, and SCTP_SENDALL.
It should say:
in Section 5.3.2
SCTP_EOF: Setting this flag invokes the SCTP graceful shutdown
procedure on the specified association. Graceful shutdown
assures that all data queued by both endpoints is
successfully transmitted before closing the association.
SCTP_EOR: This flag, if set and explicit EOR marking (see
Section 8.1.26) is enabled , indicates that the user data
provided is the last part of a user message. If explicit
EOR marking is disabled, this flag is not relevant, since the
user data provided is a complete user message.
SCTP_SENDALL: This flag, if set, will cause a one-to-many
style socket to send the message to all associations that
are currently established on this socket. For the one-to-
one style socket, this flag has no effect.
in Section 5.3.4
SCTP_EOF: Setting this flag invokes the SCTP graceful shutdown
procedures on the specified association. Graceful shutdown
assures that all data queued by both endpoints is successfully
transmitted before closing the association.
SCTP_EOR: This flag, if set and explicit EOR marking (see Section 8.1.26)
is enabled , indicates that the user data provided is the last part of
a user message. If explicit EOR marking is disabled, this flag is
not relevant, since the user data provided is a complete user message.
SCTP_SENDALL: This flag, if set, will cause a one-to-many style
socket to send the message to all associations that are
currently established on this socket. For the one-to-one style
socket, this flag has no effect.
in Section 8.1.13
The sinfo_flags field is composed of a bitwise OR
of SCTP_UNORDERED, SCTP_EOF, SCTP_EOR, and SCTP_SENDALL.
in Section 8.1.31
The snd_flags parameter is composed of a bitwise OR
of SCTP_UNORDERED, SCTP_EOF, SCTP_EOR, and SCTP_SENDALL.
Notes:
The text is missing a description of how to use the SCTP_EOR flag in the Socket API. The problem was initially reported by wanglihe in https://www.rfc-editor.org/errata/eid6081
Errata ID: 6115
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Michael Tuexen
Date Reported: 2020-04-20
Verifier Name: Martin Duke
Date Verified: 2020-04-27
Section 8.2.1 says:
sstat_state: This contains the association's current state, i.e.,
one of the following values:
* SCTP_CLOSED
* SCTP_BOUND
* SCTP_LISTEN
* SCTP_COOKIE_WAIT
* SCTP_COOKIE_ECHOED
* SCTP_ESTABLISHED
* SCTP_SHUTDOWN_PENDING
* SCTP_SHUTDOWN_SENT
* SCTP_SHUTDOWN_RECEIVED
* SCTP_SHUTDOWN_ACK_SENT
It should say:
sstat_state: This contains the association's current state, i.e.,
one of the following values:
* SCTP_CLOSED
* SCTP_LISTEN
* SCTP_COOKIE_WAIT
* SCTP_COOKIE_ECHOED
* SCTP_ESTABLISHED
* SCTP_SHUTDOWN_PENDING
* SCTP_SHUTDOWN_SENT
* SCTP_SHUTDOWN_RECEIVED
* SCTP_SHUTDOWN_ACK_SENT
Notes:
SCTP_BOUND is not a state of an SCTP association, so it should not be part of this list.
Errata ID: 6112
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Michael Tuexen
Date Reported: 2020-04-20
Verifier Name: Martin Duke
Date Verified: 2020-04-27
Section 3.2 says:
The success or failure of sending the data message (with possible SCTP_INITMSG ancillary data) will be signaled by the SCTP_ASSOC_CHANGE event with SCTP_COMM_UP or SCTP_CANT_START_ASSOC. If user data could not be sent (due to an SCTP_CANT_START_ASSOC), the sender will also receive an SCTP_SEND_FAILED_EVENT event.
It should say:
The success or failure of sending the data message (with possible SCTP_INITMSG ancillary data) will be signaled by the SCTP_ASSOC_CHANGE event with SCTP_COMM_UP or SCTP_CANT_STR_ASSOC. If user data could not be sent (due to an SCTP_CANT_STR_ASSOC), the sender will also receive an SCTP_SEND_FAILED_EVENT event.
Notes:
The constant SCTP_CANT_START_ASSOC is not defined. The correct name is SCTP_CANT_STR_ASSOC.
Errata ID: 6980
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Michael Tüxen
Date Reported: 2022-05-24
Verifier Name: RFC Editor
Date Verified: 2022-05-24
Section 8 says:
The field opt specifies which SCTP socket option to get. It can get any socket option currently supported that requests information (either read/write options or read-only) such as SCTP_RTOINFO SCTP_ASSOCINFO SCTP_PRIMARY_ADDR SCTP_PEER_ADDR_PARAMS SCTP_DEFAULT_SEND_PARAM SCTP_MAX_SEG SCTP_AUTH_ACTIVE_KEY SCTP_DELAYED_SACK SCTP_MAX_BURST SCTP_CONTEXT SCTP_EVENT SCTP_DEFAULT_SNDINFO SCTP_DEFAULT_PRINFO SCTP_STATUS SCTP_GET_PEER_ADDR_INFO SCTP_PEER_AUTH_CHUNKS SCTP_LOCAL_AUTH_CHUNKS
It should say:
The field opt specifies which SCTP socket option to get. It can get any socket option currently supported that requests information (either read/write options or read-only) such as SCTP_RTOINFO SCTP_ASSOCINFO SCTP_PRIMARY_ADDR SCTP_PEER_ADDR_PARAMS SCTP_DEFAULT_SEND_PARAM SCTP_MAXSEG SCTP_AUTH_ACTIVE_KEY SCTP_DELAYED_SACK SCTP_MAX_BURST SCTP_CONTEXT SCTP_EVENT SCTP_DEFAULT_SNDINFO SCTP_DEFAULT_PRINFO SCTP_STATUS SCTP_GET_PEER_ADDR_INFO SCTP_PEER_AUTH_CHUNKS SCTP_LOCAL_AUTH_CHUNKS
Notes:
The constant SCTP_MAX_SEG is not defined. It should be SCTP_MAXSEG.
Errata ID: 7547
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Michael Tüxen
Date Reported: 2023-06-22
Verifier Name: RFC Editor
Date Verified: 2023-06-22
Section 9.12 says:
info: A pointer to the buffer containing the attribute associated with the message to be sent. The type is indicated by the info_type parameter.
It should say:
info: A pointer to the buffer containing the attribute associated with the message to be sent. The type is indicated by the infotype parameter.
Notes:
The name of the parameter is infotype, not info_type.
Thanks to Philipp Stanner for making me aware of this issue.
Errata ID: 7548
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Michael Tüxen
Date Reported: 2023-06-22
Verifier Name: RFC Editor
Date Verified: 2023-06-22
Section 9.1 says:
info: A pointer to the buffer to hold the attributes of the received
message. The structure type of info is determined by the
info_type parameter.
infolen: An in/out parameter describing the size of the info buffer.
infotype: On return, *info_type is set to the type of the info
buffer. The current defined values are as follows:
SCTP_RECVV_NOINFO: If both SCTP_RECVRCVINFO and SCTP_RECVNXTINFO
options are not enabled, no attribute will be returned. If
only the SCTP_RECVNXTINFO option is enabled but there is no
next message in the buffer, no attribute will be returned. In
these cases, *info_type will be set to SCTP_RECVV_NOINFO.
It should say:
info: A pointer to the buffer to hold the attributes of the received
message. The structure type of info is determined by the
infotype parameter.
infolen: An in/out parameter describing the size of the info buffer.
infotype: On return, *infotype is set to the type of the info
buffer. The current defined values are as follows:
SCTP_RECVV_NOINFO: If both SCTP_RECVRCVINFO and SCTP_RECVNXTINFO
options are not enabled, no attribute will be returned. If
only the SCTP_RECVNXTINFO option is enabled but there is no
next message in the buffer, no attribute will be returned. In
these cases, *infotype will be set to SCTP_RECVV_NOINFO.
Notes:
The name of the parameter is infotype, not info_type.
Thanks to Philipp Stanner for making me aware of this issue.
Status: Held for Document Update (4)
RFC 6458, "Sockets API Extensions for the Stream Control Transmission Protocol (SCTP)", December 2011
Source of RFC: tsvwg (wit)
Errata ID: 4921
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Jonathan Leighton
Date Reported: 2017-02-02
Held for Document Update by: Martin Duke
Date Held: 2020-04-27
Section 9.1 says:
If sd is an IPv4 socket, the addresses passed must be IPv4 addresses. If the sd is an IPv6 socket, the addresses passed can either be IPv4 or IPv6 addresses.
It should say:
If sd is an IPv4 socket, the passed addresses must be IPv4 addresses. If sd is an IPv6 socket, the passed addresses must be IPv6 addresses. Use IPv4-mapped IPv6 addresses to bind an IPv6 socket to an IPv4 address. Note that some implementations optionally allow IPv4 addresses to be passed in directly.
Notes:
The erratum is a subtle change in meaning that would be a useful clarification.
Errata ID: 6116
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Michael Tuexen
Date Reported: 2020-04-20
Held for Document Update by: Martin Duke
Date Held: 2020-04-27
Section 6.1.2 says:
spc_state: This field holds one of a number of values that
communicate the event that happened to the address. They include
SCTP_ADDR_AVAILABLE: This address is now reachable. This
notification is provided whenever an address becomes reachable.
SCTP_ADDR_UNREACHABLE: The address specified can no longer be
reached. Any data sent to this address is rerouted to an
alternate until this address becomes reachable. This
notification is provided whenever an address becomes
unreachable.
SCTP_ADDR_REMOVED: The address is no longer part of the
association.
SCTP_ADDR_ADDED: The address is now part of the association.
SCTP_ADDR_MADE_PRIM: This address has now been made the primary
destination address. This notification is provided whenever an
address is made primary.
It should say:
spc_state: This field holds one of a number of values that
communicate the event that happened to the address. They include
SCTP_ADDR_CONFIRMED: This address is now confirmed. This
notification is provided once an address transitions from
the UNCONFIRMED state to the CONFIRMED state (see
Section 5.4 of [RFC 4960]).
SCTP_ADDR_AVAILABLE: This address is now reachable. This
notification is provided whenever an address becomes reachable.
SCTP_ADDR_UNREACHABLE: The address specified can no longer be
reached. Any data sent to this address is rerouted to an
alternate until this address becomes reachable. This
notification is provided whenever an address becomes
unreachable.
SCTP_ADDR_REMOVED: The address is no longer part of the
association.
SCTP_ADDR_ADDED: The address is now part of the association.
SCTP_ADDR_MADE_PRIM: This address has now been made the primary
destination address. This notification is provided whenever an
address is made primary.
Notes:
A description of the handling of the path verification as specified in Section 5.4 of RFC 4960 was missing.
Errata ID: 6113
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Michael Tuexen
Date Reported: 2020-04-20
Held for Document Update by: Martin Duke
Date Held: 2020-04-27
Section 6.1.1 says:
sac_info: If sac_state is SCTP_COMM_LOST and an ABORT chunk was
received for this association, sac_info[] contains the complete
ABORT chunk as defined in Section 3.3.7 of the SCTP specification
[RFC4960].
It should say:
sac_info: If sac_state is SCTP_COMM_LOST or SCTP_CANT_STR_ASSOC and
an ABORT chunk was received for this association, sac_info[]
contains the complete ABORT chunk as defined in Section 3.3.7
of the SCTP specification [RFC4960].
Notes:
During association setup, SCTP_CANT_STR_ASSOC is signalled when an ABORT chunk is received. SCTP_COMM_LOST is used after the association has been established.
Errata ID: 6114
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Michael Tuexen
Date Reported: 2020-04-20
Held for Document Update by: Martin Duke
Date Held: 2020-04-27
Section 9.5 says:
If the id field is set to the value '0', then the locally bound addresses are returned without regard to any particular association.
It should say:
If the id field is set to the value SCTP_FUTURE_ASSOC, then the locally bound addresses are returned without regard to any particular association.
Notes:
Don't use a numeric constant, but the symbolic constant. Its numeric value is implementation specific.
Status: Rejected (4)
RFC 6458, "Sockets API Extensions for the Stream Control Transmission Protocol (SCTP)", December 2011
Source of RFC: tsvwg (wit)
Errata ID: 6081
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: wanglihe
Date Reported: 2020-04-09
Rejected by: Martin Duke
Date Rejected: 2020-04-27
Throughout the document, when it says:
8.1.26 must indicate that they are
finished sending a particular record by including the SCTP_EOR flag.
but I can not find where to use SCTP_EOR flag.
because
5.1 The msg_flags are not used when sending a message with sendmsg().
3.1.4 flags: No new flags are defined for SCTP at this level. See
Section 5 for SCTP-specific flags used in the msghdr structure.
4.1.8 same with 3.1.4
9.10, 9.12 flags: The same flags as used by the sendmsg() call flags (e.g.,
MSG_DONTROUTE).
9.7 flags: The same as sinfo_flags (see Section 5.3.2).
5.3.2 sinfo_flags not mention about it
It should say:
maybe msg_flags should be used.
Notes:
Another problem is that, I think it should be discuss about debfine a flag like SCTP_BOR for beginning(init chunk) of a Record, because a stream of this socket(assoc) can still be used after send a SCTP_EOR.
And between a init chunk and a STCP_EOR, if I change SCTP_EXPLICIT_EOR status, what the socket will send the message?
--VERIFIER NOTES--
6111 addresses the same problem and has a more actionable recommendation.
Errata ID: 6131
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: wanglihe
Date Reported: 2020-04-09
Rejected by: Martin Duke
Date Rejected: 2020-04-27
Throughout the document, when it says:
8.1.26 must indicate that they are
finished sending a particular record by including the SCTP_EOR flag.
but I can not find where to use SCTP_EOR flag.
because
5.1 The msg_flags are not used when sending a message with sendmsg().
3.1.4 flags: No new flags are defined for SCTP at this level. See
Section 5 for SCTP-specific flags used in the msghdr structure.
4.1.8 same with 3.1.4
9.10, 9.12 flags: The same flags as used by the sendmsg() call flags (e.g.,
MSG_DONTROUTE).
9.7 flags: The same as sinfo_flags (see Section 5.3.2).
5.3.2 sinfo_flags not mention about it
It should say:
maybe msg_flags should be used.
Notes:
Another problem is that, I think it should be discuss about debfine a flag like SCTP_BOR for beginning(init chunk) of a Record, because a stream of this socket(assoc) can still be used after send a SCTP_EOR.
And between a init chunk and a STCP_EOR, if I change SCTP_EXPLICIT_EOR status, what the socket will send the message?
--VERIFIER NOTES--
This is an accidental duplication; please disregard.
Errata ID: 6132
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: wanglihe
Date Reported: 2020-04-09
Rejected by: Martin Duke
Date Rejected: 2020-04-27
Throughout the document, when it says:
8.1.26 must indicate that they are
finished sending a particular record by including the SCTP_EOR flag.
but I can not find where to use SCTP_EOR flag.
because
5.1 The msg_flags are not used when sending a message with sendmsg().
3.1.4 flags: No new flags are defined for SCTP at this level. See
Section 5 for SCTP-specific flags used in the msghdr structure.
4.1.8 same with 3.1.4
9.10, 9.12 flags: The same flags as used by the sendmsg() call flags (e.g.,
MSG_DONTROUTE).
9.7 flags: The same as sinfo_flags (see Section 5.3.2).
5.3.2 sinfo_flags not mention about it
It should say:
maybe msg_flags should be used.
Notes:
Another problem is that, I think it should be discuss about debfine a flag like SCTP_BOR for beginning(init chunk) of a Record, because a stream of this socket(assoc) can still be used after send a SCTP_EOR.
And between a init chunk and a STCP_EOR, if I change SCTP_EXPLICIT_EOR status, what the socket will send the message?
--VERIFIER NOTES--
Accidental duplication; please disregard.
Errata ID: 6133
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: wanglihe
Date Reported: 2020-04-09
Rejected by: Martin Duke
Date Rejected: 2020-04-27
Throughout the document, when it says:
8.1.26 must indicate that they are
finished sending a particular record by including the SCTP_EOR flag.
but I can not find where to use SCTP_EOR flag.
because
5.1 The msg_flags are not used when sending a message with sendmsg().
3.1.4 flags: No new flags are defined for SCTP at this level. See
Section 5 for SCTP-specific flags used in the msghdr structure.
4.1.8 same with 3.1.4
9.10, 9.12 flags: The same flags as used by the sendmsg() call flags (e.g.,
MSG_DONTROUTE).
9.7 flags: The same as sinfo_flags (see Section 5.3.2).
5.3.2 sinfo_flags not mention about it
It should say:
maybe msg_flags should be used.
Notes:
Another problem is that, I think it should be discuss about debfine a flag like SCTP_BOR for beginning(init chunk) of a Record, because a stream of this socket(assoc) can still be used after send a SCTP_EOR.
And between a init chunk and a STCP_EOR, if I change SCTP_EXPLICIT_EOR status, what the socket will send the message?
--VERIFIER NOTES--
Accidental duplicate, please disregard.