Squashed 'third_party/lksctp-tools/' content from commit 200eca7f1
Change-Id: I8f7575513f114b205178cac5c6b3706f3d725cb5
git-subtree-dir: third_party/lksctp-tools
git-subtree-split: 200eca7f1419b1ae53958b51e8551f7e7f6cd467
diff --git a/doc/rfc4460.txt b/doc/rfc4460.txt
new file mode 100644
index 0000000..1345b19
--- /dev/null
+++ b/doc/rfc4460.txt
@@ -0,0 +1,6107 @@
+
+
+
+
+
+
+Network Working Group R. Stewart
+Request for Comments: 4460 Cisco Systems, Inc.
+Category: Informational I. Arias-Rodriguez
+ Nokia Research Center
+ K. Poon
+ Sun Microsystems, Inc.
+ A. Caro
+ BBN Technologies
+ M. Tuexen
+ Muenster Univ. of Applied Sciences
+ April 2006
+
+
+ Stream Control Transmission Protocol (SCTP) Specification
+ Errata and Issues
+
+
+Status of This Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2006).
+
+Abstract
+
+ This document is a compilation of issues found during six
+ interoperability events and 5 years of experience with implementing,
+ testing, and using Stream Control Transmission Protocol (SCTP) along
+ with the suggested fixes. This document provides deltas to RFC 2960
+ and is organized in a time-based way. The issues are listed in the
+ order they were brought up. Because some text is changed several
+ times, the last delta in the text is the one that should be applied.
+ In addition to the delta, a description of the problem and the
+ details of the solution are also provided.
+
+Table of Contents
+
+ 1. Introduction ....................................................6
+ 1.1. Conventions ................................................7
+ 2. Corrections to RFC 2960 .........................................7
+ 2.1. Incorrect Error Type During Chunk Processing. ..............7
+ 2.1.1. Description of the Problem ..........................7
+ 2.1.2. Text changes to the document ........................7
+ 2.1.3. Solution Description ................................7
+
+
+
+Stewart, et al. Informational [Page 1]
+
+RFC 4460 SCTP Errata April 2006
+
+
+ 2.2. Parameter Processing Issue .................................7
+ 2.2.1. Description of the Problem ..........................7
+ 2.2.2. Text Changes to the Document ........................8
+ 2.2.3. Solution Description ................................8
+ 2.3. Padding Issues .............................................8
+ 2.3.1. Description of the Problem ..........................8
+ 2.3.2. Text Changes to the Document ........................9
+ 2.3.3. Solution Description ...............................10
+ 2.4. Parameter Types across All Chunk Types ....................10
+ 2.4.1. Description of the Problem .........................10
+ 2.4.2. Text Changes to the Document .......................10
+ 2.4.3. Solution Description ...............................12
+ 2.5. Stream Parameter Clarification ............................12
+ 2.5.1. Description of the problem .........................12
+ 2.5.2. Text Changes to the Document .......................12
+ 2.5.3. Solution Description ...............................13
+ 2.6. Restarting Association Security Issue .....................13
+ 2.6.1. Description of the Problem .........................13
+ 2.6.2. Text Changes to the Document .......................14
+ 2.6.3. Solution Description ...............................18
+ 2.7. Implicit Ability to Exceed cwnd by PMTU-1 Bytes ...........19
+ 2.7.1. Description of the Problem .........................19
+ 2.7.2. Text Changes to the Document .......................19
+ 2.7.3. Solution Description ...............................19
+ 2.8. Issues with Fast Retransmit ...............................19
+ 2.8.1. Description of the Problem .........................19
+ 2.8.2. Text Changes to the Document .......................20
+ 2.8.3. Solution Description ...............................23
+ 2.9. Missing Statement about partial_bytes_acked Update ........24
+ 2.9.1. Description of the Problem .........................24
+ 2.9.2. Text Changes to the Document .......................24
+ 2.9.3. Solution Description ...............................25
+ 2.10. Issues with Heartbeating and Failure Detection ...........25
+ 2.10.1. Description of the Problem ........................25
+ 2.10.2. Text Changes to the Document ......................26
+ 2.10.3. Solution Description ..............................28
+ 2.11. Security interactions with firewalls .....................29
+ 2.11.1. Description of the Problem ........................29
+ 2.11.2. Text Changes to the Document ......................29
+ 2.11.3. Solution Description ..............................31
+ 2.12. Shutdown Ambiguity .......................................31
+ 2.12.1. Description of the Problem ........................31
+ 2.12.2. Text Changes to the Document ......................31
+ 2.12.3. Solution Description ..............................32
+ 2.13. Inconsistency in ABORT Processing ........................32
+ 2.13.1. Description of the Problem ........................32
+ 2.13.2. Text changes to the document ......................33
+ 2.13.3. Solution Description ..............................33
+
+
+
+Stewart, et al. Informational [Page 2]
+
+RFC 4460 SCTP Errata April 2006
+
+
+ 2.14. Cwnd Gated by Its Full Use ...............................34
+ 2.14.1. Description of the Problem ........................34
+ 2.14.2. Text Changes to the Document ......................34
+ 2.14.3. Solution Description ..............................36
+ 2.15. Window Probes in SCTP ....................................36
+ 2.15.1. Description of the Problem ........................36
+ 2.15.2. Text Changes to the Document ......................36
+ 2.15.3. Solution Description ..............................38
+ 2.16. Fragmentation and Path MTU Issues ........................39
+ 2.16.1. Description of the Problem ........................39
+ 2.16.2. Text Changes to the Document ......................39
+ 2.16.3. Solution Description ..............................40
+ 2.17. Initial Value of the Cumulative TSN Ack ..................40
+ 2.17.1. Description of the Problem ........................40
+ 2.17.2. Text Changes to the Document ......................40
+ 2.17.3. Solution Description ..............................41
+ 2.18. Handling of Address Parameters within the INIT or
+ INIT-ACK .................................................41
+ 2.18.1. Description of the Problem ........................41
+ 2.18.2. Text Changes to the Document ......................41
+ 2.18.3. Solution description ..............................42
+ 2.19. Handling of Stream Shortages .............................42
+ 2.19.1. Description of the Problem ........................42
+ 2.19.2. Text Changes to the Document ......................42
+ 2.19.3. Solution Description ..............................43
+ 2.20. Indefinite Postponement ..................................43
+ 2.20.1. Description of the Problem ........................43
+ 2.20.2. Text Changes to the Document ......................43
+ 2.20.3. Solution Description ..............................44
+ 2.21. User-Initiated Abort of an Association ...................44
+ 2.21.1. Description of the Problem ........................44
+ 2.21.2. Text changes to the document ......................44
+ 2.21.3. Solution Description ..............................50
+ 2.22. Handling of Invalid Initiate Tag of INIT-ACK .............50
+ 2.22.1. Description of the Problem ........................50
+ 2.22.2. Text Changes to the Document ......................50
+ 2.22.3. Solution Description ..............................51
+ 2.23. Sending an ABORT in Response to an INIT ..................51
+ 2.23.1. Description of the Problem ........................51
+ 2.23.2. Text Changes to the Document ......................51
+ 2.23.3. Solution Description ..............................52
+ 2.24. Stream Sequence Number (SSN) Initialization ..............52
+ 2.24.1. Description of the Problem ........................52
+ 2.24.2. Text Changes to the Document ......................52
+ 2.24.3. Solution Description ..............................53
+ 2.25. SACK Packet Format .......................................53
+ 2.25.1. Description of the Problem ........................53
+ 2.25.2. Text Changes to the Document ......................53
+
+
+
+Stewart, et al. Informational [Page 3]
+
+RFC 4460 SCTP Errata April 2006
+
+
+ 2.25.3. Solution Description ..............................53
+ 2.26. Protocol Violation Error Cause ...........................53
+ 2.26.1. Description of the Problem ........................53
+ 2.26.2. Text Changes to the Document ......................54
+ 2.26.3. Solution Description ..............................56
+ 2.27. Reporting of Unrecognized Parameters .....................56
+ 2.27.1. Description of the Problem ........................56
+ 2.27.2. Text Changes to the Document ......................56
+ 2.27.3. Solution Description ..............................57
+ 2.28. Handling of IP Address Parameters ........................58
+ 2.28.1. Description of the Problem ........................58
+ 2.28.2. Text Changes to the Document ......................58
+ 2.28.3. Solution Description ..............................58
+ 2.29. Handling of COOKIE ECHO Chunks When a TCB Exists .........59
+ 2.29.1. Description of the Problem ........................59
+ 2.29.2. Text Changes to the Document ......................59
+ 2.29.3. Solution Description ..............................59
+ 2.30. The Initial Congestion Window Size .......................59
+ 2.30.1. Description of the Problem ........................59
+ 2.30.2. Text Changes to the Document ......................60
+ 2.30.3. Solution Description ..............................61
+ 2.31. Stream Sequence Numbers in Figures .......................62
+ 2.31.1. Description of the Problem ........................62
+ 2.31.2. Text Changes to the Document ......................63
+ 2.31.3. Solution description ..............................67
+ 2.32. Unrecognized Parameters ..................................67
+ 2.32.1. Description of the Problem ........................67
+ 2.32.2. Text Changes to the Document ......................67
+ 2.32.3. Solution Description ..............................68
+ 2.33. Handling of Unrecognized Parameters ......................68
+ 2.33.1. Description of the Problem ........................68
+ 2.33.2. Text Changes to the Document ......................68
+ 2.33.3. Solution Description ..............................70
+ 2.34. Tie Tags .................................................70
+ 2.34.1. Description of the Problem ........................70
+ 2.34.2. Text Changes to the Document ......................70
+ 2.34.3. Solution Description ..............................72
+ 2.35. Port Number Verification in the COOKIE-ECHO ..............72
+ 2.35.1. Description of the Problem ........................72
+ 2.35.2. Text Changes to the Document ......................72
+ 2.35.3. Solution Description ..............................73
+ 2.36. Path Initialization ......................................74
+ 2.36.1. Description of the Problem ........................74
+ 2.36.2. Text Changes to the Document ......................74
+ 2.36.3. Solution Description ..............................76
+ 2.37. ICMP Handling Procedures .................................76
+ 2.37.1. Description of the Problem ........................76
+ 2.37.2. Text Changes to the Document ......................77
+
+
+
+Stewart, et al. Informational [Page 4]
+
+RFC 4460 SCTP Errata April 2006
+
+
+ 2.37.3. Solution Description ..............................79
+ 2.38. Checksum .................................................79
+ 2.38.1. Description of the problem ........................79
+ 2.38.2. Text Changes to the Document ......................79
+ 2.38.3. Solution Description ..............................86
+ 2.39. Retransmission Policy ....................................86
+ 2.39.1. Description of the Problem ........................86
+ 2.39.2. Text Changes to the Document ......................87
+ 2.39.3. Solution Description ..............................87
+ 2.40. Port Number 0 ............................................88
+ 2.40.1. Description of the Problem ........................88
+ 2.40.2. Text Changes to the Document ......................88
+ 2.40.3. Solution Description ..............................89
+ 2.41. T Bit ....................................................89
+ 2.41.1. Description of the Problem ........................89
+ 2.41.2. Text Changes to the Document ......................89
+ 2.41.3. Solution Description ..............................93
+ 2.42. Unknown Parameter Handling ...............................93
+ 2.42.1. Description of the Problem ........................93
+ 2.42.2. Text Changes to the Document ......................93
+ 2.42.3. Solution Description ..............................95
+ 2.43. Cookie Echo Chunk ........................................95
+ 2.43.1. Description of the Problem ........................95
+ 2.43.2. Text Changes to the Document ......................95
+ 2.43.3. Solution Description ..............................96
+ 2.44. Partial Chunks ...........................................96
+ 2.44.1. Description of the Problem ........................96
+ 2.44.2. Text Changes to the Document ......................96
+ 2.44.3. Solution Description ..............................97
+ 2.45. Non-unicast Addresses ....................................97
+ 2.45.1. Description of the Problem ........................97
+ 2.45.2. Text Changes to the Document ......................97
+ 2.45.3. Solution Description ..............................98
+ 2.46. Processing of ABORT Chunks ...............................98
+ 2.46.1. Description of the Problem ........................98
+ 2.46.2. Text Changes to the Document ......................98
+ 2.46.3. Solution Description ..............................98
+ 2.47. Sending of ABORT Chunks ..................................99
+ 2.47.1. Description of the Problem ........................99
+ 2.47.2. Text Changes to the Document ......................99
+ 2.47.3. Solution Description ..............................99
+ 2.48. Handling of Supported Address Types Parameter ............99
+ 2.48.1. Description of the Problem ........................99
+ 2.48.2. Text Changes to the Document .....................100
+ 2.48.3. Solution Description .............................100
+ 2.49. Handling of Unexpected Parameters .......................101
+ 2.49.1. Description of the Problem .......................101
+ 2.49.2. Text Changes to the Document .....................101
+
+
+
+Stewart, et al. Informational [Page 5]
+
+RFC 4460 SCTP Errata April 2006
+
+
+ 2.49.3. Solution Description .............................102
+ 2.50. Payload Protocol Identifier .............................102
+ 2.50.1. Description of the Problem .......................102
+ 2.50.2. Text Changes to the Document .....................103
+ 2.50.3. Solution Description .............................103
+ 2.51. Karn's Algorithm ........................................104
+ 2.51.1. Description of the Problem .......................104
+ 2.51.2. Text Changes to the Document .....................104
+ 2.51.3. Solution Description .............................104
+ 2.52. Fast Retransmit Algorithm ...............................104
+ 2.52.1. Description of the Problem .......................104
+ 2.52.2. Text Changes to the Document .....................105
+ 2.52.3. Solution Description .............................105
+ 3. Security Considerations .......................................105
+ 4. Acknowledgements ..............................................106
+ 5. IANA Considerations ...........................................106
+ 6. Normative References ..........................................106
+
+1. Introduction
+
+ This document contains a compilation of all defects found up until
+ the publishing of this document for the Stream Control Transmission
+ Protocol (SCTP), RFC 2960 [5]. These defects may be of an editorial
+ or technical nature. This document may be thought of as a companion
+ document to be used in the implementation of SCTP to clarify errors
+ in the original SCTP document.
+
+ This document provides a history of the changes that will be compiled
+ into RFC 2960's [5] BIS document. Each error will be detailed within
+ this document in the form of
+
+ o the problem description,
+
+ o the text quoted from RFC 2960 [5],
+
+ o the replacement text that should be placed into the BIS document,
+ and
+
+ o a description of the solution.
+
+ This document is a historical record of sequential changes what have
+ been found necessary at various interop events and through discussion
+ on this list.
+
+ Note that because some text is changed several times, the last delta
+ for a text in the document is the erratum for that text in RFC 2960.
+
+
+
+
+
+Stewart, et al. Informational [Page 6]
+
+RFC 4460 SCTP Errata April 2006
+
+
+1.1. Conventions
+
+ The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
+ SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when
+ they appear in this document, are to be interpreted as described in
+ RFC 2119 [2].
+
+2. Corrections to RFC 2960
+
+2.1. Incorrect Error Type During Chunk Processing.
+
+2.1.1. Description of the Problem
+
+ A typo was discovered in RFC 2960 [5] that incorrectly specifies an
+ action to be taken when processing chunks of unknown identity.
+
+2.1.2. Text changes to the document
+
+ ---------
+ Old text: (Section 3.2)
+ ---------
+
+ 01 - Stop processing this SCTP packet and discard it, do not process
+ any further chunks within it, and report the unrecognized
+ parameter in an 'Unrecognized Parameter Type' (in either an
+ ERROR or in the INIT ACK).
+
+ ---------
+ New text: (Section 3.2)
+ ---------
+
+ 01 - Stop processing this SCTP packet and discard it, do not process
+ any further chunks within it, and report the unrecognized
+ chunk in an 'Unrecognized Chunk Type'.
+
+2.1.3. Solution Description
+
+ The receiver of an unrecognized chunk should not send a 'parameter'
+ error but instead should send the appropriate chunk error as
+ described above.
+
+2.2. Parameter Processing Issue
+
+2.2.1. Description of the Problem
+
+ A typographical error was introduced through an improper cut and
+ paste in the use of the upper two bits to describe proper handling of
+ unknown parameters.
+
+
+
+Stewart, et al. Informational [Page 7]
+
+RFC 4460 SCTP Errata April 2006
+
+
+2.2.2. Text Changes to the Document
+
+ ---------
+ Old text: (Section 3.2.1)
+ ---------
+
+ 00 - Stop processing this SCTP packet and discard it; do not process
+ any further chunks within it.
+
+ 01 - Stop processing this SCTP packet and discard it, do not process
+ any further chunks within it, and report the unrecognized
+ parameter in an 'Unrecognized Parameter Type' (in either an
+ ERROR or in the INIT ACK).
+
+ ---------
+ New text: (Section 3.2.1)
+ ---------
+
+ 00 - Stop processing this SCTP chunk and discard it, do not process
+ any further parameters within this chunk.
+
+ 01 - Stop processing this SCTP chunk and discard it, do not process
+ any further parameters within this chunk, and report the
+ unrecognized parameter in an 'Unrecognized Parameter Type' (in
+ either an ERROR or in the INIT ACK).
+
+2.2.3. Solution Description
+
+ It was always the intent to stop processing at the level one was at
+ in an unknown chunk or parameter with the upper bit set to 0. Thus,
+ if you are processing a chunk, you should drop the packet. If you
+ are processing a parameter, you should drop the chunk.
+
+2.3. Padding Issues
+
+2.3.1. Description of the Problem
+
+ A problem was found when a Chunk terminated in a TLV parameter. If
+ this last TLV was not on a 32-bit boundary (as required), there was
+ confusion as to whether the last padding was included in the chunk
+ length.
+
+
+
+
+
+
+
+
+
+
+Stewart, et al. Informational [Page 8]
+
+RFC 4460 SCTP Errata April 2006
+
+
+2.3.2. Text Changes to the Document
+
+ ---------
+ Old text: (Section 3.2)
+ ---------
+
+ Chunk Length: 16 bits (unsigned integer)
+
+ This value represents the size of the chunk in bytes including the
+ Chunk Type, Chunk Flags, Chunk Length, and Chunk Value fields.
+ Therefore, if the Chunk Value field is zero-length, the Length
+ field will be set to 4. The Chunk Length field does not count any
+ padding.
+
+ Chunk Value: variable length
+
+ The Chunk Value field contains the actual information to be
+ transferred in the chunk. The usage and format of this field is
+ dependent on the Chunk Type.
+
+ The total length of a chunk (including Type, Length and Value fields)
+ MUST be a multiple of 4 bytes. If the length of the chunk is not a
+ multiple of 4 bytes, the sender MUST pad the chunk with all zero
+ bytes and this padding is not included in the chunk length field.
+ The sender should never pad with more than 3 bytes. The receiver
+ MUST ignore the padding bytes.
+
+ ---------
+ New text: (Section 3.2)
+ ---------
+
+ Chunk Length: 16 bits (unsigned integer)
+
+ This value represents the size of the chunk in bytes, including
+ the Chunk Type, Chunk Flags, Chunk Length, and Chunk Value fields.
+ Therefore, if the Chunk Value field is zero-length, the Length
+ field will be set to 4. The Chunk Length field does not count any
+ chunk padding.
+
+ Chunks (including Type, Length, and Value fields) are padded out
+ by the sender with all zero bytes to be a multiple of 4 bytes
+ long. This padding MUST NOT be more than 3 bytes in total. The
+ Chunk Length value does not include terminating padding of the
+ chunk. However, it does include padding of any variable-length
+ parameter except the last parameter in the chunk. The receiver
+ MUST ignore the padding.
+
+
+
+
+
+Stewart, et al. Informational [Page 9]
+
+RFC 4460 SCTP Errata April 2006
+
+
+ Note: A robust implementation should accept the Chunk whether or
+ not the final padding has been included in the Chunk Length.
+
+ Chunk Value: variable length
+
+ The Chunk Value field contains the actual information to be
+ transferred in the chunk. The usage and format of this field is
+ dependent on the Chunk Type.
+
+ The total length of a chunk (including Type, Length, and Value
+ fields) MUST be a multiple of 4 bytes. If the length of the chunk is
+ not a multiple of 4 bytes, the sender MUST pad the chunk with all
+ zero bytes, and this padding is not included in the chunk length
+ field. The sender should never pad with more than 3 bytes. The
+ receiver MUST ignore the padding bytes.
+
+2.3.3. Solution Description
+
+ The above text makes clear that the padding of the last parameter is
+ not included in the Chunk Length field. It also clarifies that the
+ padding of parameters that are not the last one must be counted in
+ the Chunk Length field.
+
+2.4. Parameter Types across All Chunk Types
+
+2.4.1. Description of the Problem
+
+ A problem was noted when multiple errors are needed to be sent
+ regarding unknown or unrecognized parameters. Since often the error
+ type does not hold the chunk type field, it may become difficult to
+ tell which error was associated with which chunk.
+
+2.4.2. Text Changes to the Document
+
+ ---------
+ Old text: (Section 3.2.1)
+ ---------
+
+ The actual SCTP parameters are defined in the specific SCTP chunk
+ sections. The rules for IETF-defined parameter extensions are
+ defined in Section 13.2.
+
+ ---------
+ New text: (Section 3.2.1)
+ ---------
+
+ The actual SCTP parameters are defined in the specific SCTP chunk
+ sections. The rules for IETF-defined parameter extensions are
+
+
+
+Stewart, et al. Informational [Page 10]
+
+RFC 4460 SCTP Errata April 2006
+
+
+ defined in Section 13.2. Note that a parameter type MUST be unique
+ across all chunks. For example, the parameter type '5' is used to
+ represent an IPv4 address (see Section 3.3.2). The value '5' then is
+ reserved across all chunks to represent an IPv4 address and MUST NOT
+ be reused with a different meaning in any other chunk.
+
+ ---------
+ Old text: (Section 13.2)
+ ---------
+
+ 13.2 IETF-defined Chunk Parameter Extension
+
+ The assignment of new chunk parameter type codes is done through an
+ IETF Consensus action as defined in [RFC2434]. Documentation of the
+ chunk parameter MUST contain the following information:
+
+ a) Name of the parameter type.
+
+ b) Detailed description of the structure of the parameter field.
+ This structure MUST conform to the general type-length-value
+ format described in Section 3.2.1.
+
+ c) Detailed definition of each component of the parameter type.
+
+ d) Detailed description of the intended use of this parameter type,
+ and an indication of whether and under what circumstances multiple
+ instances of this parameter type may be found within the same
+ chunk.
+
+ ---------
+ New text: (Section 13.2)
+ ---------
+
+ 13.2. IETF-defined Chunk Parameter Extension
+
+ The assignment of new chunk parameter type codes is done through an
+ IETF Consensus action, as defined in [RFC2434]. Documentation of the
+ chunk parameter MUST contain the following information:
+
+ a) Name of the parameter type.
+
+ b) Detailed description of the structure of the parameter field.
+ This structure MUST conform to the general type-length-value
+ format described in Section 3.2.1.
+
+ c) Detailed definition of each component of the parameter type.
+
+
+
+
+
+Stewart, et al. Informational [Page 11]
+
+RFC 4460 SCTP Errata April 2006
+
+
+ d) Detailed description of the intended use of this parameter type,
+ and an indication of whether and under what circumstances multiple
+ instances of this parameter type may be found within the same
+ chunk.
+
+ e) Each parameter type MUST be unique across all chunks.
+
+2.4.3. Solution Description
+
+ By having all parameters unique across all chunk assignments (the
+ current assignment policy), no ambiguity exists as to what a
+ parameter means in different contexts. The trade-off for this is a
+ smaller parameter space, i.e., 65,536 parameters versus 65,536 *
+ Number-of- chunks.
+
+2.5. Stream Parameter Clarification
+
+2.5.1. Description of the problem
+
+ A problem was found where the specification is unclear on the
+ legality of an endpoint asking for more stream resources than were
+ allowed in the MIS value of the INIT. In particular, the value in
+ the INIT ACK requested in its OS value was larger than the MIS value
+ received in the INIT chunk. This behavior is illegal, yet it was
+ unspecified in RFC 2960 [5]
+
+2.5.2. Text Changes to the Document
+
+ ---------
+ Old text: (Section 3.3.3)
+ ---------
+
+ Number of Outbound Streams (OS): 16 bits (unsigned integer)
+
+ Defines the number of outbound streams the sender of this INIT ACK
+ chunk wishes to create in this association. The value of 0 MUST
+ NOT be used.
+
+ Note: A receiver of an INIT ACK with the OS value set to 0 SHOULD
+ destroy the association discarding its TCB.
+
+
+
+
+
+
+
+
+
+
+
+Stewart, et al. Informational [Page 12]
+
+RFC 4460 SCTP Errata April 2006
+
+
+ ---------
+ New text: (Section 3.3.3)
+ ---------
+
+ Number of Outbound Streams (OS): 16 bits (unsigned integer)
+
+ Defines the number of outbound streams the sender of this INIT ACK
+ chunk wishes to create in this association. The value of 0 MUST
+ NOT be used, and the value MUST NOT be greater than the MIS value
+ sent in the INIT chunk.
+
+ Note: A receiver of an INIT ACK with the OS value set to 0 SHOULD
+ destroy the association, discarding its TCB.
+
+2.5.3. Solution Description
+
+ The change in wording, above, changes it so that a responder to an
+ INIT chunk does not specify more streams in its OS value than were
+ represented to it in the MIS value, i.e., its maximum.
+
+2.6. Restarting Association Security Issue
+
+2.6.1. Description of the Problem
+
+ A security problem was found when a restart occurs. It is possible
+ for an intruder to send an INIT to an endpoint of an existing
+ association. In the INIT the intruder would list one or more of the
+ current addresses of an association and its own. The normal restart
+ procedures would then occur, and the intruder would have hijacked an
+ association.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stewart, et al. Informational [Page 13]
+
+RFC 4460 SCTP Errata April 2006
+
+
+2.6.2. Text Changes to the Document
+
+ ---------
+ Old text: (Section 3.3.10)
+ ---------
+
+ Cause Code
+ Value Cause Code
+ --------- ----------------
+ 1 Invalid Stream Identifier
+ 2 Missing Mandatory Parameter
+ 3 Stale Cookie Error
+ 4 Out of Resource
+ 5 Unresolvable Address
+ 6 Unrecognized Chunk Type
+ 7 Invalid Mandatory Parameter
+ 8 Unrecognized Parameters
+ 9 No User Data
+ 10 Cookie Received While Shutting Down
+
+ Cause Length: 16 bits (unsigned integer)
+
+ Set to the size of the parameter in bytes, including the Cause
+ Code, Cause Length, and Cause-Specific Information fields
+
+ Cause-specific Information: variable length
+
+ This field carries the details of the error condition.
+
+ Sections 3.3.10.1 - 3.3.10.10 define error causes for SCTP.
+
+ Guidelines for the IETF to define new error cause values are
+ discussed in Section 13.3.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stewart, et al. Informational [Page 14]
+
+RFC 4460 SCTP Errata April 2006
+
+
+ ---------
+ New text: (Section 3.3.10)
+ ---------
+
+ Cause Code
+ Value Cause Code
+ --------- ----------------
+ 1 Invalid Stream Identifier
+ 2 Missing Mandatory Parameter
+ 3 Stale Cookie Error
+ 4 Out of Resource
+ 5 Unresolvable Address
+ 6 Unrecognized Chunk Type
+ 7 Invalid Mandatory Parameter
+ 8 Unrecognized Parameters
+ 9 No User Data
+ 10 Cookie Received While Shutting Down
+ 11 Restart of an Association with New Addresses
+
+ Cause Length: 16 bits (unsigned integer)
+
+ Set to the size of the parameter in bytes, including the Cause
+ Code, Cause Length, and Cause-Specific Information fields.
+
+ Cause-specific Information: variable length
+
+ This field carries the details of the error condition.
+
+ Sections 3.3.10.1 - 3.3.10.11 define error causes for SCTP.
+ Guidelines for the IETF to define new error cause values are
+ discussed in Section 13.3.
+
+ ---------
+ New text: (Note no old text, new error cause added in section 3.3.10)
+ ---------
+
+ 3.3.10.11. Restart of an Association with New Addresses (11)
+
+ Cause of error
+ --------------
+ Restart of an association with new addresses: An INIT was received
+ on an existing association. But the INIT added addresses to the
+ association that were previously NOT part of the association. The
+ new addresses are listed in the error code. This ERROR is normally
+ sent as part of an ABORT refusing the INIT (see Section 5.2).
+
+
+
+
+
+
+Stewart, et al. Informational [Page 15]
+
+RFC 4460 SCTP Errata April 2006
+
+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Cause Code=11 | Cause Length=Variable |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ / New Address TLVs /
+ \ \
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Note: Each New Address TLV is an exact copy of the TLV
+ that was found in the INIT chunk that was new, including the
+ Parameter Type and the Parameter length.
+
+ ---------
+ Old text: (Section 5.2.1)
+ ---------
+
+ Upon receipt of an INIT in the COOKIE-WAIT or COOKIE-ECHOED state, an
+ endpoint MUST respond with an INIT ACK using the same parameters it
+ sent in its original INIT chunk (including its Initiation Tag,
+ unchanged). These original parameters are combined with those from
+ the newly received INIT chunk. The endpoint shall also generate a
+ State Cookie with the INIT ACK. The endpoint uses the parameters
+ sent in its INIT to calculate the State Cookie.
+
+ ---------
+ New text: (Section 5.2.1)
+ ---------
+
+ Upon receipt of an INIT in the COOKIE-WAIT state, an endpoint MUST
+ respond with an INIT ACK using the same parameters it sent in its
+ original INIT chunk (including its Initiation Tag, unchanged). When
+ responding, the endpoint MUST send the INIT ACK back to the same
+ address that the original INIT (sent by this endpoint) was sent to.
+
+ Upon receipt of an INIT in the COOKIE-ECHOED state, an endpoint MUST
+ respond with an INIT ACK using the same parameters it sent in its
+ original INIT chunk (including its Initiation Tag, unchanged),
+ provided that no NEW address has been added to the forming
+ association. If the INIT message indicates that a new address has
+ been added to the association, then the entire INIT MUST be
+ discarded, and NO changes should be made to the existing association.
+ An ABORT SHOULD be sent in response that MAY include the error
+ 'Restart of an association with new addresses'. The error SHOULD
+ list the addresses that were added to the restarting association.
+
+
+
+
+
+
+
+
+Stewart, et al. Informational [Page 16]
+
+RFC 4460 SCTP Errata April 2006
+
+
+ When responding in either state (COOKIE-WAIT or COOKIE-ECHOED) with
+ an INIT ACK, the original parameters are combined with those from the
+ newly received INIT chunk. The endpoint shall also generate a State
+ Cookie with the INIT ACK. The endpoint uses the parameters sent in
+ its INIT to calculate the State Cookie.
+
+ ---------
+ Old text: (Section 5.2.2)
+ ---------
+
+ 5.2.2 Unexpected INIT in States Other than CLOSED, COOKIE-ECHOED,
+ COOKIE-WAIT and SHUTDOWN-ACK-SENT
+
+ Unless otherwise stated, upon reception of an unexpected INIT for
+ this association, the endpoint shall generate an INIT ACK with a
+ State Cookie. In the outbound INIT ACK the endpoint MUST copy its
+ current Verification Tag and peer's Verification Tag into a reserved
+ place within the state cookie. We shall refer to these locations as
+ the Peer's-Tie-Tag and the Local-Tie-Tag. The outbound SCTP packet
+ containing this INIT ACK MUST carry a Verification Tag value equal to
+ the Initiation Tag found in the unexpected INIT. And the INIT ACK
+ MUST contain a new Initiation Tag (randomly generated see Section
+ 5.3.1). Other parameters for the endpoint SHOULD be copied from the
+ existing parameters of the association (e.g., number of outbound
+ streams) into the INIT ACK and cookie.
+
+ After sending out the INIT ACK, the endpoint shall take no further
+ actions, i.e., the existing association, including its current state,
+ and the corresponding TCB MUST NOT be changed.
+
+ Note: Only when a TCB exists and the association is not in a COOKIE-
+ WAIT state are the Tie-Tags populated. For a normal association INIT
+ (i.e., the endpoint is in a COOKIE-WAIT state), the Tie-Tags MUST be
+ set to 0 (indicating that no previous TCB existed). The INIT ACK and
+ State Cookie are populated as specified in section 5.2.1.
+
+ ---------
+ New text: (Section 5.2.2)
+ ---------
+
+ 5.2.2. Unexpected INIT in States Other Than CLOSED, COOKIE-ECHOED,
+ COOKIE-WAIT, and SHUTDOWN-ACK-SENT
+
+ Unless otherwise stated, upon receipt of an unexpected INIT for this
+ association, the endpoint shall generate an INIT ACK with a State
+ Cookie. Before responding, the endpoint MUST check to see if the
+ unexpected INIT adds new addresses to the association. If new
+ addresses are added to the association, the endpoint MUST respond
+
+
+
+Stewart, et al. Informational [Page 17]
+
+RFC 4460 SCTP Errata April 2006
+
+
+ with an ABORT, copying the 'Initiation Tag' of the unexpected INIT
+ into the 'Verification Tag' of the outbound packet carrying the
+ ABORT. In the ABORT response, the cause of error MAY be set to
+ 'restart of an association with new addresses'. The error SHOULD
+ list the addresses that were added to the restarting association.
+
+ If no new addresses are added, when responding to the INIT in the
+ outbound INIT ACK, the endpoint MUST copy its current Verification
+ Tag and peer's Verification Tag into a reserved place within the
+ state cookie. We shall refer to these locations as the Peer's-Tie-
+ Tag and the Local-Tie-Tag. The outbound SCTP packet containing this
+ INIT ACK MUST carry a Verification Tag value equal to the Initiation
+ Tag found in the unexpected INIT. And the INIT ACK MUST contain a
+ new Initiation Tag (randomly generated; see Section 5.3.1). Other
+ parameters for the endpoint SHOULD be copied from the existing
+ parameters of the association (e.g., number of outbound streams) into
+ the INIT ACK and cookie.
+
+ After sending out the INIT ACK or ABORT, the endpoint shall take no
+ further actions; i.e., the existing association, including its
+ current state, and the corresponding TCB MUST NOT be changed.
+
+ Note: Only when a TCB exists and the association is not in a COOKIE-
+ WAIT or SHUTDOWN-ACK-SENT state are the Tie-Tags populated with a
+ value other than 0. For a normal association INIT (i.e., the
+ endpoint is in the CLOSED state), the Tie-Tags MUST be set to 0
+ (indicating that no previous TCB existed).
+
+2.6.3. Solution Description
+
+ A new error code is being added, along with specific instructions to
+ send back an ABORT to a new association in a restart case or
+ collision case, where new addresses have been added. The error code
+ can be used by a legitimate restart to inform the endpoint that it
+ has made a software error in adding a new address. The endpoint then
+ can choose to wait until the OOTB ABORT tears down the old
+ association, or to restart without the new address.
+
+ Also, the note at the end of Section 5.2.2 explaining the use of the
+ Tie-Tags was modified to properly explain the states in which the
+ Tie-Tags should be set to a value different than 0.
+
+
+
+
+
+
+
+
+
+
+Stewart, et al. Informational [Page 18]
+
+RFC 4460 SCTP Errata April 2006
+
+
+2.7. Implicit Ability to Exceed cwnd by PMTU-1 Bytes
+
+2.7.1. Description of the Problem
+
+ Some implementations were having difficulty growing their cwnd. This
+ was due to an improper enforcement of the congestion control rules.
+ The rules, as written, provided for a slop over of the cwnd value.
+ Without this slop over, the sender would appear NOT to be using its
+ full cwnd value and thus would never increase it.
+
+2.7.2. Text Changes to the Document
+
+ ---------
+ Old text: (Section 6.1)
+ ---------
+
+ B) At any given time, the sender MUST NOT transmit new data to a
+ given transport address if it has cwnd or more bytes of data
+ outstanding to that transport address.
+
+ ---------
+ New text: (Section 6.1)
+ ---------
+
+ B) At any given time, the sender MUST NOT transmit new data to a
+ given transport address if it has cwnd or more bytes of data
+ outstanding to that transport address. The sender may exceed cwnd
+ by up to (PMTU-1) bytes on a new transmission if the cwnd is not
+ currently exceeded.
+
+2.7.3. Solution Description
+
+ The text changes make clear the ability to go over the cwnd value by
+ no more than (PMTU-1) bytes.
+
+2.8. Issues with Fast Retransmit
+
+2.8.1. Description of the Problem
+
+ Several problems were found in the current specification of fast
+ retransmit. The current wording did not require GAP ACK blocks to be
+ sent, even though they are essential to the workings of SCTP's
+ congestion control. The specification left unclear how to handle the
+ fast retransmit cycle, having the implementation wait on the cwnd to
+ retransmit a TSN that was marked for fast retransmit. No limit was
+ placed on how many times a TSN could be fast retransmitted. Fast
+ Recovery was not specified, causing the congestion window to be
+ reduced drastically when there are multiple losses in a single RTT.
+
+
+
+Stewart, et al. Informational [Page 19]
+
+RFC 4460 SCTP Errata April 2006
+
+
+2.8.2. Text Changes to the Document
+
+ ---------
+ Old text: (Section 6.2)
+ ---------
+
+ Acknowledgements MUST be sent in SACK chunks unless shutdown was
+ requested by the ULP in which case an endpoint MAY send an
+ acknowledgement in the SHUTDOWN chunk. A SACK chunk can acknowledge
+ the reception of multiple DATA chunks. See Section 3.3.4 for SACK
+ chunk format. In particular, the SCTP endpoint MUST fill in the
+ Cumulative TSN Ack field to indicate the latest sequential TSN (of a
+ valid DATA chunk) it has received. Any received DATA chunks with TSN
+ greater than the value in the Cumulative TSN Ack field SHOULD also be
+ reported in the Gap Ack Block fields.
+
+ ---------
+ New text: (Section 6.2)
+ ---------
+
+ Acknowledegments MUST be sent in SACK chunks unless shutdown was
+ requested by the ULP, in which case an endpoint MAY send an
+ acknowledgement in the SHUTDOWN chunk. A SACK chunk can acknowledge
+ the reception of multiple DATA chunks. See Section 3.3.4 for SACK
+ chunk format. In particular, the SCTP endpoint MUST fill in the
+ Cumulative TSN Ack field to indicate the latest sequential TSN (of a
+ valid DATA chunk) it has received. Any received DATA chunks with
+ TSN greater than the value in the Cumulative TSN Ack field are
+ reported in the Gap Ack Block fields. The SCTP endpoint MUST
+ report as many Gap Ack Blocks as can fit in a single SACK
+ chunk limited by the current path MTU.
+
+ ---------
+ Old text: (Section 6.2.1)
+ ---------
+
+ D) Any time a SACK arrives, the endpoint performs the following:
+
+ i) If Cumulative TSN Ack is less than the Cumulative TSN Ack
+ Point, then drop the SACK. Since Cumulative TSN Ack is
+ monotonically increasing, a SACK whose Cumulative TSN Ack is
+ less than the Cumulative TSN Ack Point indicates an out-of-
+ order SACK.
+
+ ii) Set rwnd equal to the newly received a_rwnd minus the
+ number of bytes still outstanding after processing the
+ Cumulative TSN Ack and the Gap Ack Blocks.
+
+
+
+
+Stewart, et al. Informational [Page 20]
+
+RFC 4460 SCTP Errata April 2006
+
+
+ iii) If the SACK is missing a TSN that was previously
+ acknowledged via a Gap Ack Block (e.g., the data receiver
+ reneged on the data), then mark the corresponding DATA chunk
+ as available for retransmit: Mark it as missing for fast
+ retransmit as described in Section 7.2.4 and if no
+ retransmit timer is running for the destination address
+ to which the DATA chunk was originally transmitted, then
+ T3-rtx is started for that destination address.
+
+ ---------
+ New text: (Section 6.2.1)
+ ---------
+
+ D) Any time a SACK arrives, the endpoint performs the following:
+
+ i) If Cumulative TSN Ack is less than the Cumulative TSN Ack
+ Point, then drop the SACK. Since Cumulative TSN Ack is
+ monotonically increasing, a SACK whose Cumulative TSN Ack is
+ less than the Cumulative TSN Ack Point indicates an out-of-
+ order SACK.
+
+ ii) Set rwnd equal to the newly received a_rwnd minus the
+ number of bytes still outstanding after processing the
+ Cumulative TSN Ack and the Gap Ack Blocks.
+
+ iii) If the SACK is missing a TSN that was previously
+ acknowledged via a Gap Ack Block (e.g., the data receiver
+ reneged on the data), then consider the corresponding DATA
+ that might be possibly missing: Count one miss indication
+ towards fast retransmit as described in Section 7.2.4, and
+ if no retransmit timer is running for the destination
+ address to which the DATA chunk was originally transmitted,
+ then T3-rtx is started for that destination address.
+
+ iv) If the Cumulative TSN Ack matches or exceeds the Fast
+ Recovery exitpoint (Section 7.2.4), Fast Recovery is exited.
+
+ ---------
+ Old text: (Section 7.2.4)
+ ---------
+
+ Whenever an endpoint receives a SACK that indicates some TSN(s)
+ missing, it SHOULD wait for 3 further miss indications (via
+ subsequent SACK's) on the same TSN(s) before taking action with
+ regard to Fast Retransmit.
+
+ When the TSN(s) is reported as missing in the fourth consecutive
+ SACK, the data sender shall:
+
+
+
+Stewart, et al. Informational [Page 21]
+
+RFC 4460 SCTP Errata April 2006
+
+
+ 1) Mark the missing DATA chunk(s) for retransmission,
+
+ 2) Adjust the ssthresh and cwnd of the destination address(es) to
+ which the missing DATA chunks were last sent, according to the
+ formula described in Section 7.2.3.
+
+ 3) Determine how many of the earliest (i.e., lowest TSN) DATA chunks
+ marked for retransmission will fit into a single packet, subject
+ to constraint of the path MTU of the destination transport address
+ to which the packet is being sent. Call this value K. Retransmit
+ those K DATA chunks in a single packet.
+
+ 4) Restart T3-rtx timer only if the last SACK acknowledged the lowest
+ outstanding TSN number sent to that address, or the endpoint is
+ retransmitting the first outstanding DATA chunk sent to that
+ address.
+
+ Note: Before the above adjustments, if the received SACK also
+ acknowledges new DATA chunks and advances the Cumulative TSN Ack
+ Point, the cwnd adjustment rules defined in Sections 7.2.1 and 7.2.2
+ must be applied first.
+
+ 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 4 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)
+ ---------
+
+ Whenever an endpoint receives a SACK that indicates that some TSNs
+ are missing, it SHOULD wait for 3 further miss indications (via
+ subsequent SACKs) on the same TSN(s) before taking action with
+ regard to Fast Retransmit.
+
+ Miss indications SHOULD follow the HTNA (Highest TSN Newly
+ Acknowledged) algorithm. For each incoming SACK, miss
+ indications are incremented only for missing TSNs prior to
+ the highest TSN newly acknowledged in the SACK. A newly
+ acknowledged DATA chunk is one not previously acknowledged
+ in a SACK. If an endpoint is in Fast Recovery and a SACK
+ arrives that advances the Cumulative TSN Ack Point, the
+ miss indications are incremented for all TSNs reported
+ missing in the SACK.
+
+
+
+Stewart, et al. Informational [Page 22]
+
+RFC 4460 SCTP Errata April 2006
+
+
+ When the fourth consecutive miss indication is received for a TSN(s),
+ the data sender shall do the following:
+
+ 1) Mark the DATA chunk(s) with four miss indications for
+ retransmission.
+
+ 2) If not in Fast Recovery, adjust the ssthresh and cwnd of the
+ destination address(es) to which the missing DATA chunks were
+ last sent, according to the formula described in Section 7.2.3.
+
+ 3) Determine how many of the earliest (i.e., lowest TSN) DATA chunks
+ marked for retransmission will fit into a single packet, subject
+ to constraint of the path MTU of the destination transport address
+ to which the packet is being sent. Call this value K. Retransmit
+ those K DATA chunks in a single packet. When a Fast Retransmit is
+ being performed, the sender SHOULD ignore the value of cwnd and
+ SHOULD NOT delay retransmission for this single packet.
+
+ 4) Restart T3-rtx timer only if the last SACK acknowledged the lowest
+ outstanding TSN number sent to that address, or the endpoint is
+ retransmitting the first outstanding DATA chunk sent to that
+ address.
+
+ 5) Mark the DATA chunk(s) as being fast retransmitted and thus
+ ineligible for a subsequent fast retransmit. Those TSNs marked
+ for retransmission due to the Fast Retransmit algorithm that
+ did not fit in the sent datagram carrying K other TSNs are also
+ marked as ineligible for a subsequent fast retransmit. However,
+ as they are marked for retransmission they will be retransmitted
+ later on as soon as cwnd allows.
+
+ 6) If not in Fast Recovery, enter Fast Recovery and mark the highest
+ outstanding TSN as the Fast Recovery exit point. When a SACK
+ acknowledges all TSNs up to and including this exit point, Fast
+ Recovery is exited. While in Fast Recovery, the ssthresh and cwnd
+ SHOULD NOT change for any destinations due to a subsequent Fast
+ Recovery event (i.e., one SHOULD NOT reduce the cwnd further due
+ to a subsequent fast retransmit).
+
+ Note: Before the above adjustments, if the received SACK also
+ acknowledges new DATA chunks and advances the Cumulative TSN Ack
+ Point, the cwnd adjustment rules defined in Sections 7.2.1 and 7.2.2
+ must be applied first.
+
+2.8.3. Solution Description
+
+ The effect of the above wording changes are as follows:
+
+
+
+
+Stewart, et al. Informational [Page 23]
+
+RFC 4460 SCTP Errata April 2006
+
+
+ o It requires with a MUST the sending of GAP Ack blocks instead of
+ the current RFC 2960 [5] SHOULD.
+
+ o It allows a TSN being Fast Retransmitted (FR) to be sent only once
+ via FR.
+
+ o It ends the delay in waiting for the flight size to drop when a
+ TSN is identified as being ready to FR.
+
+ o It changes the way chunks are marked during fast retransmit, so
+ that only new reports are counted.
+
+ o It introduces a Fast Recovery period to avoid multiple congestion
+ window reductions when there are multiple losses in a single RTT
+ (as shown by Caro et al. [3]).
+
+ These changes will effectively allow SCTP to follow a similar model
+ as TCP+SACK in the handling of Fast Retransmit.
+
+2.9. Missing Statement about partial_bytes_acked Update
+
+2.9.1. Description of the Problem
+
+ SCTP uses four control variables to regulate its transmission rate:
+ rwnd, cwnd, ssthresh, and partial_bytes_acked. Upon detection of
+ packet losses from SACK, or when the T3-rtx timer expires on an
+ address, cwnd and ssthresh should be updated as stated in Section
+ 7.2.3. However, that section should also clarify that
+ partial_bytes_acked must be updated as well; it has to be reset to 0.
+
+2.9.2. Text Changes to the Document
+
+ ---------
+ Old text: (Section 7.2.3)
+ ---------
+
+ 7.2.3 Congestion Control
+
+ Upon detection of packet losses from SACK (see Section 7.2.4), An
+ endpoint should do the following:
+
+ ssthresh = max(cwnd/2, 2*MTU)
+ cwnd = ssthresh
+
+ Basically, a packet loss causes cwnd to be cut in half.
+
+ When the T3-rtx timer expires on an address, SCTP should perform slow
+ start by:
+
+
+
+Stewart, et al. Informational [Page 24]
+
+RFC 4460 SCTP Errata April 2006
+
+
+ ssthresh = max(cwnd/2, 2*MTU)
+ cwnd = 1*MTU
+
+ ---------
+ New text: (Section 7.2.3)
+ ---------
+
+ 7.2.3. Congestion Control
+
+ Upon detection of packet losses from SACK (see Section 7.2.4), an
+ endpoint should do the following if not in Fast Recovery:
+
+ ssthresh = max(cwnd/2, 2*MTU)
+ cwnd = ssthresh
+ partial_bytes_acked = 0
+
+ Basically, a packet loss causes cwnd to be cut in half.
+
+ When the T3-rtx timer expires on an address, SCTP should perform slow
+ start by
+
+ ssthresh = max(cwnd/2, 2*MTU)
+ cwnd = 1*MTU
+ partial_bytes_acked = 0
+
+2.9.3. Solution Description
+
+ The missing text added solves the doubts about what to do with
+ partial_bytes_acked in the situations stated in Section 7.2.3, making
+ clear that, along with ssthresh and cwnd, partial_bytes_acked should
+ also be updated by being reset to 0.
+
+2.10. Issues with Heartbeating and Failure Detection
+
+2.10.1. Description of the Problem
+
+ Five basic problems have been discovered with the current heartbeat
+ procedures:
+
+ o The current specification does not specify that you should count a
+ failed heartbeat as an error against the overall association.
+
+ o The current specification is not specific as to when you start
+ sending heartbeats and when you should stop.
+
+ o The current specification is not specific as to when you should
+ respond to heartbeats.
+
+
+
+
+Stewart, et al. Informational [Page 25]
+
+RFC 4460 SCTP Errata April 2006
+
+
+ o When responding to a Heartbeat, it is unclear what to do if more
+ than a single TLV is present.
+
+ o The jitter applied to a heartbeat was meant to be a small variance
+ of the RTO and is currently a wide variance, due to the default
+ delay time and incorrect wording within the RFC.
+
+2.10.2. Text Changes to the Document
+
+ ---------
+ Old text: (Section 8.1)
+ ---------
+
+ 8.1 Endpoint Failure Detection
+
+ An endpoint shall keep a counter on the total number of consecutive
+ retransmissions to its peer (including retransmissions to all the
+ destination transport addresses of the peer if it is multi-homed).
+ If the value of this counter exceeds the limit indicated in the
+ protocol parameter 'Association.Max.Retrans', the endpoint shall
+ consider the peer endpoint unreachable and shall stop transmitting
+ any more data to it (and thus the association enters the CLOSED
+ state). In addition, the endpoint shall report the failure to the
+ upper layer, and optionally report back all outstanding user data
+ remaining in its outbound queue. The association is automatically
+ closed when the peer endpoint becomes unreachable.
+
+ 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-ACK is received from the peer endpoint.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stewart, et al. Informational [Page 26]
+
+RFC 4460 SCTP Errata April 2006
+
+
+ ---------
+ New text: (Section 8.1)
+ ---------
+
+ 8.1. Endpoint Failure Detection
+
+ 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. If the value of this
+ counter exceeds the limit indicated in the protocol parameter
+ 'Association.Max.Retrans', the endpoint shall consider the peer
+ endpoint unreachable and shall stop transmitting any more data to it
+ (and thus the association enters the CLOSED state). In addition, the
+ endpoint MAY report the failure to the upper layer and optionally
+ report back all outstanding user data remaining in its outbound
+ queue. The association is automatically closed when the peer
+ endpoint becomes unreachable.
+
+ 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-ACK is received from the peer endpoint.
+
+
+ ---------
+ Old text: (Section 8.3)
+ ---------
+
+ 8.3 Path Heartbeat
+
+ By default, an SCTP endpoint shall monitor the reachability of the
+ idle destination transport address(es) of its peer by sending a
+ HEARTBEAT chunk periodically to the destination transport
+ address(es).
+
+ ---------
+ New text: (Section 8.3)
+ ---------
+
+ 8.3 Path Heartbeat
+
+ By default, an SCTP endpoint SHOULD monitor the reachability of the
+ idle destination transport address(es) of its peer by sending a
+ HEARTBEAT chunk periodically to the destination transport
+ address(es). HEARTBEAT sending MAY begin upon reaching the
+ ESTABLISHED state and is discontinued after sending either SHUTDOWN
+ or SHUTDOWN-ACK. A receiver of a HEARTBEAT MUST respond to a
+ HEARTBEAT with a HEARTBEAT-ACK after entering the COOKIE-ECHOED state
+
+
+
+Stewart, et al. Informational [Page 27]
+
+RFC 4460 SCTP Errata April 2006
+
+
+ (INIT sender) or the ESTABLISHED state (INIT receiver), up until
+ reaching the SHUTDOWN-SENT state (SHUTDOWN sender) or the SHUTDOWN-
+ ACK-SENT state (SHUTDOWN receiver).
+
+
+ ---------
+ Old text: (Section 8.3)
+ ---------
+
+ The receiver of the HEARTBEAT should immediately respond with a
+ HEARTBEAT ACK that contains the Heartbeat Information field copied
+ from the received HEARTBEAT chunk.
+
+ ---------
+ New text: (Section 8.3)
+ ---------
+
+ The receiver of the HEARTBEAT should immediately respond with a
+ HEARTBEAT ACK that contains the Heartbeat Information TLV, together
+ with any other received TLVs, copied unchanged from the received
+ HEARTBEAT chunk.
+
+
+ ---------
+ Old text: (Section 8.3)
+ ---------
+
+ On an idle destination address that is allowed to heartbeat, a
+ HEARTBEAT chunk is RECOMMENDED to be sent once per RTO of that
+ destination address plus the protocol parameter 'HB.interval' , with
+ jittering of +/- 50%, and exponential back-off of the RTO if the
+ previous HEARTBEAT is unanswered.
+
+ ---------
+ New text: (Section 8.3)
+ ---------
+
+ On an idle destination address that is allowed to heartbeat, it is
+ recommended that a HEARTBEAT chunk is sent once per RTO of that
+ destination address plus the protocol parameter 'HB.interval', with
+ jittering of +/- 50% of the RTO value, and exponential back-off of
+ the RTO if the previous HEARTBEAT is unanswered.
+
+2.10.3. Solution Description
+
+ The above text provides guidance as to how to respond to the five
+ issues mentioned in Section 2.10.1. In particular, the wording
+ changes provide guidance as to when to start and stop heartbeating,
+
+
+
+Stewart, et al. Informational [Page 28]
+
+RFC 4460 SCTP Errata April 2006
+
+
+ how to respond to a heartbeat with extra parameters, and it clarifies
+ the error counting procedures for the association.
+
+2.11. Security interactions with firewalls
+
+2.11.1. Description of the Problem
+
+ When dealing with firewalls, it is advantageous for the firewall to
+ be able to properly determine the initial startup sequence of a
+ reliable transport protocol. With this in mind, the following text
+ is to be added to SCTP's security section.
+
+2.11.2. Text Changes to the Document
+
+ ---------
+ New text: (no old text, new section added)
+ ---------
+
+ 11.4 SCTP Interactions with Firewalls
+
+ It is helpful for some firewalls if they can inspect
+ just the first fragment of a fragmented SCTP packet and unambiguously
+ determine whether it corresponds to an INIT chunk (for further
+ information, please refer to RFC1858). Accordingly, we
+ stress the requirements, stated in 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 chunk MUST have a zero Verification Tag.
+ Furthermore, we require that the receiver of an INIT chunk MUST
+ enforce these rules by silently discarding an arriving packet with an
+ INIT chunk that is bundled with other chunks.
+
+ ---------
+ Old text: (Section 18)
+ ---------
+
+ 18. Bibliography
+
+ [ALLMAN99] Allman, M. and Paxson, V., "On Estimating End-to-End
+ Network Path Properties", Proc. SIGCOMM'99, 1999.
+
+ [FALL96] Fall, K. and Floyd, S., Simulation-based Comparisons of
+ Tahoe, Reno, and SACK TCP, Computer Communications Review,
+ V. 26 N. 3, July 1996, pp. 5-21.
+
+ [RFC1750] Eastlake, D. (ed.), "Randomness Recommendations for
+ Security", RFC 1750, December 1994.
+
+
+
+
+
+Stewart, et al. Informational [Page 29]
+
+RFC 4460 SCTP Errata April 2006
+
+
+ [RFC1950] Deutsch P. and J. Gailly, "ZLIB Compressed Data Format
+ Specification version 3.3", RFC 1950, May 1996.
+
+ [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-
+ Hashing for Message Authentication", RFC 2104, March 1997.
+
+ [RFC2196] Fraser, B., "Site Security Handbook", FYI 8, RFC 2196,
+ September 1997.
+
+ [RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management
+ Protocol", RFC 2522, March 1999.
+
+ [SAVAGE99] Savage, S., Cardwell, N., Wetherall, D., and Anderson, T.,
+ "TCP Congestion Control with a Misbehaving Receiver", ACM
+ Computer Communication Review, 29(5), October 1999.
+
+ ---------
+ New text: (Section 18)
+ ---------
+
+ 18. Bibliography
+
+ [ALLMAN99] Allman, M. and Paxson, V., "On Estimating End-to-End
+ Network Path Properties", Proc. SIGCOMM'99, 1999.
+
+ [FALL96] Fall, K. and Floyd, S., Simulation-based Comparisons of
+ Tahoe, Reno, and SACK TCP, Computer Communications Review,
+ V. 26 N. 3, July 1996, pp. 5-21.
+
+ [RFC1750] Eastlake, D. (ed.), "Randomness Recommendations for
+ Security", RFC 1750, December 1994.
+
+ [RFC1858] Ziemba, G., Reed, D. and Traina P., "Security
+ Considerations for IP Fragment Filtering", RFC 1858,
+ October 1995.
+
+ [RFC1950] Deutsch P. and J. Gailly, "ZLIB Compressed Data Format
+ Specification version 3.3", RFC 1950, May 1996.
+
+ [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-
+ Hashing for Message Authentication", RFC 2104, March 1997.
+
+ [RFC2196] Fraser, B., "Site Security Handbook", FYI 8, RFC 2196,
+ September 1997.
+
+ [RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management
+ Protocol", RFC 2522, March 1999.
+
+
+
+
+Stewart, et al. Informational [Page 30]
+
+RFC 4460 SCTP Errata April 2006
+
+
+ [SAVAGE99] Savage, S., Cardwell, N., Wetherall, D., and Anderson, T.,
+ "TCP Congestion Control with a Misbehaving Receiver", ACM
+ Computer Communication Review, 29(5), October 1999.
+
+2.11.3. Solution Description
+
+ The above text, which adds a new subsection to the Security
+ Considerations section of RFC 2960 [5] makes clear that, to make
+ easier the interaction with firewalls, an INIT chunk must not be
+ bundled in any case with any other chunk that will silently discard
+ the packets that do not follow this rule (this rule is enforced by
+ the packet receiver).
+
+2.12. Shutdown Ambiguity
+
+2.12.1. Description of the Problem
+
+ Currently, there is an ambiguity between the statements in Sections
+ 6.2 and 9.2. Section 6.2 allows the sending of a SHUTDOWN chunk in
+ place of a SACK when the sender is in the process of shutting down,
+ while section 9.2 requires that both a SHUTDOWN chunk and a SACK
+ chunk be sent.
+
+ Along with this ambiguity there is a problem wherein an errant
+ SHUTDOWN receiver may fail to stop accepting user data.
+
+2.12.2. Text Changes to the Document
+
+ ---------
+ Old text: (Section 9.2)
+ ---------
+
+ If there are still outstanding DATA chunks left, the SHUTDOWN
+ receiver shall continue to follow normal data transmission procedures
+ defined in Section 6 until all outstanding DATA chunks are
+ acknowledged; however, the SHUTDOWN receiver MUST NOT accept new data
+ from its SCTP user.
+
+ While in SHUTDOWN-SENT state, the SHUTDOWN sender MUST immediately
+ respond to each received packet containing one or more DATA chunk(s)
+ with a SACK, a SHUTDOWN chunk, and restart the T2-shutdown timer. If
+ it has no more outstanding DATA chunks, the SHUTDOWN receiver shall
+ send a SHUTDOWN ACK and start a T2-shutdown timer of its own,
+ entering the SHUTDOWN-ACK-SENT state. If the timer expires, the
+ endpoint must re-send the SHUTDOWN ACK.
+
+
+
+
+
+
+Stewart, et al. Informational [Page 31]
+
+RFC 4460 SCTP Errata April 2006
+
+
+ ---------
+ New text: (Section 9.2)
+ ---------
+
+ If there are still outstanding DATA chunks left, the SHUTDOWN
+ receiver MUST continue to follow normal data transmission procedures
+ defined in Section 6, until all outstanding DATA chunks are
+ acknowledged; however, the SHUTDOWN receiver MUST NOT accept new data
+ from its SCTP user.
+
+ While in SHUTDOWN-SENT state, the SHUTDOWN sender MUST immediately
+ respond to each received packet containing one or more DATA chunks
+ with a SHUTDOWN chunk and restart the T2-shutdown timer. If a
+ SHUTDOWN chunk by itself cannot acknowledge all of the received DATA
+ chunks (i.e., there are TSNs that can be acknowledged that are larger
+ than the cumulative TSN, and thus gaps exist in the TSN sequence), or
+ if duplicate TSNs have been received, then a SACK chunk MUST also be
+ sent.
+
+ The sender of the SHUTDOWN MAY also start an overall guard timer
+ 'T5-shutdown-guard' to bound the overall time for shutdown sequence.
+ At the expiration of this timer, the sender SHOULD abort the
+ association by sending an ABORT chunk. If the 'T5-shutdown-guard'
+ timer is used, it SHOULD be set to the recommended value of 5 times
+ 'RTO.Max'.
+
+ If the receiver of the SHUTDOWN has no more outstanding DATA chunks,
+ the SHUTDOWN receiver MUST send a SHUTDOWN ACK and start a
+ T2-shutdown timer of its own, entering the SHUTDOWN-ACK-SENT state.
+ If the timer expires, the endpoint must re-send the SHUTDOWN ACK.
+
+2.12.3. Solution Description
+
+ The above text clarifies the use of a SACK in conjunction with a
+ SHUTDOWN chunk. It also adds a guard timer to the SCTP shutdown
+ sequence to protect against errant receivers of SHUTDOWN chunks.
+
+2.13. Inconsistency in ABORT Processing
+
+2.13.1. Description of the Problem
+
+ It was noted that the wording in Section 8.5.1 did not give proper
+ directions in the use of the 'T bit' with the Verification Tags.
+
+
+
+
+
+
+
+
+Stewart, et al. Informational [Page 32]
+
+RFC 4460 SCTP Errata April 2006
+
+
+2.13.2. Text changes to the document
+
+ ---------
+ Old text: (Section 8.5.1)
+ ---------
+
+ B) Rules for packet carrying ABORT:
+
+ - The endpoint shall always fill in the Verification Tag field
+ of the outbound packet with the destination endpoint's tag
+ value if it is known.
+
+ - If the ABORT is sent in response to an OOTB packet, the
+ endpoint MUST follow the procedure described in Section 8.4.
+
+ - The receiver MUST accept the packet if the Verification Tag
+ matches either its own tag, OR the tag of its peer. Otherwise,
+ the receiver MUST silently discard the packet and take no
+ further action.
+
+ ---------
+ New text: (Section 8.5.1)
+ ---------
+
+ B) Rules for packet carrying ABORT:
+
+ - The endpoint MUST always fill in the Verification Tag field of
+ the outbound packet with the destination endpoint's tag value,
+ if it is known.
+
+ - If the ABORT is sent in response to an OOTB packet, the
+ endpoint MUST follow the procedure described in Section 8.4.
+
+ - The receiver of a ABORT MUST accept the packet if the
+ Verification Tag field of the packet matches its own tag OR if
+ it is set to its peer's tag and the T bit is set in the Chunk
+ Flags. Otherwise, the receiver MUST silently discard the
+ packet and take no further action.
+
+2.13.3. Solution Description
+
+ The above text change clarifies that the T bit must be set before an
+ implementation looks for the peer's tag.
+
+
+
+
+
+
+
+
+Stewart, et al. Informational [Page 33]
+
+RFC 4460 SCTP Errata April 2006
+
+
+2.14. Cwnd Gated by Its Full Use
+
+2.14.1. Description of the Problem
+
+ A problem was found with the current specification of the growth and
+ decay of cwnd. The cwnd should only be increased if it is being
+ fully utilized, and after periods of underutilization, the cwnd
+ should be decreased. In some sections, the current wording is weak
+ and is not clearly defined. Also, the current specification
+ unnecessarily introduces the need for special case code to ensure
+ cwnd degradation. Plus, the cwnd should not be increased during Fast
+ Recovery, since a full cwnd during Fast Recovery does not qualify the
+ cwnd as being fully utilized. Additionally, multiple loss scenarios
+ in a single window may cause the cwnd to grow more rapidly as the
+ number of losses in a window increases [3].
+
+2.14.2. Text Changes to the Document
+
+ ---------
+ Old text: (Section 6.1)
+ ---------
+
+ D) Then, the sender can send out as many new DATA chunks as Rule A
+ and Rule B above allow.
+
+ ---------
+ New text: (Section 6.1)
+ ---------
+
+ D) When the time comes for the sender to transmit new DATA chunks,
+ the protocol parameter Max.Burst SHOULD be used to limit the
+ number of packets sent. The limit MAY be applied by adjusting
+ cwnd as follows:
+
+ if((flightsize + Max.Burst*MTU) < cwnd)
+ cwnd = flightsize + Max.Burst*MTU
+
+ Or it MAY be applied by strictly limiting the number of packets
+ emitted by the output routine.
+
+ E) Then, the sender can send out as many new DATA chunks as Rule A
+ and Rule B allow.
+
+
+
+
+
+
+
+
+
+Stewart, et al. Informational [Page 34]
+
+RFC 4460 SCTP Errata April 2006
+
+
+ ---------
+ Old text: (Section 7.2.1)
+ ---------
+
+ o When cwnd is less than or equal to ssthresh an SCTP endpoint MUST
+ use the slow start algorithm to increase cwnd (assuming the
+ current congestion window is being fully utilized). If an
+ incoming SACK advances the Cumulative TSN Ack Point, cwnd MUST be
+ increased by at most the lesser of 1) the total size of the
+ previously outstanding DATA chunk(s) acknowledged, and 2) the
+ destination's path MTU. This protects against the ACK-Splitting
+ attack outlined in [SAVAGE99].
+
+ ---------
+ New text: (Section 7.2.1)
+ ---------
+
+ o When cwnd is less than or equal to ssthresh, an SCTP endpoint MUST
+ use the slow start algorithm to increase cwnd only if the current
+ congestion window is being fully utilized, an incoming SACK
+ advances the Cumulative TSN Ack Point, and the data sender is not
+ in Fast Recovery. Only when these three conditions are met can
+ the cwnd be increased; otherwise, the cwnd MUST not be increased.
+ If these conditions are met, then cwnd MUST be increased by, at
+ most, the lesser of 1) the total size of the previously
+ outstanding DATA chunk(s) acknowledged, and 2) the destination's
+ path MTU. This upper bound protects against the ACK-Splitting
+ attack outlined in [SAVAGE99].
+
+
+ ---------
+ Old text: (Section 14)
+ ---------
+
+ 14. Suggested SCTP Protocol Parameter Values
+
+ The following protocol parameters are RECOMMENDED:
+
+ RTO.Initial - 3 seconds
+ RTO.Min - 1 second
+ RTO.Max - 60 seconds
+ 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
+
+
+
+Stewart, et al. Informational [Page 35]
+
+RFC 4460 SCTP Errata April 2006
+
+
+ ---------
+ New text: (Section 14)
+ ---------
+
+ 14. 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
+
+2.14.3. Solution Description
+
+ The above changes strengthen the rules and make it much more apparent
+ as to the need to block cwnd growth when the full cwnd is not being
+ utilized. The changes also apply cwnd degradation without
+ introducing the need for complex special case code.
+
+2.15. Window Probes in SCTP
+
+2.15.1. Description of the Problem
+
+ When a receiver clamps its rwnd to 0 to flow control the peer, the
+ specification implies that one must continue to accept data from the
+ remote peer. This is incorrect and needs clarification.
+
+2.15.2. Text Changes to the Document
+
+ ---------
+ Old text: (Section 6.2)
+ ---------
+
+ The SCTP endpoint MUST always acknowledge the receipt of each valid
+ DATA chunk.
+
+
+
+
+
+
+
+
+Stewart, et al. Informational [Page 36]
+
+RFC 4460 SCTP Errata April 2006
+
+
+ ---------
+ New text: (Section 6.2)
+ ---------
+
+ 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 RFC 813. The algorithm can be
+ similar to the one described in Section 4.2.3.3 of RFC 1122.
+
+
+ ---------
+ Old text: (Section 6.1)
+ ---------
+
+ A) At any given time, the data sender MUST NOT transmit new data to
+ any destination transport address if its peer's rwnd indicates
+ that the peer has no buffer space (i.e., rwnd is 0, see Section
+ 6.2.1). However, regardless of the value of rwnd (including if it
+ is 0), the data sender can always have one DATA chunk in flight to
+ the 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 due to the SACK having been lost in transit from the data
+ receiver to the data sender.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stewart, et al. Informational [Page 37]
+
+RFC 4460 SCTP Errata April 2006
+
+
+ ---------
+ New text: (Section 6.1)
+ ---------
+
+ A) At any given time, the data sender MUST NOT transmit new data to
+ any destination transport address if its peer's rwnd indicates
+ that the peer has no buffer space (i.e., rwnd is 0; see Section
+ 6.2.1). However, regardless of the value of rwnd (including if it
+ is 0), the data sender can always have one DATA chunk in flight to
+ the 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 due to the SACK's having been lost in transit from the data
+ receiver to the data sender.
+
+ When the receiver's advertised window is zero, this probe is
+ called a zero window probe. Note that a zero window probe
+ SHOULD only be sent when all outstanding DATA chunks have
+ been cumulatively acknowledged and no DATA chunks are in
+ flight. Zero window probing MUST be supported.
+
+ If the sender continues to receive new packets from the receiver
+ while doing zero window probing, the unacknowledged window probes
+ should not increment the error counter for the association or any
+ destination transport address.This is because the receiver MAY
+ keep its window closed for an indefinite time. Refer to
+ Section 6.2 on the receiver behavior when it advertises a zero
+ window. The sender SHOULD send the first zero window probe after
+ 1 RTO when it detects that the receiver has closed its window
+ and SHOULD increase the probe interval exponentially afterwards.
+ Also note that the cwnd SHOULD be adjusted according to
+ Section 7.2.1. Zero window probing does not affect the
+ calculation of cwnd.
+
+ The sender MUST also have an algorithm for sending new DATA chunks
+ to avoid silly window syndrome (SWS) as described in RFC 813. The
+ algorithm can be similar to the one described in Section 4.2.3.4
+ of RFC 1122.
+
+2.15.3. Solution Description
+
+ The above allows a receiver to drop new data that arrives and yet
+ still requires the receiver to send a SACK showing the conditions
+ unchanged (with the possible exception of a new a_rwnd) and the
+ dropped chunk as missing. This will allow the association to
+ continue until the rwnd condition clears.
+
+
+
+
+
+
+Stewart, et al. Informational [Page 38]
+
+RFC 4460 SCTP Errata April 2006
+
+
+2.16. Fragmentation and Path MTU Issues
+
+2.16.1. Description of the Problem
+
+ The current wording of the Fragmentation and Reassembly forces an
+ implementation that supports fragmentation to always fragment. This
+ prohibits an implementation from offering its users an option to
+ disable sends that exceed the SCTP fragmentation point.
+
+ The restriction in RFC 2960 [5], Section 6.9, was never meant to
+ restrict an implementations API from this behavior.
+
+2.16.2. Text Changes to the Document
+
+ ---------
+ Old text: (Section 6.1)
+ ---------
+
+ 6.9 Fragmentation and Reassembly
+
+ An endpoint MAY support fragmentation when sending DATA chunks, but
+ MUST support reassembly when receiving DATA chunks. If an endpoint
+ supports fragmentation, it MUST fragment a user message if the size
+ of the user message to be sent causes the outbound SCTP packet size
+ to exceed the current MTU. If an implementation does not support
+ fragmentation of outbound user messages, the endpoint must return an
+ error to its upper layer and not attempt to send the user message.
+
+ IMPLEMENTATION NOTE: In this error case, the Send primitive
+ discussed in Section 10.1 would need to return an error to the upper
+ layer.
+
+ ---------
+ New text: (Section 6.1)
+ ---------
+
+ 6.9. Fragmentation and Reassembly
+
+ An endpoint MAY support fragmentation when sending DATA chunks, but
+ it MUST support reassembly when receiving DATA chunks. If an
+ endpoint supports fragmentation, it MUST fragment a user message if
+ the size of the user message to be sent causes the outbound SCTP
+ packet size to exceed the current MTU. If an implementation does not
+ support fragmentation of outbound user messages, the endpoint MUST
+ return an error to its upper layer and not attempt to send the user
+ message.
+
+
+
+
+
+Stewart, et al. Informational [Page 39]
+
+RFC 4460 SCTP Errata April 2006
+
+
+ Note: If an implementation that supports fragmentation makes
+ available to its upper layer a mechanism to turn off fragmentation it
+ may do so. However, in so doing, it MUST react just like an
+ implementation that does NOT support fragmentation, i.e., it MUST
+ reject sends that exceed the current P-MTU.
+
+ IMPLEMENTATION NOTE: In this error case, the Send primitive
+ discussed in Section 10.1 would need to return an error to the upper
+ layer.
+
+2.16.3. Solution Description
+
+ The above wording will allow an implementation to offer the option of
+ rejecting sends that exceed the P-MTU size even when the
+ implementation supports fragmentation.
+
+2.17. Initial Value of the Cumulative TSN Ack
+
+2.17.1. Description of the Problem
+
+ The current description of the SACK chunk within the RFC does not
+ clearly state the value that would be put within a SACK when no DATA
+ chunk has been received.
+
+2.17.2. Text Changes to the Document
+
+ ---------
+ Old text: (Section 3.3.4)
+ ---------
+
+ Cumulative TSN Ack: 32 bits (unsigned integer)
+
+ This parameter contains the TSN of the last DATA chunk received in
+ sequence before a gap.
+
+ ---------
+ New text: (Section 3.3.4)
+ ---------
+
+ Cumulative TSN Ack: 32 bits (unsigned integer)
+
+ This parameter contains the TSN of the last DATA chunk received in
+ sequence before a gap. In the case where no DATA chunk has
+ been received, this value is set to the peer's Initial TSN minus
+ one.
+
+
+
+
+
+
+Stewart, et al. Informational [Page 40]
+
+RFC 4460 SCTP Errata April 2006
+
+
+2.17.3. Solution Description
+
+ This change clearly states what the initial value will be for a SACK
+ sender.
+
+2.18. Handling of Address Parameters within the INIT or INIT-ACK
+
+2.18.1. Description of the Problem
+
+ The current description on handling address parameters contained
+ within the INIT and INIT-ACK does not fully describe a requirement
+ for their handling.
+
+2.18.2. Text Changes to the Document
+
+ ---------
+ Old text: (Section 5.1.2)
+ ---------
+
+ C) If there are only IPv4/IPv6 addresses present in the received INIT
+ or INIT ACK chunk, the receiver shall derive and record all the
+ transport address(es) from the received chunk AND the source IP
+ address that sent the INIT or INIT ACK. The transport address(es)
+ are derived by the combination of SCTP source port (from the
+ common header) and the IP address parameter(s) carried in the INIT
+ or INIT ACK chunk and the source IP address of the IP datagram.
+ The receiver should use only these transport addresses as
+ destination transport addresses when sending subsequent packets to
+ its peer.
+
+ ---------
+ New text: (Section 5.1.2)
+ ---------
+
+ C) If there are only IPv4/IPv6 addresses present in the received INIT
+ or INIT ACK chunk, the receiver MUST derive and record all the
+ transport addresses from the received chunk AND the source IP
+ address that sent the INIT or INIT ACK. The transport addresses
+ are derived by the combination of SCTP source port (from the
+ common header) and the IP address parameter(s) carried in the INIT
+ or INIT ACK chunk and the source IP address of the IP datagram.
+ The receiver should use only these transport addresses as
+ destination transport addresses when sending subsequent packets to
+ its peer.
+
+
+
+
+
+
+
+Stewart, et al. Informational [Page 41]
+
+RFC 4460 SCTP Errata April 2006
+
+
+ D) An INIT or INIT ACK chunk MUST be treated as belonging
+ to an already established association (or one in the
+ process of being established) if the use of any of the
+ valid address parameters contained within the chunk
+ would identify an existing TCB.
+
+2.18.3. Solution description
+
+ This new text clearly specifies to an implementor the need to look
+ within the INIT or INIT ACK. Any implementation that does not do
+ this may (for example) not be able to recognize an INIT chunk coming
+ from an already established association that adds new addresses (see
+ Section 2.6) or an incoming INIT ACK chunk sent from a source address
+ different from the destination address used to send the INIT chunk.
+
+2.19. Handling of Stream Shortages
+
+2.19.1. Description of the Problem
+
+ The current wording in the RFC places the choice of sending an ABORT
+ upon the SCTP stack when a stream shortage occurs. This decision
+ should really be made by the upper layer, not the SCTP stack.
+
+2.19.2. Text Changes to the Document
+
+ ---------
+ Old text:
+ ---------
+
+ 5.1.1 Handle Stream Parameters
+
+ In the INIT and INIT ACK chunks, the sender of the chunk shall
+ indicate the number of outbound streams (OS) it wishes to have in
+ the association, as well as the maximum inbound streams (MIS) it
+ will accept from the other endpoint.
+
+ After receiving the stream configuration information from the other
+ side, each endpoint shall perform the following check: If the peer's
+ MIS is less than the endpoint's OS, meaning that the peer is
+ incapable of supporting all the outbound streams the endpoint wants
+ to configure, the endpoint MUST either use MIS outbound streams, or
+ abort the association and report to its upper layer the resources
+ shortage at its peer.
+
+
+
+
+
+
+
+
+Stewart, et al. Informational [Page 42]
+
+RFC 4460 SCTP Errata April 2006
+
+
+ ---------
+ New text: (Section 5.1.2)
+ ---------
+
+ 5.1.1. Handle Stream Parameters
+
+ In the INIT and INIT ACK chunks, the sender of the chunk MUST
+ indicate the number of outbound streams (OS) it wishes to have in
+ the association, as well as the maximum inbound streams (MIS) it will
+ accept from the other endpoint.
+
+ After receiving the stream configuration information from the other
+ side, each endpoint MUST perform the following check: If the peer's
+ MIS is less than the endpoint's OS, meaning that the peer is
+ incapable of supporting all the outbound streams the endpoint wants
+ to configure, the endpoint MUST use MIS outbound streams and MAY
+ report any shortage to the upper layer. The upper layer can then
+ choose to abort the association if the resource shortage
+ is unacceptable.
+
+2.19.3. Solution Description
+
+ The above changes take the decision to ABORT out of the realm of the
+ SCTP stack and place it into the user's hands.
+
+2.20. Indefinite Postponement
+
+2.20.1. Description of the Problem
+
+ The current RFC does not provide any guidance on the assignment of
+ TSN sequence numbers to outbound messages nor reception of these
+ messages. This could lead to a possible indefinite postponement.
+
+2.20.2. Text Changes to the Document
+
+ ---------
+ Old text: (Section 6.1)
+ ---------
+
+ Note: The data sender SHOULD NOT use a TSN that is more than 2**31 -
+ 1 above the beginning TSN of the current send window.
+
+ 6.2 Acknowledgement on Reception of DATA Chunks
+
+
+
+
+
+
+
+
+Stewart, et al. Informational [Page 43]
+
+RFC 4460 SCTP Errata April 2006
+
+
+ ---------
+ New text: (Section 6.1)
+ ---------
+
+ Note: The data sender SHOULD NOT use a TSN that is more than 2**31 -
+ 1 above the beginning TSN of the current send window.
+
+ The algorithm by which an implementation assigns sequential TSNs to
+ messages on a particular association MUST ensure that no user
+ message that has been accepted by SCTP is indefinitely postponed
+ from being assigned a TSN. Acceptable algorithms for assigning TSNs
+ include
+
+ (a) assigning TSNs in round-robin order over all streams with
+ pending data; and
+
+ (b) preserving the linear order in which the user messages were
+ submitted to the SCTP association.
+
+ When an upper layer requests to read data on an SCTP association,
+ the SCTP receiver SHOULD choose the message with the lowest TSN from
+ among all deliverable messages. In SCTP implementations that allow a
+ user to request data on a specific stream, this operation SHOULD NOT
+ block if data is not available, since this can lead to a deadlock
+ under certain conditions.
+
+ 6.2. Acknowledgement on Receipt of DATA Chunks
+
+2.20.3. Solution Description
+
+ The above wording clarifies how TSNs SHOULD be assigned by the
+ sender.
+
+2.21. User-Initiated Abort of an Association
+
+2.21.1. Description of the Problem
+
+ It is not possible for an upper layer to abort the association and
+ provide the peer with an indication of why the association is
+ aborted.
+
+2.21.2. Text changes to the document
+
+ Some of the changes given here already include changes suggested in
+ Section 2.6 of this document.
+
+
+
+
+
+
+Stewart, et al. Informational [Page 44]
+
+RFC 4460 SCTP Errata April 2006
+
+
+ ---------
+ Old text: (Section 3.3.10)
+ ---------
+
+ Cause Code
+ Value Cause Code
+ --------- ----------------
+ 1 Invalid Stream Identifier
+ 2 Missing Mandatory Parameter
+ 3 Stale Cookie Error
+ 4 Out of Resource
+ 5 Unresolvable Address
+ 6 Unrecognized Chunk Type
+ 7 Invalid Mandatory Parameter
+ 8 Unrecognized Parameters
+ 9 No User Data
+ 10 Cookie Received While Shutting Down
+
+ Cause Length: 16 bits (unsigned integer)
+
+ Set to the size of the parameter in bytes, including the Cause
+ Code, Cause Length, and Cause-Specific Information fields
+
+ Cause-specific Information: variable length
+
+ This field carries the details of the error condition.
+
+ Sections 3.3.10.1 - 3.3.10.10 define error causes for SCTP.
+ Guidelines for the IETF to define new error cause values are
+ discussed in Section 13.3.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stewart, et al. Informational [Page 45]
+
+RFC 4460 SCTP Errata April 2006
+
+
+ ---------
+ New text: (Section 3.3.10)
+ ---------
+
+ Cause Code
+ Value Cause Code
+ --------- ----------------
+ 1 Invalid Stream Identifier
+ 2 Missing Mandatory Parameter
+ 3 Stale Cookie Error
+ 4 Out of Resource
+ 5 Unresolvable Address
+ 6 Unrecognized Chunk Type
+ 7 Invalid Mandatory Parameter
+ 8 Unrecognized Parameters
+ 9 No User Data
+ 10 Cookie Received While Shutting Down
+ 11 Restart of an Association with New Addresses
+ 12 User-Initiated Abort
+
+ Cause Length: 16 bits (unsigned integer)
+
+ Set to the size of the parameter in bytes, including the Cause
+ Code, Cause Length, and Cause-Specific Information fields
+
+ Cause-specific Information: variable length
+
+ This field carries the details of the error condition.
+
+ Sections 3.3.10.1 - 3.3.10.12 define error causes for SCTP.
+ Guidelines for the IETF to define new error cause values are
+ discussed in Section 13.3.
+
+ ---------
+ New text: (Note: no old text, new error added in Section 3.3.10)
+ ---------
+
+ 3.3.10.12. User-Initiated Abort (12)
+
+ Cause of error
+ --------------
+
+ This error cause MAY be included in ABORT chunks that are sent
+ because of an upper layer request. The upper layer can specify
+ an Upper Layer Abort Reason that is transported by SCTP
+ transparently and MAY be delivered to the upper layer protocol
+ at the peer.
+
+
+
+
+Stewart, et al. Informational [Page 46]
+
+RFC 4460 SCTP Errata April 2006
+
+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Cause Code=12 | Cause Length=Variable |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ / Upper Layer Abort Reason /
+ \ \
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ ---------
+ Old text: (Section 9.1)
+ ---------
+
+ 9.1 Abort of an Association
+
+ When an endpoint decides to abort an existing association, it
+ shall send an ABORT chunk to its peer endpoint. The sender MUST
+ fill in the peer's Verification Tag in the outbound packet and
+ MUST NOT bundle any DATA chunk with the ABORT.
+
+ An endpoint MUST NOT respond to any received packet that contains
+ an ABORT chunk (also see Section 8.4).
+
+ An endpoint receiving an ABORT shall apply the special
+ Verification Tag check rules described in Section 8.5.1.
+
+ After checking the Verification Tag, the receiving endpoint shall
+ remove the association from its record and shall report the
+ termination to its upper layer.
+
+ ---------
+ New text: (Section 9.1)
+ ---------
+
+ 9.1. Abort of an Association
+
+ When an endpoint decides to abort an existing association, it MUST
+ send an ABORT chunk to its peer endpoint. The sender MUST fill in
+ the peer's Verification Tag in the outbound packet and MUST NOT
+ bundle any DATA chunk with the ABORT. If the association is
+ aborted on request of the upper layer, a User-Initiated Abort
+ error cause (see 3.3.10.12) SHOULD be present in the ABORT chunk.
+
+ An endpoint MUST NOT respond to any received packet that contains
+ an ABORT chunk (also see Section 8.4).
+
+ An endpoint receiving an ABORT MUST apply the special Verification
+ Tag check rules described in Section 8.5.1.
+
+ After checking the Verification Tag, the receiving endpoint MUST
+
+
+
+Stewart, et al. Informational [Page 47]
+
+RFC 4460 SCTP Errata April 2006
+
+
+ remove the association from its record and SHOULD report the
+ termination to its upper layer. If a User-Initiated Abort error
+ cause is present in the ABORT chunk, the Upper Layer Abort Reason
+ SHOULD be made available to the upper layer.
+
+ ---------
+ Old text: (Section 10.1)
+ ---------
+
+ D) Abort
+
+ Format: ABORT(association id [, cause code])
+ -> 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 abortion 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 cause code - reason of the abort to be passed to the peer.
+
+
+ ---------
+ New text: (Section 10.1)
+ ---------
+
+ 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 abortion 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.
+
+
+
+
+Stewart, et al. Informational [Page 48]
+
+RFC 4460 SCTP Errata April 2006
+
+
+ Optional attributes:
+
+ o Upper Layer Abort Reason - Reason of the abort to be passed
+ to the peer.
+
+ None.
+
+ ---------
+ Old text: (Section 10.2)
+ ---------
+
+ E) COMMUNICATION LOST notification
+
+ When SCTP loses communication to an endpoint completely (e.g., via
+ Heartbeats) or detects that the endpoint has performed an abort
+ operation, it shall invoke this notification on the ULP.
+
+ The following shall be passed with the notification:
+
+ o association id - local handle to the SCTP association
+
+ o status - This indicates what type of event has occurred; The
+ status may indicate a failure OR a normal termination
+ event occurred in response to a shutdown or abort
+ request.
+
+ The following may be passed with the notification:
+
+ o data retrieval id - an identification used to retrieve
+ unsent and unacknowledged data.
+
+ o last-acked - the TSN last acked by that peer endpoint;
+
+ o last-sent - the TSN last sent to that peer endpoint;
+
+ ---------
+ New text: (Section 10.2)
+ ---------
+
+ E) COMMUNICATION LOST notification
+
+ When SCTP loses communication to an endpoint completely (e.g., via
+ Heartbeats) or detects that the endpoint has performed an abort
+ operation, it shall invoke this notification on the ULP.
+
+ The following shall be passed with the notification:
+
+ o association id - Local handle to the SCTP association.
+
+
+
+Stewart, et al. Informational [Page 49]
+
+RFC 4460 SCTP Errata April 2006
+
+
+ o status - This indicates what type of event has occurred; The
+ status may indicate that a failure OR a normal
+ termination event occurred in response to a shutdown
+ or abort request.
+
+ The following may be passed with the notification:
+
+ o data retrieval id - An identification used to retrieve unsent
+ and unacknowledged data.
+
+ o last-acked - The TSN last acked by that peer endpoint.
+
+ o last-sent - The TSN last sent to that peer endpoint.
+
+ o Upper Layer Abort Reason - The abort reason specified in
+ case of a user-initiated abort.
+
+2.21.3. Solution Description
+
+ The above allows an upper layer to provide its peer with an
+ indication of why the association was aborted. Therefore, an
+ addition error cause was introduced.
+
+2.22. Handling of Invalid Initiate Tag of INIT-ACK
+
+2.22.1. Description of the Problem
+
+ RFC 2960 requires that the receiver of an INIT-ACK with the Initiate
+ Tag set to zero handles this as an error and sends back an ABORT.
+ But the sender of the INIT-ACK normally has no TCB, and thus the
+ ABORT is useless.
+
+2.22.2. Text Changes to the Document
+
+ ---------
+ Old text: (Section 3.3.3)
+ ---------
+
+ Initiate Tag: 32 bits (unsigned integer)
+
+ The receiver of the INIT ACK records the value of the
+ Initiate Tag parameter. This value MUST be placed into
+ the Verification Tag field of every SCTP packet that the
+ INIT ACK receiver transmits within this association.
+
+ The Initiate Tag MUST NOT take the value 0. See Section 5.3.1
+ for more on the selection of the Initiate Tag value.
+
+
+
+
+Stewart, et al. Informational [Page 50]
+
+RFC 4460 SCTP Errata April 2006
+
+
+ If the value of the Initiate Tag in a received INIT ACK chunk
+ is found to be 0, the receiver MUST treat it as an error and
+ close the association by transmitting an ABORT.
+
+ ---------
+ New text: (Section 3.3.3)
+ ---------
+
+ Initiate Tag: 32 bits (unsigned integer)
+
+ The receiver of the INIT ACK records the value of the
+ Initiate Tag parameter. This value MUST be placed into
+ the Verification Tag field of every SCTP packet that the
+ INIT ACK receiver transmits within this association.
+
+ The Initiate Tag MUST NOT take the value 0. See Section 5.3.1
+ for more on the selection of the Initiate Tag value.
+
+ If the value of the Initiate Tag in a received INIT ACK
+ chunk is found to be 0, the receiver MUST destroy the
+ association discarding its TCB. The receiver MAY send an
+ ABORT for debugging purpose.
+
+2.22.3. Solution Description
+
+ The new text does not require that the receiver of the invalid INIT-
+ ACK send the ABORT. This behavior is in tune with the error case of
+ invalid stream numbers in the INIT-ACK. However, sending an ABORT
+ for debugging purposes is allowed.
+
+2.23. Sending an ABORT in Response to an INIT
+
+2.23.1. Description of the Problem
+
+ Whenever the receiver of an INIT chunk has to send an ABORT chunk in
+ response, for whatever reason, it is not stated clearly which
+ Verification Tag and value of the T-bit should be used.
+
+2.23.2. Text Changes to the Document
+
+ ---------
+ Old text: (Section 8.4)
+ ---------
+
+ 3) If the packet contains an INIT chunk with a Verification Tag
+ set to '0', process it as described in Section 5.1.
+ Otherwise,
+
+
+
+
+Stewart, et al. Informational [Page 51]
+
+RFC 4460 SCTP Errata April 2006
+
+
+ ---------
+ New text: (Section 8.4)
+ ---------
+
+ 3) If the packet contains an INIT chunk with a Verification Tag
+ set to '0', process it as described in Section 5.1. If, for
+ whatever reason, the INIT cannot be processed normally and
+ an ABORT has to be sent in response, the Verification Tag
+ of the packet containing the ABORT chunk MUST be the
+ Initiate tag of the received INIT chunk, and the T-Bit of
+ the ABORT chunk has to be set to 0, indicating that
+ a TCB was destroyed. Otherwise,
+
+2.23.3. Solution Description
+
+ The new text stated clearly which value of the Verification Tag and
+ T-bit have to be used.
+
+2.24. Stream Sequence Number (SSN) Initialization
+
+2.24.1. Description of the Problem
+
+ RFC 2960 does not describe the fact that the SSN has to be
+ initialized to 0, as required by RFC 2119.
+
+2.24.2. Text Changes to the Document
+
+ ---------
+ Old text: (Section 6.5)
+ ---------
+
+ The stream sequence number in all the streams shall start from 0
+ when the association is established. Also, when the stream
+ sequence number reaches the value 65535 the next stream sequence
+ number shall be set to 0.
+
+ ---------
+ New text: (Section 6.5)
+ ---------
+
+ The stream sequence number in all the streams MUST start from 0
+ when the association is established. Also, when the stream
+ sequence number reaches the value 65535 the next stream sequence
+ number MUST be set to 0.
+
+
+
+
+
+
+
+Stewart, et al. Informational [Page 52]
+
+RFC 4460 SCTP Errata April 2006
+
+
+2.24.3. Solution Description
+
+ The 'shall' in the text is replaced by a 'MUST' to clearly state the
+ required behavior.
+
+2.25. SACK Packet Format
+
+2.25.1. Description of the Problem
+
+ It is not clear in RFC 2960 whether a SACK must contain the fields
+ Number of Gap Ack Blocks and Number of Duplicate TSNs.
+
+2.25.2. Text Changes to the Document
+
+ ---------
+ Old text: (Section 3.3.4)
+ ---------
+
+ The SACK MUST contain the Cumulative TSN Ack and
+ Advertised Receiver Window Credit (a_rwnd) parameters.
+
+ ---------
+ New text: (Section 3.3.4)
+ ---------
+
+ The SACK MUST contain the Cumulative TSN Ack,
+ Advertised Receiver Window Credit (a_rwnd), Number
+ of Gap Ack Blocks, and Number of Duplicate TSNs fields.
+
+2.25.3. Solution Description
+
+ The text has been modified. It is now clear that a SACK always
+ contains the fields Number of Gap Ack Blocks and Number of Duplicate
+ TSNs.
+
+2.26. Protocol Violation Error Cause
+
+2.26.1. Description of the Problem
+
+ There are many situations where an SCTP endpoint may detect that its
+ peer violates the protocol. The result of such detection often
+ results in the association being destroyed by the sending of an
+ ABORT. Currently, there are only some error causes that could be
+ used to indicate the reason for the abort, but these do not cover all
+ cases.
+
+
+
+
+
+
+Stewart, et al. Informational [Page 53]
+
+RFC 4460 SCTP Errata April 2006
+
+
+2.26.2. Text Changes to the Document
+
+ Some of the changes given here already include changes suggested in
+ Section 2.6 and 2.21 of this document.
+
+ ---------
+ Old text: (Section 3.3.10)
+ ---------
+
+ Cause Code
+ Value Cause Code
+ --------- ----------------
+ 1 Invalid Stream Identifier
+ 2 Missing Mandatory Parameter
+ 3 Stale Cookie Error
+ 4 Out of Resource
+ 5 Unresolvable Address
+ 6 Unrecognized Chunk Type
+ 7 Invalid Mandatory Parameter
+ 8 Unrecognized Parameters
+ 9 No User Data
+ 10 Cookie Received While Shutting Down
+
+ Cause Length: 16 bits (unsigned integer)
+
+ Set to the size of the parameter in bytes, including the Cause
+ Code, Cause Length, and Cause-Specific Information fields
+
+ Cause-specific Information: variable length
+
+ This field carries the details of the error condition.
+
+ Sections 3.3.10.1 - 3.3.10.10 define error causes for SCTP.
+ Guidelines for the IETF to define new error cause values are
+ discussed in Section 13.3.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stewart, et al. Informational [Page 54]
+
+RFC 4460 SCTP Errata April 2006
+
+
+ ---------
+ New text: (Section 3.3.10)
+ ---------
+
+ Cause Code
+ Value Cause Code
+ --------- ----------------
+ 1 Invalid Stream Identifier
+ 2 Missing Mandatory Parameter
+ 3 Stale Cookie Error
+ 4 Out of Resource
+ 5 Unresolvable Address
+ 6 Unrecognized Chunk Type
+ 7 Invalid Mandatory Parameter
+ 8 Unrecognized Parameters
+ 9 No User Data
+ 10 Cookie Received While Shutting Down
+ 11 Restart of an Association with New Addresses
+ 12 User Initiated Abort
+ 13 Protocol Violation
+
+ Cause Length: 16 bits (unsigned integer)
+
+ Set to the size of the parameter in bytes, including the Cause
+ Code, Cause Length, and Cause-Specific Information fields
+
+ Cause-specific Information: variable length
+
+ This field carries the details of the error condition.
+
+ Sections 3.3.10.1 - 3.3.10.13 define error causes for SCTP.
+ Guidelines for the IETF to define new error cause values are
+ discussed in Section 13.3.
+
+ ---------
+ New text: (Note: no old text; new error added in section 3.3.10)
+ ---------
+
+ 3.3.10.13. Protocol Violation (13)
+
+ Cause of error
+ --------------
+
+ This error cause MAY be included in ABORT chunks that are sent
+ because an SCTP endpoint detects a protocol violation of the peer
+ that is not covered by the error causes described in 3.3.10.1 to
+ 3.3.10.12. An implementation MAY provide additional information
+ specifying what kind of protocol violation has been detected.
+
+
+
+Stewart, et al. Informational [Page 55]
+
+RFC 4460 SCTP Errata April 2006
+
+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Cause Code=13 | Cause Length=Variable |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ / Additional Information /
+ \ \
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+2.26.3. Solution Description
+
+ An additional error cause has been defined that can be used by an
+ endpoint to indicate a protocol violation of the peer.
+
+2.27. Reporting of Unrecognized Parameters
+
+2.27.1. Description of the Problem
+
+ It is not stated clearly in RFC 2960 [5] how unrecognized parameters
+ should be reported. Unrecognized parameters in an INIT chunk could
+ be reported in the INIT-ACK chunk or in a separate ERROR chunk, which
+ can get lost. Unrecognized parameters in an INIT-ACK chunk have to
+ be reported in an ERROR-chunk. This can be bundled with the COOKIE-
+ ERROR chunk or sent separately. If it is sent separately and
+ received before the COOKIE-ECHO, it will be handled as an OOTB
+ packet, resulting in sending out an ABORT chunk. Therefore, the
+ association would not be established.
+
+2.27.2. Text Changes to the Document
+
+ Some of the changes given here already include changes suggested in
+ Section 2.2 of this document.
+
+ ---------
+ Old text: (Section 3.2.1)
+ ---------
+
+ 00 - Stop processing this SCTP packet and discard it, do not process
+ any further chunks within it.
+
+ 01 - Stop processing this SCTP packet and discard it, do not process
+ any further chunks within it, and report the unrecognized
+ parameter in an 'Unrecognized Parameter Type' (in either an
+ ERROR or in the INIT ACK).
+
+ 10 - Skip this parameter and continue processing.
+
+ 11 - Skip this parameter and continue processing but report the
+ unrecognized parameter in an 'Unrecognized Parameter Type' (in
+ either an ERROR or in the INIT ACK).
+
+
+
+Stewart, et al. Informational [Page 56]
+
+RFC 4460 SCTP Errata April 2006
+
+
+ ---------
+ New text: (Section 3.2.1)
+ ---------
+
+ 00 - Stop processing this SCTP chunk and discard it; do not process
+ any further parameters within this chunk.
+
+ 01 - Stop processing this SCTP chunk and discard it, do not process
+ any further parameters within this chunk, and report the
+ unrecognized parameter in an 'Unrecognized Parameter Type', as
+ described in 3.2.2.
+
+ 10 - Skip this parameter and continue processing.
+
+ 11 - Skip this parameter and continue processing but report the
+ unrecognized parameter in an 'Unrecognized Parameter Type', as
+ described in 3.2.2.
+
+ ---------
+ New text: (Note: no old text; clarification added in Section 3.2)
+ ---------
+
+ 3.2.2. Reporting of Unrecognized Parameters
+
+ If the receiver of an INIT chunk detects unrecognized parameters
+ and has to report them according to Section 3.2.1, it MUST put
+ the 'Unrecognized Parameter' parameter(s) in the INIT-ACK chunk
+ sent in response to the INIT-chunk. Note that if the receiver
+ of the INIT chunk is NOT going to establish an association (e.g.,
+ due to lack of resources), then no report would be sent back.
+
+ If the receiver of an INIT-ACK chunk detects unrecognized
+ parameters and has to report them according to Section 3.2.1,
+ it SHOULD bundle the ERROR chunk containing the
+ 'Unrecognized Parameter' error cause with the COOKIE-ECHO
+ chunk sent in response to the INIT-ACK chunk. If the
+ receiver of the INIT-ACK cannot bundle the COOKIE-ECHO chunk
+ with the ERROR chunk, the ERROR chunk MAY be sent separately
+ but not before the COOKIE-ACK has been received.
+
+ Note: Any time a COOKIE-ECHO is sent in a packet, it MUST be the
+ first chunk.
+
+2.27.3. Solution Description
+
+ The procedure of reporting unrecognized parameters has been described
+ clearly.
+
+
+
+
+Stewart, et al. Informational [Page 57]
+
+RFC 4460 SCTP Errata April 2006
+
+
+2.28. Handling of IP Address Parameters
+
+2.28.1. Description of the Problem
+
+ It is not stated clearly in RFC 2960 [5] how an SCTP endpoint that
+ supports either IPv4 addresses or IPv6 addresses should respond if
+ IPv4 and IPv6 addresses are presented by the peer in the INIT or
+ INIT-ACK chunk.
+
+2.28.2. Text Changes to the Document
+
+ ---------
+ Old text: (Section 5.1.2)
+ ---------
+
+ IMPLEMENTATION NOTE: In the case that the receiver of an INIT ACK
+ fails to resolve the address parameter due to an unsupported type,
+ it can abort the initiation process and then attempt a
+ re-initiation by using a 'Supported Address Types' parameter in
+ the new INIT to indicate what types of address it prefers.
+
+ ---------
+ New text: (Section 5.1.2)
+ ---------
+
+ IMPLEMENTATION NOTE: In the case that the receiver of an INIT ACK
+ fails to resolve the address parameter due to an unsupported type,
+ it can abort the initiation process and then attempt a re-
+ initiation by using a 'Supported Address Types' parameter in the
+ new INIT to indicate what types of address it prefers.
+
+ IMPLEMENTATION NOTE: If an SCTP endpoint that only supports either
+ IPv4 or IPv6 receives IPv4 and IPv6 addresses in an INIT or INIT-
+ ACK chunk from its peer, it MUST use all the addresses belonging
+ to the supported address family. The other addresses MAY be
+ ignored. The endpoint SHOULD NOT respond with any kind of error
+ indication.
+
+2.28.3. Solution Description
+
+ The procedure of handling IP address parameters has been described
+ clearly.
+
+
+
+
+
+
+
+
+
+Stewart, et al. Informational [Page 58]
+
+RFC 4460 SCTP Errata April 2006
+
+
+2.29. Handling of COOKIE ECHO Chunks When a TCB Exists
+
+2.29.1. Description of the Problem
+
+ The description of the behavior in RFC 2960 [5] when a COOKIE ECHO
+ chunk and a TCB exist could be misunderstood. When a COOKIE ECHO is
+ received, a TCB exists and the local tag and peer's tag match, it is
+ stated that the endpoint should enter the ESTABLISHED state if it has
+ not already done so and send a COOKIE ACK. It was not clear that, in
+ the case the endpoint has already left the ESTABLISHED state again,
+ then it should not go back to established. In case D, the endpoint
+ can only enter state ESTABLISHED from COOKIE-ECHOED because in state
+ CLOSED it has no TCB and in state COOKIE-WAIT it has a TCB but knows
+ nothing about the peer's tag, which is requested to match in this
+ case.
+
+2.29.2. Text Changes to the Document
+
+ ---------
+ Old text: (Section 5.2.4)
+ ---------
+ D) When both local and remote tags match the endpoint should
+ always enter the ESTABLISHED state, if it has not already
+ done so. It should stop any init or cookie timers that may
+ be running and send a COOKIE ACK.
+
+ ---------
+ New text: (Section 5.2.4)
+ ---------
+ D) When both local and remote tags match, the endpoint should
+ enter the ESTABLISHED state, if it is in the COOKIE-ECHOED
+ state. It should stop any cookie timer that may
+ be running and send a COOKIE ACK.
+
+2.29.3. Solution Description
+
+ The procedure of handling of COOKIE-ECHO chunks when a TCB exists has
+ been described clearly.
+
+2.30. The Initial Congestion Window Size
+
+2.30.1. Description of the Problem
+
+ RFC 2960 was published with the intention of having the same
+ congestion control properties as TCP. Since the publication of RFC
+ 2960, TCP's initial congestion window size has been increased via RFC
+ 3390. This same update will be needed for SCTP to keep SCTP's
+ congestion control properties equivalent to that of TCP.
+
+
+
+Stewart, et al. Informational [Page 59]
+
+RFC 4460 SCTP Errata April 2006
+
+
+2.30.2. Text Changes to the Document
+
+ ---------
+ Old text: (Section 7.2.1)
+ ---------
+ o The initial cwnd before DATA transmission or after a
+ sufficiently long idle period MUST be <= 2*MTU.
+
+ ---------
+ New text: (Section 7.2.1)
+ ---------
+ o The initial cwnd before DATA transmission or after a
+ sufficiently long idle period MUST be set to
+ min(4*MTU, max (2*MTU, 4380 bytes)).
+
+ ---------
+ Old text: (Section 7.2.1)
+ ---------
+ o When the endpoint does not transmit data on a given transport
+ address, the cwnd of the transport address should be adjusted
+ to max(cwnd/2, 2*MTU) per RTO.
+
+ ---------
+ New text: (Section 7.2.1)
+ ---------
+ o When the endpoint does not transmit data on a given transport
+ address, the cwnd of the transport address should be adjusted
+ to max(cwnd/2, 4*MTU) per RTO.
+
+ ---------
+ Old text: (Section 7.2.2)
+ ---------
+ o Same as in the slow start, when the sender does not transmit
+ DATA on a given transport address, the cwnd of the transport
+ address should be adjusted to max(cwnd / 2, 2*MTU) per RTO.
+
+ ---------
+ New text: (Section 7.2.2)
+ ---------
+ o Same as in the slow start, when the sender does not transmit
+ DATA on a given transport address, the cwnd of the transport
+ address should be adjusted to max(cwnd / 2, 4*MTU) per RTO.
+
+
+
+
+
+
+
+
+
+Stewart, et al. Informational [Page 60]
+
+RFC 4460 SCTP Errata April 2006
+
+
+ ---------
+ Old text: (Section 7.2.3)
+ ---------
+
+ 7.2.3. Congestion Control
+
+ Upon detection of packet losses from SACK (see Section 7.2.4), an
+ endpoint should do the following:
+
+ ssthresh = max(cwnd/2, 2*MTU)
+ cwnd = ssthresh
+
+ Basically, a packet loss causes cwnd to be cut in half.
+
+ When the T3-rtx timer expires on an address, SCTP should perform
+ slow start by
+
+ ssthresh = max(cwnd/2, 2*MTU)
+ cwnd = 1*MTU
+
+ ---------
+ New text: (Section 7.2.3)
+ ---------
+
+ 7.2.3 Congestion Control
+
+ Upon detection of packet losses from SACK (see Section 7.2.4), An
+ endpoint should do the following:
+
+ ssthresh = max(cwnd/2, 4*MTU)
+ cwnd = ssthresh
+
+ Basically, a packet loss causes cwnd to be cut in half.
+
+ When the T3-rtx timer expires on an address, SCTP should perform
+ slow start by:
+
+ ssthresh = max(cwnd/2, 4*MTU)
+ cwnd = 1*MTU
+
+2.30.3. Solution Description
+
+ The change to SCTP's initial congestion window will allow it to
+ continue to maintain the same congestion control properties as TCP.
+
+
+
+
+
+
+
+Stewart, et al. Informational [Page 61]
+
+RFC 4460 SCTP Errata April 2006
+
+
+2.31. Stream Sequence Numbers in Figures
+
+2.31.1. Description of the Problem
+
+ In Section 2.24 of this document, it is clarified that the SSN are
+ initialized with 0. Two figures in RFC 2960 [5] illustrate that they
+ start with 1.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stewart, et al. Informational [Page 62]
+
+RFC 4460 SCTP Errata April 2006
+
+
+2.31.2. Text Changes to the Document
+
+ ---------
+ Old text: (Section 7.2.1)
+ ---------
+
+ Endpoint A Endpoint Z
+ {app sets association with Z}
+ (build TCB)
+ INIT [I-Tag=Tag_A
+ & other info] ------\
+ (Start T1-init timer) \
+ (Enter COOKIE-WAIT state) \---> (compose temp TCB and Cookie_Z)
+ /-- 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, <-----/
+ Enter ESTABLISHED state)
+ {app sends 1st user data; strm 0}
+ DATA [TSN=initial TSN_A
+ Strm=0,Seq=1 & user data]--\
+ (Start T3-rtx timer) \
+ \->
+ /----- SACK [TSN Ack=init
+ / TSN_A,Block=0]
+ (Cancel T3-rtx timer) <------/
+ ...
+ {app sends 2 messages;strm 0}
+ /---- DATA
+ / [TSN=init TSN_Z
+ <--/ Strm=0,Seq=1 & user data 1]
+ SACK [TSN Ack=init TSN_Z, / ---- DATA
+ Block=0] --------\ / [TSN=init TSN_Z +1,
+ \/ Strm=0,Seq=2 & user data 2]
+ <------/\
+ \
+ \------>
+
+ Figure 4: INITiation Example
+
+
+
+
+
+Stewart, et al. Informational [Page 63]
+
+RFC 4460 SCTP Errata April 2006
+
+
+ ---------
+ New text: (Section 7.2.1)
+ ---------
+
+
+ Endpoint A Endpoint Z
+ {app sets association with Z}
+ (build TCB)
+ INIT [I-Tag=Tag_A
+ & other info] ------\
+ (Start T1-init timer) \
+ (Enter COOKIE-WAIT state) \---> (compose temp TCB and Cookie_Z)
+ /-- 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, <-----/
+ Enter ESTABLISHED state)
+ {app sends 1st user data; strm 0}
+ DATA [TSN=initial TSN_A
+ Strm=0,Seq=0 & user data]--\
+ (Start T3-rtx timer) \
+ \->
+ /----- SACK [TSN Ack=init
+ / TSN_A,Block=0]
+ (Cancel T3-rtx timer) <------/
+ ...
+ {app sends 2 messages;strm 0}
+ /---- DATA
+ / [TSN=init TSN_Z
+ <--/ Strm=0,Seq=0 & user data 1]
+ SACK [TSN Ack=init TSN_Z, /---- DATA
+ Block=0] --------\ / [TSN=init TSN_Z +1,
+ \/ Strm=0,Seq=1 & user data 2]
+ <------/\
+ \
+ \------>
+
+ Figure 4: INITiation Example
+
+
+
+
+
+
+Stewart, et al. Informational [Page 64]
+
+RFC 4460 SCTP Errata April 2006
+
+
+ ---------
+ Old text: (Section 5.2.4.1)
+ ---------
+
+ Endpoint A Endpoint Z
+ <------------ Association is established---------------------->
+ Tag=Tag_A Tag=Tag_Z
+ <------------------------------------------------------------->
+ {A crashes and restarts}
+ {app sets up a association with Z}
+ (build TCB)
+ INIT [I-Tag=Tag_A'
+ & other info] --------\
+ (Start T1-init timer) \
+ (Enter COOKIE-WAIT state) \---> (find a existing TCB
+ compose temp TCB and Cookie_Z
+ with Tie-Tags to previous
+ association)
+ /--- INIT ACK [Veri Tag=Tag_A',
+ / I-Tag=Tag_Z',
+ (Cancel T1-init timer) <------/ Cookie_Z[TieTags=
+ Tag_A,Tag_Z
+ & other info]
+ (destroy temp TCB,leave original
+ in place)
+ COOKIE ECHO [Veri=Tag_Z',
+ Cookie_Z
+ Tie=Tag_A,
+ Tag_Z]----------\
+ (Start T1-init timer) \
+ (Enter COOKIE-ECHOED state) \---> (Find existing association,
+ Tie-Tags match old tags,
+ Tags do not match i.e.,
+ case X X M M above,
+ Announce Restart to ULP
+ and reset association).
+ /---- COOKIE-ACK
+ (Cancel T1-init timer, <------/
+ Enter ESTABLISHED state)
+ {app sends 1st user data; strm 0}
+ DATA [TSN=initial TSN_A
+ Strm=0,Seq=1 & user data]--\
+ (Start T3-rtx timer) \
+ \->
+ /--- SACK [TSN Ack=init TSN_A,Block=0]
+ (Cancel T3-rtx timer) <------/
+
+ Figure 5: A Restart Example
+
+
+
+Stewart, et al. Informational [Page 65]
+
+RFC 4460 SCTP Errata April 2006
+
+
+ ---------
+ New text: (Section 5.2.4.1)
+ ---------
+
+ Endpoint A Endpoint Z
+ <-------------- Association is established---------------------->
+ Tag=Tag_A Tag=Tag_Z
+ <--------------------------------------------------------------->
+ {A crashes and restarts}
+ {app sets up a association with Z}
+ (build TCB)
+ INIT [I-Tag=Tag_A'
+ & other info] --------\
+ (Start T1-init timer) \
+ (Enter COOKIE-WAIT state) \---> (find a existing TCB
+ compose temp TCB and Cookie_Z
+ with Tie-Tags to previous
+ association)
+ /--- INIT ACK [Veri Tag=Tag_A',
+ / I-Tag=Tag_Z',
+ (Cancel T1-init timer) <------/ Cookie_Z[TieTags=
+ Tag_A,Tag_Z
+ & other info]
+ (destroy temp TCB,leave original
+ in place)
+ COOKIE ECHO [Veri=Tag_Z',
+ Cookie_Z
+ Tie=Tag_A,
+ Tag_Z]----------\
+ (Start T1-init timer) \
+ (Enter COOKIE-ECHOED state) \---> (Find existing association,
+ Tie-Tags match old tags,
+ Tags do not match i.e.,
+ case X X M M above,
+ Announce Restart to ULP
+ and reset association).
+ /---- COOKIE-ACK
+ (Cancel T1-init timer, <------/
+ Enter ESTABLISHED state)
+ {app sends 1st user data; strm 0}
+ DATA [TSN=initial TSN_A
+ Strm=0,Seq=0 & user data]--\
+ (Start T3-rtx timer) \
+ \->
+ /--- SACK [TSN Ack=init TSN_A,Block=0]
+ (Cancel T3-rtx timer) <------/
+
+ Figure 5: A Restart Example
+
+
+
+Stewart, et al. Informational [Page 66]
+
+RFC 4460 SCTP Errata April 2006
+
+
+2.31.3. Solution description
+
+ Figure 4 and 5 were changed so that the SSN starts with 0 instead of
+ 1.
+
+2.32. Unrecognized Parameters
+
+2.32.1. Description of the Problem
+
+ The RFC does not state clearly in Section 3.3.3.1 whether one or
+ multiple unrecognized parameters are included in the 'Unrecognized
+ Parameter' parameter.
+
+2.32.2. Text Changes to the Document
+
+ ---------
+ Old text: (Section 3.3.3)
+ ---------
+ Variable Parameters Status Type Value
+ -------------------------------------------------------------
+ State Cookie Mandatory 7
+ IPv4 Address (Note 1) Optional 5
+ IPv6 Address (Note 1) Optional 6
+ Unrecognized Parameters Optional 8
+ Reserved for ECN Capable (Note 2) Optional 32768 (0x8000)
+ Host Name Address (Note 3) Optional 11
+
+ ---------
+ New text: (Section 3.3.3)
+ ---------
+ Variable Parameters Status Type Value
+ -------------------------------------------------------------
+ State Cookie Mandatory 7
+ IPv4 Address (Note 1) Optional 5
+ IPv6 Address (Note 1) Optional 6
+ Unrecognized Parameter Optional 8
+ Reserved for ECN Capable (Note 2) Optional 32768 (0x8000)
+ Host Name Address (Note 3) Optional 11
+
+
+ ---------
+ Old text: (Section 3.3.3.1)
+ ---------
+ Unrecognized Parameters:
+
+ Parameter Type Value: 8
+
+ Parameter Length: Variable Size.
+
+
+
+Stewart, et al. Informational [Page 67]
+
+RFC 4460 SCTP Errata April 2006
+
+
+ Parameter Value:
+ This parameter is returned to the originator of the INIT
+ chunk when the INIT contains an unrecognized parameter
+ which has a value that indicates that it should be reported
+ to the sender. This parameter value field will contain
+ unrecognized parameters copied from the INIT chunk complete
+ with Parameter Type, Length and Value fields.
+
+ ---------
+ New text: (Section 3.3.3.1)
+ ---------
+ Unrecognized Parameter:
+
+ Parameter Type Value: 8
+
+ Parameter Length: Variable Size.
+
+ Parameter Value:
+
+ This parameter is returned to the originator of the INIT
+ chunk when the INIT contains an unrecognized parameter
+ that has a value that indicates that it should be reported
+ to the sender. This parameter value field will contain the
+ unrecognized parameter copied from the INIT chunk complete
+ with Parameter Type, Length, and Value fields.
+
+2.32.3. Solution Description
+
+ The new text states clearly that only one unrecognized parameter is
+ reported per parameter.
+
+2.33. Handling of Unrecognized Parameters
+
+2.33.1. Description of the Problem
+
+ It is not stated clearly in RFC 2960 [5] how unrecognized parameters
+ should be handled. The problem comes up when an INIT contains an
+ unrecognized parameter with highest bits 00. It was not clear
+ whether an INIT-ACK should be sent.
+
+2.33.2. Text Changes to the Document
+
+ Some of the changes given here already include changes suggested in
+ Section 2.27 of this document.
+
+
+
+
+
+
+
+Stewart, et al. Informational [Page 68]
+
+RFC 4460 SCTP Errata April 2006
+
+
+ ---------
+ Old text: (Section 3.2.1)
+ ---------
+
+ 00 - Stop processing this SCTP packet and discard it, do not process
+ any further chunks within it.
+
+ 01 - Stop processing this SCTP packet and discard it, do not process
+ any further chunks within it, and report the unrecognized
+ parameter in an 'Unrecognized Parameter Type' (in either an
+ ERROR or in the INIT ACK).
+
+ 10 - Skip this parameter and continue processing.
+
+ 11 - Skip this parameter and continue processing but report the
+ unrecognized parameter in an 'Unrecognized Parameter Type' (in
+ either an ERROR or in the INIT ACK).
+
+ ---------
+ New text: (Section 3.2.1)
+ ---------
+
+ 00 - Stop processing this parameter; do not process
+ any further parameters within this chunk.
+
+ 01 - Stop processing this parameter, do not process
+ any further parameters within this chunk, and report the
+ unrecognized parameter in an 'Unrecognized Parameter Type', as
+ described in 3.2.2.
+
+ 10 - Skip this parameter and continue processing.
+
+ 11 - Skip this parameter and continue processing but report the
+ unrecognized parameter in an 'Unrecognized Parameter Type', as
+ described in 3.2.2.
+
+
+ ---------
+ New text: (Note: no old text; clarification added in section 3.2)
+ ---------
+
+ 3.2.2. Reporting of Unrecognized Parameters
+
+ If the receiver of an INIT chunk detects unrecognized parameters and
+ has to report them according to Section 3.2.1, it MUST put the
+ 'Unrecognized Parameter' parameter(s) in the INIT-ACK chunk sent in
+ response to the INIT-chunk. Note that if the receiver of the INIT
+ chunk is NOT going to establish an association (e.g., due to lack of
+
+
+
+Stewart, et al. Informational [Page 69]
+
+RFC 4460 SCTP Errata April 2006
+
+
+ resources), an 'Unrecognized Parameter' would NOT be included with
+ any ABORT being sent to the sender of the INIT.
+
+ If the receiver of an INIT-ACK chunk detects unrecognized parameters
+ and has to report them according to Section 3.2.1, it SHOULD bundle
+ the ERROR chunk containing the 'Unrecognized Parameter' error cause
+ with the COOKIE-ECHO chunk sent in response to the INIT-ACK chunk.
+ If the receiver of the INIT-ACK cannot bundle the COOKIE-ECHO chunk
+ with the ERROR chunk, the ERROR chunk MAY be sent separately but not
+ before the COOKIE-ACK has been received.
+
+ Note: Any time a COOKIE-ECHO is sent in a packet, it MUST be the
+ first chunk.
+
+2.33.3. Solution Description
+
+ The procedure of handling unrecognized parameters has been described
+ clearly.
+
+2.34. Tie Tags
+
+2.34.1. Description of the Problem
+
+ RFC 2960 requires that Tie-Tags be included in the COOKIE. The
+ cookie may not be encrypted. An attacker could discover the value of
+ the Verification Tags by analyzing cookies received after sending an
+ INIT.
+
+2.34.2. Text Changes to the Document
+
+ ---------
+ Old text: (Section 1.4)
+ ---------
+ o Tie-Tags: Verification Tags from a previous association. These
+ Tags are used within a State Cookie so that the newly
+ restarting association can be linked to the original
+ association within the endpoint that did not restart.
+
+ ---------
+ New text: (Section 1.4)
+ ---------
+
+ o Tie-Tags: Two 32-bit random numbers that together make a 64-
+ bit nonce. These Tags are used within a State Cookie and TCB
+ so that a newly restarting association can be linked to the
+ original association within the endpoint that did not restart
+ and yet not reveal the true Verification Tags of an existing
+ association.
+
+
+
+Stewart, et al. Informational [Page 70]
+
+RFC 4460 SCTP Errata April 2006
+
+
+ ---------
+ Old text: (Section 5.2.1)
+ ---------
+
+ For an endpoint that is in the COOKIE-ECHOED state it MUST
+ populate its Tie-Tags with the Tag information of itself and
+ its peer (see Section 5.2.2 for a description of the Tie-Tags).
+
+ ---------
+ New text: (Section 5.2.1)
+ ---------
+ For an endpoint that is in the COOKIE-ECHOED state it MUST
+ populate its Tie-Tags within both the association TCB and
+ inside the State Cookie (see section 5.2.2 for a description
+ of the Tie-Tags).
+
+
+ ---------
+ Old text: (Section 5.2.2)
+ ---------
+ Unless otherwise stated, upon reception of an unexpected INIT for
+ this association, the endpoint shall generate an INIT ACK with a
+ State Cookie. In the outbound INIT ACK the endpoint MUST copy its
+ current Verification Tag and peer's Verification Tag into a
+ reserved place within the state cookie. We shall refer to these
+ locations as the Peer's-Tie-Tag and the Local-Tie-Tag. The
+ outbound SCTP packet containing this INIT ACK MUST carry a
+ Verification Tag value equal to the Initiation Tag found in the
+ unexpected INIT. And the INIT ACK MUST contain a new Initiation
+ Tag (randomly generated see Section 5.3.1). Other parameters
+ for the endpoint SHOULD be copied from the existing parameters
+ of the association (e.g., number of outbound streams) into the
+ INIT ACK and cookie.
+
+ ---------
+ New text: (Section 5.2.2)
+ ---------
+
+ Unless otherwise stated, upon receipt of an unexpected INIT for
+ this association, the endpoint MUST generate an INIT ACK with a
+ State Cookie. In the outbound INIT ACK, the endpoint MUST copy
+ its current Tie-Tags to a reserved place within the State Cookie
+ and the association's TCB. We shall refer to these locations
+ inside the cookie as the Peer's-Tie-Tag and the Local-Tie-Tag. We
+ will refer to the copy within an association's TCB as the Local
+ Tag and Peer's Tag. The outbound SCTP packet containing this INIT
+ ACK MUST carry a Verification Tag value equal to the Initiation
+ Tag found in the unexpected INIT. And the INIT ACK MUST contain a
+
+
+
+Stewart, et al. Informational [Page 71]
+
+RFC 4460 SCTP Errata April 2006
+
+
+ new Initiation Tag (randomly generated; see Section 5.3.1). Other
+ parameters for the endpoint SHOULD be copied from the existing
+ parameters of the association (e.g., number of outbound streams)
+ into the INIT ACK and cookie.
+
+2.34.3. Solution Description
+
+ The solution to this problem is not to use the real Verification Tags
+ within the State Cookie as tie-tags. Instead, two 32-bit random
+ numbers are created to form one 64-bit nonce and stored both in the
+ State Cookie and the existing association TCB. This prevents
+ exposing the Verification Tags inadvertently.
+
+2.35. Port Number Verification in the COOKIE-ECHO
+
+2.35.1. Description of the Problem
+
+ The State Cookie sent by a listening SCTP endpoint may not contain
+ the original port numbers or the local Verification Tag. It is then
+ possible that the endpoint, on receipt of the COOKIE-ECHO, will not
+ be able to verify that these values match the original values found
+ in the INIT and INIT-ACK that began the association setup.
+
+2.35.2. Text Changes to the Document
+
+ ---------
+ Old text: (Section 5.1.5)
+ ---------
+ 3) Compare the creation timestamp in the State Cookie to the
+ current local time. If the elapsed time is longer than the
+ lifespan carried in the State Cookie, then the packet,
+ including the COOKIE ECHO and any attached DATA chunks,
+ SHOULD be discarded and the endpoint MUST transmit an ERROR
+ chunk with a "Stale Cookie" error cause to the peer endpoint,
+
+ 4) If the State Cookie is valid, create an association to the
+ sender of the COOKIE ECHO chunk with the information in the
+ TCB data carried in the COOKIE ECHO, and enter the
+ ESTABLISHED state,
+
+ 5) Send a COOKIE ACK chunk to the peer acknowledging reception
+ of the COOKIE ECHO. The COOKIE ACK MAY be bundled with an
+ outbound DATA chunk or SACK chunk; however, the COOKIE ACK
+ MUST be the first chunk in the SCTP packet.
+
+ 6) Immediately acknowledge any DATA chunk bundled with the COOKIE
+ ECHO with a SACK (subsequent DATA chunk acknowledgement should
+ follow the rules defined in Section 6.2). As mentioned in step
+
+
+
+Stewart, et al. Informational [Page 72]
+
+RFC 4460 SCTP Errata April 2006
+
+
+ 5), if the SACK is bundled with the COOKIE ACK, the COOKIE ACK
+ MUST appear first in the SCTP packet.
+
+ ---------
+ New text: (Section 5.1.5)
+ ---------
+
+ 3) Compare the port numbers and the Verification Tag contained
+ within the COOKIE ECHO chunk to the actual port numbers and the
+ Verification Tag within the SCTP common header of the received
+ packet. If these values do not match, the packet MUST be
+ silently discarded.
+
+ 4) Compare the creation timestamp in the State Cookie to the
+ current local time. If the elapsed time is longer than the
+ lifespan carried in the State Cookie, then the packet,
+ including the COOKIE ECHO and any attached DATA chunks,
+ SHOULD be discarded, and the endpoint MUST transmit an
+ ERROR chunk with a "Stale Cookie" error cause to the peer
+ endpoint.
+
+ 5) If the State Cookie is valid, create an association to the
+ sender of the COOKIE ECHO chunk with the information in the
+ TCB data carried in the COOKIE ECHO and enter the
+ ESTABLISHED state.
+
+ 6) Send a COOKIE ACK chunk to the peer acknowledging receipt of
+ the COOKIE ECHO. The COOKIE ACK MAY be bundled with an
+ outbound DATA chunk or SACK chunk; however, the COOKIE ACK
+ MUST be the first chunk in the SCTP packet.
+
+ 7) Immediately acknowledge any DATA chunk bundled with the COOKIE
+ ECHO with a SACK (subsequent DATA chunk acknowledgement should
+ follow the rules defined in Section 6.2). As mentioned in step
+ 5, if the SACK is bundled with the COOKIE ACK, the COOKIE ACK
+ MUST appear first in the SCTP packet.
+
+2.35.3. Solution Description
+
+ By including both port numbers and the local Verification Tag within
+ the State Cookie and verifying these during COOKIE-ECHO processing,
+ this issue is resolved.
+
+
+
+
+
+
+
+
+
+Stewart, et al. Informational [Page 73]
+
+RFC 4460 SCTP Errata April 2006
+
+
+2.36. Path Initialization
+
+2.36.1. Description of the Problem
+
+ When an association enters the ESTABLISHED state, the endpoint has no
+ verification that all of the addresses presented by the peer do in
+ fact belong to the peer. This could cause various forms of denial of
+ service attacks.
+
+2.36.2. Text Changes to the Document
+
+ ---------
+ Old text: None
+ ---------
+
+ ---------
+ New text: (Section 5.4)
+ ---------
+ 5.4. Path Verification
+
+ During association establishment, the two peers exchange a list of
+ addresses. In the predominant case, these lists accurately represent
+ the addresses owned by each peer. However, it is possible that a
+ misbehaving peer may supply addresses that it does not own. To
+ prevent this, the following rules are applied to all addresses of the
+ new association:
+
+ 1) Any address passed to the sender of the INIT by its upper layer is
+ automatically considered to be CONFIRMED.
+
+ 2) For the receiver of the COOKIE-ECHO the only CONFIRMED address is
+ the one that the INIT-ACK was sent to.
+
+ 3) All other addresses not covered by rules 1 and 2 are considered
+ UNCONFIRMED and are subject to probing for verification.
+
+ To probe an address for verification, an endpoint will send
+ HEARTBEATs including a 64-bit random nonce and a path indicator (to
+ identify the address that the HEARTBEAT is sent to) within the
+ HEARTBEAT parameter.
+
+ Upon receipt of the HEARTBEAT-ACK, a verification is made that the
+ nonce included in the HEARTBEAT parameter is the one sent to the
+ address indicated inside the HEARTBEAT parameter. When this match
+ occurs, the address that the original HEARTBEAT was sent to is now
+ considered CONFIRMED and available for normal data transfer.
+
+
+
+
+
+Stewart, et al. Informational [Page 74]
+
+RFC 4460 SCTP Errata April 2006
+
+
+ These probing procedures are started when an association moves to the
+ ESTABLISHED state and are ended when all paths are confirmed.
+
+ Each RTO a probe may be sent on an active UNCONFIRMED path in an
+ attempt to move it to the CONFIRMED state. If during this probing
+ the path becomes inactive, this rate is lowered to the normal
+ HEARTBEAT rate. At the expiration of the RTO timer, the error
+ counter of any path that was probed but not CONFIRMED is incremented
+ by one and subjected to path failure detection, as defined in section
+ 8.2. When probing UNCONFIRMED addresses, however, the association
+ overall error count is NOT incremented.
+
+ The number of HEARTBEATS sent at each RTO SHOULD be limited by the
+ HB.Max.Burst parameter. It is an implementation decision as to how
+ to distribute HEARTBEATS to the peer's addresses for path
+ verification.
+
+ Whenever a path is confirmed, an indication MAY be given to the upper
+ layer.
+
+ An endpoint MUST NOT send any chunks to an UNCONFIRMED address, with
+ the following exceptions:
+
+ - A HEARTBEAT including a nonce MAY be sent to an UNCONFIRMED
+ address.
+
+ - A HEARTBEAT-ACK MAY be sent to an UNCONFIRMED address.
+
+ - A COOKIE-ACK MAY be sent to an UNCONFIRMED address, but it MUST be
+ bundled with a HEARTBEAT including a nonce. An implementation that
+ does NOT support bundling MUST NOT send a COOKIE-ACK to an
+ UNCONFIRMED address.
+
+ - A COOKE-ECHO MAY be sent to an UNCONFIRMED address, but it MUST be
+ bundled with a HEARTBEAT including a nonce, and the packet MUST NOT
+ exceed the path MTU. If the implementation does NOT support
+ bundling or if the bundled COOKIE-ECHO plus HEARTBEAT (including
+ nonce) would exceed the path MTU, then the implementation MUST NOT
+ send a COOKIE-ECHO to an UNCONFIRMED address.
+
+ ---------
+ Old text: (Section 14)
+ ---------
+
+ 14. Suggested SCTP Protocol Parameter Values
+
+ The following protocol parameters are RECOMMENDED:
+
+
+
+
+Stewart, et al. Informational [Page 75]
+
+RFC 4460 SCTP Errata April 2006
+
+
+ RTO.Initial - 3 seconds
+ RTO.Min - 1 second
+ RTO.Max - 60 seconds
+ 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
+
+ ---------
+ New text: (Section 14)
+ ---------
+
+ 14. 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
+
+2.36.3. Solution Description
+
+ By properly setting up initial path state and accelerated probing via
+ HEARTBEAT's, a new association can verify that all addresses
+ presented by a peer belong to that peer.
+
+2.37. ICMP Handling Procedures
+
+2.37.1. Description of the Problem
+
+ RFC 2960 does not describe how ICMP messages should be processed by
+ an SCTP endpoint.
+
+
+
+
+
+
+
+Stewart, et al. Informational [Page 76]
+
+RFC 4460 SCTP Errata April 2006
+
+
+2.37.2. Text Changes to the Document
+
+ --------
+ Old text: None
+ --------
+
+ ---------
+ New text
+ ---------
+
+ 11.5. Protection of Non-SCTP Capable Hosts.
+
+ To provide a non-SCTP capable host with the same level of protection
+ against attacks as for SCTP-capable ones, all SCTP stacks MUST
+ implement the ICMP handling described in Appendix C.
+
+ When an SCTP stack receives a packet containing multiple control or
+ DATA chunks and the processing of the packet requires the sending of
+ multiple chunks in response, the sender of the response chunk(s) MUST
+ NOT send more than one packet. If bundling is supported, multiple
+ response chunks that fit into a single packet MAY be bundled together
+ into one single response packet. If bundling is not supported, then
+ the sender MUST NOT send more than one response chunk and MUST
+ discard all other responses. Note that this rule does NOT apply to a
+ SACK chunk, since a SACK chunk is, in itself, a response to DATA and
+ a SACK does not require a response of more DATA.
+
+ An SCTP implementation SHOULD abort the association if it receives a
+ SACK acknowledging a TSN that has not been sent.
+
+ An SCTP implementation that receives an INIT that would require a
+ large packet in response, due to the inclusion of multiple ERROR
+ parameters, MAY (at its discretion) elect to omit some or all of the
+ ERROR parameters to reduce the size of the INIT-ACK. Due to a
+ combination of the size of the COOKIE parameter and the number of
+ addresses a receiver of an INIT may be indicating to a peer, it is
+ always possible that the INIT-ACK will be larger than the original
+ INIT. An SCTP implementation SHOULD attempt to make the INIT-ACK as
+ small as possible to reduce the possibility of byte amplification
+ attacks.
+
+ ---------
+ Old text: None
+ ---------
+
+
+
+
+
+
+
+Stewart, et al. Informational [Page 77]
+
+RFC 4460 SCTP Errata April 2006
+
+
+ ---------
+ New text: (Appendix C)
+ ---------
+
+ Appendix C ICMP Handling
+
+ Whenever an ICMP message is received by an SCTP endpoint the
+ following procedures MUST be followed to ensure proper utilization of
+ the information being provided by layer 3.
+
+ ICMP1) An implementation MAY ignore all ICMPv4 messages where the
+ type field is not set to "Destination Unreachable".
+
+ ICMP2) An implementation MAY ignore all ICMPv6 messages where the
+ type field is not "Destination Unreachable, "Parameter
+ Problem" or "Packet Too Big".
+
+ ICMP3) An implementation MAY ignore any ICMPv4 messages where the
+ code does not indicate "Protocol Unreachable" or
+ "Fragmentation Needed".
+
+ ICMP4) An implementation MAY ignore all ICMPv6 messages of type
+ "Parameter Problem" if the code is not "Unrecognized next
+ header type encountered".
+
+ ICMP5) An implementation MUST use the payload of the ICMP message (V4
+ or V6) to locate the association that sent the message that
+ ICMP is responding to. If the association cannot be found, an
+ implementation SHOULD ignore the ICMP message.
+
+ ICMP6) An implementation MUST validate that the Verification Tag
+ contained in the ICMP message matches the verification tag of
+ the peer. If the Verification Tag is not 0 and does NOT
+ match, discard the ICMP message. If it is 0 and the ICMP
+ message contains enough bytes to verify that the chunk type is
+ an INIT chunk and that the initiate tag matches the tag of the
+ peer, continue with ICMP7. If the ICMP message is too short
+ or the chunk type or the initiate tag does not match, silently
+ discard the packet.
+
+ ICMP7) If the ICMP message is either a V6 "Packet Too Big" or a V4
+ "Fragmentation Needed", an implementation MAY process this
+ information as defined for PATH MTU discovery.
+
+ ICMP8) If the ICMP code is a "Unrecognized next header type
+ encountered" or a "Protocol Unreachable", an implementation
+ MUST treat this message as an abort with the T bit set if it
+ does not contain an INIT chunk. If it does contain an INIT
+
+
+
+Stewart, et al. Informational [Page 78]
+
+RFC 4460 SCTP Errata April 2006
+
+
+ chunk and the association is in COOKIE-WAIT state, handle the
+ ICMP message like an ABORT.
+
+ ICMP9) If the ICMPv6 code is "Destination Unreachable", the
+ implementation MAY mark the destination into the unreachable
+ state or alternatively increment the path error counter.
+
+ Note that these procedures differ from RFC 1122 [1] and from its
+ requirements for processing of port-unreachable messages and the
+ requirements that an implementation MUST abort associations in
+ response to a "protocol unreachable" message. Port unreachable
+ messages are not processed, since an implementation will send an
+ ABORT, not a port unreachable. The stricter handling of the
+ "protocol unreachable" message is due to security concerns for hosts
+ that do NOT support SCTP.
+
+2.37.3. Solution Description
+
+ The new appendix now describes proper handling of ICMP messages in
+ conjunction with SCTP.
+
+2.38. Checksum
+
+2.38.1. Description of the problem
+
+ RFC 3309 [6] changes the SCTP checksum due to weaknesses in the
+ original Adler 32 checksum for small messages. This document, being
+ used as a guide for a cut and paste replacement to update RFC 2960,
+ thus also needs to incorporate the checksum changes. The idea is
+ that one could apply all changes found in this guide to a copy of RFC
+ 2960 and have a "new" document that has ALL changes (including RFC
+ 3309).
+
+2.38.2. Text Changes to the Document
+
+ ---------
+ Old text:
+ ---------
+
+ 6.8 Adler-32 Checksum Calculation
+
+ When sending an SCTP packet, the endpoint MUST strengthen the data
+ integrity of the transmission by including the Adler-32 checksum
+ value calculated on the packet, as described below.
+
+ After the packet is constructed (containing the SCTP common header
+ and one or more control or DATA chunks), the transmitter shall:
+
+
+
+
+Stewart, et al. Informational [Page 79]
+
+RFC 4460 SCTP Errata April 2006
+
+
+ 1) Fill in the proper Verification Tag in the SCTP common header
+ and initialize the checksum field to 0's.
+
+ 2) Calculate the Adler-32 checksum of the whole packet, including
+ the SCTP common header and all the chunks. Refer to
+ appendix B for details of the Adler-32 algorithm. And,
+
+ 3) Put the resultant value into the checksum field in the common
+ header, and leave the rest of the bits unchanged.
+
+ When an SCTP packet is received, the receiver MUST first check the
+ Adler-32 checksum:
+
+ 1) Store the received Adler-32 checksum value aside,
+
+ 2) Replace the 32 bits of the checksum field in the received SCTP
+ packet with all '0's and calculate an Adler-32 checksum value
+ of the whole received packet. And,
+
+ 3) Verify that the calculated Adler-32 checksum is the same as the
+ received Adler-32 checksum. If not, the receiver MUST treat
+ the packet as an invalid SCTP packet.
+
+ The default procedure for handling invalid SCTP packets is to
+ silently discard them.
+
+ ---------
+ New text:
+ ---------
+
+ 6.8 CRC-32c Checksum Calculation
+
+ When sending an SCTP packet, the endpoint MUST strengthen the data
+ integrity of the transmission by including the CRC32c checksum
+ value calculated on the packet, as described below.
+
+ After the packet is constructed (containing the SCTP common header
+ and one or more control or DATA chunks), the transmitter MUST
+
+ 1) fill in the proper Verification Tag in the SCTP common header
+ and initialize the checksum field to '0's,
+
+ 2) calculate the CRC32c checksum of the whole packet, including
+ the SCTP common header and all the chunks (refer to
+ appendix B for details of the CRC32c algorithm); and
+
+ 3) put the resultant value into the checksum field in the common
+ header, and leave the rest of the bits unchanged.
+
+
+
+Stewart, et al. Informational [Page 80]
+
+RFC 4460 SCTP Errata April 2006
+
+
+ When an SCTP packet is received, the receiver MUST first check the
+ CRC32c checksum as follows:
+
+ 1) Store the received CRC32c checksum value aside.
+
+ 2) Replace the 32 bits of the checksum field in the received SCTP
+ packet with all '0's and calculate a CRC32c checksum value of
+ the whole received packet.
+
+ 3) Verify that the calculated CRC32c checksum is the same as the
+ received CRC32c checksum. If it is not, the receiver MUST
+ treat the packet as an invalid SCTP packet.
+
+ The default procedure for handling invalid SCTP packets is to
+ silently discard them.
+
+ Any hardware implementation SHOULD be done in a way that is
+ verifiable by the software.
+
+
+ ---------
+ Old text:
+ ---------
+
+ Appendix B Alder 32 bit checksum calculation
+
+ The Adler-32 checksum calculation given in this appendix is
+ copied from [RFC1950].
+
+ Adler-32 is composed of two sums accumulated per byte: s1 is the
+ sum of all bytes, s2 is the sum of all s1 values. Both sums are
+ done modulo 65521. s1 is initialized to 1, s2 to zero. The
+ Adler-32 checksum is stored as s2*65536 + s1 in network byte
+ order.
+
+ The following C code computes the Adler-32 checksum of a data
+ buffer. It is written for clarity, not for speed. The sample
+ code is in the ANSI C programming language. Non C users may
+ find it easier to read with these hints:
+
+ & Bitwise AND operator.
+ >> Bitwise right shift operator. When applied to an
+ unsigned quantity, as here, right shift inserts zero bit(s)
+ at the left.
+ << Bitwise left shift operator. Left shift inserts zero
+ bit(s) at the right.
+ ++ "n++" increments the variable n.
+ % modulo operator: a % b is the remainder of a divided by b.
+
+
+
+Stewart, et al. Informational [Page 81]
+
+RFC 4460 SCTP Errata April 2006
+
+
+ #define BASE 65521 /* largest prime smaller than 65536 */
+ /*
+ Update a running Adler-32 checksum with the bytes buf[0..len-1]
+ and return the updated checksum. The Adler-32 checksum should
+ be initialized to 1.
+
+ Usage example:
+
+ unsigned long adler = 1L;
+
+ while (read_buffer(buffer, length) != EOF) {
+ adler = update_adler32(adler, buffer, length);
+ }
+ if (adler != original_adler) error();
+ */
+ unsigned long update_adler32(unsigned long adler,
+ unsigned char *buf, int len)
+ {
+ unsigned long s1 = adler & 0xffff;
+ unsigned long s2 = (adler >> 16) & 0xffff;
+ int n;
+
+ for (n = 0; n < len; n++) {
+ s1 = (s1 + buf[n]) % BASE;
+ s2 = (s2 + s1) % BASE;
+ }
+ return (s2 << 16) + s1;
+ }
+
+ /* Return the adler32 of the bytes buf[0..len-1] */
+ unsigned long adler32(unsigned char *buf, int len)
+ {
+ return update_adler32(1L, buf, len);
+ }
+
+ ---------
+ New text:
+ ---------
+
+ Appendix B CRC32c Checksum Calculation
+
+ We define a 'reflected value' as one that is the opposite of the
+ normal bit order of the machine. The 32-bit CRC is calculated as
+ described for CRC-32c and uses the polynomial code 0x11EDC6F41
+ (Castagnoli93) or x^32+x^28+x^27+x^26+x^25
+ +x^23+x^22+x^20+x^19+x^18+x^14+x^13+x^11+x^10+x^9+x^8+x^6+x^0.
+ The CRC is computed using a procedure similar to ETHERNET CRC
+ [ITU32], modified to reflect transport level usage.
+
+
+
+Stewart, et al. Informational [Page 82]
+
+RFC 4460 SCTP Errata April 2006
+
+
+ CRC computation uses polynomial division. A message
+ bit-string M is transformed to a polynomial, M(X), and the CRC
+ is calculated from M(X) using polynomial arithmetic [PETERSON 72].
+
+ When CRCs are used at the link layer, the polynomial is derived
+ from on-the-wire bit ordering: the first bit 'on the wire' is the
+ high-order coefficient. Since SCTP is a transport-level protocol,
+ it cannot know the actual serial-media bit ordering. Moreover,
+ different links in the path between SCTP endpoints may use
+ different link-level bit orders.
+
+ A convention must therefore be established for mapping SCTP
+ transport messages to polynomials for purposes of CRC computation.
+ The bit-ordering for mapping SCTP messages to polynomials is that
+ bytes are taken most-significant first; but within each byte, bits
+ are taken least-significant first. The first byte of the message
+ provides the eight highest coefficients. Within each byte,
+ the least-significant SCTP bit gives the most significant
+ polynomial coefficient within that byte, and the most-significant
+ SCTP bit is the least significant polynomial coefficient in that
+ byte. (This bit ordering is sometimes called 'mirrored' or
+ 'reflected' [WILLIAMS93].) CRC polynomials are to be transformed
+ back into SCTP transport-level byte values, using a consistent
+ mapping.
+
+ The SCTP transport-level CRC value should be calculated as
+ follows:
+
+ - CRC input data are assigned to a byte stream, numbered from
+ 0 to N-1.
+
+ - The transport-level byte-stream is mapped to a polynomial
+ value. An N-byte PDU with j bytes numbered 0 to N-1 is
+ considered as coefficients of a polynomial M(x) of order
+ 8N-1, with bit 0 of byte j being coefficient x^(8(N-j)-8),
+ and bit 7 of byte j being coefficient x^(8(N-j)-1).
+
+ - The CRC remainder register is initialized with all 1s and
+ the CRC is computed with an algorithm that simultaneously
+ multiplies by x^32 and divides by the CRC polynomial.
+
+ - The polynomial is multiplied by x^32 and divided by G(x),
+ the generator polynomial, producing a remainder R(x) of
+ degree less than or equal to 31.
+
+ - The coefficients of R(x) are considered a 32-bit sequence.
+
+
+
+
+
+Stewart, et al. Informational [Page 83]
+
+RFC 4460 SCTP Errata April 2006
+
+
+ - The bit sequence is complemented. The result is the CRC
+ polynomial.
+
+ - The CRC polynomial is mapped back into SCTP transport-level
+ bytes. The coefficient of x^31 gives the value of bit 7 of
+ SCTP byte 0, and the coefficient of x^24 gives the value of
+ bit 0 of byte 0. The coefficient of x^7 gives bit 7 of
+ byte 3, and the coefficient of x^0 gives bit 0 of byte 3.
+ The resulting four-byte transport-level sequence is the
+ 32-bit SCTP checksum value.
+
+ IMPLEMENTATION NOTE: Standards documents, textbooks, and vendor
+ literature on CRCs often follow an alternative formulation, in
+ which the register used to hold the remainder of the
+ long-division algorithm is initialized to zero rather than
+ all-1s, and instead the first 32 bits of the message are
+ complemented. The long-division algorithm used in our
+ formulation is specified such that the initial
+ multiplication by 2^32 and the long-division are combined into
+ one simultaneous operation. For such algorithms, and for
+ messages longer than 64 bits, the two specifications are
+ precisely equivalent. That equivalence is the intent of
+ this document.
+
+ Implementors of SCTP are warned that both specifications are to be
+ found in the literature, sometimes with no restriction on the
+ long-division algorithm. The choice of formulation in this
+ document is to permit non-SCTP usage, where the same CRC
+ algorithm may be used to protect messages shorter than 64 bits.
+
+ There may be a computational advantage in validating the
+ Association against the Verification Tag, prior to performing a
+ checksum, as invalid tags will result in the same action as a bad
+ checksum in most cases. The exceptions for this technique would
+ be INIT and some SHUTDOWN-COMPLETE exchanges, as well as a stale
+ COOKIE-ECHO. These special case exchanges must represent small
+ packets and will minimize the effect of the checksum calculation.
+
+
+ ---------
+ Old text: (Section 18)
+ ---------
+
+ 18. Bibliography
+
+ [ALLMAN99] Allman, M. and Paxson, V., "On Estimating End-to-End
+ Network Path Properties", Proc. SIGCOMM'99, 1999.
+
+
+
+
+Stewart, et al. Informational [Page 84]
+
+RFC 4460 SCTP Errata April 2006
+
+
+ [FALL96] Fall, K. and Floyd, S., Simulation-based Comparisons of
+ Tahoe, Reno, and SACK TCP, Computer Communications Review,
+ V. 26 N. 3, July 1996, pp. 5-21.
+
+ [RFC1750] Eastlake, D. (ed.), "Randomness Recommendations for
+ Security", RFC 1750, December 1994.
+
+ [RFC1950] Deutsch P. and J. Gailly, "ZLIB Compressed Data Format
+ Specification version 3.3", RFC 1950, May 1996.
+
+ [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-
+ Hashing for Message Authentication", RFC 2104, March 1997.
+
+ [RFC2196] Fraser, B., "Site Security Handbook", FYI 8, RFC 2196,
+ September 1997.
+
+ [RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management
+ Protocol", RFC 2522, March 1999.
+
+ [SAVAGE99] Savage, S., Cardwell, N., Wetherall, D., and Anderson, T.,
+ "TCP Congestion Control with a Misbehaving Receiver", ACM
+ Computer Communication Review, 29(5), October 1999.
+
+ ---------
+ New text: (Section 18, including changes from 2.11)
+ ---------
+
+ 18. Bibliography
+
+ [ALLMAN99] Allman, M. and Paxson, V., "On Estimating End-to-End
+ Network Path Properties", Proc. SIGCOMM'99, 1999.
+
+ [FALL96] Fall, K. and Floyd, S., Simulation-based Comparisons of
+ Tahoe, Reno, and SACK TCP, Computer Communications Review,
+ V. 26 N. 3, July 1996, pp. 5-21.
+
+ [ITU32] ITU-T Recommendation V.42, "Error-correcting
+ procedures for DCEs using asynchronous-to-synchronous
+ conversion", Section 8.1.1.6.2, October 1996.
+
+ [PETERSON 1972] W. W. Peterson and E.J Weldon, Error Correcting
+ Codes, 2nd Edition, MIT Press, Cambridge,
+ Massachusetts.
+
+ [RFC1750] Eastlake, D., Ed., "Randomness Recommendations for
+ Security", RFC 1750, December 1994.
+
+
+
+
+
+Stewart, et al. Informational [Page 85]
+
+RFC 4460 SCTP Errata April 2006
+
+
+ [RFC1858] Ziemba, G., Reed, D. and Traina P., "Security
+ Considerations for IP Fragment Filtering", RFC 1858,
+ October 1995.
+
+ [RFC1950] Deutsch P. and J. Gailly, "ZLIB Compressed Data Format
+ Specification version 3.3", RFC 1950, May 1996.
+
+ [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-
+ Hashing for Message Authentication", RFC 2104, March 1997.
+
+ [RFC2196] Fraser, B., "Site Security Handbook", FYI 8, RFC 2196,
+ September 1997.
+
+ [RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management
+ Protocol", RFC 2522, March 1999.
+
+ [SAVAGE99] Savage, S., Cardwell, N., Wetherall, D., and Anderson, T.,
+ "TCP Congestion Control with a Misbehaving Receiver", ACM
+ Computer Communication Review, 29(5), October 1999.
+
+ [WILLIAMS93] Williams, R., "A PAINLESS GUIDE TO CRC ERROR
+ DETECTION ALGORITHMS" - Internet publication, August
+ 1993,
+ http://www.geocities.com/SiliconValley/Pines/
+ 8659/crc.htm.
+
+2.38.3. Solution Description
+
+ This change adds to the implementor's guide the complete set of
+ changes that, when combined with RFC 2960 [5], encompasses the
+ changes from RFC 3309 [6].
+
+2.39. Retransmission Policy
+
+2.39.1. Description of the Problem
+
+ The current retransmission policy (send all retransmissions an
+ alternate destination) in the specification has performance issues
+ under certain loss conditions with multihomed endpoints. Instead,
+ fast retransmissions should be sent to the same destination, and only
+ timeout retransmissions should be sent to an alternate destination
+ [4].
+
+
+
+
+
+
+
+
+
+Stewart, et al. Informational [Page 86]
+
+RFC 4460 SCTP Errata April 2006
+
+
+2.39.2. Text Changes to the Document
+
+ ---------
+ Old text: (Section 6.4)
+ ---------
+
+ Furthermore, when its peer is multi-homed, an endpoint SHOULD try to
+ retransmit a chunk to an active destination transport address that is
+ different from the last destination address to which the DATA chunk
+ was sent.
+
+ ---------
+ New text: (Section 6.4)
+ ---------
+
+ Furthermore, when its peer is multi-homed, an endpoint SHOULD try to
+ retransmit a chunk that timed out to an active destination transport
+ address that is different from the last destination address to which
+ the DATA chunk was sent.
+
+ ---------
+ Old text: (Section 6.4.1)
+ ---------
+
+ When retransmitting data, if the endpoint is multi-homed, it should
+ consider each source-destination address pair in its retransmission
+ selection policy. When retransmitting the endpoint should attempt to
+ pick the most divergent source-destination pair from the original
+ source-destination pair to which the packet was transmitted.
+
+ ---------
+ New text: (Section 6.4.1)
+ ---------
+
+ When retransmitting data that timed out, if the endpoint is
+ multi-homed, it should consider each source-destination address
+ pair in its retransmission selection policy. When retransmitting
+ timed out data, the endpoint should attempt to pick the most
+ divergent source-destination pair from the original
+ source-destination pair to which the packet was transmitted.
+
+2.39.3. Solution Description
+
+ The above wording changes clarify that only timeout retransmissions
+ should be sent to an alternate active destination.
+
+
+
+
+
+
+Stewart, et al. Informational [Page 87]
+
+RFC 4460 SCTP Errata April 2006
+
+
+2.40. Port Number 0
+
+2.40.1. Description of the Problem
+
+ The port number 0 has a special semantic in various APIs. For
+ example, in the socket API, if the user specifies 0, the SCTP
+ implementation chooses an appropriate port number for the user.
+ Therefore, the port number 0 should not be used on the wire.
+
+2.40.2. Text Changes to the Document
+
+ ---------
+ Old text: (Section 3.1)
+ ---------
+
+ Source Port Number: 16 bits (unsigned integer)
+
+ This is the SCTP sender's port number. It can be used by the
+ receiver in combination with the source IP address, the SCTP
+ destination port, and possibly the destination IP address to
+ identify the association to which this packet belongs.
+
+ Destination Port Number: 16 bits (unsigned integer)
+
+ This is the SCTP port number to which this packet is destined.
+ The receiving host will use this port number to de-multiplex
+ the SCTP packet to the correct receiving endpoint/application.
+
+ ---------
+ New text: (Section 3.1)
+ ---------
+
+ Source Port Number: 16 bits (unsigned integer)
+
+ This is the SCTP sender's port number. It can be used by the
+ receiver in combination with the source IP address, the SCTP
+ destination port and possibly the destination IP address to
+ identify the association to which this packet belongs.
+ The port number 0 MUST NOT be used.
+
+ Destination Port Number: 16 bits (unsigned integer)
+
+ This is the SCTP port number to which this packet is destined.
+ The receiving host will use this port number to de-multiplex
+ the SCTP packet to the correct receiving endpoint/application.
+ The port number 0 MUST NOT be used.
+
+
+
+
+
+Stewart, et al. Informational [Page 88]
+
+RFC 4460 SCTP Errata April 2006
+
+
+2.40.3. Solution Description
+
+ It is clearly stated that the port number 0 is an invalid value on
+ the wire.
+
+2.41. T Bit
+
+2.41.1. Description of the Problem
+
+ The description of the T bit as the bit describing whether a TCB has
+ been destroyed is misleading. In addition, the procedure described
+ in Section 2.13 is not as precise as needed.
+
+2.41.2. Text Changes to the Document
+
+ ---------
+ Old text: (Section 3.3.7)
+ ---------
+
+ T bit: 1 bit
+ The T bit is set to 0 if the sender had a TCB that it
+ destroyed. If the sender did not have a TCB it should set
+ this bit to 1.
+
+ ---------
+ New text: (Section 3.3.7)
+ ---------
+
+ T bit: 1 bit
+ The T bit is set to 0 if the sender filled in the
+ Verification Tag expected by the peer. If the Verification
+ Tag is reflected, the T bit MUST be set to 1. Reflecting means
+ that the sent Verification Tag is the same as the received
+ one.
+
+
+ ---------
+ Old text: (Section 3.3.13)
+ ---------
+
+ T bit: 1 bit
+ The T bit is set to 0 if the sender had a TCB that it
+ destroyed. If the sender did not have a TCB it should set
+ this bit to 1.
+
+
+
+
+
+
+
+Stewart, et al. Informational [Page 89]
+
+RFC 4460 SCTP Errata April 2006
+
+
+ ---------
+ New text: (Section 3.3.13)
+ ---------
+
+ T bit: 1 bit
+ The T bit is set to 0 if the sender filled in the
+ Verification Tag expected by the peer. If the Verification
+ Tag is reflected, the T bit MUST be set to 1. Reflecting means
+ that the sent Verification Tag is the same as the received
+ one.
+
+
+ ---------
+ Old text: (Section 8.4)
+ ---------
+
+ 3) If the packet contains an INIT chunk with a Verification Tag
+ set to '0', process it as described in Section 5.1.
+ Otherwise,
+
+ ---------
+ New text: (Section 8.4)
+ ---------
+ 3) If the packet contains an INIT chunk with a Verification Tag
+ set to '0', process it as described in Section 5.1. If, for
+ whatever reason, the INIT cannot be processed normally and
+ an ABORT has to be sent in response, the Verification Tag of
+ the packet containing the ABORT chunk MUST be the Initiate
+ tag of the received INIT chunk, and the T-Bit of the ABORT
+ chunk has to be set to 0, indicating that the Verification
+ Tag is NOT reflected.
+
+
+ ---------
+ Old text: (Section 8.4)
+ ---------
+ 5) If the packet contains a SHUTDOWN ACK chunk, the receiver
+ should respond to the sender of the OOTB packet with a
+ SHUTDOWN COMPLETE. When sending the SHUTDOWN COMPLETE, the
+ receiver of the OOTB packet must fill in the Verification
+ Tag field of the outbound packet with the Verification Tag
+ received in the SHUTDOWN ACK and set the T-bit in the Chunk
+ Flags to indicate that no TCB was found. Otherwise,
+
+
+
+
+
+
+
+
+Stewart, et al. Informational [Page 90]
+
+RFC 4460 SCTP Errata April 2006
+
+
+ ---------
+ New text: (Section 8.4)
+ ---------
+
+ 5) If the packet contains a SHUTDOWN ACK chunk, the receiver
+ should respond to the sender of the OOTB packet with a
+ SHUTDOWN COMPLETE. When sending the SHUTDOWN COMPLETE, the
+ receiver of the OOTB packet must fill in the Verification
+ Tag field of the outbound packet with the Verification Tag
+ received in the SHUTDOWN ACK and set the T-bit in the
+ Chunk Flags to indicate that the Verification Tag is
+ reflected. Otherwise,
+
+
+ ---------
+ Old text: (Section 8.4)
+ ---------
+
+ 8) The receiver should respond to the sender of the OOTB packet
+ with an ABORT. When sending the ABORT, the receiver of the
+ OOTB packet MUST fill in the Verification Tag field of the
+ outbound packet with the value found in the Verification
+ Tag field of the OOTB packet and set the T-bit in the Chunk
+ Flags to indicate that no TCB was found. After sending this
+ ABORT, the receiver of the OOTB packet shall discard the
+ OOTB packet and take no further action.
+
+ ---------
+ New text: (Section 8.4)
+ ---------
+
+ 8) The receiver should respond to the sender of the OOTB packet
+ with an ABORT. When sending the ABORT, the receiver of the
+ OOTB packet MUST fill in the Verification Tag field of the
+ outbound packet with the value found in the Verification Tag
+ field of the OOTB packet and set the T-bit in the Chunk Flags
+ to indicate that the Verification Tag is reflected. After
+ sending this ABORT, the receiver of the OOTB packet shall
+ discard the OOTB packet and take no further action.
+
+
+ ---------
+ Old text: (Section 8.5.1)
+ ---------
+
+ B) Rules for packet carrying ABORT:
+
+
+
+
+
+Stewart, et al. Informational [Page 91]
+
+RFC 4460 SCTP Errata April 2006
+
+
+ - The endpoint shall always fill in the Verification Tag
+ field of the outbound packet with the destination
+ endpoint's tag value if it is known.
+
+ - If the ABORT is sent in response to an OOTB packet, the
+ endpoint MUST follow the procedure described in
+ Section 8.4.
+
+ - The receiver MUST accept the packet if the Verification
+ Tag matches either its own tag, OR the tag of its peer.
+ Otherwise, the receiver MUST silently discard the packet
+ and take no further action.
+
+ ---------
+ New text: (Section 8.5.1)
+ ---------
+
+ B) Rules for packet carrying ABORT:
+
+ - The endpoint MUST always fill in the Verification Tag
+ field of the outbound packet with the destination
+ endpoint's tag value, if it is known.
+
+ - If the ABORT is sent in response to an OOTB packet, the
+ endpoint MUST follow the procedure described in
+ Section 8.4.
+
+ - The receiver of an ABORT MUST accept the packet
+ if the Verification Tag field of the packet matches its
+ own tag and the T bit is not set
+ OR
+ if it is set to its peer's tag and the T bit is set in
+ the Chunk Flags.
+ Otherwise, the receiver MUST silently discard the packet
+ and take no further action.
+
+
+ ---------
+ Old text: (Section 8.5.1)
+ ---------
+
+ C) Rules for packet carrying SHUTDOWN COMPLETE:
+
+ - When sending a SHUTDOWN COMPLETE, if the receiver of the
+ SHUTDOWN ACK has a TCB then the destination endpoint's
+ tag MUST be used. Only where no TCB exists should the
+ sender use the Verification Tag from the SHUTDOWN ACK.
+
+
+
+
+Stewart, et al. Informational [Page 92]
+
+RFC 4460 SCTP Errata April 2006
+
+
+ - The receiver of a SHUTDOWN COMPLETE shall accept the
+ packet if the Verification Tag field of the packet matches
+ its own tag OR it is set to its peer's tag and the T bit
+ is set in the Chunk Flags. Otherwise, the receiver MUST
+ silently discard the packet and take no further action.
+ An endpoint MUST ignore the SHUTDOWN COMPLETE if it is
+ not in the SHUTDOWN-ACK-SENT state.
+
+ ---------
+ New text: (Section 8.5.1)
+ ---------
+
+ C) Rules for packet carrying SHUTDOWN COMPLETE:
+
+ - When sending a SHUTDOWN COMPLETE, if the receiver of the
+ SHUTDOWN ACK has a TCB, then the destination endpoint's tag
+ MUST be used, and the T-bit MUST NOT be set. Only where no
+ TCB exists should the sender use the Verification Tag from
+ the SHUTDOWN ACK, and MUST set the T-bit.
+
+ - The receiver of a SHUTDOWN COMPLETE shall accept the packet
+ if the Verification Tag field of the packet matches its own
+ tag and the T bit is not set
+ OR
+ if it is set to its peer's tag and the T bit is set in the
+ Chunk Flags.
+ Otherwise, the receiver MUST silently discard the packet
+ and take no further action. An endpoint MUST ignore the
+ SHUTDOWN COMPLETE if it is not in the SHUTDOWN-ACK-SENT
+ state.
+
+2.41.3. Solution Description
+
+ The description of the T bit now clearly describes the semantic of
+ the bit. The procedures for receiving the T bit have been clarified.
+
+2.42. Unknown Parameter Handling
+
+2.42.1. Description of the Problem
+
+ The description given in Section 2.33 does not state clearly whether
+ an INIT-ACK or COOKIE-ECHO is sent.
+
+2.42.2. Text Changes to the Document
+
+ The changes given here already include changes suggested in Section
+ 2.2, 2.27, and 2.33 of this document.
+
+
+
+
+Stewart, et al. Informational [Page 93]
+
+RFC 4460 SCTP Errata April 2006
+
+
+ ---------
+ Old text: (Section 3.2.1)
+ ---------
+
+ 00 - Stop processing this SCTP packet and discard it do not process
+ any further chunks within it.
+
+ 01 - Stop processing this SCTP packet and discard it, do not process
+ any further chunks within it, and report the unrecognized
+ parameter in an 'Unrecognized Parameter Type' (in either an
+ ERROR or in the INIT ACK).
+
+ 10 - Skip this parameter and continue processing.
+
+ 11 - Skip this parameter and continue processing but report the
+ unrecognized parameter in an 'Unrecognized Parameter Type' (in
+ either an ERROR or in the INIT ACK).
+
+ ---------
+ New text: (Section 3.2.1)
+ ---------
+
+ 00 - Stop processing this parameter; do not process
+ any further parameters within this chunk.
+
+ 01 - Stop processing this parameter, do not process
+ any further parameters within this chunk, and report the
+ unrecognized parameter in an 'Unrecognized Parameter', as
+ described in 3.2.2.
+
+ 10 - Skip this parameter and continue processing.
+
+ 11 - Skip this parameter and continue processing but report the
+ unrecognized parameter in an 'Unrecognized Parameter', as
+ described in 3.2.2.
+
+ Please note that in all four cases an INIT-ACK or COOKIE-ECHO
+ chunk is sent. In the 00 or 01 case the processing of the
+ parameters after the unknown parameter is canceled, but no
+ processing already done is rolled back.
+
+
+
+
+
+
+
+
+
+
+
+Stewart, et al. Informational [Page 94]
+
+RFC 4460 SCTP Errata April 2006
+
+
+ ---------
+ New text: (Note: no old text; clarification added in Section 3.2)
+ ---------
+
+ 3.2.2. Reporting of Unrecognized Parameters
+
+ If the receiver of an INIT chunk detects unrecognized parameters
+ and has to report them according to Section 3.2.1, it MUST put
+ the 'Unrecognized Parameter' parameter(s) in the INIT-ACK chunk
+ sent in response to the INIT-chunk. Note that if the receiver
+ of the INIT chunk is NOT going to establish an association (e.g.,
+ due to lack of resources), an 'Unrecognized Parameter' would NOT
+ be included with any ABORT being sent to the sender of the INIT.
+
+ If the receiver of an INIT-ACK chunk detects unrecognized
+ parameters and has to report them according to Section 3.2.1, it
+ SHOULD bundle the ERROR chunk containing the 'Unrecognized
+ Parameters' error cause with the COOKIE-ECHO chunk sent in
+ response to the INIT-ACK chunk. If the receiver of the INIT-ACK
+ cannot bundle the COOKIE-ECHO chunk with the ERROR chunk, the
+ ERROR chunk MAY be sent separately but not before the COOKIE-ACK
+ has been received.
+
+ Note: Any time a COOKIE-ECHO is sent in a packet, it MUST be the
+ first chunk.
+
+2.42.3. Solution Description
+
+ The new text clearly states that an INIT-ACK or COOKIE-ECHO has to be
+ sent.
+
+2.43. Cookie Echo Chunk
+
+2.43.1. Description of the Problem
+
+ The description given in Section 3.3.11 of RFC 2960 [5] is unclear as
+ to how the COOKIE-ECHO is composed.
+
+2.43.2. Text Changes to the Document
+
+ ---------
+ Old text: (Section 3.3.11)
+ ---------
+ Cookie: variable size
+
+ This field must contain the exact cookie received in the State
+ Cookie parameter from the previous INIT ACK.
+
+
+
+
+Stewart, et al. Informational [Page 95]
+
+RFC 4460 SCTP Errata April 2006
+
+
+ An implementation SHOULD make the cookie as small as possible
+ to insure interoperability.
+
+ ---------
+ New text: (Section 3.3.11)
+ ---------
+ Cookie: variable size
+
+ This field must contain the exact cookie received in the State
+ Cookie parameter from the previous INIT ACK.
+
+ An implementation SHOULD make the cookie as small as possible
+ to ensure interoperability.
+
+ Note: A Cookie Echo does NOT contain a State Cookie
+ Parameter; instead, the data within the State Cookie's
+ Parameter Value becomes the data within the Cookie Echo's
+ Chunk Value. This allows an implementation to change only
+ the first two bytes of the State Cookie parameter to become
+ a Cookie Echo Chunk.
+
+2.43.3. Solution Description
+
+ The new text adds a note that helps clarify that a Cookie Echo chunk
+ is nothing more than the State Cookie parameter with only two bytes
+ modified.
+
+2.44. Partial Chunks
+
+2.44.1. Description of the Problem
+
+ Section 6.10 of RFC 2960 [5] uses the notion of 'partial chunks'
+ without defining it.
+
+2.44.2. Text Changes to the Document
+
+ ---------
+ Old text: (Section 6.10)
+ ---------
+ Partial chunks MUST NOT be placed in an SCTP packet.
+
+ ---------
+ New text: (Section 6.10)
+ ---------
+ Partial chunks MUST NOT be placed in an SCTP packet. A partial
+ chunk is a chunk that is not completely contained in the SCTP
+ packet; i.e., the SCTP packet is too short to contain all the bytes
+ of the chunk as indicated by the chunk length.
+
+
+
+Stewart, et al. Informational [Page 96]
+
+RFC 4460 SCTP Errata April 2006
+
+
+2.44.3. Solution Description
+
+ The new text adds a definition of 'partial chunks'.
+
+2.45. Non-unicast Addresses
+
+2.45.1. Description of the Problem
+
+ Section 8.4 of RFC 2960 [5] forces the OOTB handling to discard all
+ non-unicast addresses. This leaves future use of anycast addresses
+ in question. With the addition of the add-ip feature, SCTP should be
+ able to easily handle anycast INIT s that can be followed, after
+ association setup, with a delete of the anycast address from the
+ association.
+
+2.45.2. Text Changes to the Document
+
+ ---------
+ Old text: (Section 8.4)
+ ---------
+ 8.4 Handle "Out of the blue" Packets
+
+ An SCTP packet is called an "out of the blue" (OOTB) packet if
+ it is correctly formed, i.e., passed the receiver's Adler-32
+ check (see Section 6.8), but the receiver is not able to
+ identify the association to which this packet belongs.
+
+ The receiver of an OOTB packet MUST do the following:
+
+ 1) If the OOTB packet is to or from a non-unicast address,
+ silently discard the packet. Otherwise,
+
+
+ ---------
+ New text: (Section 8.4)
+ ---------
+
+ 8.4. Handle "Out of the Blue" Packets
+
+ An SCTP packet is called an "out of the blue" (OOTB) packet if
+ it is correctly formed (i.e., passed the receiver's CRC32c
+ check; see Section 6.8), but the receiver is not able to identify
+ the association to which this packet belongs.
+
+ The receiver of an OOTB packet MUST do the following:
+
+ 1) If the OOTB packet is to or from a non-unicast address, a
+ receiver SHOULD silently discard the packet. Otherwise,
+
+
+
+Stewart, et al. Informational [Page 97]
+
+RFC 4460 SCTP Errata April 2006
+
+
+2.45.3. Solution Description
+
+ The loosening of the wording to a SHOULD will now allow future use of
+ anycast addresses. Note that no changes are made to Section
+ 11.2.4.1, since responding to broadcast addresses could lead to
+ flooding attacks and implementors should pay careful attention to
+ these words.
+
+2.46. Processing of ABORT Chunks
+
+2.46.1. Description of the Problem
+
+ Section 3.3.7 of RFC 2960 [5] requires an SCTP endpoint to silently
+ discard ABORT chunks received for associations that do not exist. It
+ is not clear what this means in the COOKIE-WAIT state, for example.
+ Therefore, it was not clear whether an ABORT sent in response to an
+ INIT should be processed or silently discarded.
+
+2.46.2. Text Changes to the Document
+
+ ---------
+ Old text: (Section 3.3.7)
+ ---------
+
+ If an endpoint receives an ABORT with a format error or for an
+ association that doesn't exist, it MUST silently discard it.
+
+ ---------
+ New text: (Section 3.3.7)
+ ---------
+
+ If an endpoint receives an ABORT with a format error or no
+ TCB is found, it MUST silently discard it.
+
+2.46.3. Solution Description
+
+ It is now clearly stated that an ABORT chunk should be processed
+ whenever a TCB is found.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stewart, et al. Informational [Page 98]
+
+RFC 4460 SCTP Errata April 2006
+
+
+2.47. Sending of ABORT Chunks
+
+2.47.1. Description of the Problem
+
+ Section 5.1 of RFC 2960 [5] requires that an ABORT chunk be sent in
+ response to an INIT chunk when there is no listening end point. To
+ make port scanning harder, someone might not want these ABORTs to be
+ received by the sender of the INIT chunks. Currently, the only way
+ to enforce this is by using a firewall that discards the packets
+ containing the INIT chunks or the packets containing the ABORT
+ chunks. It is desirable that the same can be done without a middle
+ box.
+
+2.47.2. Text Changes to the Document
+
+ ---------
+ Old text: (Section 5.1)
+ ---------
+
+ If an endpoint receives an INIT, INIT ACK, or COOKIE ECHO chunk
+ but decides not to establish the new association due to missing
+ mandatory parameters in the received INIT or INIT ACK, invalid
+ parameter values, or lack of local resources, it MUST respond with
+ an ABORT chunk.
+
+ ---------
+ New text: (Section 5.1)
+ ---------
+
+ If an endpoint receives an INIT, INIT ACK, or COOKIE ECHO chunk
+ but decides not to establish the new association due to missing
+ mandatory parameters in the received INIT or INIT ACK, invalid
+ parameter values, or lack of local resources, it SHOULD respond
+ with an ABORT chunk.
+
+2.47.3. Solution Description
+
+ The requirement of sending ABORT chunks is relaxed such that an
+ implementation can decide not to send ABORT chunks.
+
+2.48. Handling of Supported Address Types Parameter
+
+2.48.1. Description of the Problem
+
+ The sender of the INIT chunk can include a 'Supported Address Types'
+ parameter to indicate which address families are supported. It is
+ unclear how an INIT chunk should be processed where the source
+ address of the packet containing the INIT chunk or listed addresses
+
+
+
+Stewart, et al. Informational [Page 99]
+
+RFC 4460 SCTP Errata April 2006
+
+
+ within the INIT chunk indicate that more address types are supported
+ than those listed in the 'Supported Address Types' parameter.
+
+2.48.2. Text Changes to the Document
+
+ The changes given here already include changes suggested in Section
+ 2.28 of this document.
+
+ ---------
+ Old text: (Section 5.1.2)
+ ---------
+
+ IMPLEMENTATION NOTE: In the case that the receiver of an INIT ACK
+ fails to resolve the address parameter due to an unsupported type,
+ it can abort the initiation process and then attempt a
+ re-initiation by using a 'Supported Address Types' parameter in
+ the new INIT to indicate what types of address it prefers.
+
+ ---------
+ New text: (Section 5.1.2)
+ ---------
+
+ IMPLEMENTATION NOTE: In the case that the receiver of an INIT ACK
+ fails to resolve the address parameter due to an unsupported type,
+ it can abort the initiation process and then attempt a re-
+ initiation by using a 'Supported Address Types' parameter in the
+ new INIT to indicate what types of address it prefers.
+
+ IMPLEMENTATION NOTE: If an SCTP endpoint that only supports either
+ IPv4 or IPv6 receives IPv4 and IPv6 addresses in an INIT or INIT-
+ ACK chunk from its peer, it MUST use all the addresses belonging
+ to the supported address family. The other addresses MAY be
+ ignored. The endpoint SHOULD NOT respond with any kind of error
+ indication.
+
+ IMPLEMENTATION NOTE: If an SCTP endpoint lists in the 'Supported
+ Address Types' parameter either IPv4 or IPv6, but uses the other
+ family for sending the packet containing the INIT chunk, or if it
+ also lists addresses of the other family in the INIT chunk, then
+ the address family that is not listed in the 'Supported Address
+ Types' parameter SHOULD also be considered as supported by the
+ receiver of the INIT chunk. The receiver of the INIT chunk SHOULD
+ NOT respond with any kind of error indication.
+
+2.48.3. Solution Description
+
+ It is now clearly described how these Supported Address Types
+ parameters with incorrect data should be handled.
+
+
+
+Stewart, et al. Informational [Page 100]
+
+RFC 4460 SCTP Errata April 2006
+
+
+2.49. Handling of Unexpected Parameters
+
+2.49.1. Description of the Problem
+
+ RFC 2960 [5] clearly describes how unknown parameters in the INIT and
+ INIT-ACK chunk should be processed. But it is not described how
+ unexpected parameters should be processed. A parameter is unexpected
+ if it is known and is an optional parameter in either the INIT or
+ INIT-ACK chunk but is received in the chunk for which it is not an
+ optional parameter. For example, the 'Supported Address Types'
+ parameter would be an unexpected parameter if contained in an INIT-
+ ACK chunk.
+
+2.49.2. Text Changes to the Document
+
+ ---------
+ Old text: (Section 3.3.2)
+ ---------
+
+ Note 4: This parameter, when present, specifies all the address
+ types the sending endpoint can support. The absence of this
+ parameter indicates that the sending endpoint can support any
+ address type.
+
+ ---------
+ New text: (Section 3.3.2)
+ ---------
+
+ Note 4: This parameter, when present, specifies all the address
+ types the sending endpoint can support. The absence of this
+ parameter indicates that the sending endpoint can support any
+ address type.
+
+ IMPLEMENTATION NOTE: If an INIT chunk is received with known
+ parameters that are not optional parameters of the INIT chunk
+ then the receiver SHOULD process the INIT chunk and send back
+ an INIT-ACK. The receiver of the INIT chunk MAY bundle an ERROR
+ chunk with the COOKIE-ACK chunk later. However, restrictive
+ implementations MAY send back an ABORT chunk in response to
+ the INIT chunk.
+
+
+
+
+
+
+
+
+
+
+
+Stewart, et al. Informational [Page 101]
+
+RFC 4460 SCTP Errata April 2006
+
+
+ ---------
+ Old text: (Section 3.3.3)
+ ---------
+
+ IMPLEMENTATION NOTE: An implementation MUST be prepared to receive
+ a INIT ACK that is quite large (more than 1500 bytes) due to the
+ variable size of the state cookie AND the variable address list.
+ For example if a responder to the INIT has 1000 IPv4 addresses
+ it wishes to send, it would need at least 8,000 bytes to encode
+ this in the INIT ACK.
+
+ ---------
+ New text: (Section 3.3.3)
+ ---------
+
+ IMPLEMENTATION NOTE: An implementation MUST be prepared to receive
+ a INIT ACK that is quite large (more than 1500 bytes) due to the
+ variable size of the state cookie AND the variable address list.
+ For example, if a responder to the INIT has 1000 IPv4 addresses
+ it wishes to send, it would need at least 8,000 bytes to encode
+ this in the INIT ACK.
+
+ IMPLEMENTATION NOTE: If an INIT-ACK chunk is received with known
+ parameters that are not optional parameters of the INIT-ACK
+ chunk, then the receiver SHOULD process the INIT-ACK chunk and
+ send back a COOKIE-ECHO. The receiver of the INIT-ACK chunk
+ MAY bundle an ERROR chunk with the COOKIE-ECHO chunk. However,
+ restrictive implementations MAY send back an ABORT chunk in
+ response to the INIT-ACK chunk.
+
+2.49.3. Solution Description
+
+ It is now stated how unexpected parameters should be processed.
+
+2.50. Payload Protocol Identifier
+
+2.50.1. Description of the Problem
+
+ The current description of the payload protocol identifier does NOT
+ highlight the fact that the field is NOT necessarily in network byte
+ order.
+
+
+
+
+
+
+
+
+
+
+Stewart, et al. Informational [Page 102]
+
+RFC 4460 SCTP Errata April 2006
+
+
+2.50.2. Text Changes to the Document
+
+ ---------
+ Old text: (Section 3.3.1)
+ ---------
+ Payload Protocol Identifier: 32 bits (unsigned integer)
+
+ This value represents an application (or upper layer) specified
+ protocol identifier. This value is passed to SCTP by its upper
+ layer and sent to its peer. This identifier is not used by
+ SCTP but can be used by certain network entities as well as
+ the peer application to identify the type of information being
+ carried in this DATA chunk. This field must be sent even in
+ fragmented DATA chunks (to make sure it is available for agents
+ in the middle of the network).
+
+ The value 0 indicates no application identifier is specified by
+ the upper layer for this payload data.
+
+ ---------
+ New text: (Section 3.3.1)
+ ---------
+ Payload Protocol Identifier: 32 bits (unsigned integer)
+
+ This value represents an application (or upper layer) specified
+ protocol identifier. This value is passed to SCTP by its upper
+ layer and sent to its peer. This identifier is not used by
+ SCTP but can be used by certain network entities, as well as by
+ the peer application, to identify the type of information being
+ carried in this DATA chunk. This field must be sent even in
+ fragmented DATA chunks (to make sure it is available for agents
+ in the middle of the network). Note that this field is NOT
+ touched by an SCTP implementation, therefore its byte order is
+ NOT necessarily Big Endian. The upper layer is responsible
+ for any byte order conversions to this field.
+
+ The value 0 indicates that no application identifier is
+ specified by the upper layer for this payload data.
+
+2.50.3. Solution Description
+
+ It is now explicitly stated that the upper layer is responsible for
+ the byte order of this field.
+
+
+
+
+
+
+
+
+Stewart, et al. Informational [Page 103]
+
+RFC 4460 SCTP Errata April 2006
+
+
+2.51. Karn's Algorithm
+
+2.51.1. Description of the Problem
+
+ The current wording of the use of Karn's algorithm is not descriptive
+ enough to ensure that an implementation in a multi-homed association
+ does not incorrectly mismeasure the RTT.
+
+2.51.2. Text Changes to the Document
+
+ ---------
+ Old text: (Section 6.3.1)
+ ---------
+
+ C5) Karn's algorithm: RTT measurements MUST NOT be made using
+ packets that were retransmitted (and thus for which it is
+ ambiguous whether the reply was for the first instance of the
+ packet or a later instance)
+ ---------
+ New text: (Section 6.3.1)
+ ---------
+
+ C5) Karn's algorithm: RTT measurements MUST NOT be made using
+ chunks that were retransmitted (and thus for which it is
+ ambiguous whether the reply was for the first instance of
+ the chunk or for a later instance)
+
+ IMPLEMENTATION NOTE: RTT measurements should only be
+ made using a chunk with TSN r if no chunk
+ with TSN less than or equal to r is retransmitted
+ since r is first sent.
+
+2.51.3. Solution Description
+
+ The above clarification adds an implementation note that will provide
+ additional guidance in the application of Karn's algorithm.
+
+2.52. Fast Retransmit Algorithm
+
+2.52.1. Description of the Problem
+
+ The original SCTP specification is overly conservative in requiring 4
+ missing reports before fast retransmitting a segment. TCP uses 3
+ missing reports or 4 acknowledgements indicating that the same
+ segment was received.
+
+
+
+
+
+
+Stewart, et al. Informational [Page 104]
+
+RFC 4460 SCTP Errata April 2006
+
+
+2.52.2. Text Changes to the Document
+
+ ---------
+ Old text:
+ ---------
+
+ 7.2.4 Fast Retransmit on Gap Reports
+
+ In the absence of data loss, an endpoint performs delayed
+ acknowledgement. However, whenever an endpoint notices a hole in
+ the arriving TSN sequence, it SHOULD start sending a SACK back
+ every time a packet arrives carrying data until the
+ hole is filled.
+
+ Whenever an endpoint receives a SACK that indicates some TSN(s)
+ missing, it SHOULD wait for 3 further miss indications (via
+ subsequent SACK's) on the same TSN(s) before taking action with
+ regard to Fast Retransmit.
+
+
+ ---------
+ New text:
+ ---------
+
+ 7.2.4. Fast Retransmit on Gap Reports
+
+ In the absence of data loss, an endpoint performs delayed
+ acknowledgement. However, whenever an endpoint notices a hole in
+ the arriving TSN sequence, it SHOULD start sending a SACK back
+ every time a packet arrives carrying data until the
+ hole is filled.
+
+ Whenever an endpoint receives a SACK that indicates that some
+ TSNs are missing, it SHOULD wait for 2 further miss indications
+ (via subsequent SACKs for a total of 3 missing reports) on the
+ same TSNs before taking action with regard to Fast Retransmit.
+
+2.52.3. Solution Description
+
+ The above changes will make SCTP and TCP behave similarly in terms of
+ how fast they engage the Fast Retransmission algorithm upon receiving
+ missing reports.
+
+3. Security Considerations
+
+ This document should add no additional security risks to SCTP and in
+ fact SHOULD correct some original security flaws within the original
+ document once it is incorporated into a RFC 2960 [5] BIS document.
+
+
+
+Stewart, et al. Informational [Page 105]
+
+RFC 4460 SCTP Errata April 2006
+
+
+4. Acknowledgements
+
+ The authors would like to thank the following people who have
+ provided comments and input for this document:
+
+ Barry Zuckerman, La Monte Yarroll, Qiaobing Xie, Wang Xiaopeng,
+ Jonathan Wood, Jeff Waskow, Mike Turner, John Townsend, Sabina
+ Torrente, Cliff Thomas, Yuji Suzuki, Manoj Solanki, Sverre Slotte,
+ Keyur Shah, Jan Rovins, Ben Robinson, Renee Revis, Ian Periam, RC
+ Monee, Sanjay Rao, Sujith Radhakrishnan, Heinz Prantner, Biren Patel,
+ Nathalie Mouellic, Mitch Miers, Bernward Meyknecht, Stan McClellan,
+ Oliver Mayor, Tomas Orti Martin, Sandeep Mahajan, David Lehmann,
+ Jonathan Lee, Philippe Langlois, Karl Knutson, Joe Keller, Gareth
+ Keily, Andreas Jungmaier, Janardhan Iyengar, Mutsuya Irie, John
+ Hebert, Kausar Hassan, Fred Hasle, Dan Harrison, Jon Grim, Laurent
+ Glaude, Steven Furniss, Atsushi Fukumoto, Ken Fujita, Steve Dimig,
+ Thomas Curran, Serkan Cil, Melissa Campbell, Peter Butler, Rob
+ Brennan, Harsh Bhondwe, Brian Bidulock, Caitlin Bestler, Jon Berger,
+ Robby Benedyk, Stephen Baucke, Sandeep Balani, and Ronnie Sellar.
+
+ A special thanks to Mark Allman, who should actually be a co-author
+ for his work on the max-burst, but managed to wiggle out due to a
+ technicality. Also, we would like to acknowledge Lyndon Ong and Phil
+ Conrad for their valuable input and many contributions.
+
+5. IANA Considerations
+
+ This document recommends changes for the RFC 2960 [5] BIS document.
+ As such, even though it lists new error cause code, this document in
+ itself does NOT define those new codes. Instead, the BIS document
+ will make the needed changes to RFC 2960 [5] and thus its IANA
+ section will require changes to be made.
+
+6. Normative References
+
+ [1] Braden, R., "Requirements for Internet Hosts - Communication
+ Layers", STD 3, RFC 1122, October 1989.
+
+ [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+ [3] Caro, A., Shah, K., Iyengar, J., Amer, P., and R. Stewart, "SCTP
+ and TCP Variants: Congestion Control Under Multiple Losses",
+ Technical Report TR2003-04, Computer and Information Sciences
+ Department, University of Delaware, February 2003,
+ <http://www.armandocaro.net/papers>.
+
+
+
+
+
+Stewart, et al. Informational [Page 106]
+
+RFC 4460 SCTP Errata April 2006
+
+
+ [4] Caro, A., Amer, P., and R. Stewart, "Retransmission Schemes for
+ End-to-end Failover with Transport Layer Multihoming", GLOBECOM,
+ November 2004., <http://www.armandocaro.net/papers>.
+
+ [5] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
+ H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V.
+ Paxson, "Stream Control Transmission Protocol", RFC 2960,
+ October 2000.
+
+ [6] Stone, J., Stewart, R., and D. Otis, "Stream Control
+ Transmission Protocol (SCTP) Checksum Change", RFC 3309,
+ September 2002.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stewart, et al. Informational [Page 107]
+
+RFC 4460 SCTP Errata April 2006
+
+
+Authors' Addresses
+
+ Randall R. Stewart
+ Cisco Systems, Inc.
+ 4875 Forest Drive
+ Suite 200
+ Columbia, SC 29206
+ USA
+
+ EMail: rrs@cisco.com
+
+
+ Ivan Arias-Rodriguez
+ Nokia Research Center
+ PO Box 407
+ FIN-00045 Nokia Group
+ Finland
+
+ EMail: ivan.arias-rodriguez@nokia.com
+
+
+ Kacheong Poon
+ Sun Microsystems, Inc.
+ 3571 N. First St.
+ San Jose, CA 95134
+ USA
+
+ EMail: kacheong.poon@sun.com
+
+
+ Armando L. Caro Jr.
+ BBN Technologies
+ 10 Moulton St.
+ Cambridge, MA 02138
+
+ EMail: acaro@bbn.com
+ URI: http://www.armandocaro.net
+
+
+ Michael Tuexen
+ Muenster Univ. of Applied Sciences
+ Stegerwaldstr. 39
+ 48565 Steinfurt
+ Germany
+
+ EMail: tuexen@fh-muenster.de
+
+
+
+
+
+Stewart, et al. Informational [Page 108]
+
+RFC 4460 SCTP Errata April 2006
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2006).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Stewart, et al. Informational [Page 109]
+