7 Network Working Group R. Stewart
8 Request for Comments: 4460 Cisco Systems, Inc.
9 Category: Informational I. Arias-Rodriguez
12 Sun Microsystems, Inc.
16 Muenster Univ. of Applied Sciences
20 Stream Control Transmission Protocol (SCTP) Specification
26 This memo provides information for the Internet community. It does
27 not specify an Internet standard of any kind. Distribution of this
32 Copyright (C) The Internet Society (2006).
36 This document is a compilation of issues found during six
37 interoperability events and 5 years of experience with implementing,
38 testing, and using Stream Control Transmission Protocol (SCTP) along
39 with the suggested fixes. This document provides deltas to RFC 2960
40 and is organized in a time-based way. The issues are listed in the
41 order they were brought up. Because some text is changed several
42 times, the last delta in the text is the one that should be applied.
43 In addition to the delta, a description of the problem and the
44 details of the solution are also provided.
48 1. Introduction ....................................................6
49 1.1. Conventions ................................................7
50 2. Corrections to RFC 2960 .........................................7
51 2.1. Incorrect Error Type During Chunk Processing. ..............7
52 2.1.1. Description of the Problem ..........................7
53 2.1.2. Text changes to the document ........................7
54 2.1.3. Solution Description ................................7
58 Stewart, et al. Informational [Page 1]
60 RFC 4460 SCTP Errata April 2006
63 2.2. Parameter Processing Issue .................................7
64 2.2.1. Description of the Problem ..........................7
65 2.2.2. Text Changes to the Document ........................8
66 2.2.3. Solution Description ................................8
67 2.3. Padding Issues .............................................8
68 2.3.1. Description of the Problem ..........................8
69 2.3.2. Text Changes to the Document ........................9
70 2.3.3. Solution Description ...............................10
71 2.4. Parameter Types across All Chunk Types ....................10
72 2.4.1. Description of the Problem .........................10
73 2.4.2. Text Changes to the Document .......................10
74 2.4.3. Solution Description ...............................12
75 2.5. Stream Parameter Clarification ............................12
76 2.5.1. Description of the problem .........................12
77 2.5.2. Text Changes to the Document .......................12
78 2.5.3. Solution Description ...............................13
79 2.6. Restarting Association Security Issue .....................13
80 2.6.1. Description of the Problem .........................13
81 2.6.2. Text Changes to the Document .......................14
82 2.6.3. Solution Description ...............................18
83 2.7. Implicit Ability to Exceed cwnd by PMTU-1 Bytes ...........19
84 2.7.1. Description of the Problem .........................19
85 2.7.2. Text Changes to the Document .......................19
86 2.7.3. Solution Description ...............................19
87 2.8. Issues with Fast Retransmit ...............................19
88 2.8.1. Description of the Problem .........................19
89 2.8.2. Text Changes to the Document .......................20
90 2.8.3. Solution Description ...............................23
91 2.9. Missing Statement about partial_bytes_acked Update ........24
92 2.9.1. Description of the Problem .........................24
93 2.9.2. Text Changes to the Document .......................24
94 2.9.3. Solution Description ...............................25
95 2.10. Issues with Heartbeating and Failure Detection ...........25
96 2.10.1. Description of the Problem ........................25
97 2.10.2. Text Changes to the Document ......................26
98 2.10.3. Solution Description ..............................28
99 2.11. Security interactions with firewalls .....................29
100 2.11.1. Description of the Problem ........................29
101 2.11.2. Text Changes to the Document ......................29
102 2.11.3. Solution Description ..............................31
103 2.12. Shutdown Ambiguity .......................................31
104 2.12.1. Description of the Problem ........................31
105 2.12.2. Text Changes to the Document ......................31
106 2.12.3. Solution Description ..............................32
107 2.13. Inconsistency in ABORT Processing ........................32
108 2.13.1. Description of the Problem ........................32
109 2.13.2. Text changes to the document ......................33
110 2.13.3. Solution Description ..............................33
114 Stewart, et al. Informational [Page 2]
116 RFC 4460 SCTP Errata April 2006
119 2.14. Cwnd Gated by Its Full Use ...............................34
120 2.14.1. Description of the Problem ........................34
121 2.14.2. Text Changes to the Document ......................34
122 2.14.3. Solution Description ..............................36
123 2.15. Window Probes in SCTP ....................................36
124 2.15.1. Description of the Problem ........................36
125 2.15.2. Text Changes to the Document ......................36
126 2.15.3. Solution Description ..............................38
127 2.16. Fragmentation and Path MTU Issues ........................39
128 2.16.1. Description of the Problem ........................39
129 2.16.2. Text Changes to the Document ......................39
130 2.16.3. Solution Description ..............................40
131 2.17. Initial Value of the Cumulative TSN Ack ..................40
132 2.17.1. Description of the Problem ........................40
133 2.17.2. Text Changes to the Document ......................40
134 2.17.3. Solution Description ..............................41
135 2.18. Handling of Address Parameters within the INIT or
136 INIT-ACK .................................................41
137 2.18.1. Description of the Problem ........................41
138 2.18.2. Text Changes to the Document ......................41
139 2.18.3. Solution description ..............................42
140 2.19. Handling of Stream Shortages .............................42
141 2.19.1. Description of the Problem ........................42
142 2.19.2. Text Changes to the Document ......................42
143 2.19.3. Solution Description ..............................43
144 2.20. Indefinite Postponement ..................................43
145 2.20.1. Description of the Problem ........................43
146 2.20.2. Text Changes to the Document ......................43
147 2.20.3. Solution Description ..............................44
148 2.21. User-Initiated Abort of an Association ...................44
149 2.21.1. Description of the Problem ........................44
150 2.21.2. Text changes to the document ......................44
151 2.21.3. Solution Description ..............................50
152 2.22. Handling of Invalid Initiate Tag of INIT-ACK .............50
153 2.22.1. Description of the Problem ........................50
154 2.22.2. Text Changes to the Document ......................50
155 2.22.3. Solution Description ..............................51
156 2.23. Sending an ABORT in Response to an INIT ..................51
157 2.23.1. Description of the Problem ........................51
158 2.23.2. Text Changes to the Document ......................51
159 2.23.3. Solution Description ..............................52
160 2.24. Stream Sequence Number (SSN) Initialization ..............52
161 2.24.1. Description of the Problem ........................52
162 2.24.2. Text Changes to the Document ......................52
163 2.24.3. Solution Description ..............................53
164 2.25. SACK Packet Format .......................................53
165 2.25.1. Description of the Problem ........................53
166 2.25.2. Text Changes to the Document ......................53
170 Stewart, et al. Informational [Page 3]
172 RFC 4460 SCTP Errata April 2006
175 2.25.3. Solution Description ..............................53
176 2.26. Protocol Violation Error Cause ...........................53
177 2.26.1. Description of the Problem ........................53
178 2.26.2. Text Changes to the Document ......................54
179 2.26.3. Solution Description ..............................56
180 2.27. Reporting of Unrecognized Parameters .....................56
181 2.27.1. Description of the Problem ........................56
182 2.27.2. Text Changes to the Document ......................56
183 2.27.3. Solution Description ..............................57
184 2.28. Handling of IP Address Parameters ........................58
185 2.28.1. Description of the Problem ........................58
186 2.28.2. Text Changes to the Document ......................58
187 2.28.3. Solution Description ..............................58
188 2.29. Handling of COOKIE ECHO Chunks When a TCB Exists .........59
189 2.29.1. Description of the Problem ........................59
190 2.29.2. Text Changes to the Document ......................59
191 2.29.3. Solution Description ..............................59
192 2.30. The Initial Congestion Window Size .......................59
193 2.30.1. Description of the Problem ........................59
194 2.30.2. Text Changes to the Document ......................60
195 2.30.3. Solution Description ..............................61
196 2.31. Stream Sequence Numbers in Figures .......................62
197 2.31.1. Description of the Problem ........................62
198 2.31.2. Text Changes to the Document ......................63
199 2.31.3. Solution description ..............................67
200 2.32. Unrecognized Parameters ..................................67
201 2.32.1. Description of the Problem ........................67
202 2.32.2. Text Changes to the Document ......................67
203 2.32.3. Solution Description ..............................68
204 2.33. Handling of Unrecognized Parameters ......................68
205 2.33.1. Description of the Problem ........................68
206 2.33.2. Text Changes to the Document ......................68
207 2.33.3. Solution Description ..............................70
208 2.34. Tie Tags .................................................70
209 2.34.1. Description of the Problem ........................70
210 2.34.2. Text Changes to the Document ......................70
211 2.34.3. Solution Description ..............................72
212 2.35. Port Number Verification in the COOKIE-ECHO ..............72
213 2.35.1. Description of the Problem ........................72
214 2.35.2. Text Changes to the Document ......................72
215 2.35.3. Solution Description ..............................73
216 2.36. Path Initialization ......................................74
217 2.36.1. Description of the Problem ........................74
218 2.36.2. Text Changes to the Document ......................74
219 2.36.3. Solution Description ..............................76
220 2.37. ICMP Handling Procedures .................................76
221 2.37.1. Description of the Problem ........................76
222 2.37.2. Text Changes to the Document ......................77
226 Stewart, et al. Informational [Page 4]
228 RFC 4460 SCTP Errata April 2006
231 2.37.3. Solution Description ..............................79
232 2.38. Checksum .................................................79
233 2.38.1. Description of the problem ........................79
234 2.38.2. Text Changes to the Document ......................79
235 2.38.3. Solution Description ..............................86
236 2.39. Retransmission Policy ....................................86
237 2.39.1. Description of the Problem ........................86
238 2.39.2. Text Changes to the Document ......................87
239 2.39.3. Solution Description ..............................87
240 2.40. Port Number 0 ............................................88
241 2.40.1. Description of the Problem ........................88
242 2.40.2. Text Changes to the Document ......................88
243 2.40.3. Solution Description ..............................89
244 2.41. T Bit ....................................................89
245 2.41.1. Description of the Problem ........................89
246 2.41.2. Text Changes to the Document ......................89
247 2.41.3. Solution Description ..............................93
248 2.42. Unknown Parameter Handling ...............................93
249 2.42.1. Description of the Problem ........................93
250 2.42.2. Text Changes to the Document ......................93
251 2.42.3. Solution Description ..............................95
252 2.43. Cookie Echo Chunk ........................................95
253 2.43.1. Description of the Problem ........................95
254 2.43.2. Text Changes to the Document ......................95
255 2.43.3. Solution Description ..............................96
256 2.44. Partial Chunks ...........................................96
257 2.44.1. Description of the Problem ........................96
258 2.44.2. Text Changes to the Document ......................96
259 2.44.3. Solution Description ..............................97
260 2.45. Non-unicast Addresses ....................................97
261 2.45.1. Description of the Problem ........................97
262 2.45.2. Text Changes to the Document ......................97
263 2.45.3. Solution Description ..............................98
264 2.46. Processing of ABORT Chunks ...............................98
265 2.46.1. Description of the Problem ........................98
266 2.46.2. Text Changes to the Document ......................98
267 2.46.3. Solution Description ..............................98
268 2.47. Sending of ABORT Chunks ..................................99
269 2.47.1. Description of the Problem ........................99
270 2.47.2. Text Changes to the Document ......................99
271 2.47.3. Solution Description ..............................99
272 2.48. Handling of Supported Address Types Parameter ............99
273 2.48.1. Description of the Problem ........................99
274 2.48.2. Text Changes to the Document .....................100
275 2.48.3. Solution Description .............................100
276 2.49. Handling of Unexpected Parameters .......................101
277 2.49.1. Description of the Problem .......................101
278 2.49.2. Text Changes to the Document .....................101
282 Stewart, et al. Informational [Page 5]
284 RFC 4460 SCTP Errata April 2006
287 2.49.3. Solution Description .............................102
288 2.50. Payload Protocol Identifier .............................102
289 2.50.1. Description of the Problem .......................102
290 2.50.2. Text Changes to the Document .....................103
291 2.50.3. Solution Description .............................103
292 2.51. Karn's Algorithm ........................................104
293 2.51.1. Description of the Problem .......................104
294 2.51.2. Text Changes to the Document .....................104
295 2.51.3. Solution Description .............................104
296 2.52. Fast Retransmit Algorithm ...............................104
297 2.52.1. Description of the Problem .......................104
298 2.52.2. Text Changes to the Document .....................105
299 2.52.3. Solution Description .............................105
300 3. Security Considerations .......................................105
301 4. Acknowledgements ..............................................106
302 5. IANA Considerations ...........................................106
303 6. Normative References ..........................................106
307 This document contains a compilation of all defects found up until
308 the publishing of this document for the Stream Control Transmission
309 Protocol (SCTP), RFC 2960 [5]. These defects may be of an editorial
310 or technical nature. This document may be thought of as a companion
311 document to be used in the implementation of SCTP to clarify errors
312 in the original SCTP document.
314 This document provides a history of the changes that will be compiled
315 into RFC 2960's [5] BIS document. Each error will be detailed within
316 this document in the form of
318 o the problem description,
320 o the text quoted from RFC 2960 [5],
322 o the replacement text that should be placed into the BIS document,
325 o a description of the solution.
327 This document is a historical record of sequential changes what have
328 been found necessary at various interop events and through discussion
331 Note that because some text is changed several times, the last delta
332 for a text in the document is the erratum for that text in RFC 2960.
338 Stewart, et al. Informational [Page 6]
340 RFC 4460 SCTP Errata April 2006
345 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
346 SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when
347 they appear in this document, are to be interpreted as described in
350 2. Corrections to RFC 2960
352 2.1. Incorrect Error Type During Chunk Processing.
354 2.1.1. Description of the Problem
356 A typo was discovered in RFC 2960 [5] that incorrectly specifies an
357 action to be taken when processing chunks of unknown identity.
359 2.1.2. Text changes to the document
362 Old text: (Section 3.2)
365 01 - Stop processing this SCTP packet and discard it, do not process
366 any further chunks within it, and report the unrecognized
367 parameter in an 'Unrecognized Parameter Type' (in either an
368 ERROR or in the INIT ACK).
371 New text: (Section 3.2)
374 01 - Stop processing this SCTP packet and discard it, do not process
375 any further chunks within it, and report the unrecognized
376 chunk in an 'Unrecognized Chunk Type'.
378 2.1.3. Solution Description
380 The receiver of an unrecognized chunk should not send a 'parameter'
381 error but instead should send the appropriate chunk error as
384 2.2. Parameter Processing Issue
386 2.2.1. Description of the Problem
388 A typographical error was introduced through an improper cut and
389 paste in the use of the upper two bits to describe proper handling of
394 Stewart, et al. Informational [Page 7]
396 RFC 4460 SCTP Errata April 2006
399 2.2.2. Text Changes to the Document
402 Old text: (Section 3.2.1)
405 00 - Stop processing this SCTP packet and discard it; do not process
406 any further chunks within it.
408 01 - Stop processing this SCTP packet and discard it, do not process
409 any further chunks within it, and report the unrecognized
410 parameter in an 'Unrecognized Parameter Type' (in either an
411 ERROR or in the INIT ACK).
414 New text: (Section 3.2.1)
417 00 - Stop processing this SCTP chunk and discard it, do not process
418 any further parameters within this chunk.
420 01 - Stop processing this SCTP chunk and discard it, do not process
421 any further parameters within this chunk, and report the
422 unrecognized parameter in an 'Unrecognized Parameter Type' (in
423 either an ERROR or in the INIT ACK).
425 2.2.3. Solution Description
427 It was always the intent to stop processing at the level one was at
428 in an unknown chunk or parameter with the upper bit set to 0. Thus,
429 if you are processing a chunk, you should drop the packet. If you
430 are processing a parameter, you should drop the chunk.
434 2.3.1. Description of the Problem
436 A problem was found when a Chunk terminated in a TLV parameter. If
437 this last TLV was not on a 32-bit boundary (as required), there was
438 confusion as to whether the last padding was included in the chunk
450 Stewart, et al. Informational [Page 8]
452 RFC 4460 SCTP Errata April 2006
455 2.3.2. Text Changes to the Document
458 Old text: (Section 3.2)
461 Chunk Length: 16 bits (unsigned integer)
463 This value represents the size of the chunk in bytes including the
464 Chunk Type, Chunk Flags, Chunk Length, and Chunk Value fields.
465 Therefore, if the Chunk Value field is zero-length, the Length
466 field will be set to 4. The Chunk Length field does not count any
469 Chunk Value: variable length
471 The Chunk Value field contains the actual information to be
472 transferred in the chunk. The usage and format of this field is
473 dependent on the Chunk Type.
475 The total length of a chunk (including Type, Length and Value fields)
476 MUST be a multiple of 4 bytes. If the length of the chunk is not a
477 multiple of 4 bytes, the sender MUST pad the chunk with all zero
478 bytes and this padding is not included in the chunk length field.
479 The sender should never pad with more than 3 bytes. The receiver
480 MUST ignore the padding bytes.
483 New text: (Section 3.2)
486 Chunk Length: 16 bits (unsigned integer)
488 This value represents the size of the chunk in bytes, including
489 the Chunk Type, Chunk Flags, Chunk Length, and Chunk Value fields.
490 Therefore, if the Chunk Value field is zero-length, the Length
491 field will be set to 4. The Chunk Length field does not count any
494 Chunks (including Type, Length, and Value fields) are padded out
495 by the sender with all zero bytes to be a multiple of 4 bytes
496 long. This padding MUST NOT be more than 3 bytes in total. The
497 Chunk Length value does not include terminating padding of the
498 chunk. However, it does include padding of any variable-length
499 parameter except the last parameter in the chunk. The receiver
500 MUST ignore the padding.
506 Stewart, et al. Informational [Page 9]
508 RFC 4460 SCTP Errata April 2006
511 Note: A robust implementation should accept the Chunk whether or
512 not the final padding has been included in the Chunk Length.
514 Chunk Value: variable length
516 The Chunk Value field contains the actual information to be
517 transferred in the chunk. The usage and format of this field is
518 dependent on the Chunk Type.
520 The total length of a chunk (including Type, Length, and Value
521 fields) MUST be a multiple of 4 bytes. If the length of the chunk is
522 not a multiple of 4 bytes, the sender MUST pad the chunk with all
523 zero bytes, and this padding is not included in the chunk length
524 field. The sender should never pad with more than 3 bytes. The
525 receiver MUST ignore the padding bytes.
527 2.3.3. Solution Description
529 The above text makes clear that the padding of the last parameter is
530 not included in the Chunk Length field. It also clarifies that the
531 padding of parameters that are not the last one must be counted in
532 the Chunk Length field.
534 2.4. Parameter Types across All Chunk Types
536 2.4.1. Description of the Problem
538 A problem was noted when multiple errors are needed to be sent
539 regarding unknown or unrecognized parameters. Since often the error
540 type does not hold the chunk type field, it may become difficult to
541 tell which error was associated with which chunk.
543 2.4.2. Text Changes to the Document
546 Old text: (Section 3.2.1)
549 The actual SCTP parameters are defined in the specific SCTP chunk
550 sections. The rules for IETF-defined parameter extensions are
551 defined in Section 13.2.
554 New text: (Section 3.2.1)
557 The actual SCTP parameters are defined in the specific SCTP chunk
558 sections. The rules for IETF-defined parameter extensions are
562 Stewart, et al. Informational [Page 10]
564 RFC 4460 SCTP Errata April 2006
567 defined in Section 13.2. Note that a parameter type MUST be unique
568 across all chunks. For example, the parameter type '5' is used to
569 represent an IPv4 address (see Section 3.3.2). The value '5' then is
570 reserved across all chunks to represent an IPv4 address and MUST NOT
571 be reused with a different meaning in any other chunk.
574 Old text: (Section 13.2)
577 13.2 IETF-defined Chunk Parameter Extension
579 The assignment of new chunk parameter type codes is done through an
580 IETF Consensus action as defined in [RFC2434]. Documentation of the
581 chunk parameter MUST contain the following information:
583 a) Name of the parameter type.
585 b) Detailed description of the structure of the parameter field.
586 This structure MUST conform to the general type-length-value
587 format described in Section 3.2.1.
589 c) Detailed definition of each component of the parameter type.
591 d) Detailed description of the intended use of this parameter type,
592 and an indication of whether and under what circumstances multiple
593 instances of this parameter type may be found within the same
597 New text: (Section 13.2)
600 13.2. IETF-defined Chunk Parameter Extension
602 The assignment of new chunk parameter type codes is done through an
603 IETF Consensus action, as defined in [RFC2434]. Documentation of the
604 chunk parameter MUST contain the following information:
606 a) Name of the parameter type.
608 b) Detailed description of the structure of the parameter field.
609 This structure MUST conform to the general type-length-value
610 format described in Section 3.2.1.
612 c) Detailed definition of each component of the parameter type.
618 Stewart, et al. Informational [Page 11]
620 RFC 4460 SCTP Errata April 2006
623 d) Detailed description of the intended use of this parameter type,
624 and an indication of whether and under what circumstances multiple
625 instances of this parameter type may be found within the same
628 e) Each parameter type MUST be unique across all chunks.
630 2.4.3. Solution Description
632 By having all parameters unique across all chunk assignments (the
633 current assignment policy), no ambiguity exists as to what a
634 parameter means in different contexts. The trade-off for this is a
635 smaller parameter space, i.e., 65,536 parameters versus 65,536 *
638 2.5. Stream Parameter Clarification
640 2.5.1. Description of the problem
642 A problem was found where the specification is unclear on the
643 legality of an endpoint asking for more stream resources than were
644 allowed in the MIS value of the INIT. In particular, the value in
645 the INIT ACK requested in its OS value was larger than the MIS value
646 received in the INIT chunk. This behavior is illegal, yet it was
647 unspecified in RFC 2960 [5]
649 2.5.2. Text Changes to the Document
652 Old text: (Section 3.3.3)
655 Number of Outbound Streams (OS): 16 bits (unsigned integer)
657 Defines the number of outbound streams the sender of this INIT ACK
658 chunk wishes to create in this association. The value of 0 MUST
661 Note: A receiver of an INIT ACK with the OS value set to 0 SHOULD
662 destroy the association discarding its TCB.
674 Stewart, et al. Informational [Page 12]
676 RFC 4460 SCTP Errata April 2006
680 New text: (Section 3.3.3)
683 Number of Outbound Streams (OS): 16 bits (unsigned integer)
685 Defines the number of outbound streams the sender of this INIT ACK
686 chunk wishes to create in this association. The value of 0 MUST
687 NOT be used, and the value MUST NOT be greater than the MIS value
688 sent in the INIT chunk.
690 Note: A receiver of an INIT ACK with the OS value set to 0 SHOULD
691 destroy the association, discarding its TCB.
693 2.5.3. Solution Description
695 The change in wording, above, changes it so that a responder to an
696 INIT chunk does not specify more streams in its OS value than were
697 represented to it in the MIS value, i.e., its maximum.
699 2.6. Restarting Association Security Issue
701 2.6.1. Description of the Problem
703 A security problem was found when a restart occurs. It is possible
704 for an intruder to send an INIT to an endpoint of an existing
705 association. In the INIT the intruder would list one or more of the
706 current addresses of an association and its own. The normal restart
707 procedures would then occur, and the intruder would have hijacked an
730 Stewart, et al. Informational [Page 13]
732 RFC 4460 SCTP Errata April 2006
735 2.6.2. Text Changes to the Document
738 Old text: (Section 3.3.10)
743 --------- ----------------
744 1 Invalid Stream Identifier
745 2 Missing Mandatory Parameter
748 5 Unresolvable Address
749 6 Unrecognized Chunk Type
750 7 Invalid Mandatory Parameter
751 8 Unrecognized Parameters
753 10 Cookie Received While Shutting Down
755 Cause Length: 16 bits (unsigned integer)
757 Set to the size of the parameter in bytes, including the Cause
758 Code, Cause Length, and Cause-Specific Information fields
760 Cause-specific Information: variable length
762 This field carries the details of the error condition.
764 Sections 3.3.10.1 - 3.3.10.10 define error causes for SCTP.
766 Guidelines for the IETF to define new error cause values are
767 discussed in Section 13.3.
786 Stewart, et al. Informational [Page 14]
788 RFC 4460 SCTP Errata April 2006
792 New text: (Section 3.3.10)
797 --------- ----------------
798 1 Invalid Stream Identifier
799 2 Missing Mandatory Parameter
802 5 Unresolvable Address
803 6 Unrecognized Chunk Type
804 7 Invalid Mandatory Parameter
805 8 Unrecognized Parameters
807 10 Cookie Received While Shutting Down
808 11 Restart of an Association with New Addresses
810 Cause Length: 16 bits (unsigned integer)
812 Set to the size of the parameter in bytes, including the Cause
813 Code, Cause Length, and Cause-Specific Information fields.
815 Cause-specific Information: variable length
817 This field carries the details of the error condition.
819 Sections 3.3.10.1 - 3.3.10.11 define error causes for SCTP.
820 Guidelines for the IETF to define new error cause values are
821 discussed in Section 13.3.
824 New text: (Note no old text, new error cause added in section 3.3.10)
827 3.3.10.11. Restart of an Association with New Addresses (11)
831 Restart of an association with new addresses: An INIT was received
832 on an existing association. But the INIT added addresses to the
833 association that were previously NOT part of the association. The
834 new addresses are listed in the error code. This ERROR is normally
835 sent as part of an ABORT refusing the INIT (see Section 5.2).
842 Stewart, et al. Informational [Page 15]
844 RFC 4460 SCTP Errata April 2006
847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
848 | Cause Code=11 | Cause Length=Variable |
849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
854 Note: Each New Address TLV is an exact copy of the TLV
855 that was found in the INIT chunk that was new, including the
856 Parameter Type and the Parameter length.
859 Old text: (Section 5.2.1)
862 Upon receipt of an INIT in the COOKIE-WAIT or COOKIE-ECHOED state, an
863 endpoint MUST respond with an INIT ACK using the same parameters it
864 sent in its original INIT chunk (including its Initiation Tag,
865 unchanged). These original parameters are combined with those from
866 the newly received INIT chunk. The endpoint shall also generate a
867 State Cookie with the INIT ACK. The endpoint uses the parameters
868 sent in its INIT to calculate the State Cookie.
871 New text: (Section 5.2.1)
874 Upon receipt of an INIT in the COOKIE-WAIT state, an endpoint MUST
875 respond with an INIT ACK using the same parameters it sent in its
876 original INIT chunk (including its Initiation Tag, unchanged). When
877 responding, the endpoint MUST send the INIT ACK back to the same
878 address that the original INIT (sent by this endpoint) was sent to.
880 Upon receipt of an INIT in the COOKIE-ECHOED state, an endpoint MUST
881 respond with an INIT ACK using the same parameters it sent in its
882 original INIT chunk (including its Initiation Tag, unchanged),
883 provided that no NEW address has been added to the forming
884 association. If the INIT message indicates that a new address has
885 been added to the association, then the entire INIT MUST be
886 discarded, and NO changes should be made to the existing association.
887 An ABORT SHOULD be sent in response that MAY include the error
888 'Restart of an association with new addresses'. The error SHOULD
889 list the addresses that were added to the restarting association.
898 Stewart, et al. Informational [Page 16]
900 RFC 4460 SCTP Errata April 2006
903 When responding in either state (COOKIE-WAIT or COOKIE-ECHOED) with
904 an INIT ACK, the original parameters are combined with those from the
905 newly received INIT chunk. The endpoint shall also generate a State
906 Cookie with the INIT ACK. The endpoint uses the parameters sent in
907 its INIT to calculate the State Cookie.
910 Old text: (Section 5.2.2)
913 5.2.2 Unexpected INIT in States Other than CLOSED, COOKIE-ECHOED,
914 COOKIE-WAIT and SHUTDOWN-ACK-SENT
916 Unless otherwise stated, upon reception of an unexpected INIT for
917 this association, the endpoint shall generate an INIT ACK with a
918 State Cookie. In the outbound INIT ACK the endpoint MUST copy its
919 current Verification Tag and peer's Verification Tag into a reserved
920 place within the state cookie. We shall refer to these locations as
921 the Peer's-Tie-Tag and the Local-Tie-Tag. The outbound SCTP packet
922 containing this INIT ACK MUST carry a Verification Tag value equal to
923 the Initiation Tag found in the unexpected INIT. And the INIT ACK
924 MUST contain a new Initiation Tag (randomly generated see Section
925 5.3.1). Other parameters for the endpoint SHOULD be copied from the
926 existing parameters of the association (e.g., number of outbound
927 streams) into the INIT ACK and cookie.
929 After sending out the INIT ACK, the endpoint shall take no further
930 actions, i.e., the existing association, including its current state,
931 and the corresponding TCB MUST NOT be changed.
933 Note: Only when a TCB exists and the association is not in a COOKIE-
934 WAIT state are the Tie-Tags populated. For a normal association INIT
935 (i.e., the endpoint is in a COOKIE-WAIT state), the Tie-Tags MUST be
936 set to 0 (indicating that no previous TCB existed). The INIT ACK and
937 State Cookie are populated as specified in section 5.2.1.
940 New text: (Section 5.2.2)
943 5.2.2. Unexpected INIT in States Other Than CLOSED, COOKIE-ECHOED,
944 COOKIE-WAIT, and SHUTDOWN-ACK-SENT
946 Unless otherwise stated, upon receipt of an unexpected INIT for this
947 association, the endpoint shall generate an INIT ACK with a State
948 Cookie. Before responding, the endpoint MUST check to see if the
949 unexpected INIT adds new addresses to the association. If new
950 addresses are added to the association, the endpoint MUST respond
954 Stewart, et al. Informational [Page 17]
956 RFC 4460 SCTP Errata April 2006
959 with an ABORT, copying the 'Initiation Tag' of the unexpected INIT
960 into the 'Verification Tag' of the outbound packet carrying the
961 ABORT. In the ABORT response, the cause of error MAY be set to
962 'restart of an association with new addresses'. The error SHOULD
963 list the addresses that were added to the restarting association.
965 If no new addresses are added, when responding to the INIT in the
966 outbound INIT ACK, the endpoint MUST copy its current Verification
967 Tag and peer's Verification Tag into a reserved place within the
968 state cookie. We shall refer to these locations as the Peer's-Tie-
969 Tag and the Local-Tie-Tag. The outbound SCTP packet containing this
970 INIT ACK MUST carry a Verification Tag value equal to the Initiation
971 Tag found in the unexpected INIT. And the INIT ACK MUST contain a
972 new Initiation Tag (randomly generated; see Section 5.3.1). Other
973 parameters for the endpoint SHOULD be copied from the existing
974 parameters of the association (e.g., number of outbound streams) into
975 the INIT ACK and cookie.
977 After sending out the INIT ACK or ABORT, the endpoint shall take no
978 further actions; i.e., the existing association, including its
979 current state, and the corresponding TCB MUST NOT be changed.
981 Note: Only when a TCB exists and the association is not in a COOKIE-
982 WAIT or SHUTDOWN-ACK-SENT state are the Tie-Tags populated with a
983 value other than 0. For a normal association INIT (i.e., the
984 endpoint is in the CLOSED state), the Tie-Tags MUST be set to 0
985 (indicating that no previous TCB existed).
987 2.6.3. Solution Description
989 A new error code is being added, along with specific instructions to
990 send back an ABORT to a new association in a restart case or
991 collision case, where new addresses have been added. The error code
992 can be used by a legitimate restart to inform the endpoint that it
993 has made a software error in adding a new address. The endpoint then
994 can choose to wait until the OOTB ABORT tears down the old
995 association, or to restart without the new address.
997 Also, the note at the end of Section 5.2.2 explaining the use of the
998 Tie-Tags was modified to properly explain the states in which the
999 Tie-Tags should be set to a value different than 0.
1010 Stewart, et al. Informational [Page 18]
1012 RFC 4460 SCTP Errata April 2006
1015 2.7. Implicit Ability to Exceed cwnd by PMTU-1 Bytes
1017 2.7.1. Description of the Problem
1019 Some implementations were having difficulty growing their cwnd. This
1020 was due to an improper enforcement of the congestion control rules.
1021 The rules, as written, provided for a slop over of the cwnd value.
1022 Without this slop over, the sender would appear NOT to be using its
1023 full cwnd value and thus would never increase it.
1025 2.7.2. Text Changes to the Document
1028 Old text: (Section 6.1)
1031 B) At any given time, the sender MUST NOT transmit new data to a
1032 given transport address if it has cwnd or more bytes of data
1033 outstanding to that transport address.
1036 New text: (Section 6.1)
1039 B) At any given time, the sender MUST NOT transmit new data to a
1040 given transport address if it has cwnd or more bytes of data
1041 outstanding to that transport address. The sender may exceed cwnd
1042 by up to (PMTU-1) bytes on a new transmission if the cwnd is not
1045 2.7.3. Solution Description
1047 The text changes make clear the ability to go over the cwnd value by
1048 no more than (PMTU-1) bytes.
1050 2.8. Issues with Fast Retransmit
1052 2.8.1. Description of the Problem
1054 Several problems were found in the current specification of fast
1055 retransmit. The current wording did not require GAP ACK blocks to be
1056 sent, even though they are essential to the workings of SCTP's
1057 congestion control. The specification left unclear how to handle the
1058 fast retransmit cycle, having the implementation wait on the cwnd to
1059 retransmit a TSN that was marked for fast retransmit. No limit was
1060 placed on how many times a TSN could be fast retransmitted. Fast
1061 Recovery was not specified, causing the congestion window to be
1062 reduced drastically when there are multiple losses in a single RTT.
1066 Stewart, et al. Informational [Page 19]
1068 RFC 4460 SCTP Errata April 2006
1071 2.8.2. Text Changes to the Document
1074 Old text: (Section 6.2)
1077 Acknowledgements MUST be sent in SACK chunks unless shutdown was
1078 requested by the ULP in which case an endpoint MAY send an
1079 acknowledgement in the SHUTDOWN chunk. A SACK chunk can acknowledge
1080 the reception of multiple DATA chunks. See Section 3.3.4 for SACK
1081 chunk format. In particular, the SCTP endpoint MUST fill in the
1082 Cumulative TSN Ack field to indicate the latest sequential TSN (of a
1083 valid DATA chunk) it has received. Any received DATA chunks with TSN
1084 greater than the value in the Cumulative TSN Ack field SHOULD also be
1085 reported in the Gap Ack Block fields.
1088 New text: (Section 6.2)
1091 Acknowledegments MUST be sent in SACK chunks unless shutdown was
1092 requested by the ULP, in which case an endpoint MAY send an
1093 acknowledgement in the SHUTDOWN chunk. A SACK chunk can acknowledge
1094 the reception of multiple DATA chunks. See Section 3.3.4 for SACK
1095 chunk format. In particular, the SCTP endpoint MUST fill in the
1096 Cumulative TSN Ack field to indicate the latest sequential TSN (of a
1097 valid DATA chunk) it has received. Any received DATA chunks with
1098 TSN greater than the value in the Cumulative TSN Ack field are
1099 reported in the Gap Ack Block fields. The SCTP endpoint MUST
1100 report as many Gap Ack Blocks as can fit in a single SACK
1101 chunk limited by the current path MTU.
1104 Old text: (Section 6.2.1)
1107 D) Any time a SACK arrives, the endpoint performs the following:
1109 i) If Cumulative TSN Ack is less than the Cumulative TSN Ack
1110 Point, then drop the SACK. Since Cumulative TSN Ack is
1111 monotonically increasing, a SACK whose Cumulative TSN Ack is
1112 less than the Cumulative TSN Ack Point indicates an out-of-
1115 ii) Set rwnd equal to the newly received a_rwnd minus the
1116 number of bytes still outstanding after processing the
1117 Cumulative TSN Ack and the Gap Ack Blocks.
1122 Stewart, et al. Informational [Page 20]
1124 RFC 4460 SCTP Errata April 2006
1127 iii) If the SACK is missing a TSN that was previously
1128 acknowledged via a Gap Ack Block (e.g., the data receiver
1129 reneged on the data), then mark the corresponding DATA chunk
1130 as available for retransmit: Mark it as missing for fast
1131 retransmit as described in Section 7.2.4 and if no
1132 retransmit timer is running for the destination address
1133 to which the DATA chunk was originally transmitted, then
1134 T3-rtx is started for that destination address.
1137 New text: (Section 6.2.1)
1140 D) Any time a SACK arrives, the endpoint performs the following:
1142 i) If Cumulative TSN Ack is less than the Cumulative TSN Ack
1143 Point, then drop the SACK. Since Cumulative TSN Ack is
1144 monotonically increasing, a SACK whose Cumulative TSN Ack is
1145 less than the Cumulative TSN Ack Point indicates an out-of-
1148 ii) Set rwnd equal to the newly received a_rwnd minus the
1149 number of bytes still outstanding after processing the
1150 Cumulative TSN Ack and the Gap Ack Blocks.
1152 iii) If the SACK is missing a TSN that was previously
1153 acknowledged via a Gap Ack Block (e.g., the data receiver
1154 reneged on the data), then consider the corresponding DATA
1155 that might be possibly missing: Count one miss indication
1156 towards fast retransmit as described in Section 7.2.4, and
1157 if no retransmit timer is running for the destination
1158 address to which the DATA chunk was originally transmitted,
1159 then T3-rtx is started for that destination address.
1161 iv) If the Cumulative TSN Ack matches or exceeds the Fast
1162 Recovery exitpoint (Section 7.2.4), Fast Recovery is exited.
1165 Old text: (Section 7.2.4)
1168 Whenever an endpoint receives a SACK that indicates some TSN(s)
1169 missing, it SHOULD wait for 3 further miss indications (via
1170 subsequent SACK's) on the same TSN(s) before taking action with
1171 regard to Fast Retransmit.
1173 When the TSN(s) is reported as missing in the fourth consecutive
1174 SACK, the data sender shall:
1178 Stewart, et al. Informational [Page 21]
1180 RFC 4460 SCTP Errata April 2006
1183 1) Mark the missing DATA chunk(s) for retransmission,
1185 2) Adjust the ssthresh and cwnd of the destination address(es) to
1186 which the missing DATA chunks were last sent, according to the
1187 formula described in Section 7.2.3.
1189 3) Determine how many of the earliest (i.e., lowest TSN) DATA chunks
1190 marked for retransmission will fit into a single packet, subject
1191 to constraint of the path MTU of the destination transport address
1192 to which the packet is being sent. Call this value K. Retransmit
1193 those K DATA chunks in a single packet.
1195 4) Restart T3-rtx timer only if the last SACK acknowledged the lowest
1196 outstanding TSN number sent to that address, or the endpoint is
1197 retransmitting the first outstanding DATA chunk sent to that
1200 Note: Before the above adjustments, if the received SACK also
1201 acknowledges new DATA chunks and advances the Cumulative TSN Ack
1202 Point, the cwnd adjustment rules defined in Sections 7.2.1 and 7.2.2
1203 must be applied first.
1205 A straightforward implementation of the above keeps a counter for
1206 each TSN hole reported by a SACK. The counter increments for each
1207 consecutive SACK reporting the TSN hole. After reaching 4 and
1208 starting the fast retransmit procedure, the counter resets to 0.
1209 Because cwnd in SCTP indirectly bounds the number of outstanding
1210 TSN's, the effect of TCP fast-recovery is achieved automatically with
1211 no adjustment to the congestion control window size.
1214 New text: (Section 7.2.4)
1217 Whenever an endpoint receives a SACK that indicates that some TSNs
1218 are missing, it SHOULD wait for 3 further miss indications (via
1219 subsequent SACKs) on the same TSN(s) before taking action with
1220 regard to Fast Retransmit.
1222 Miss indications SHOULD follow the HTNA (Highest TSN Newly
1223 Acknowledged) algorithm. For each incoming SACK, miss
1224 indications are incremented only for missing TSNs prior to
1225 the highest TSN newly acknowledged in the SACK. A newly
1226 acknowledged DATA chunk is one not previously acknowledged
1227 in a SACK. If an endpoint is in Fast Recovery and a SACK
1228 arrives that advances the Cumulative TSN Ack Point, the
1229 miss indications are incremented for all TSNs reported
1230 missing in the SACK.
1234 Stewart, et al. Informational [Page 22]
1236 RFC 4460 SCTP Errata April 2006
1239 When the fourth consecutive miss indication is received for a TSN(s),
1240 the data sender shall do the following:
1242 1) Mark the DATA chunk(s) with four miss indications for
1245 2) If not in Fast Recovery, adjust the ssthresh and cwnd of the
1246 destination address(es) to which the missing DATA chunks were
1247 last sent, according to the formula described in Section 7.2.3.
1249 3) Determine how many of the earliest (i.e., lowest TSN) DATA chunks
1250 marked for retransmission will fit into a single packet, subject
1251 to constraint of the path MTU of the destination transport address
1252 to which the packet is being sent. Call this value K. Retransmit
1253 those K DATA chunks in a single packet. When a Fast Retransmit is
1254 being performed, the sender SHOULD ignore the value of cwnd and
1255 SHOULD NOT delay retransmission for this single packet.
1257 4) Restart T3-rtx timer only if the last SACK acknowledged the lowest
1258 outstanding TSN number sent to that address, or the endpoint is
1259 retransmitting the first outstanding DATA chunk sent to that
1262 5) Mark the DATA chunk(s) as being fast retransmitted and thus
1263 ineligible for a subsequent fast retransmit. Those TSNs marked
1264 for retransmission due to the Fast Retransmit algorithm that
1265 did not fit in the sent datagram carrying K other TSNs are also
1266 marked as ineligible for a subsequent fast retransmit. However,
1267 as they are marked for retransmission they will be retransmitted
1268 later on as soon as cwnd allows.
1270 6) If not in Fast Recovery, enter Fast Recovery and mark the highest
1271 outstanding TSN as the Fast Recovery exit point. When a SACK
1272 acknowledges all TSNs up to and including this exit point, Fast
1273 Recovery is exited. While in Fast Recovery, the ssthresh and cwnd
1274 SHOULD NOT change for any destinations due to a subsequent Fast
1275 Recovery event (i.e., one SHOULD NOT reduce the cwnd further due
1276 to a subsequent fast retransmit).
1278 Note: Before the above adjustments, if the received SACK also
1279 acknowledges new DATA chunks and advances the Cumulative TSN Ack
1280 Point, the cwnd adjustment rules defined in Sections 7.2.1 and 7.2.2
1281 must be applied first.
1283 2.8.3. Solution Description
1285 The effect of the above wording changes are as follows:
1290 Stewart, et al. Informational [Page 23]
1292 RFC 4460 SCTP Errata April 2006
1295 o It requires with a MUST the sending of GAP Ack blocks instead of
1296 the current RFC 2960 [5] SHOULD.
1298 o It allows a TSN being Fast Retransmitted (FR) to be sent only once
1301 o It ends the delay in waiting for the flight size to drop when a
1302 TSN is identified as being ready to FR.
1304 o It changes the way chunks are marked during fast retransmit, so
1305 that only new reports are counted.
1307 o It introduces a Fast Recovery period to avoid multiple congestion
1308 window reductions when there are multiple losses in a single RTT
1309 (as shown by Caro et al. [3]).
1311 These changes will effectively allow SCTP to follow a similar model
1312 as TCP+SACK in the handling of Fast Retransmit.
1314 2.9. Missing Statement about partial_bytes_acked Update
1316 2.9.1. Description of the Problem
1318 SCTP uses four control variables to regulate its transmission rate:
1319 rwnd, cwnd, ssthresh, and partial_bytes_acked. Upon detection of
1320 packet losses from SACK, or when the T3-rtx timer expires on an
1321 address, cwnd and ssthresh should be updated as stated in Section
1322 7.2.3. However, that section should also clarify that
1323 partial_bytes_acked must be updated as well; it has to be reset to 0.
1325 2.9.2. Text Changes to the Document
1328 Old text: (Section 7.2.3)
1331 7.2.3 Congestion Control
1333 Upon detection of packet losses from SACK (see Section 7.2.4), An
1334 endpoint should do the following:
1336 ssthresh = max(cwnd/2, 2*MTU)
1339 Basically, a packet loss causes cwnd to be cut in half.
1341 When the T3-rtx timer expires on an address, SCTP should perform slow
1346 Stewart, et al. Informational [Page 24]
1348 RFC 4460 SCTP Errata April 2006
1351 ssthresh = max(cwnd/2, 2*MTU)
1355 New text: (Section 7.2.3)
1358 7.2.3. Congestion Control
1360 Upon detection of packet losses from SACK (see Section 7.2.4), an
1361 endpoint should do the following if not in Fast Recovery:
1363 ssthresh = max(cwnd/2, 2*MTU)
1365 partial_bytes_acked = 0
1367 Basically, a packet loss causes cwnd to be cut in half.
1369 When the T3-rtx timer expires on an address, SCTP should perform slow
1372 ssthresh = max(cwnd/2, 2*MTU)
1374 partial_bytes_acked = 0
1376 2.9.3. Solution Description
1378 The missing text added solves the doubts about what to do with
1379 partial_bytes_acked in the situations stated in Section 7.2.3, making
1380 clear that, along with ssthresh and cwnd, partial_bytes_acked should
1381 also be updated by being reset to 0.
1383 2.10. Issues with Heartbeating and Failure Detection
1385 2.10.1. Description of the Problem
1387 Five basic problems have been discovered with the current heartbeat
1390 o The current specification does not specify that you should count a
1391 failed heartbeat as an error against the overall association.
1393 o The current specification is not specific as to when you start
1394 sending heartbeats and when you should stop.
1396 o The current specification is not specific as to when you should
1397 respond to heartbeats.
1402 Stewart, et al. Informational [Page 25]
1404 RFC 4460 SCTP Errata April 2006
1407 o When responding to a Heartbeat, it is unclear what to do if more
1408 than a single TLV is present.
1410 o The jitter applied to a heartbeat was meant to be a small variance
1411 of the RTO and is currently a wide variance, due to the default
1412 delay time and incorrect wording within the RFC.
1414 2.10.2. Text Changes to the Document
1417 Old text: (Section 8.1)
1420 8.1 Endpoint Failure Detection
1422 An endpoint shall keep a counter on the total number of consecutive
1423 retransmissions to its peer (including retransmissions to all the
1424 destination transport addresses of the peer if it is multi-homed).
1425 If the value of this counter exceeds the limit indicated in the
1426 protocol parameter 'Association.Max.Retrans', the endpoint shall
1427 consider the peer endpoint unreachable and shall stop transmitting
1428 any more data to it (and thus the association enters the CLOSED
1429 state). In addition, the endpoint shall report the failure to the
1430 upper layer, and optionally report back all outstanding user data
1431 remaining in its outbound queue. The association is automatically
1432 closed when the peer endpoint becomes unreachable.
1434 The counter shall be reset each time a DATA chunk sent to that peer
1435 endpoint is acknowledged (by the reception of a SACK), or a
1436 HEARTBEAT-ACK is received from the peer endpoint.
1458 Stewart, et al. Informational [Page 26]
1460 RFC 4460 SCTP Errata April 2006
1464 New text: (Section 8.1)
1467 8.1. Endpoint Failure Detection
1469 An endpoint shall keep a counter on the total number of consecutive
1470 retransmissions to its peer (this includes retransmissions to all the
1471 destination transport addresses of the peer if it is multi-homed),
1472 including unacknowledged HEARTBEAT Chunks. If the value of this
1473 counter exceeds the limit indicated in the protocol parameter
1474 'Association.Max.Retrans', the endpoint shall consider the peer
1475 endpoint unreachable and shall stop transmitting any more data to it
1476 (and thus the association enters the CLOSED state). In addition, the
1477 endpoint MAY report the failure to the upper layer and optionally
1478 report back all outstanding user data remaining in its outbound
1479 queue. The association is automatically closed when the peer
1480 endpoint becomes unreachable.
1482 The counter shall be reset each time a DATA chunk sent to that peer
1483 endpoint is acknowledged (by the reception of a SACK), or a
1484 HEARTBEAT-ACK is received from the peer endpoint.
1488 Old text: (Section 8.3)
1493 By default, an SCTP endpoint shall monitor the reachability of the
1494 idle destination transport address(es) of its peer by sending a
1495 HEARTBEAT chunk periodically to the destination transport
1499 New text: (Section 8.3)
1504 By default, an SCTP endpoint SHOULD monitor the reachability of the
1505 idle destination transport address(es) of its peer by sending a
1506 HEARTBEAT chunk periodically to the destination transport
1507 address(es). HEARTBEAT sending MAY begin upon reaching the
1508 ESTABLISHED state and is discontinued after sending either SHUTDOWN
1509 or SHUTDOWN-ACK. A receiver of a HEARTBEAT MUST respond to a
1510 HEARTBEAT with a HEARTBEAT-ACK after entering the COOKIE-ECHOED state
1514 Stewart, et al. Informational [Page 27]
1516 RFC 4460 SCTP Errata April 2006
1519 (INIT sender) or the ESTABLISHED state (INIT receiver), up until
1520 reaching the SHUTDOWN-SENT state (SHUTDOWN sender) or the SHUTDOWN-
1521 ACK-SENT state (SHUTDOWN receiver).
1525 Old text: (Section 8.3)
1528 The receiver of the HEARTBEAT should immediately respond with a
1529 HEARTBEAT ACK that contains the Heartbeat Information field copied
1530 from the received HEARTBEAT chunk.
1533 New text: (Section 8.3)
1536 The receiver of the HEARTBEAT should immediately respond with a
1537 HEARTBEAT ACK that contains the Heartbeat Information TLV, together
1538 with any other received TLVs, copied unchanged from the received
1543 Old text: (Section 8.3)
1546 On an idle destination address that is allowed to heartbeat, a
1547 HEARTBEAT chunk is RECOMMENDED to be sent once per RTO of that
1548 destination address plus the protocol parameter 'HB.interval' , with
1549 jittering of +/- 50%, and exponential back-off of the RTO if the
1550 previous HEARTBEAT is unanswered.
1553 New text: (Section 8.3)
1556 On an idle destination address that is allowed to heartbeat, it is
1557 recommended that a HEARTBEAT chunk is sent once per RTO of that
1558 destination address plus the protocol parameter 'HB.interval', with
1559 jittering of +/- 50% of the RTO value, and exponential back-off of
1560 the RTO if the previous HEARTBEAT is unanswered.
1562 2.10.3. Solution Description
1564 The above text provides guidance as to how to respond to the five
1565 issues mentioned in Section 2.10.1. In particular, the wording
1566 changes provide guidance as to when to start and stop heartbeating,
1570 Stewart, et al. Informational [Page 28]
1572 RFC 4460 SCTP Errata April 2006
1575 how to respond to a heartbeat with extra parameters, and it clarifies
1576 the error counting procedures for the association.
1578 2.11. Security interactions with firewalls
1580 2.11.1. Description of the Problem
1582 When dealing with firewalls, it is advantageous for the firewall to
1583 be able to properly determine the initial startup sequence of a
1584 reliable transport protocol. With this in mind, the following text
1585 is to be added to SCTP's security section.
1587 2.11.2. Text Changes to the Document
1590 New text: (no old text, new section added)
1593 11.4 SCTP Interactions with Firewalls
1595 It is helpful for some firewalls if they can inspect
1596 just the first fragment of a fragmented SCTP packet and unambiguously
1597 determine whether it corresponds to an INIT chunk (for further
1598 information, please refer to RFC1858). Accordingly, we
1599 stress the requirements, stated in 3.1, that (1) an INIT chunk MUST
1600 NOT be bundled with any other chunk in a packet, and (2) a packet
1601 containing an INIT chunk MUST have a zero Verification Tag.
1602 Furthermore, we require that the receiver of an INIT chunk MUST
1603 enforce these rules by silently discarding an arriving packet with an
1604 INIT chunk that is bundled with other chunks.
1607 Old text: (Section 18)
1612 [ALLMAN99] Allman, M. and Paxson, V., "On Estimating End-to-End
1613 Network Path Properties", Proc. SIGCOMM'99, 1999.
1615 [FALL96] Fall, K. and Floyd, S., Simulation-based Comparisons of
1616 Tahoe, Reno, and SACK TCP, Computer Communications Review,
1617 V. 26 N. 3, July 1996, pp. 5-21.
1619 [RFC1750] Eastlake, D. (ed.), "Randomness Recommendations for
1620 Security", RFC 1750, December 1994.
1626 Stewart, et al. Informational [Page 29]
1628 RFC 4460 SCTP Errata April 2006
1631 [RFC1950] Deutsch P. and J. Gailly, "ZLIB Compressed Data Format
1632 Specification version 3.3", RFC 1950, May 1996.
1634 [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-
1635 Hashing for Message Authentication", RFC 2104, March 1997.
1637 [RFC2196] Fraser, B., "Site Security Handbook", FYI 8, RFC 2196,
1640 [RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management
1641 Protocol", RFC 2522, March 1999.
1643 [SAVAGE99] Savage, S., Cardwell, N., Wetherall, D., and Anderson, T.,
1644 "TCP Congestion Control with a Misbehaving Receiver", ACM
1645 Computer Communication Review, 29(5), October 1999.
1648 New text: (Section 18)
1653 [ALLMAN99] Allman, M. and Paxson, V., "On Estimating End-to-End
1654 Network Path Properties", Proc. SIGCOMM'99, 1999.
1656 [FALL96] Fall, K. and Floyd, S., Simulation-based Comparisons of
1657 Tahoe, Reno, and SACK TCP, Computer Communications Review,
1658 V. 26 N. 3, July 1996, pp. 5-21.
1660 [RFC1750] Eastlake, D. (ed.), "Randomness Recommendations for
1661 Security", RFC 1750, December 1994.
1663 [RFC1858] Ziemba, G., Reed, D. and Traina P., "Security
1664 Considerations for IP Fragment Filtering", RFC 1858,
1667 [RFC1950] Deutsch P. and J. Gailly, "ZLIB Compressed Data Format
1668 Specification version 3.3", RFC 1950, May 1996.
1670 [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-
1671 Hashing for Message Authentication", RFC 2104, March 1997.
1673 [RFC2196] Fraser, B., "Site Security Handbook", FYI 8, RFC 2196,
1676 [RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management
1677 Protocol", RFC 2522, March 1999.
1682 Stewart, et al. Informational [Page 30]
1684 RFC 4460 SCTP Errata April 2006
1687 [SAVAGE99] Savage, S., Cardwell, N., Wetherall, D., and Anderson, T.,
1688 "TCP Congestion Control with a Misbehaving Receiver", ACM
1689 Computer Communication Review, 29(5), October 1999.
1691 2.11.3. Solution Description
1693 The above text, which adds a new subsection to the Security
1694 Considerations section of RFC 2960 [5] makes clear that, to make
1695 easier the interaction with firewalls, an INIT chunk must not be
1696 bundled in any case with any other chunk that will silently discard
1697 the packets that do not follow this rule (this rule is enforced by
1698 the packet receiver).
1700 2.12. Shutdown Ambiguity
1702 2.12.1. Description of the Problem
1704 Currently, there is an ambiguity between the statements in Sections
1705 6.2 and 9.2. Section 6.2 allows the sending of a SHUTDOWN chunk in
1706 place of a SACK when the sender is in the process of shutting down,
1707 while section 9.2 requires that both a SHUTDOWN chunk and a SACK
1710 Along with this ambiguity there is a problem wherein an errant
1711 SHUTDOWN receiver may fail to stop accepting user data.
1713 2.12.2. Text Changes to the Document
1716 Old text: (Section 9.2)
1719 If there are still outstanding DATA chunks left, the SHUTDOWN
1720 receiver shall continue to follow normal data transmission procedures
1721 defined in Section 6 until all outstanding DATA chunks are
1722 acknowledged; however, the SHUTDOWN receiver MUST NOT accept new data
1725 While in SHUTDOWN-SENT state, the SHUTDOWN sender MUST immediately
1726 respond to each received packet containing one or more DATA chunk(s)
1727 with a SACK, a SHUTDOWN chunk, and restart the T2-shutdown timer. If
1728 it has no more outstanding DATA chunks, the SHUTDOWN receiver shall
1729 send a SHUTDOWN ACK and start a T2-shutdown timer of its own,
1730 entering the SHUTDOWN-ACK-SENT state. If the timer expires, the
1731 endpoint must re-send the SHUTDOWN ACK.
1738 Stewart, et al. Informational [Page 31]
1740 RFC 4460 SCTP Errata April 2006
1744 New text: (Section 9.2)
1747 If there are still outstanding DATA chunks left, the SHUTDOWN
1748 receiver MUST continue to follow normal data transmission procedures
1749 defined in Section 6, until all outstanding DATA chunks are
1750 acknowledged; however, the SHUTDOWN receiver MUST NOT accept new data
1753 While in SHUTDOWN-SENT state, the SHUTDOWN sender MUST immediately
1754 respond to each received packet containing one or more DATA chunks
1755 with a SHUTDOWN chunk and restart the T2-shutdown timer. If a
1756 SHUTDOWN chunk by itself cannot acknowledge all of the received DATA
1757 chunks (i.e., there are TSNs that can be acknowledged that are larger
1758 than the cumulative TSN, and thus gaps exist in the TSN sequence), or
1759 if duplicate TSNs have been received, then a SACK chunk MUST also be
1762 The sender of the SHUTDOWN MAY also start an overall guard timer
1763 'T5-shutdown-guard' to bound the overall time for shutdown sequence.
1764 At the expiration of this timer, the sender SHOULD abort the
1765 association by sending an ABORT chunk. If the 'T5-shutdown-guard'
1766 timer is used, it SHOULD be set to the recommended value of 5 times
1769 If the receiver of the SHUTDOWN has no more outstanding DATA chunks,
1770 the SHUTDOWN receiver MUST send a SHUTDOWN ACK and start a
1771 T2-shutdown timer of its own, entering the SHUTDOWN-ACK-SENT state.
1772 If the timer expires, the endpoint must re-send the SHUTDOWN ACK.
1774 2.12.3. Solution Description
1776 The above text clarifies the use of a SACK in conjunction with a
1777 SHUTDOWN chunk. It also adds a guard timer to the SCTP shutdown
1778 sequence to protect against errant receivers of SHUTDOWN chunks.
1780 2.13. Inconsistency in ABORT Processing
1782 2.13.1. Description of the Problem
1784 It was noted that the wording in Section 8.5.1 did not give proper
1785 directions in the use of the 'T bit' with the Verification Tags.
1794 Stewart, et al. Informational [Page 32]
1796 RFC 4460 SCTP Errata April 2006
1799 2.13.2. Text changes to the document
1802 Old text: (Section 8.5.1)
1805 B) Rules for packet carrying ABORT:
1807 - The endpoint shall always fill in the Verification Tag field
1808 of the outbound packet with the destination endpoint's tag
1809 value if it is known.
1811 - If the ABORT is sent in response to an OOTB packet, the
1812 endpoint MUST follow the procedure described in Section 8.4.
1814 - The receiver MUST accept the packet if the Verification Tag
1815 matches either its own tag, OR the tag of its peer. Otherwise,
1816 the receiver MUST silently discard the packet and take no
1820 New text: (Section 8.5.1)
1823 B) Rules for packet carrying ABORT:
1825 - The endpoint MUST always fill in the Verification Tag field of
1826 the outbound packet with the destination endpoint's tag value,
1829 - If the ABORT is sent in response to an OOTB packet, the
1830 endpoint MUST follow the procedure described in Section 8.4.
1832 - The receiver of a ABORT MUST accept the packet if the
1833 Verification Tag field of the packet matches its own tag OR if
1834 it is set to its peer's tag and the T bit is set in the Chunk
1835 Flags. Otherwise, the receiver MUST silently discard the
1836 packet and take no further action.
1838 2.13.3. Solution Description
1840 The above text change clarifies that the T bit must be set before an
1841 implementation looks for the peer's tag.
1850 Stewart, et al. Informational [Page 33]
1852 RFC 4460 SCTP Errata April 2006
1855 2.14. Cwnd Gated by Its Full Use
1857 2.14.1. Description of the Problem
1859 A problem was found with the current specification of the growth and
1860 decay of cwnd. The cwnd should only be increased if it is being
1861 fully utilized, and after periods of underutilization, the cwnd
1862 should be decreased. In some sections, the current wording is weak
1863 and is not clearly defined. Also, the current specification
1864 unnecessarily introduces the need for special case code to ensure
1865 cwnd degradation. Plus, the cwnd should not be increased during Fast
1866 Recovery, since a full cwnd during Fast Recovery does not qualify the
1867 cwnd as being fully utilized. Additionally, multiple loss scenarios
1868 in a single window may cause the cwnd to grow more rapidly as the
1869 number of losses in a window increases [3].
1871 2.14.2. Text Changes to the Document
1874 Old text: (Section 6.1)
1877 D) Then, the sender can send out as many new DATA chunks as Rule A
1878 and Rule B above allow.
1881 New text: (Section 6.1)
1884 D) When the time comes for the sender to transmit new DATA chunks,
1885 the protocol parameter Max.Burst SHOULD be used to limit the
1886 number of packets sent. The limit MAY be applied by adjusting
1889 if((flightsize + Max.Burst*MTU) < cwnd)
1890 cwnd = flightsize + Max.Burst*MTU
1892 Or it MAY be applied by strictly limiting the number of packets
1893 emitted by the output routine.
1895 E) Then, the sender can send out as many new DATA chunks as Rule A
1906 Stewart, et al. Informational [Page 34]
1908 RFC 4460 SCTP Errata April 2006
1912 Old text: (Section 7.2.1)
1915 o When cwnd is less than or equal to ssthresh an SCTP endpoint MUST
1916 use the slow start algorithm to increase cwnd (assuming the
1917 current congestion window is being fully utilized). If an
1918 incoming SACK advances the Cumulative TSN Ack Point, cwnd MUST be
1919 increased by at most the lesser of 1) the total size of the
1920 previously outstanding DATA chunk(s) acknowledged, and 2) the
1921 destination's path MTU. This protects against the ACK-Splitting
1922 attack outlined in [SAVAGE99].
1925 New text: (Section 7.2.1)
1928 o When cwnd is less than or equal to ssthresh, an SCTP endpoint MUST
1929 use the slow start algorithm to increase cwnd only if the current
1930 congestion window is being fully utilized, an incoming SACK
1931 advances the Cumulative TSN Ack Point, and the data sender is not
1932 in Fast Recovery. Only when these three conditions are met can
1933 the cwnd be increased; otherwise, the cwnd MUST not be increased.
1934 If these conditions are met, then cwnd MUST be increased by, at
1935 most, the lesser of 1) the total size of the previously
1936 outstanding DATA chunk(s) acknowledged, and 2) the destination's
1937 path MTU. This upper bound protects against the ACK-Splitting
1938 attack outlined in [SAVAGE99].
1942 Old text: (Section 14)
1945 14. Suggested SCTP Protocol Parameter Values
1947 The following protocol parameters are RECOMMENDED:
1949 RTO.Initial - 3 seconds
1951 RTO.Max - 60 seconds
1954 Valid.Cookie.Life - 60 seconds
1955 Association.Max.Retrans - 10 attempts
1956 Path.Max.Retrans - 5 attempts (per destination address)
1957 Max.Init.Retransmits - 8 attempts
1958 HB.interval - 30 seconds
1962 Stewart, et al. Informational [Page 35]
1964 RFC 4460 SCTP Errata April 2006
1968 New text: (Section 14)
1971 14. Suggested SCTP Protocol Parameter Values
1973 The following protocol parameters are RECOMMENDED:
1975 RTO.Initial - 3 seconds
1977 RTO.Max - 60 seconds
1981 Valid.Cookie.Life - 60 seconds
1982 Association.Max.Retrans - 10 attempts
1983 Path.Max.Retrans - 5 attempts (per destination address)
1984 Max.Init.Retransmits - 8 attempts
1985 HB.Interval - 30 seconds
1987 2.14.3. Solution Description
1989 The above changes strengthen the rules and make it much more apparent
1990 as to the need to block cwnd growth when the full cwnd is not being
1991 utilized. The changes also apply cwnd degradation without
1992 introducing the need for complex special case code.
1994 2.15. Window Probes in SCTP
1996 2.15.1. Description of the Problem
1998 When a receiver clamps its rwnd to 0 to flow control the peer, the
1999 specification implies that one must continue to accept data from the
2000 remote peer. This is incorrect and needs clarification.
2002 2.15.2. Text Changes to the Document
2005 Old text: (Section 6.2)
2008 The SCTP endpoint MUST always acknowledge the receipt of each valid
2018 Stewart, et al. Informational [Page 36]
2020 RFC 4460 SCTP Errata April 2006
2024 New text: (Section 6.2)
2027 The SCTP endpoint MUST always acknowledge the reception of each valid
2028 DATA chunk when the DATA chunk received is inside its receive window.
2030 When the receiver's advertised window is 0, the receiver MUST drop
2031 any new incoming DATA chunk with a TSN larger than the largest TSN
2032 received so far. If the new incoming DATA chunk holds a TSN value
2033 less than the largest TSN received so far, then the receiver SHOULD
2034 drop the largest TSN held for reordering and accept the new incoming
2035 DATA chunk. In either case, if such a DATA chunk is dropped, the
2036 receiver MUST immediately send back a SACK with the current receive
2037 window showing only DATA chunks received and accepted so far. The
2038 dropped DATA chunk(s) MUST NOT be included in the SACK, as they were
2039 not accepted. The receiver MUST also have an algorithm for
2040 advertising its receive window to avoid receiver silly window
2041 syndrome (SWS), as described in RFC 813. The algorithm can be
2042 similar to the one described in Section 4.2.3.3 of RFC 1122.
2046 Old text: (Section 6.1)
2049 A) At any given time, the data sender MUST NOT transmit new data to
2050 any destination transport address if its peer's rwnd indicates
2051 that the peer has no buffer space (i.e., rwnd is 0, see Section
2052 6.2.1). However, regardless of the value of rwnd (including if it
2053 is 0), the data sender can always have one DATA chunk in flight to
2054 the receiver if allowed by cwnd (see rule B below). This rule
2055 allows the sender to probe for a change in rwnd that the sender
2056 missed due to the SACK having been lost in transit from the data
2057 receiver to the data sender.
2074 Stewart, et al. Informational [Page 37]
2076 RFC 4460 SCTP Errata April 2006
2080 New text: (Section 6.1)
2083 A) At any given time, the data sender MUST NOT transmit new data to
2084 any destination transport address if its peer's rwnd indicates
2085 that the peer has no buffer space (i.e., rwnd is 0; see Section
2086 6.2.1). However, regardless of the value of rwnd (including if it
2087 is 0), the data sender can always have one DATA chunk in flight to
2088 the receiver if allowed by cwnd (see rule B, below). This rule
2089 allows the sender to probe for a change in rwnd that the sender
2090 missed due to the SACK's having been lost in transit from the data
2091 receiver to the data sender.
2093 When the receiver's advertised window is zero, this probe is
2094 called a zero window probe. Note that a zero window probe
2095 SHOULD only be sent when all outstanding DATA chunks have
2096 been cumulatively acknowledged and no DATA chunks are in
2097 flight. Zero window probing MUST be supported.
2099 If the sender continues to receive new packets from the receiver
2100 while doing zero window probing, the unacknowledged window probes
2101 should not increment the error counter for the association or any
2102 destination transport address.This is because the receiver MAY
2103 keep its window closed for an indefinite time. Refer to
2104 Section 6.2 on the receiver behavior when it advertises a zero
2105 window. The sender SHOULD send the first zero window probe after
2106 1 RTO when it detects that the receiver has closed its window
2107 and SHOULD increase the probe interval exponentially afterwards.
2108 Also note that the cwnd SHOULD be adjusted according to
2109 Section 7.2.1. Zero window probing does not affect the
2110 calculation of cwnd.
2112 The sender MUST also have an algorithm for sending new DATA chunks
2113 to avoid silly window syndrome (SWS) as described in RFC 813. The
2114 algorithm can be similar to the one described in Section 4.2.3.4
2117 2.15.3. Solution Description
2119 The above allows a receiver to drop new data that arrives and yet
2120 still requires the receiver to send a SACK showing the conditions
2121 unchanged (with the possible exception of a new a_rwnd) and the
2122 dropped chunk as missing. This will allow the association to
2123 continue until the rwnd condition clears.
2130 Stewart, et al. Informational [Page 38]
2132 RFC 4460 SCTP Errata April 2006
2135 2.16. Fragmentation and Path MTU Issues
2137 2.16.1. Description of the Problem
2139 The current wording of the Fragmentation and Reassembly forces an
2140 implementation that supports fragmentation to always fragment. This
2141 prohibits an implementation from offering its users an option to
2142 disable sends that exceed the SCTP fragmentation point.
2144 The restriction in RFC 2960 [5], Section 6.9, was never meant to
2145 restrict an implementations API from this behavior.
2147 2.16.2. Text Changes to the Document
2150 Old text: (Section 6.1)
2153 6.9 Fragmentation and Reassembly
2155 An endpoint MAY support fragmentation when sending DATA chunks, but
2156 MUST support reassembly when receiving DATA chunks. If an endpoint
2157 supports fragmentation, it MUST fragment a user message if the size
2158 of the user message to be sent causes the outbound SCTP packet size
2159 to exceed the current MTU. If an implementation does not support
2160 fragmentation of outbound user messages, the endpoint must return an
2161 error to its upper layer and not attempt to send the user message.
2163 IMPLEMENTATION NOTE: In this error case, the Send primitive
2164 discussed in Section 10.1 would need to return an error to the upper
2168 New text: (Section 6.1)
2171 6.9. Fragmentation and Reassembly
2173 An endpoint MAY support fragmentation when sending DATA chunks, but
2174 it MUST support reassembly when receiving DATA chunks. If an
2175 endpoint supports fragmentation, it MUST fragment a user message if
2176 the size of the user message to be sent causes the outbound SCTP
2177 packet size to exceed the current MTU. If an implementation does not
2178 support fragmentation of outbound user messages, the endpoint MUST
2179 return an error to its upper layer and not attempt to send the user
2186 Stewart, et al. Informational [Page 39]
2188 RFC 4460 SCTP Errata April 2006
2191 Note: If an implementation that supports fragmentation makes
2192 available to its upper layer a mechanism to turn off fragmentation it
2193 may do so. However, in so doing, it MUST react just like an
2194 implementation that does NOT support fragmentation, i.e., it MUST
2195 reject sends that exceed the current P-MTU.
2197 IMPLEMENTATION NOTE: In this error case, the Send primitive
2198 discussed in Section 10.1 would need to return an error to the upper
2201 2.16.3. Solution Description
2203 The above wording will allow an implementation to offer the option of
2204 rejecting sends that exceed the P-MTU size even when the
2205 implementation supports fragmentation.
2207 2.17. Initial Value of the Cumulative TSN Ack
2209 2.17.1. Description of the Problem
2211 The current description of the SACK chunk within the RFC does not
2212 clearly state the value that would be put within a SACK when no DATA
2213 chunk has been received.
2215 2.17.2. Text Changes to the Document
2218 Old text: (Section 3.3.4)
2221 Cumulative TSN Ack: 32 bits (unsigned integer)
2223 This parameter contains the TSN of the last DATA chunk received in
2224 sequence before a gap.
2227 New text: (Section 3.3.4)
2230 Cumulative TSN Ack: 32 bits (unsigned integer)
2232 This parameter contains the TSN of the last DATA chunk received in
2233 sequence before a gap. In the case where no DATA chunk has
2234 been received, this value is set to the peer's Initial TSN minus
2242 Stewart, et al. Informational [Page 40]
2244 RFC 4460 SCTP Errata April 2006
2247 2.17.3. Solution Description
2249 This change clearly states what the initial value will be for a SACK
2252 2.18. Handling of Address Parameters within the INIT or INIT-ACK
2254 2.18.1. Description of the Problem
2256 The current description on handling address parameters contained
2257 within the INIT and INIT-ACK does not fully describe a requirement
2260 2.18.2. Text Changes to the Document
2263 Old text: (Section 5.1.2)
2266 C) If there are only IPv4/IPv6 addresses present in the received INIT
2267 or INIT ACK chunk, the receiver shall derive and record all the
2268 transport address(es) from the received chunk AND the source IP
2269 address that sent the INIT or INIT ACK. The transport address(es)
2270 are derived by the combination of SCTP source port (from the
2271 common header) and the IP address parameter(s) carried in the INIT
2272 or INIT ACK chunk and the source IP address of the IP datagram.
2273 The receiver should use only these transport addresses as
2274 destination transport addresses when sending subsequent packets to
2278 New text: (Section 5.1.2)
2281 C) If there are only IPv4/IPv6 addresses present in the received INIT
2282 or INIT ACK chunk, the receiver MUST derive and record all the
2283 transport addresses from the received chunk AND the source IP
2284 address that sent the INIT or INIT ACK. The transport addresses
2285 are derived by the combination of SCTP source port (from the
2286 common header) and the IP address parameter(s) carried in the INIT
2287 or INIT ACK chunk and the source IP address of the IP datagram.
2288 The receiver should use only these transport addresses as
2289 destination transport addresses when sending subsequent packets to
2298 Stewart, et al. Informational [Page 41]
2300 RFC 4460 SCTP Errata April 2006
2303 D) An INIT or INIT ACK chunk MUST be treated as belonging
2304 to an already established association (or one in the
2305 process of being established) if the use of any of the
2306 valid address parameters contained within the chunk
2307 would identify an existing TCB.
2309 2.18.3. Solution description
2311 This new text clearly specifies to an implementor the need to look
2312 within the INIT or INIT ACK. Any implementation that does not do
2313 this may (for example) not be able to recognize an INIT chunk coming
2314 from an already established association that adds new addresses (see
2315 Section 2.6) or an incoming INIT ACK chunk sent from a source address
2316 different from the destination address used to send the INIT chunk.
2318 2.19. Handling of Stream Shortages
2320 2.19.1. Description of the Problem
2322 The current wording in the RFC places the choice of sending an ABORT
2323 upon the SCTP stack when a stream shortage occurs. This decision
2324 should really be made by the upper layer, not the SCTP stack.
2326 2.19.2. Text Changes to the Document
2332 5.1.1 Handle Stream Parameters
2334 In the INIT and INIT ACK chunks, the sender of the chunk shall
2335 indicate the number of outbound streams (OS) it wishes to have in
2336 the association, as well as the maximum inbound streams (MIS) it
2337 will accept from the other endpoint.
2339 After receiving the stream configuration information from the other
2340 side, each endpoint shall perform the following check: If the peer's
2341 MIS is less than the endpoint's OS, meaning that the peer is
2342 incapable of supporting all the outbound streams the endpoint wants
2343 to configure, the endpoint MUST either use MIS outbound streams, or
2344 abort the association and report to its upper layer the resources
2345 shortage at its peer.
2354 Stewart, et al. Informational [Page 42]
2356 RFC 4460 SCTP Errata April 2006
2360 New text: (Section 5.1.2)
2363 5.1.1. Handle Stream Parameters
2365 In the INIT and INIT ACK chunks, the sender of the chunk MUST
2366 indicate the number of outbound streams (OS) it wishes to have in
2367 the association, as well as the maximum inbound streams (MIS) it will
2368 accept from the other endpoint.
2370 After receiving the stream configuration information from the other
2371 side, each endpoint MUST perform the following check: If the peer's
2372 MIS is less than the endpoint's OS, meaning that the peer is
2373 incapable of supporting all the outbound streams the endpoint wants
2374 to configure, the endpoint MUST use MIS outbound streams and MAY
2375 report any shortage to the upper layer. The upper layer can then
2376 choose to abort the association if the resource shortage
2379 2.19.3. Solution Description
2381 The above changes take the decision to ABORT out of the realm of the
2382 SCTP stack and place it into the user's hands.
2384 2.20. Indefinite Postponement
2386 2.20.1. Description of the Problem
2388 The current RFC does not provide any guidance on the assignment of
2389 TSN sequence numbers to outbound messages nor reception of these
2390 messages. This could lead to a possible indefinite postponement.
2392 2.20.2. Text Changes to the Document
2395 Old text: (Section 6.1)
2398 Note: The data sender SHOULD NOT use a TSN that is more than 2**31 -
2399 1 above the beginning TSN of the current send window.
2401 6.2 Acknowledgement on Reception of DATA Chunks
2410 Stewart, et al. Informational [Page 43]
2412 RFC 4460 SCTP Errata April 2006
2416 New text: (Section 6.1)
2419 Note: The data sender SHOULD NOT use a TSN that is more than 2**31 -
2420 1 above the beginning TSN of the current send window.
2422 The algorithm by which an implementation assigns sequential TSNs to
2423 messages on a particular association MUST ensure that no user
2424 message that has been accepted by SCTP is indefinitely postponed
2425 from being assigned a TSN. Acceptable algorithms for assigning TSNs
2428 (a) assigning TSNs in round-robin order over all streams with
2431 (b) preserving the linear order in which the user messages were
2432 submitted to the SCTP association.
2434 When an upper layer requests to read data on an SCTP association,
2435 the SCTP receiver SHOULD choose the message with the lowest TSN from
2436 among all deliverable messages. In SCTP implementations that allow a
2437 user to request data on a specific stream, this operation SHOULD NOT
2438 block if data is not available, since this can lead to a deadlock
2439 under certain conditions.
2441 6.2. Acknowledgement on Receipt of DATA Chunks
2443 2.20.3. Solution Description
2445 The above wording clarifies how TSNs SHOULD be assigned by the
2448 2.21. User-Initiated Abort of an Association
2450 2.21.1. Description of the Problem
2452 It is not possible for an upper layer to abort the association and
2453 provide the peer with an indication of why the association is
2456 2.21.2. Text changes to the document
2458 Some of the changes given here already include changes suggested in
2459 Section 2.6 of this document.
2466 Stewart, et al. Informational [Page 44]
2468 RFC 4460 SCTP Errata April 2006
2472 Old text: (Section 3.3.10)
2477 --------- ----------------
2478 1 Invalid Stream Identifier
2479 2 Missing Mandatory Parameter
2480 3 Stale Cookie Error
2482 5 Unresolvable Address
2483 6 Unrecognized Chunk Type
2484 7 Invalid Mandatory Parameter
2485 8 Unrecognized Parameters
2487 10 Cookie Received While Shutting Down
2489 Cause Length: 16 bits (unsigned integer)
2491 Set to the size of the parameter in bytes, including the Cause
2492 Code, Cause Length, and Cause-Specific Information fields
2494 Cause-specific Information: variable length
2496 This field carries the details of the error condition.
2498 Sections 3.3.10.1 - 3.3.10.10 define error causes for SCTP.
2499 Guidelines for the IETF to define new error cause values are
2500 discussed in Section 13.3.
2522 Stewart, et al. Informational [Page 45]
2524 RFC 4460 SCTP Errata April 2006
2528 New text: (Section 3.3.10)
2533 --------- ----------------
2534 1 Invalid Stream Identifier
2535 2 Missing Mandatory Parameter
2536 3 Stale Cookie Error
2538 5 Unresolvable Address
2539 6 Unrecognized Chunk Type
2540 7 Invalid Mandatory Parameter
2541 8 Unrecognized Parameters
2543 10 Cookie Received While Shutting Down
2544 11 Restart of an Association with New Addresses
2545 12 User-Initiated Abort
2547 Cause Length: 16 bits (unsigned integer)
2549 Set to the size of the parameter in bytes, including the Cause
2550 Code, Cause Length, and Cause-Specific Information fields
2552 Cause-specific Information: variable length
2554 This field carries the details of the error condition.
2556 Sections 3.3.10.1 - 3.3.10.12 define error causes for SCTP.
2557 Guidelines for the IETF to define new error cause values are
2558 discussed in Section 13.3.
2561 New text: (Note: no old text, new error added in Section 3.3.10)
2564 3.3.10.12. User-Initiated Abort (12)
2569 This error cause MAY be included in ABORT chunks that are sent
2570 because of an upper layer request. The upper layer can specify
2571 an Upper Layer Abort Reason that is transported by SCTP
2572 transparently and MAY be delivered to the upper layer protocol
2578 Stewart, et al. Informational [Page 46]
2580 RFC 4460 SCTP Errata April 2006
2583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2584 | Cause Code=12 | Cause Length=Variable |
2585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2586 / Upper Layer Abort Reason /
2588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2591 Old text: (Section 9.1)
2594 9.1 Abort of an Association
2596 When an endpoint decides to abort an existing association, it
2597 shall send an ABORT chunk to its peer endpoint. The sender MUST
2598 fill in the peer's Verification Tag in the outbound packet and
2599 MUST NOT bundle any DATA chunk with the ABORT.
2601 An endpoint MUST NOT respond to any received packet that contains
2602 an ABORT chunk (also see Section 8.4).
2604 An endpoint receiving an ABORT shall apply the special
2605 Verification Tag check rules described in Section 8.5.1.
2607 After checking the Verification Tag, the receiving endpoint shall
2608 remove the association from its record and shall report the
2609 termination to its upper layer.
2612 New text: (Section 9.1)
2615 9.1. Abort of an Association
2617 When an endpoint decides to abort an existing association, it MUST
2618 send an ABORT chunk to its peer endpoint. The sender MUST fill in
2619 the peer's Verification Tag in the outbound packet and MUST NOT
2620 bundle any DATA chunk with the ABORT. If the association is
2621 aborted on request of the upper layer, a User-Initiated Abort
2622 error cause (see 3.3.10.12) SHOULD be present in the ABORT chunk.
2624 An endpoint MUST NOT respond to any received packet that contains
2625 an ABORT chunk (also see Section 8.4).
2627 An endpoint receiving an ABORT MUST apply the special Verification
2628 Tag check rules described in Section 8.5.1.
2630 After checking the Verification Tag, the receiving endpoint MUST
2634 Stewart, et al. Informational [Page 47]
2636 RFC 4460 SCTP Errata April 2006
2639 remove the association from its record and SHOULD report the
2640 termination to its upper layer. If a User-Initiated Abort error
2641 cause is present in the ABORT chunk, the Upper Layer Abort Reason
2642 SHOULD be made available to the upper layer.
2645 Old text: (Section 10.1)
2650 Format: ABORT(association id [, cause code])
2653 Ungracefully closes an association. Any locally queued user
2654 data will be discarded and an ABORT chunk is sent to the peer.
2655 A success code will be returned on successful abortion of the
2656 association. If attempting to abort the association results
2657 in a failure, an error code shall be returned.
2659 Mandatory attributes:
2661 o association id - local handle to the SCTP association
2663 Optional attributes:
2665 o cause code - reason of the abort to be passed to the peer.
2669 New text: (Section 10.1)
2674 Format: ABORT(association id [, Upper Layer Abort Reason])
2677 Ungracefully closes an association. Any locally queued user
2678 data will be discarded, and an ABORT chunk is sent to the peer.
2679 A success code will be returned on successful abortion of the
2680 association. If attempting to abort the association results
2681 in a failure, an error code shall be returned.
2683 Mandatory attributes:
2685 o association id - Local handle to the SCTP association.
2690 Stewart, et al. Informational [Page 48]
2692 RFC 4460 SCTP Errata April 2006
2695 Optional attributes:
2697 o Upper Layer Abort Reason - Reason of the abort to be passed
2703 Old text: (Section 10.2)
2706 E) COMMUNICATION LOST notification
2708 When SCTP loses communication to an endpoint completely (e.g., via
2709 Heartbeats) or detects that the endpoint has performed an abort
2710 operation, it shall invoke this notification on the ULP.
2712 The following shall be passed with the notification:
2714 o association id - local handle to the SCTP association
2716 o status - This indicates what type of event has occurred; The
2717 status may indicate a failure OR a normal termination
2718 event occurred in response to a shutdown or abort
2721 The following may be passed with the notification:
2723 o data retrieval id - an identification used to retrieve
2724 unsent and unacknowledged data.
2726 o last-acked - the TSN last acked by that peer endpoint;
2728 o last-sent - the TSN last sent to that peer endpoint;
2731 New text: (Section 10.2)
2734 E) COMMUNICATION LOST notification
2736 When SCTP loses communication to an endpoint completely (e.g., via
2737 Heartbeats) or detects that the endpoint has performed an abort
2738 operation, it shall invoke this notification on the ULP.
2740 The following shall be passed with the notification:
2742 o association id - Local handle to the SCTP association.
2746 Stewart, et al. Informational [Page 49]
2748 RFC 4460 SCTP Errata April 2006
2751 o status - This indicates what type of event has occurred; The
2752 status may indicate that a failure OR a normal
2753 termination event occurred in response to a shutdown
2756 The following may be passed with the notification:
2758 o data retrieval id - An identification used to retrieve unsent
2759 and unacknowledged data.
2761 o last-acked - The TSN last acked by that peer endpoint.
2763 o last-sent - The TSN last sent to that peer endpoint.
2765 o Upper Layer Abort Reason - The abort reason specified in
2766 case of a user-initiated abort.
2768 2.21.3. Solution Description
2770 The above allows an upper layer to provide its peer with an
2771 indication of why the association was aborted. Therefore, an
2772 addition error cause was introduced.
2774 2.22. Handling of Invalid Initiate Tag of INIT-ACK
2776 2.22.1. Description of the Problem
2778 RFC 2960 requires that the receiver of an INIT-ACK with the Initiate
2779 Tag set to zero handles this as an error and sends back an ABORT.
2780 But the sender of the INIT-ACK normally has no TCB, and thus the
2783 2.22.2. Text Changes to the Document
2786 Old text: (Section 3.3.3)
2789 Initiate Tag: 32 bits (unsigned integer)
2791 The receiver of the INIT ACK records the value of the
2792 Initiate Tag parameter. This value MUST be placed into
2793 the Verification Tag field of every SCTP packet that the
2794 INIT ACK receiver transmits within this association.
2796 The Initiate Tag MUST NOT take the value 0. See Section 5.3.1
2797 for more on the selection of the Initiate Tag value.
2802 Stewart, et al. Informational [Page 50]
2804 RFC 4460 SCTP Errata April 2006
2807 If the value of the Initiate Tag in a received INIT ACK chunk
2808 is found to be 0, the receiver MUST treat it as an error and
2809 close the association by transmitting an ABORT.
2812 New text: (Section 3.3.3)
2815 Initiate Tag: 32 bits (unsigned integer)
2817 The receiver of the INIT ACK records the value of the
2818 Initiate Tag parameter. This value MUST be placed into
2819 the Verification Tag field of every SCTP packet that the
2820 INIT ACK receiver transmits within this association.
2822 The Initiate Tag MUST NOT take the value 0. See Section 5.3.1
2823 for more on the selection of the Initiate Tag value.
2825 If the value of the Initiate Tag in a received INIT ACK
2826 chunk is found to be 0, the receiver MUST destroy the
2827 association discarding its TCB. The receiver MAY send an
2828 ABORT for debugging purpose.
2830 2.22.3. Solution Description
2832 The new text does not require that the receiver of the invalid INIT-
2833 ACK send the ABORT. This behavior is in tune with the error case of
2834 invalid stream numbers in the INIT-ACK. However, sending an ABORT
2835 for debugging purposes is allowed.
2837 2.23. Sending an ABORT in Response to an INIT
2839 2.23.1. Description of the Problem
2841 Whenever the receiver of an INIT chunk has to send an ABORT chunk in
2842 response, for whatever reason, it is not stated clearly which
2843 Verification Tag and value of the T-bit should be used.
2845 2.23.2. Text Changes to the Document
2848 Old text: (Section 8.4)
2851 3) If the packet contains an INIT chunk with a Verification Tag
2852 set to '0', process it as described in Section 5.1.
2858 Stewart, et al. Informational [Page 51]
2860 RFC 4460 SCTP Errata April 2006
2864 New text: (Section 8.4)
2867 3) If the packet contains an INIT chunk with a Verification Tag
2868 set to '0', process it as described in Section 5.1. If, for
2869 whatever reason, the INIT cannot be processed normally and
2870 an ABORT has to be sent in response, the Verification Tag
2871 of the packet containing the ABORT chunk MUST be the
2872 Initiate tag of the received INIT chunk, and the T-Bit of
2873 the ABORT chunk has to be set to 0, indicating that
2874 a TCB was destroyed. Otherwise,
2876 2.23.3. Solution Description
2878 The new text stated clearly which value of the Verification Tag and
2879 T-bit have to be used.
2881 2.24. Stream Sequence Number (SSN) Initialization
2883 2.24.1. Description of the Problem
2885 RFC 2960 does not describe the fact that the SSN has to be
2886 initialized to 0, as required by RFC 2119.
2888 2.24.2. Text Changes to the Document
2891 Old text: (Section 6.5)
2894 The stream sequence number in all the streams shall start from 0
2895 when the association is established. Also, when the stream
2896 sequence number reaches the value 65535 the next stream sequence
2897 number shall be set to 0.
2900 New text: (Section 6.5)
2903 The stream sequence number in all the streams MUST start from 0
2904 when the association is established. Also, when the stream
2905 sequence number reaches the value 65535 the next stream sequence
2906 number MUST be set to 0.
2914 Stewart, et al. Informational [Page 52]
2916 RFC 4460 SCTP Errata April 2006
2919 2.24.3. Solution Description
2921 The 'shall' in the text is replaced by a 'MUST' to clearly state the
2924 2.25. SACK Packet Format
2926 2.25.1. Description of the Problem
2928 It is not clear in RFC 2960 whether a SACK must contain the fields
2929 Number of Gap Ack Blocks and Number of Duplicate TSNs.
2931 2.25.2. Text Changes to the Document
2934 Old text: (Section 3.3.4)
2937 The SACK MUST contain the Cumulative TSN Ack and
2938 Advertised Receiver Window Credit (a_rwnd) parameters.
2941 New text: (Section 3.3.4)
2944 The SACK MUST contain the Cumulative TSN Ack,
2945 Advertised Receiver Window Credit (a_rwnd), Number
2946 of Gap Ack Blocks, and Number of Duplicate TSNs fields.
2948 2.25.3. Solution Description
2950 The text has been modified. It is now clear that a SACK always
2951 contains the fields Number of Gap Ack Blocks and Number of Duplicate
2954 2.26. Protocol Violation Error Cause
2956 2.26.1. Description of the Problem
2958 There are many situations where an SCTP endpoint may detect that its
2959 peer violates the protocol. The result of such detection often
2960 results in the association being destroyed by the sending of an
2961 ABORT. Currently, there are only some error causes that could be
2962 used to indicate the reason for the abort, but these do not cover all
2970 Stewart, et al. Informational [Page 53]
2972 RFC 4460 SCTP Errata April 2006
2975 2.26.2. Text Changes to the Document
2977 Some of the changes given here already include changes suggested in
2978 Section 2.6 and 2.21 of this document.
2981 Old text: (Section 3.3.10)
2986 --------- ----------------
2987 1 Invalid Stream Identifier
2988 2 Missing Mandatory Parameter
2989 3 Stale Cookie Error
2991 5 Unresolvable Address
2992 6 Unrecognized Chunk Type
2993 7 Invalid Mandatory Parameter
2994 8 Unrecognized Parameters
2996 10 Cookie Received While Shutting Down
2998 Cause Length: 16 bits (unsigned integer)
3000 Set to the size of the parameter in bytes, including the Cause
3001 Code, Cause Length, and Cause-Specific Information fields
3003 Cause-specific Information: variable length
3005 This field carries the details of the error condition.
3007 Sections 3.3.10.1 - 3.3.10.10 define error causes for SCTP.
3008 Guidelines for the IETF to define new error cause values are
3009 discussed in Section 13.3.
3026 Stewart, et al. Informational [Page 54]
3028 RFC 4460 SCTP Errata April 2006
3032 New text: (Section 3.3.10)
3037 --------- ----------------
3038 1 Invalid Stream Identifier
3039 2 Missing Mandatory Parameter
3040 3 Stale Cookie Error
3042 5 Unresolvable Address
3043 6 Unrecognized Chunk Type
3044 7 Invalid Mandatory Parameter
3045 8 Unrecognized Parameters
3047 10 Cookie Received While Shutting Down
3048 11 Restart of an Association with New Addresses
3049 12 User Initiated Abort
3050 13 Protocol Violation
3052 Cause Length: 16 bits (unsigned integer)
3054 Set to the size of the parameter in bytes, including the Cause
3055 Code, Cause Length, and Cause-Specific Information fields
3057 Cause-specific Information: variable length
3059 This field carries the details of the error condition.
3061 Sections 3.3.10.1 - 3.3.10.13 define error causes for SCTP.
3062 Guidelines for the IETF to define new error cause values are
3063 discussed in Section 13.3.
3066 New text: (Note: no old text; new error added in section 3.3.10)
3069 3.3.10.13. Protocol Violation (13)
3074 This error cause MAY be included in ABORT chunks that are sent
3075 because an SCTP endpoint detects a protocol violation of the peer
3076 that is not covered by the error causes described in 3.3.10.1 to
3077 3.3.10.12. An implementation MAY provide additional information
3078 specifying what kind of protocol violation has been detected.
3082 Stewart, et al. Informational [Page 55]
3084 RFC 4460 SCTP Errata April 2006
3087 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3088 | Cause Code=13 | Cause Length=Variable |
3089 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3090 / Additional Information /
3092 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3094 2.26.3. Solution Description
3096 An additional error cause has been defined that can be used by an
3097 endpoint to indicate a protocol violation of the peer.
3099 2.27. Reporting of Unrecognized Parameters
3101 2.27.1. Description of the Problem
3103 It is not stated clearly in RFC 2960 [5] how unrecognized parameters
3104 should be reported. Unrecognized parameters in an INIT chunk could
3105 be reported in the INIT-ACK chunk or in a separate ERROR chunk, which
3106 can get lost. Unrecognized parameters in an INIT-ACK chunk have to
3107 be reported in an ERROR-chunk. This can be bundled with the COOKIE-
3108 ERROR chunk or sent separately. If it is sent separately and
3109 received before the COOKIE-ECHO, it will be handled as an OOTB
3110 packet, resulting in sending out an ABORT chunk. Therefore, the
3111 association would not be established.
3113 2.27.2. Text Changes to the Document
3115 Some of the changes given here already include changes suggested in
3116 Section 2.2 of this document.
3119 Old text: (Section 3.2.1)
3122 00 - Stop processing this SCTP packet and discard it, do not process
3123 any further chunks within it.
3125 01 - Stop processing this SCTP packet and discard it, do not process
3126 any further chunks within it, and report the unrecognized
3127 parameter in an 'Unrecognized Parameter Type' (in either an
3128 ERROR or in the INIT ACK).
3130 10 - Skip this parameter and continue processing.
3132 11 - Skip this parameter and continue processing but report the
3133 unrecognized parameter in an 'Unrecognized Parameter Type' (in
3134 either an ERROR or in the INIT ACK).
3138 Stewart, et al. Informational [Page 56]
3140 RFC 4460 SCTP Errata April 2006
3144 New text: (Section 3.2.1)
3147 00 - Stop processing this SCTP chunk and discard it; do not process
3148 any further parameters within this chunk.
3150 01 - Stop processing this SCTP chunk and discard it, do not process
3151 any further parameters within this chunk, and report the
3152 unrecognized parameter in an 'Unrecognized Parameter Type', as
3155 10 - Skip this parameter and continue processing.
3157 11 - Skip this parameter and continue processing but report the
3158 unrecognized parameter in an 'Unrecognized Parameter Type', as
3162 New text: (Note: no old text; clarification added in Section 3.2)
3165 3.2.2. Reporting of Unrecognized Parameters
3167 If the receiver of an INIT chunk detects unrecognized parameters
3168 and has to report them according to Section 3.2.1, it MUST put
3169 the 'Unrecognized Parameter' parameter(s) in the INIT-ACK chunk
3170 sent in response to the INIT-chunk. Note that if the receiver
3171 of the INIT chunk is NOT going to establish an association (e.g.,
3172 due to lack of resources), then no report would be sent back.
3174 If the receiver of an INIT-ACK chunk detects unrecognized
3175 parameters and has to report them according to Section 3.2.1,
3176 it SHOULD bundle the ERROR chunk containing the
3177 'Unrecognized Parameter' error cause with the COOKIE-ECHO
3178 chunk sent in response to the INIT-ACK chunk. If the
3179 receiver of the INIT-ACK cannot bundle the COOKIE-ECHO chunk
3180 with the ERROR chunk, the ERROR chunk MAY be sent separately
3181 but not before the COOKIE-ACK has been received.
3183 Note: Any time a COOKIE-ECHO is sent in a packet, it MUST be the
3186 2.27.3. Solution Description
3188 The procedure of reporting unrecognized parameters has been described
3194 Stewart, et al. Informational [Page 57]
3196 RFC 4460 SCTP Errata April 2006
3199 2.28. Handling of IP Address Parameters
3201 2.28.1. Description of the Problem
3203 It is not stated clearly in RFC 2960 [5] how an SCTP endpoint that
3204 supports either IPv4 addresses or IPv6 addresses should respond if
3205 IPv4 and IPv6 addresses are presented by the peer in the INIT or
3208 2.28.2. Text Changes to the Document
3211 Old text: (Section 5.1.2)
3214 IMPLEMENTATION NOTE: In the case that the receiver of an INIT ACK
3215 fails to resolve the address parameter due to an unsupported type,
3216 it can abort the initiation process and then attempt a
3217 re-initiation by using a 'Supported Address Types' parameter in
3218 the new INIT to indicate what types of address it prefers.
3221 New text: (Section 5.1.2)
3224 IMPLEMENTATION NOTE: In the case that the receiver of an INIT ACK
3225 fails to resolve the address parameter due to an unsupported type,
3226 it can abort the initiation process and then attempt a re-
3227 initiation by using a 'Supported Address Types' parameter in the
3228 new INIT to indicate what types of address it prefers.
3230 IMPLEMENTATION NOTE: If an SCTP endpoint that only supports either
3231 IPv4 or IPv6 receives IPv4 and IPv6 addresses in an INIT or INIT-
3232 ACK chunk from its peer, it MUST use all the addresses belonging
3233 to the supported address family. The other addresses MAY be
3234 ignored. The endpoint SHOULD NOT respond with any kind of error
3237 2.28.3. Solution Description
3239 The procedure of handling IP address parameters has been described
3250 Stewart, et al. Informational [Page 58]
3252 RFC 4460 SCTP Errata April 2006
3255 2.29. Handling of COOKIE ECHO Chunks When a TCB Exists
3257 2.29.1. Description of the Problem
3259 The description of the behavior in RFC 2960 [5] when a COOKIE ECHO
3260 chunk and a TCB exist could be misunderstood. When a COOKIE ECHO is
3261 received, a TCB exists and the local tag and peer's tag match, it is
3262 stated that the endpoint should enter the ESTABLISHED state if it has
3263 not already done so and send a COOKIE ACK. It was not clear that, in
3264 the case the endpoint has already left the ESTABLISHED state again,
3265 then it should not go back to established. In case D, the endpoint
3266 can only enter state ESTABLISHED from COOKIE-ECHOED because in state
3267 CLOSED it has no TCB and in state COOKIE-WAIT it has a TCB but knows
3268 nothing about the peer's tag, which is requested to match in this
3271 2.29.2. Text Changes to the Document
3274 Old text: (Section 5.2.4)
3276 D) When both local and remote tags match the endpoint should
3277 always enter the ESTABLISHED state, if it has not already
3278 done so. It should stop any init or cookie timers that may
3279 be running and send a COOKIE ACK.
3282 New text: (Section 5.2.4)
3284 D) When both local and remote tags match, the endpoint should
3285 enter the ESTABLISHED state, if it is in the COOKIE-ECHOED
3286 state. It should stop any cookie timer that may
3287 be running and send a COOKIE ACK.
3289 2.29.3. Solution Description
3291 The procedure of handling of COOKIE-ECHO chunks when a TCB exists has
3292 been described clearly.
3294 2.30. The Initial Congestion Window Size
3296 2.30.1. Description of the Problem
3298 RFC 2960 was published with the intention of having the same
3299 congestion control properties as TCP. Since the publication of RFC
3300 2960, TCP's initial congestion window size has been increased via RFC
3301 3390. This same update will be needed for SCTP to keep SCTP's
3302 congestion control properties equivalent to that of TCP.
3306 Stewart, et al. Informational [Page 59]
3308 RFC 4460 SCTP Errata April 2006
3311 2.30.2. Text Changes to the Document
3314 Old text: (Section 7.2.1)
3316 o The initial cwnd before DATA transmission or after a
3317 sufficiently long idle period MUST be <= 2*MTU.
3320 New text: (Section 7.2.1)
3322 o The initial cwnd before DATA transmission or after a
3323 sufficiently long idle period MUST be set to
3324 min(4*MTU, max (2*MTU, 4380 bytes)).
3327 Old text: (Section 7.2.1)
3329 o When the endpoint does not transmit data on a given transport
3330 address, the cwnd of the transport address should be adjusted
3331 to max(cwnd/2, 2*MTU) per RTO.
3334 New text: (Section 7.2.1)
3336 o When the endpoint does not transmit data on a given transport
3337 address, the cwnd of the transport address should be adjusted
3338 to max(cwnd/2, 4*MTU) per RTO.
3341 Old text: (Section 7.2.2)
3343 o Same as in the slow start, when the sender does not transmit
3344 DATA on a given transport address, the cwnd of the transport
3345 address should be adjusted to max(cwnd / 2, 2*MTU) per RTO.
3348 New text: (Section 7.2.2)
3350 o Same as in the slow start, when the sender does not transmit
3351 DATA on a given transport address, the cwnd of the transport
3352 address should be adjusted to max(cwnd / 2, 4*MTU) per RTO.
3362 Stewart, et al. Informational [Page 60]
3364 RFC 4460 SCTP Errata April 2006
3368 Old text: (Section 7.2.3)
3371 7.2.3. Congestion Control
3373 Upon detection of packet losses from SACK (see Section 7.2.4), an
3374 endpoint should do the following:
3376 ssthresh = max(cwnd/2, 2*MTU)
3379 Basically, a packet loss causes cwnd to be cut in half.
3381 When the T3-rtx timer expires on an address, SCTP should perform
3384 ssthresh = max(cwnd/2, 2*MTU)
3388 New text: (Section 7.2.3)
3391 7.2.3 Congestion Control
3393 Upon detection of packet losses from SACK (see Section 7.2.4), An
3394 endpoint should do the following:
3396 ssthresh = max(cwnd/2, 4*MTU)
3399 Basically, a packet loss causes cwnd to be cut in half.
3401 When the T3-rtx timer expires on an address, SCTP should perform
3404 ssthresh = max(cwnd/2, 4*MTU)
3407 2.30.3. Solution Description
3409 The change to SCTP's initial congestion window will allow it to
3410 continue to maintain the same congestion control properties as TCP.
3418 Stewart, et al. Informational [Page 61]
3420 RFC 4460 SCTP Errata April 2006
3423 2.31. Stream Sequence Numbers in Figures
3425 2.31.1. Description of the Problem
3427 In Section 2.24 of this document, it is clarified that the SSN are
3428 initialized with 0. Two figures in RFC 2960 [5] illustrate that they
3474 Stewart, et al. Informational [Page 62]
3476 RFC 4460 SCTP Errata April 2006
3479 2.31.2. Text Changes to the Document
3482 Old text: (Section 7.2.1)
3485 Endpoint A Endpoint Z
3486 {app sets association with Z}
3489 & other info] ------\
3490 (Start T1-init timer) \
3491 (Enter COOKIE-WAIT state) \---> (compose temp TCB and Cookie_Z)
3492 /-- INIT ACK [Veri Tag=Tag_A,
3494 (Cancel T1-init timer) <-----/ Cookie_Z, & other info]
3496 COOKIE ECHO [Cookie_Z] ------\
3497 (Start T1-init timer) \
3498 (Enter COOKIE-ECHOED state) \---> (build TCB enter ESTABLISHED
3502 (Cancel T1-init timer, <-----/
3503 Enter ESTABLISHED state)
3504 {app sends 1st user data; strm 0}
3505 DATA [TSN=initial TSN_A
3506 Strm=0,Seq=1 & user data]--\
3507 (Start T3-rtx timer) \
3509 /----- SACK [TSN Ack=init
3511 (Cancel T3-rtx timer) <------/
3513 {app sends 2 messages;strm 0}
3516 <--/ Strm=0,Seq=1 & user data 1]
3517 SACK [TSN Ack=init TSN_Z, / ---- DATA
3518 Block=0] --------\ / [TSN=init TSN_Z +1,
3519 \/ Strm=0,Seq=2 & user data 2]
3524 Figure 4: INITiation Example
3530 Stewart, et al. Informational [Page 63]
3532 RFC 4460 SCTP Errata April 2006
3536 New text: (Section 7.2.1)
3540 Endpoint A Endpoint Z
3541 {app sets association with Z}
3544 & other info] ------\
3545 (Start T1-init timer) \
3546 (Enter COOKIE-WAIT state) \---> (compose temp TCB and Cookie_Z)
3547 /-- INIT ACK [Veri Tag=Tag_A,
3549 (Cancel T1-init timer) <------/ Cookie_Z, & other info]
3551 COOKIE ECHO [Cookie_Z] ------\
3552 (Start T1-init timer) \
3553 (Enter COOKIE-ECHOED state) \---> (build TCB enter ESTABLISHED
3557 (Cancel T1-init timer, <-----/
3558 Enter ESTABLISHED state)
3559 {app sends 1st user data; strm 0}
3560 DATA [TSN=initial TSN_A
3561 Strm=0,Seq=0 & user data]--\
3562 (Start T3-rtx timer) \
3564 /----- SACK [TSN Ack=init
3566 (Cancel T3-rtx timer) <------/
3568 {app sends 2 messages;strm 0}
3571 <--/ Strm=0,Seq=0 & user data 1]
3572 SACK [TSN Ack=init TSN_Z, /---- DATA
3573 Block=0] --------\ / [TSN=init TSN_Z +1,
3574 \/ Strm=0,Seq=1 & user data 2]
3579 Figure 4: INITiation Example
3586 Stewart, et al. Informational [Page 64]
3588 RFC 4460 SCTP Errata April 2006
3592 Old text: (Section 5.2.4.1)
3595 Endpoint A Endpoint Z
3596 <------------ Association is established---------------------->
3598 <------------------------------------------------------------->
3599 {A crashes and restarts}
3600 {app sets up a association with Z}
3603 & other info] --------\
3604 (Start T1-init timer) \
3605 (Enter COOKIE-WAIT state) \---> (find a existing TCB
3606 compose temp TCB and Cookie_Z
3607 with Tie-Tags to previous
3609 /--- INIT ACK [Veri Tag=Tag_A',
3611 (Cancel T1-init timer) <------/ Cookie_Z[TieTags=
3614 (destroy temp TCB,leave original
3616 COOKIE ECHO [Veri=Tag_Z',
3620 (Start T1-init timer) \
3621 (Enter COOKIE-ECHOED state) \---> (Find existing association,
3622 Tie-Tags match old tags,
3623 Tags do not match i.e.,
3625 Announce Restart to ULP
3626 and reset association).
3628 (Cancel T1-init timer, <------/
3629 Enter ESTABLISHED state)
3630 {app sends 1st user data; strm 0}
3631 DATA [TSN=initial TSN_A
3632 Strm=0,Seq=1 & user data]--\
3633 (Start T3-rtx timer) \
3635 /--- SACK [TSN Ack=init TSN_A,Block=0]
3636 (Cancel T3-rtx timer) <------/
3638 Figure 5: A Restart Example
3642 Stewart, et al. Informational [Page 65]
3644 RFC 4460 SCTP Errata April 2006
3648 New text: (Section 5.2.4.1)
3651 Endpoint A Endpoint Z
3652 <-------------- Association is established---------------------->
3654 <--------------------------------------------------------------->
3655 {A crashes and restarts}
3656 {app sets up a association with Z}
3659 & other info] --------\
3660 (Start T1-init timer) \
3661 (Enter COOKIE-WAIT state) \---> (find a existing TCB
3662 compose temp TCB and Cookie_Z
3663 with Tie-Tags to previous
3665 /--- INIT ACK [Veri Tag=Tag_A',
3667 (Cancel T1-init timer) <------/ Cookie_Z[TieTags=
3670 (destroy temp TCB,leave original
3672 COOKIE ECHO [Veri=Tag_Z',
3676 (Start T1-init timer) \
3677 (Enter COOKIE-ECHOED state) \---> (Find existing association,
3678 Tie-Tags match old tags,
3679 Tags do not match i.e.,
3681 Announce Restart to ULP
3682 and reset association).
3684 (Cancel T1-init timer, <------/
3685 Enter ESTABLISHED state)
3686 {app sends 1st user data; strm 0}
3687 DATA [TSN=initial TSN_A
3688 Strm=0,Seq=0 & user data]--\
3689 (Start T3-rtx timer) \
3691 /--- SACK [TSN Ack=init TSN_A,Block=0]
3692 (Cancel T3-rtx timer) <------/
3694 Figure 5: A Restart Example
3698 Stewart, et al. Informational [Page 66]
3700 RFC 4460 SCTP Errata April 2006
3703 2.31.3. Solution description
3705 Figure 4 and 5 were changed so that the SSN starts with 0 instead of
3708 2.32. Unrecognized Parameters
3710 2.32.1. Description of the Problem
3712 The RFC does not state clearly in Section 3.3.3.1 whether one or
3713 multiple unrecognized parameters are included in the 'Unrecognized
3714 Parameter' parameter.
3716 2.32.2. Text Changes to the Document
3719 Old text: (Section 3.3.3)
3721 Variable Parameters Status Type Value
3722 -------------------------------------------------------------
3723 State Cookie Mandatory 7
3724 IPv4 Address (Note 1) Optional 5
3725 IPv6 Address (Note 1) Optional 6
3726 Unrecognized Parameters Optional 8
3727 Reserved for ECN Capable (Note 2) Optional 32768 (0x8000)
3728 Host Name Address (Note 3) Optional 11
3731 New text: (Section 3.3.3)
3733 Variable Parameters Status Type Value
3734 -------------------------------------------------------------
3735 State Cookie Mandatory 7
3736 IPv4 Address (Note 1) Optional 5
3737 IPv6 Address (Note 1) Optional 6
3738 Unrecognized Parameter Optional 8
3739 Reserved for ECN Capable (Note 2) Optional 32768 (0x8000)
3740 Host Name Address (Note 3) Optional 11
3744 Old text: (Section 3.3.3.1)
3746 Unrecognized Parameters:
3748 Parameter Type Value: 8
3750 Parameter Length: Variable Size.
3754 Stewart, et al. Informational [Page 67]
3756 RFC 4460 SCTP Errata April 2006
3760 This parameter is returned to the originator of the INIT
3761 chunk when the INIT contains an unrecognized parameter
3762 which has a value that indicates that it should be reported
3763 to the sender. This parameter value field will contain
3764 unrecognized parameters copied from the INIT chunk complete
3765 with Parameter Type, Length and Value fields.
3768 New text: (Section 3.3.3.1)
3770 Unrecognized Parameter:
3772 Parameter Type Value: 8
3774 Parameter Length: Variable Size.
3778 This parameter is returned to the originator of the INIT
3779 chunk when the INIT contains an unrecognized parameter
3780 that has a value that indicates that it should be reported
3781 to the sender. This parameter value field will contain the
3782 unrecognized parameter copied from the INIT chunk complete
3783 with Parameter Type, Length, and Value fields.
3785 2.32.3. Solution Description
3787 The new text states clearly that only one unrecognized parameter is
3788 reported per parameter.
3790 2.33. Handling of Unrecognized Parameters
3792 2.33.1. Description of the Problem
3794 It is not stated clearly in RFC 2960 [5] how unrecognized parameters
3795 should be handled. The problem comes up when an INIT contains an
3796 unrecognized parameter with highest bits 00. It was not clear
3797 whether an INIT-ACK should be sent.
3799 2.33.2. Text Changes to the Document
3801 Some of the changes given here already include changes suggested in
3802 Section 2.27 of this document.
3810 Stewart, et al. Informational [Page 68]
3812 RFC 4460 SCTP Errata April 2006
3816 Old text: (Section 3.2.1)
3819 00 - Stop processing this SCTP packet and discard it, do not process
3820 any further chunks within it.
3822 01 - Stop processing this SCTP packet and discard it, do not process
3823 any further chunks within it, and report the unrecognized
3824 parameter in an 'Unrecognized Parameter Type' (in either an
3825 ERROR or in the INIT ACK).
3827 10 - Skip this parameter and continue processing.
3829 11 - Skip this parameter and continue processing but report the
3830 unrecognized parameter in an 'Unrecognized Parameter Type' (in
3831 either an ERROR or in the INIT ACK).
3834 New text: (Section 3.2.1)
3837 00 - Stop processing this parameter; do not process
3838 any further parameters within this chunk.
3840 01 - Stop processing this parameter, do not process
3841 any further parameters within this chunk, and report the
3842 unrecognized parameter in an 'Unrecognized Parameter Type', as
3845 10 - Skip this parameter and continue processing.
3847 11 - Skip this parameter and continue processing but report the
3848 unrecognized parameter in an 'Unrecognized Parameter Type', as
3853 New text: (Note: no old text; clarification added in section 3.2)
3856 3.2.2. Reporting of Unrecognized Parameters
3858 If the receiver of an INIT chunk detects unrecognized parameters and
3859 has to report them according to Section 3.2.1, it MUST put the
3860 'Unrecognized Parameter' parameter(s) in the INIT-ACK chunk sent in
3861 response to the INIT-chunk. Note that if the receiver of the INIT
3862 chunk is NOT going to establish an association (e.g., due to lack of
3866 Stewart, et al. Informational [Page 69]
3868 RFC 4460 SCTP Errata April 2006
3871 resources), an 'Unrecognized Parameter' would NOT be included with
3872 any ABORT being sent to the sender of the INIT.
3874 If the receiver of an INIT-ACK chunk detects unrecognized parameters
3875 and has to report them according to Section 3.2.1, it SHOULD bundle
3876 the ERROR chunk containing the 'Unrecognized Parameter' error cause
3877 with the COOKIE-ECHO chunk sent in response to the INIT-ACK chunk.
3878 If the receiver of the INIT-ACK cannot bundle the COOKIE-ECHO chunk
3879 with the ERROR chunk, the ERROR chunk MAY be sent separately but not
3880 before the COOKIE-ACK has been received.
3882 Note: Any time a COOKIE-ECHO is sent in a packet, it MUST be the
3885 2.33.3. Solution Description
3887 The procedure of handling unrecognized parameters has been described
3892 2.34.1. Description of the Problem
3894 RFC 2960 requires that Tie-Tags be included in the COOKIE. The
3895 cookie may not be encrypted. An attacker could discover the value of
3896 the Verification Tags by analyzing cookies received after sending an
3899 2.34.2. Text Changes to the Document
3902 Old text: (Section 1.4)
3904 o Tie-Tags: Verification Tags from a previous association. These
3905 Tags are used within a State Cookie so that the newly
3906 restarting association can be linked to the original
3907 association within the endpoint that did not restart.
3910 New text: (Section 1.4)
3913 o Tie-Tags: Two 32-bit random numbers that together make a 64-
3914 bit nonce. These Tags are used within a State Cookie and TCB
3915 so that a newly restarting association can be linked to the
3916 original association within the endpoint that did not restart
3917 and yet not reveal the true Verification Tags of an existing
3922 Stewart, et al. Informational [Page 70]
3924 RFC 4460 SCTP Errata April 2006
3928 Old text: (Section 5.2.1)
3931 For an endpoint that is in the COOKIE-ECHOED state it MUST
3932 populate its Tie-Tags with the Tag information of itself and
3933 its peer (see Section 5.2.2 for a description of the Tie-Tags).
3936 New text: (Section 5.2.1)
3938 For an endpoint that is in the COOKIE-ECHOED state it MUST
3939 populate its Tie-Tags within both the association TCB and
3940 inside the State Cookie (see section 5.2.2 for a description
3945 Old text: (Section 5.2.2)
3947 Unless otherwise stated, upon reception of an unexpected INIT for
3948 this association, the endpoint shall generate an INIT ACK with a
3949 State Cookie. In the outbound INIT ACK the endpoint MUST copy its
3950 current Verification Tag and peer's Verification Tag into a
3951 reserved place within the state cookie. We shall refer to these
3952 locations as the Peer's-Tie-Tag and the Local-Tie-Tag. The
3953 outbound SCTP packet containing this INIT ACK MUST carry a
3954 Verification Tag value equal to the Initiation Tag found in the
3955 unexpected INIT. And the INIT ACK MUST contain a new Initiation
3956 Tag (randomly generated see Section 5.3.1). Other parameters
3957 for the endpoint SHOULD be copied from the existing parameters
3958 of the association (e.g., number of outbound streams) into the
3959 INIT ACK and cookie.
3962 New text: (Section 5.2.2)
3965 Unless otherwise stated, upon receipt of an unexpected INIT for
3966 this association, the endpoint MUST generate an INIT ACK with a
3967 State Cookie. In the outbound INIT ACK, the endpoint MUST copy
3968 its current Tie-Tags to a reserved place within the State Cookie
3969 and the association's TCB. We shall refer to these locations
3970 inside the cookie as the Peer's-Tie-Tag and the Local-Tie-Tag. We
3971 will refer to the copy within an association's TCB as the Local
3972 Tag and Peer's Tag. The outbound SCTP packet containing this INIT
3973 ACK MUST carry a Verification Tag value equal to the Initiation
3974 Tag found in the unexpected INIT. And the INIT ACK MUST contain a
3978 Stewart, et al. Informational [Page 71]
3980 RFC 4460 SCTP Errata April 2006
3983 new Initiation Tag (randomly generated; see Section 5.3.1). Other
3984 parameters for the endpoint SHOULD be copied from the existing
3985 parameters of the association (e.g., number of outbound streams)
3986 into the INIT ACK and cookie.
3988 2.34.3. Solution Description
3990 The solution to this problem is not to use the real Verification Tags
3991 within the State Cookie as tie-tags. Instead, two 32-bit random
3992 numbers are created to form one 64-bit nonce and stored both in the
3993 State Cookie and the existing association TCB. This prevents
3994 exposing the Verification Tags inadvertently.
3996 2.35. Port Number Verification in the COOKIE-ECHO
3998 2.35.1. Description of the Problem
4000 The State Cookie sent by a listening SCTP endpoint may not contain
4001 the original port numbers or the local Verification Tag. It is then
4002 possible that the endpoint, on receipt of the COOKIE-ECHO, will not
4003 be able to verify that these values match the original values found
4004 in the INIT and INIT-ACK that began the association setup.
4006 2.35.2. Text Changes to the Document
4009 Old text: (Section 5.1.5)
4011 3) Compare the creation timestamp in the State Cookie to the
4012 current local time. If the elapsed time is longer than the
4013 lifespan carried in the State Cookie, then the packet,
4014 including the COOKIE ECHO and any attached DATA chunks,
4015 SHOULD be discarded and the endpoint MUST transmit an ERROR
4016 chunk with a "Stale Cookie" error cause to the peer endpoint,
4018 4) If the State Cookie is valid, create an association to the
4019 sender of the COOKIE ECHO chunk with the information in the
4020 TCB data carried in the COOKIE ECHO, and enter the
4023 5) Send a COOKIE ACK chunk to the peer acknowledging reception
4024 of the COOKIE ECHO. The COOKIE ACK MAY be bundled with an
4025 outbound DATA chunk or SACK chunk; however, the COOKIE ACK
4026 MUST be the first chunk in the SCTP packet.
4028 6) Immediately acknowledge any DATA chunk bundled with the COOKIE
4029 ECHO with a SACK (subsequent DATA chunk acknowledgement should
4030 follow the rules defined in Section 6.2). As mentioned in step
4034 Stewart, et al. Informational [Page 72]
4036 RFC 4460 SCTP Errata April 2006
4039 5), if the SACK is bundled with the COOKIE ACK, the COOKIE ACK
4040 MUST appear first in the SCTP packet.
4043 New text: (Section 5.1.5)
4046 3) Compare the port numbers and the Verification Tag contained
4047 within the COOKIE ECHO chunk to the actual port numbers and the
4048 Verification Tag within the SCTP common header of the received
4049 packet. If these values do not match, the packet MUST be
4052 4) Compare the creation timestamp in the State Cookie to the
4053 current local time. If the elapsed time is longer than the
4054 lifespan carried in the State Cookie, then the packet,
4055 including the COOKIE ECHO and any attached DATA chunks,
4056 SHOULD be discarded, and the endpoint MUST transmit an
4057 ERROR chunk with a "Stale Cookie" error cause to the peer
4060 5) If the State Cookie is valid, create an association to the
4061 sender of the COOKIE ECHO chunk with the information in the
4062 TCB data carried in the COOKIE ECHO and enter the
4065 6) Send a COOKIE ACK chunk to the peer acknowledging receipt of
4066 the COOKIE ECHO. The COOKIE ACK MAY be bundled with an
4067 outbound DATA chunk or SACK chunk; however, the COOKIE ACK
4068 MUST be the first chunk in the SCTP packet.
4070 7) Immediately acknowledge any DATA chunk bundled with the COOKIE
4071 ECHO with a SACK (subsequent DATA chunk acknowledgement should
4072 follow the rules defined in Section 6.2). As mentioned in step
4073 5, if the SACK is bundled with the COOKIE ACK, the COOKIE ACK
4074 MUST appear first in the SCTP packet.
4076 2.35.3. Solution Description
4078 By including both port numbers and the local Verification Tag within
4079 the State Cookie and verifying these during COOKIE-ECHO processing,
4080 this issue is resolved.
4090 Stewart, et al. Informational [Page 73]
4092 RFC 4460 SCTP Errata April 2006
4095 2.36. Path Initialization
4097 2.36.1. Description of the Problem
4099 When an association enters the ESTABLISHED state, the endpoint has no
4100 verification that all of the addresses presented by the peer do in
4101 fact belong to the peer. This could cause various forms of denial of
4104 2.36.2. Text Changes to the Document
4111 New text: (Section 5.4)
4113 5.4. Path Verification
4115 During association establishment, the two peers exchange a list of
4116 addresses. In the predominant case, these lists accurately represent
4117 the addresses owned by each peer. However, it is possible that a
4118 misbehaving peer may supply addresses that it does not own. To
4119 prevent this, the following rules are applied to all addresses of the
4122 1) Any address passed to the sender of the INIT by its upper layer is
4123 automatically considered to be CONFIRMED.
4125 2) For the receiver of the COOKIE-ECHO the only CONFIRMED address is
4126 the one that the INIT-ACK was sent to.
4128 3) All other addresses not covered by rules 1 and 2 are considered
4129 UNCONFIRMED and are subject to probing for verification.
4131 To probe an address for verification, an endpoint will send
4132 HEARTBEATs including a 64-bit random nonce and a path indicator (to
4133 identify the address that the HEARTBEAT is sent to) within the
4134 HEARTBEAT parameter.
4136 Upon receipt of the HEARTBEAT-ACK, a verification is made that the
4137 nonce included in the HEARTBEAT parameter is the one sent to the
4138 address indicated inside the HEARTBEAT parameter. When this match
4139 occurs, the address that the original HEARTBEAT was sent to is now
4140 considered CONFIRMED and available for normal data transfer.
4146 Stewart, et al. Informational [Page 74]
4148 RFC 4460 SCTP Errata April 2006
4151 These probing procedures are started when an association moves to the
4152 ESTABLISHED state and are ended when all paths are confirmed.
4154 Each RTO a probe may be sent on an active UNCONFIRMED path in an
4155 attempt to move it to the CONFIRMED state. If during this probing
4156 the path becomes inactive, this rate is lowered to the normal
4157 HEARTBEAT rate. At the expiration of the RTO timer, the error
4158 counter of any path that was probed but not CONFIRMED is incremented
4159 by one and subjected to path failure detection, as defined in section
4160 8.2. When probing UNCONFIRMED addresses, however, the association
4161 overall error count is NOT incremented.
4163 The number of HEARTBEATS sent at each RTO SHOULD be limited by the
4164 HB.Max.Burst parameter. It is an implementation decision as to how
4165 to distribute HEARTBEATS to the peer's addresses for path
4168 Whenever a path is confirmed, an indication MAY be given to the upper
4171 An endpoint MUST NOT send any chunks to an UNCONFIRMED address, with
4172 the following exceptions:
4174 - A HEARTBEAT including a nonce MAY be sent to an UNCONFIRMED
4177 - A HEARTBEAT-ACK MAY be sent to an UNCONFIRMED address.
4179 - A COOKIE-ACK MAY be sent to an UNCONFIRMED address, but it MUST be
4180 bundled with a HEARTBEAT including a nonce. An implementation that
4181 does NOT support bundling MUST NOT send a COOKIE-ACK to an
4182 UNCONFIRMED address.
4184 - A COOKE-ECHO MAY be sent to an UNCONFIRMED address, but it MUST be
4185 bundled with a HEARTBEAT including a nonce, and the packet MUST NOT
4186 exceed the path MTU. If the implementation does NOT support
4187 bundling or if the bundled COOKIE-ECHO plus HEARTBEAT (including
4188 nonce) would exceed the path MTU, then the implementation MUST NOT
4189 send a COOKIE-ECHO to an UNCONFIRMED address.
4192 Old text: (Section 14)
4195 14. Suggested SCTP Protocol Parameter Values
4197 The following protocol parameters are RECOMMENDED:
4202 Stewart, et al. Informational [Page 75]
4204 RFC 4460 SCTP Errata April 2006
4207 RTO.Initial - 3 seconds
4209 RTO.Max - 60 seconds
4212 Valid.Cookie.Life - 60 seconds
4213 Association.Max.Retrans - 10 attempts
4214 Path.Max.Retrans - 5 attempts (per destination address)
4215 Max.Init.Retransmits - 8 attempts
4216 HB.interval - 30 seconds
4219 New text: (Section 14)
4222 14. Suggested SCTP Protocol Parameter Values
4224 The following protocol parameters are RECOMMENDED:
4226 RTO.Initial - 3 seconds
4228 RTO.Max - 60 seconds
4232 Valid.Cookie.Life - 60 seconds
4233 Association.Max.Retrans - 10 attempts
4234 Path.Max.Retrans - 5 attempts (per destination address)
4235 Max.Init.Retransmits - 8 attempts
4236 HB.Interval - 30 seconds
4239 2.36.3. Solution Description
4241 By properly setting up initial path state and accelerated probing via
4242 HEARTBEAT's, a new association can verify that all addresses
4243 presented by a peer belong to that peer.
4245 2.37. ICMP Handling Procedures
4247 2.37.1. Description of the Problem
4249 RFC 2960 does not describe how ICMP messages should be processed by
4258 Stewart, et al. Informational [Page 76]
4260 RFC 4460 SCTP Errata April 2006
4263 2.37.2. Text Changes to the Document
4273 11.5. Protection of Non-SCTP Capable Hosts.
4275 To provide a non-SCTP capable host with the same level of protection
4276 against attacks as for SCTP-capable ones, all SCTP stacks MUST
4277 implement the ICMP handling described in Appendix C.
4279 When an SCTP stack receives a packet containing multiple control or
4280 DATA chunks and the processing of the packet requires the sending of
4281 multiple chunks in response, the sender of the response chunk(s) MUST
4282 NOT send more than one packet. If bundling is supported, multiple
4283 response chunks that fit into a single packet MAY be bundled together
4284 into one single response packet. If bundling is not supported, then
4285 the sender MUST NOT send more than one response chunk and MUST
4286 discard all other responses. Note that this rule does NOT apply to a
4287 SACK chunk, since a SACK chunk is, in itself, a response to DATA and
4288 a SACK does not require a response of more DATA.
4290 An SCTP implementation SHOULD abort the association if it receives a
4291 SACK acknowledging a TSN that has not been sent.
4293 An SCTP implementation that receives an INIT that would require a
4294 large packet in response, due to the inclusion of multiple ERROR
4295 parameters, MAY (at its discretion) elect to omit some or all of the
4296 ERROR parameters to reduce the size of the INIT-ACK. Due to a
4297 combination of the size of the COOKIE parameter and the number of
4298 addresses a receiver of an INIT may be indicating to a peer, it is
4299 always possible that the INIT-ACK will be larger than the original
4300 INIT. An SCTP implementation SHOULD attempt to make the INIT-ACK as
4301 small as possible to reduce the possibility of byte amplification
4314 Stewart, et al. Informational [Page 77]
4316 RFC 4460 SCTP Errata April 2006
4320 New text: (Appendix C)
4323 Appendix C ICMP Handling
4325 Whenever an ICMP message is received by an SCTP endpoint the
4326 following procedures MUST be followed to ensure proper utilization of
4327 the information being provided by layer 3.
4329 ICMP1) An implementation MAY ignore all ICMPv4 messages where the
4330 type field is not set to "Destination Unreachable".
4332 ICMP2) An implementation MAY ignore all ICMPv6 messages where the
4333 type field is not "Destination Unreachable, "Parameter
4334 Problem" or "Packet Too Big".
4336 ICMP3) An implementation MAY ignore any ICMPv4 messages where the
4337 code does not indicate "Protocol Unreachable" or
4338 "Fragmentation Needed".
4340 ICMP4) An implementation MAY ignore all ICMPv6 messages of type
4341 "Parameter Problem" if the code is not "Unrecognized next
4342 header type encountered".
4344 ICMP5) An implementation MUST use the payload of the ICMP message (V4
4345 or V6) to locate the association that sent the message that
4346 ICMP is responding to. If the association cannot be found, an
4347 implementation SHOULD ignore the ICMP message.
4349 ICMP6) An implementation MUST validate that the Verification Tag
4350 contained in the ICMP message matches the verification tag of
4351 the peer. If the Verification Tag is not 0 and does NOT
4352 match, discard the ICMP message. If it is 0 and the ICMP
4353 message contains enough bytes to verify that the chunk type is
4354 an INIT chunk and that the initiate tag matches the tag of the
4355 peer, continue with ICMP7. If the ICMP message is too short
4356 or the chunk type or the initiate tag does not match, silently
4359 ICMP7) If the ICMP message is either a V6 "Packet Too Big" or a V4
4360 "Fragmentation Needed", an implementation MAY process this
4361 information as defined for PATH MTU discovery.
4363 ICMP8) If the ICMP code is a "Unrecognized next header type
4364 encountered" or a "Protocol Unreachable", an implementation
4365 MUST treat this message as an abort with the T bit set if it
4366 does not contain an INIT chunk. If it does contain an INIT
4370 Stewart, et al. Informational [Page 78]
4372 RFC 4460 SCTP Errata April 2006
4375 chunk and the association is in COOKIE-WAIT state, handle the
4376 ICMP message like an ABORT.
4378 ICMP9) If the ICMPv6 code is "Destination Unreachable", the
4379 implementation MAY mark the destination into the unreachable
4380 state or alternatively increment the path error counter.
4382 Note that these procedures differ from RFC 1122 [1] and from its
4383 requirements for processing of port-unreachable messages and the
4384 requirements that an implementation MUST abort associations in
4385 response to a "protocol unreachable" message. Port unreachable
4386 messages are not processed, since an implementation will send an
4387 ABORT, not a port unreachable. The stricter handling of the
4388 "protocol unreachable" message is due to security concerns for hosts
4389 that do NOT support SCTP.
4391 2.37.3. Solution Description
4393 The new appendix now describes proper handling of ICMP messages in
4394 conjunction with SCTP.
4398 2.38.1. Description of the problem
4400 RFC 3309 [6] changes the SCTP checksum due to weaknesses in the
4401 original Adler 32 checksum for small messages. This document, being
4402 used as a guide for a cut and paste replacement to update RFC 2960,
4403 thus also needs to incorporate the checksum changes. The idea is
4404 that one could apply all changes found in this guide to a copy of RFC
4405 2960 and have a "new" document that has ALL changes (including RFC
4408 2.38.2. Text Changes to the Document
4414 6.8 Adler-32 Checksum Calculation
4416 When sending an SCTP packet, the endpoint MUST strengthen the data
4417 integrity of the transmission by including the Adler-32 checksum
4418 value calculated on the packet, as described below.
4420 After the packet is constructed (containing the SCTP common header
4421 and one or more control or DATA chunks), the transmitter shall:
4426 Stewart, et al. Informational [Page 79]
4428 RFC 4460 SCTP Errata April 2006
4431 1) Fill in the proper Verification Tag in the SCTP common header
4432 and initialize the checksum field to 0's.
4434 2) Calculate the Adler-32 checksum of the whole packet, including
4435 the SCTP common header and all the chunks. Refer to
4436 appendix B for details of the Adler-32 algorithm. And,
4438 3) Put the resultant value into the checksum field in the common
4439 header, and leave the rest of the bits unchanged.
4441 When an SCTP packet is received, the receiver MUST first check the
4444 1) Store the received Adler-32 checksum value aside,
4446 2) Replace the 32 bits of the checksum field in the received SCTP
4447 packet with all '0's and calculate an Adler-32 checksum value
4448 of the whole received packet. And,
4450 3) Verify that the calculated Adler-32 checksum is the same as the
4451 received Adler-32 checksum. If not, the receiver MUST treat
4452 the packet as an invalid SCTP packet.
4454 The default procedure for handling invalid SCTP packets is to
4455 silently discard them.
4461 6.8 CRC-32c Checksum Calculation
4463 When sending an SCTP packet, the endpoint MUST strengthen the data
4464 integrity of the transmission by including the CRC32c checksum
4465 value calculated on the packet, as described below.
4467 After the packet is constructed (containing the SCTP common header
4468 and one or more control or DATA chunks), the transmitter MUST
4470 1) fill in the proper Verification Tag in the SCTP common header
4471 and initialize the checksum field to '0's,
4473 2) calculate the CRC32c checksum of the whole packet, including
4474 the SCTP common header and all the chunks (refer to
4475 appendix B for details of the CRC32c algorithm); and
4477 3) put the resultant value into the checksum field in the common
4478 header, and leave the rest of the bits unchanged.
4482 Stewart, et al. Informational [Page 80]
4484 RFC 4460 SCTP Errata April 2006
4487 When an SCTP packet is received, the receiver MUST first check the
4488 CRC32c checksum as follows:
4490 1) Store the received CRC32c checksum value aside.
4492 2) Replace the 32 bits of the checksum field in the received SCTP
4493 packet with all '0's and calculate a CRC32c checksum value of
4494 the whole received packet.
4496 3) Verify that the calculated CRC32c checksum is the same as the
4497 received CRC32c checksum. If it is not, the receiver MUST
4498 treat the packet as an invalid SCTP packet.
4500 The default procedure for handling invalid SCTP packets is to
4501 silently discard them.
4503 Any hardware implementation SHOULD be done in a way that is
4504 verifiable by the software.
4511 Appendix B Alder 32 bit checksum calculation
4513 The Adler-32 checksum calculation given in this appendix is
4514 copied from [RFC1950].
4516 Adler-32 is composed of two sums accumulated per byte: s1 is the
4517 sum of all bytes, s2 is the sum of all s1 values. Both sums are
4518 done modulo 65521. s1 is initialized to 1, s2 to zero. The
4519 Adler-32 checksum is stored as s2*65536 + s1 in network byte
4522 The following C code computes the Adler-32 checksum of a data
4523 buffer. It is written for clarity, not for speed. The sample
4524 code is in the ANSI C programming language. Non C users may
4525 find it easier to read with these hints:
4527 & Bitwise AND operator.
4528 >> Bitwise right shift operator. When applied to an
4529 unsigned quantity, as here, right shift inserts zero bit(s)
4531 << Bitwise left shift operator. Left shift inserts zero
4532 bit(s) at the right.
4533 ++ "n++" increments the variable n.
4534 % modulo operator: a % b is the remainder of a divided by b.
4538 Stewart, et al. Informational [Page 81]
4540 RFC 4460 SCTP Errata April 2006
4543 #define BASE 65521 /* largest prime smaller than 65536 */
4545 Update a running Adler-32 checksum with the bytes buf[0..len-1]
4546 and return the updated checksum. The Adler-32 checksum should
4547 be initialized to 1.
4551 unsigned long adler = 1L;
4553 while (read_buffer(buffer, length) != EOF) {
4554 adler = update_adler32(adler, buffer, length);
4556 if (adler != original_adler) error();
4558 unsigned long update_adler32(unsigned long adler,
4559 unsigned char *buf, int len)
4561 unsigned long s1 = adler & 0xffff;
4562 unsigned long s2 = (adler >> 16) & 0xffff;
4565 for (n = 0; n < len; n++) {
4566 s1 = (s1 + buf[n]) % BASE;
4567 s2 = (s2 + s1) % BASE;
4569 return (s2 << 16) + s1;
4572 /* Return the adler32 of the bytes buf[0..len-1] */
4573 unsigned long adler32(unsigned char *buf, int len)
4575 return update_adler32(1L, buf, len);
4582 Appendix B CRC32c Checksum Calculation
4584 We define a 'reflected value' as one that is the opposite of the
4585 normal bit order of the machine. The 32-bit CRC is calculated as
4586 described for CRC-32c and uses the polynomial code 0x11EDC6F41
4587 (Castagnoli93) or x^32+x^28+x^27+x^26+x^25
4588 +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.
4589 The CRC is computed using a procedure similar to ETHERNET CRC
4590 [ITU32], modified to reflect transport level usage.
4594 Stewart, et al. Informational [Page 82]
4596 RFC 4460 SCTP Errata April 2006
4599 CRC computation uses polynomial division. A message
4600 bit-string M is transformed to a polynomial, M(X), and the CRC
4601 is calculated from M(X) using polynomial arithmetic [PETERSON 72].
4603 When CRCs are used at the link layer, the polynomial is derived
4604 from on-the-wire bit ordering: the first bit 'on the wire' is the
4605 high-order coefficient. Since SCTP is a transport-level protocol,
4606 it cannot know the actual serial-media bit ordering. Moreover,
4607 different links in the path between SCTP endpoints may use
4608 different link-level bit orders.
4610 A convention must therefore be established for mapping SCTP
4611 transport messages to polynomials for purposes of CRC computation.
4612 The bit-ordering for mapping SCTP messages to polynomials is that
4613 bytes are taken most-significant first; but within each byte, bits
4614 are taken least-significant first. The first byte of the message
4615 provides the eight highest coefficients. Within each byte,
4616 the least-significant SCTP bit gives the most significant
4617 polynomial coefficient within that byte, and the most-significant
4618 SCTP bit is the least significant polynomial coefficient in that
4619 byte. (This bit ordering is sometimes called 'mirrored' or
4620 'reflected' [WILLIAMS93].) CRC polynomials are to be transformed
4621 back into SCTP transport-level byte values, using a consistent
4624 The SCTP transport-level CRC value should be calculated as
4627 - CRC input data are assigned to a byte stream, numbered from
4630 - The transport-level byte-stream is mapped to a polynomial
4631 value. An N-byte PDU with j bytes numbered 0 to N-1 is
4632 considered as coefficients of a polynomial M(x) of order
4633 8N-1, with bit 0 of byte j being coefficient x^(8(N-j)-8),
4634 and bit 7 of byte j being coefficient x^(8(N-j)-1).
4636 - The CRC remainder register is initialized with all 1s and
4637 the CRC is computed with an algorithm that simultaneously
4638 multiplies by x^32 and divides by the CRC polynomial.
4640 - The polynomial is multiplied by x^32 and divided by G(x),
4641 the generator polynomial, producing a remainder R(x) of
4642 degree less than or equal to 31.
4644 - The coefficients of R(x) are considered a 32-bit sequence.
4650 Stewart, et al. Informational [Page 83]
4652 RFC 4460 SCTP Errata April 2006
4655 - The bit sequence is complemented. The result is the CRC
4658 - The CRC polynomial is mapped back into SCTP transport-level
4659 bytes. The coefficient of x^31 gives the value of bit 7 of
4660 SCTP byte 0, and the coefficient of x^24 gives the value of
4661 bit 0 of byte 0. The coefficient of x^7 gives bit 7 of
4662 byte 3, and the coefficient of x^0 gives bit 0 of byte 3.
4663 The resulting four-byte transport-level sequence is the
4664 32-bit SCTP checksum value.
4666 IMPLEMENTATION NOTE: Standards documents, textbooks, and vendor
4667 literature on CRCs often follow an alternative formulation, in
4668 which the register used to hold the remainder of the
4669 long-division algorithm is initialized to zero rather than
4670 all-1s, and instead the first 32 bits of the message are
4671 complemented. The long-division algorithm used in our
4672 formulation is specified such that the initial
4673 multiplication by 2^32 and the long-division are combined into
4674 one simultaneous operation. For such algorithms, and for
4675 messages longer than 64 bits, the two specifications are
4676 precisely equivalent. That equivalence is the intent of
4679 Implementors of SCTP are warned that both specifications are to be
4680 found in the literature, sometimes with no restriction on the
4681 long-division algorithm. The choice of formulation in this
4682 document is to permit non-SCTP usage, where the same CRC
4683 algorithm may be used to protect messages shorter than 64 bits.
4685 There may be a computational advantage in validating the
4686 Association against the Verification Tag, prior to performing a
4687 checksum, as invalid tags will result in the same action as a bad
4688 checksum in most cases. The exceptions for this technique would
4689 be INIT and some SHUTDOWN-COMPLETE exchanges, as well as a stale
4690 COOKIE-ECHO. These special case exchanges must represent small
4691 packets and will minimize the effect of the checksum calculation.
4695 Old text: (Section 18)
4700 [ALLMAN99] Allman, M. and Paxson, V., "On Estimating End-to-End
4701 Network Path Properties", Proc. SIGCOMM'99, 1999.
4706 Stewart, et al. Informational [Page 84]
4708 RFC 4460 SCTP Errata April 2006
4711 [FALL96] Fall, K. and Floyd, S., Simulation-based Comparisons of
4712 Tahoe, Reno, and SACK TCP, Computer Communications Review,
4713 V. 26 N. 3, July 1996, pp. 5-21.
4715 [RFC1750] Eastlake, D. (ed.), "Randomness Recommendations for
4716 Security", RFC 1750, December 1994.
4718 [RFC1950] Deutsch P. and J. Gailly, "ZLIB Compressed Data Format
4719 Specification version 3.3", RFC 1950, May 1996.
4721 [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-
4722 Hashing for Message Authentication", RFC 2104, March 1997.
4724 [RFC2196] Fraser, B., "Site Security Handbook", FYI 8, RFC 2196,
4727 [RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management
4728 Protocol", RFC 2522, March 1999.
4730 [SAVAGE99] Savage, S., Cardwell, N., Wetherall, D., and Anderson, T.,
4731 "TCP Congestion Control with a Misbehaving Receiver", ACM
4732 Computer Communication Review, 29(5), October 1999.
4735 New text: (Section 18, including changes from 2.11)
4740 [ALLMAN99] Allman, M. and Paxson, V., "On Estimating End-to-End
4741 Network Path Properties", Proc. SIGCOMM'99, 1999.
4743 [FALL96] Fall, K. and Floyd, S., Simulation-based Comparisons of
4744 Tahoe, Reno, and SACK TCP, Computer Communications Review,
4745 V. 26 N. 3, July 1996, pp. 5-21.
4747 [ITU32] ITU-T Recommendation V.42, "Error-correcting
4748 procedures for DCEs using asynchronous-to-synchronous
4749 conversion", Section 8.1.1.6.2, October 1996.
4751 [PETERSON 1972] W. W. Peterson and E.J Weldon, Error Correcting
4752 Codes, 2nd Edition, MIT Press, Cambridge,
4755 [RFC1750] Eastlake, D., Ed., "Randomness Recommendations for
4756 Security", RFC 1750, December 1994.
4762 Stewart, et al. Informational [Page 85]
4764 RFC 4460 SCTP Errata April 2006
4767 [RFC1858] Ziemba, G., Reed, D. and Traina P., "Security
4768 Considerations for IP Fragment Filtering", RFC 1858,
4771 [RFC1950] Deutsch P. and J. Gailly, "ZLIB Compressed Data Format
4772 Specification version 3.3", RFC 1950, May 1996.
4774 [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-
4775 Hashing for Message Authentication", RFC 2104, March 1997.
4777 [RFC2196] Fraser, B., "Site Security Handbook", FYI 8, RFC 2196,
4780 [RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management
4781 Protocol", RFC 2522, March 1999.
4783 [SAVAGE99] Savage, S., Cardwell, N., Wetherall, D., and Anderson, T.,
4784 "TCP Congestion Control with a Misbehaving Receiver", ACM
4785 Computer Communication Review, 29(5), October 1999.
4787 [WILLIAMS93] Williams, R., "A PAINLESS GUIDE TO CRC ERROR
4788 DETECTION ALGORITHMS" - Internet publication, August
4790 http://www.geocities.com/SiliconValley/Pines/
4793 2.38.3. Solution Description
4795 This change adds to the implementor's guide the complete set of
4796 changes that, when combined with RFC 2960 [5], encompasses the
4797 changes from RFC 3309 [6].
4799 2.39. Retransmission Policy
4801 2.39.1. Description of the Problem
4803 The current retransmission policy (send all retransmissions an
4804 alternate destination) in the specification has performance issues
4805 under certain loss conditions with multihomed endpoints. Instead,
4806 fast retransmissions should be sent to the same destination, and only
4807 timeout retransmissions should be sent to an alternate destination
4818 Stewart, et al. Informational [Page 86]
4820 RFC 4460 SCTP Errata April 2006
4823 2.39.2. Text Changes to the Document
4826 Old text: (Section 6.4)
4829 Furthermore, when its peer is multi-homed, an endpoint SHOULD try to
4830 retransmit a chunk to an active destination transport address that is
4831 different from the last destination address to which the DATA chunk
4835 New text: (Section 6.4)
4838 Furthermore, when its peer is multi-homed, an endpoint SHOULD try to
4839 retransmit a chunk that timed out to an active destination transport
4840 address that is different from the last destination address to which
4841 the DATA chunk was sent.
4844 Old text: (Section 6.4.1)
4847 When retransmitting data, if the endpoint is multi-homed, it should
4848 consider each source-destination address pair in its retransmission
4849 selection policy. When retransmitting the endpoint should attempt to
4850 pick the most divergent source-destination pair from the original
4851 source-destination pair to which the packet was transmitted.
4854 New text: (Section 6.4.1)
4857 When retransmitting data that timed out, if the endpoint is
4858 multi-homed, it should consider each source-destination address
4859 pair in its retransmission selection policy. When retransmitting
4860 timed out data, the endpoint should attempt to pick the most
4861 divergent source-destination pair from the original
4862 source-destination pair to which the packet was transmitted.
4864 2.39.3. Solution Description
4866 The above wording changes clarify that only timeout retransmissions
4867 should be sent to an alternate active destination.
4874 Stewart, et al. Informational [Page 87]
4876 RFC 4460 SCTP Errata April 2006
4881 2.40.1. Description of the Problem
4883 The port number 0 has a special semantic in various APIs. For
4884 example, in the socket API, if the user specifies 0, the SCTP
4885 implementation chooses an appropriate port number for the user.
4886 Therefore, the port number 0 should not be used on the wire.
4888 2.40.2. Text Changes to the Document
4891 Old text: (Section 3.1)
4894 Source Port Number: 16 bits (unsigned integer)
4896 This is the SCTP sender's port number. It can be used by the
4897 receiver in combination with the source IP address, the SCTP
4898 destination port, and possibly the destination IP address to
4899 identify the association to which this packet belongs.
4901 Destination Port Number: 16 bits (unsigned integer)
4903 This is the SCTP port number to which this packet is destined.
4904 The receiving host will use this port number to de-multiplex
4905 the SCTP packet to the correct receiving endpoint/application.
4908 New text: (Section 3.1)
4911 Source Port Number: 16 bits (unsigned integer)
4913 This is the SCTP sender's port number. It can be used by the
4914 receiver in combination with the source IP address, the SCTP
4915 destination port and possibly the destination IP address to
4916 identify the association to which this packet belongs.
4917 The port number 0 MUST NOT be used.
4919 Destination Port Number: 16 bits (unsigned integer)
4921 This is the SCTP port number to which this packet is destined.
4922 The receiving host will use this port number to de-multiplex
4923 the SCTP packet to the correct receiving endpoint/application.
4924 The port number 0 MUST NOT be used.
4930 Stewart, et al. Informational [Page 88]
4932 RFC 4460 SCTP Errata April 2006
4935 2.40.3. Solution Description
4937 It is clearly stated that the port number 0 is an invalid value on
4942 2.41.1. Description of the Problem
4944 The description of the T bit as the bit describing whether a TCB has
4945 been destroyed is misleading. In addition, the procedure described
4946 in Section 2.13 is not as precise as needed.
4948 2.41.2. Text Changes to the Document
4951 Old text: (Section 3.3.7)
4955 The T bit is set to 0 if the sender had a TCB that it
4956 destroyed. If the sender did not have a TCB it should set
4960 New text: (Section 3.3.7)
4964 The T bit is set to 0 if the sender filled in the
4965 Verification Tag expected by the peer. If the Verification
4966 Tag is reflected, the T bit MUST be set to 1. Reflecting means
4967 that the sent Verification Tag is the same as the received
4972 Old text: (Section 3.3.13)
4976 The T bit is set to 0 if the sender had a TCB that it
4977 destroyed. If the sender did not have a TCB it should set
4986 Stewart, et al. Informational [Page 89]
4988 RFC 4460 SCTP Errata April 2006
4992 New text: (Section 3.3.13)
4996 The T bit is set to 0 if the sender filled in the
4997 Verification Tag expected by the peer. If the Verification
4998 Tag is reflected, the T bit MUST be set to 1. Reflecting means
4999 that the sent Verification Tag is the same as the received
5004 Old text: (Section 8.4)
5007 3) If the packet contains an INIT chunk with a Verification Tag
5008 set to '0', process it as described in Section 5.1.
5012 New text: (Section 8.4)
5014 3) If the packet contains an INIT chunk with a Verification Tag
5015 set to '0', process it as described in Section 5.1. If, for
5016 whatever reason, the INIT cannot be processed normally and
5017 an ABORT has to be sent in response, the Verification Tag of
5018 the packet containing the ABORT chunk MUST be the Initiate
5019 tag of the received INIT chunk, and the T-Bit of the ABORT
5020 chunk has to be set to 0, indicating that the Verification
5021 Tag is NOT reflected.
5025 Old text: (Section 8.4)
5027 5) If the packet contains a SHUTDOWN ACK chunk, the receiver
5028 should respond to the sender of the OOTB packet with a
5029 SHUTDOWN COMPLETE. When sending the SHUTDOWN COMPLETE, the
5030 receiver of the OOTB packet must fill in the Verification
5031 Tag field of the outbound packet with the Verification Tag
5032 received in the SHUTDOWN ACK and set the T-bit in the Chunk
5033 Flags to indicate that no TCB was found. Otherwise,
5042 Stewart, et al. Informational [Page 90]
5044 RFC 4460 SCTP Errata April 2006
5048 New text: (Section 8.4)
5051 5) If the packet contains a SHUTDOWN ACK chunk, the receiver
5052 should respond to the sender of the OOTB packet with a
5053 SHUTDOWN COMPLETE. When sending the SHUTDOWN COMPLETE, the
5054 receiver of the OOTB packet must fill in the Verification
5055 Tag field of the outbound packet with the Verification Tag
5056 received in the SHUTDOWN ACK and set the T-bit in the
5057 Chunk Flags to indicate that the Verification Tag is
5058 reflected. Otherwise,
5062 Old text: (Section 8.4)
5065 8) The receiver should respond to the sender of the OOTB packet
5066 with an ABORT. When sending the ABORT, the receiver of the
5067 OOTB packet MUST fill in the Verification Tag field of the
5068 outbound packet with the value found in the Verification
5069 Tag field of the OOTB packet and set the T-bit in the Chunk
5070 Flags to indicate that no TCB was found. After sending this
5071 ABORT, the receiver of the OOTB packet shall discard the
5072 OOTB packet and take no further action.
5075 New text: (Section 8.4)
5078 8) The receiver should respond to the sender of the OOTB packet
5079 with an ABORT. When sending the ABORT, the receiver of the
5080 OOTB packet MUST fill in the Verification Tag field of the
5081 outbound packet with the value found in the Verification Tag
5082 field of the OOTB packet and set the T-bit in the Chunk Flags
5083 to indicate that the Verification Tag is reflected. After
5084 sending this ABORT, the receiver of the OOTB packet shall
5085 discard the OOTB packet and take no further action.
5089 Old text: (Section 8.5.1)
5092 B) Rules for packet carrying ABORT:
5098 Stewart, et al. Informational [Page 91]
5100 RFC 4460 SCTP Errata April 2006
5103 - The endpoint shall always fill in the Verification Tag
5104 field of the outbound packet with the destination
5105 endpoint's tag value if it is known.
5107 - If the ABORT is sent in response to an OOTB packet, the
5108 endpoint MUST follow the procedure described in
5111 - The receiver MUST accept the packet if the Verification
5112 Tag matches either its own tag, OR the tag of its peer.
5113 Otherwise, the receiver MUST silently discard the packet
5114 and take no further action.
5117 New text: (Section 8.5.1)
5120 B) Rules for packet carrying ABORT:
5122 - The endpoint MUST always fill in the Verification Tag
5123 field of the outbound packet with the destination
5124 endpoint's tag value, if it is known.
5126 - If the ABORT is sent in response to an OOTB packet, the
5127 endpoint MUST follow the procedure described in
5130 - The receiver of an ABORT MUST accept the packet
5131 if the Verification Tag field of the packet matches its
5132 own tag and the T bit is not set
5134 if it is set to its peer's tag and the T bit is set in
5136 Otherwise, the receiver MUST silently discard the packet
5137 and take no further action.
5141 Old text: (Section 8.5.1)
5144 C) Rules for packet carrying SHUTDOWN COMPLETE:
5146 - When sending a SHUTDOWN COMPLETE, if the receiver of the
5147 SHUTDOWN ACK has a TCB then the destination endpoint's
5148 tag MUST be used. Only where no TCB exists should the
5149 sender use the Verification Tag from the SHUTDOWN ACK.
5154 Stewart, et al. Informational [Page 92]
5156 RFC 4460 SCTP Errata April 2006
5159 - The receiver of a SHUTDOWN COMPLETE shall accept the
5160 packet if the Verification Tag field of the packet matches
5161 its own tag OR it is set to its peer's tag and the T bit
5162 is set in the Chunk Flags. Otherwise, the receiver MUST
5163 silently discard the packet and take no further action.
5164 An endpoint MUST ignore the SHUTDOWN COMPLETE if it is
5165 not in the SHUTDOWN-ACK-SENT state.
5168 New text: (Section 8.5.1)
5171 C) Rules for packet carrying SHUTDOWN COMPLETE:
5173 - When sending a SHUTDOWN COMPLETE, if the receiver of the
5174 SHUTDOWN ACK has a TCB, then the destination endpoint's tag
5175 MUST be used, and the T-bit MUST NOT be set. Only where no
5176 TCB exists should the sender use the Verification Tag from
5177 the SHUTDOWN ACK, and MUST set the T-bit.
5179 - The receiver of a SHUTDOWN COMPLETE shall accept the packet
5180 if the Verification Tag field of the packet matches its own
5181 tag and the T bit is not set
5183 if it is set to its peer's tag and the T bit is set in the
5185 Otherwise, the receiver MUST silently discard the packet
5186 and take no further action. An endpoint MUST ignore the
5187 SHUTDOWN COMPLETE if it is not in the SHUTDOWN-ACK-SENT
5190 2.41.3. Solution Description
5192 The description of the T bit now clearly describes the semantic of
5193 the bit. The procedures for receiving the T bit have been clarified.
5195 2.42. Unknown Parameter Handling
5197 2.42.1. Description of the Problem
5199 The description given in Section 2.33 does not state clearly whether
5200 an INIT-ACK or COOKIE-ECHO is sent.
5202 2.42.2. Text Changes to the Document
5204 The changes given here already include changes suggested in Section
5205 2.2, 2.27, and 2.33 of this document.
5210 Stewart, et al. Informational [Page 93]
5212 RFC 4460 SCTP Errata April 2006
5216 Old text: (Section 3.2.1)
5219 00 - Stop processing this SCTP packet and discard it do not process
5220 any further chunks within it.
5222 01 - Stop processing this SCTP packet and discard it, do not process
5223 any further chunks within it, and report the unrecognized
5224 parameter in an 'Unrecognized Parameter Type' (in either an
5225 ERROR or in the INIT ACK).
5227 10 - Skip this parameter and continue processing.
5229 11 - Skip this parameter and continue processing but report the
5230 unrecognized parameter in an 'Unrecognized Parameter Type' (in
5231 either an ERROR or in the INIT ACK).
5234 New text: (Section 3.2.1)
5237 00 - Stop processing this parameter; do not process
5238 any further parameters within this chunk.
5240 01 - Stop processing this parameter, do not process
5241 any further parameters within this chunk, and report the
5242 unrecognized parameter in an 'Unrecognized Parameter', as
5245 10 - Skip this parameter and continue processing.
5247 11 - Skip this parameter and continue processing but report the
5248 unrecognized parameter in an 'Unrecognized Parameter', as
5251 Please note that in all four cases an INIT-ACK or COOKIE-ECHO
5252 chunk is sent. In the 00 or 01 case the processing of the
5253 parameters after the unknown parameter is canceled, but no
5254 processing already done is rolled back.
5266 Stewart, et al. Informational [Page 94]
5268 RFC 4460 SCTP Errata April 2006
5272 New text: (Note: no old text; clarification added in Section 3.2)
5275 3.2.2. Reporting of Unrecognized Parameters
5277 If the receiver of an INIT chunk detects unrecognized parameters
5278 and has to report them according to Section 3.2.1, it MUST put
5279 the 'Unrecognized Parameter' parameter(s) in the INIT-ACK chunk
5280 sent in response to the INIT-chunk. Note that if the receiver
5281 of the INIT chunk is NOT going to establish an association (e.g.,
5282 due to lack of resources), an 'Unrecognized Parameter' would NOT
5283 be included with any ABORT being sent to the sender of the INIT.
5285 If the receiver of an INIT-ACK chunk detects unrecognized
5286 parameters and has to report them according to Section 3.2.1, it
5287 SHOULD bundle the ERROR chunk containing the 'Unrecognized
5288 Parameters' error cause with the COOKIE-ECHO chunk sent in
5289 response to the INIT-ACK chunk. If the receiver of the INIT-ACK
5290 cannot bundle the COOKIE-ECHO chunk with the ERROR chunk, the
5291 ERROR chunk MAY be sent separately but not before the COOKIE-ACK
5294 Note: Any time a COOKIE-ECHO is sent in a packet, it MUST be the
5297 2.42.3. Solution Description
5299 The new text clearly states that an INIT-ACK or COOKIE-ECHO has to be
5302 2.43. Cookie Echo Chunk
5304 2.43.1. Description of the Problem
5306 The description given in Section 3.3.11 of RFC 2960 [5] is unclear as
5307 to how the COOKIE-ECHO is composed.
5309 2.43.2. Text Changes to the Document
5312 Old text: (Section 3.3.11)
5314 Cookie: variable size
5316 This field must contain the exact cookie received in the State
5317 Cookie parameter from the previous INIT ACK.
5322 Stewart, et al. Informational [Page 95]
5324 RFC 4460 SCTP Errata April 2006
5327 An implementation SHOULD make the cookie as small as possible
5328 to insure interoperability.
5331 New text: (Section 3.3.11)
5333 Cookie: variable size
5335 This field must contain the exact cookie received in the State
5336 Cookie parameter from the previous INIT ACK.
5338 An implementation SHOULD make the cookie as small as possible
5339 to ensure interoperability.
5341 Note: A Cookie Echo does NOT contain a State Cookie
5342 Parameter; instead, the data within the State Cookie's
5343 Parameter Value becomes the data within the Cookie Echo's
5344 Chunk Value. This allows an implementation to change only
5345 the first two bytes of the State Cookie parameter to become
5346 a Cookie Echo Chunk.
5348 2.43.3. Solution Description
5350 The new text adds a note that helps clarify that a Cookie Echo chunk
5351 is nothing more than the State Cookie parameter with only two bytes
5354 2.44. Partial Chunks
5356 2.44.1. Description of the Problem
5358 Section 6.10 of RFC 2960 [5] uses the notion of 'partial chunks'
5359 without defining it.
5361 2.44.2. Text Changes to the Document
5364 Old text: (Section 6.10)
5366 Partial chunks MUST NOT be placed in an SCTP packet.
5369 New text: (Section 6.10)
5371 Partial chunks MUST NOT be placed in an SCTP packet. A partial
5372 chunk is a chunk that is not completely contained in the SCTP
5373 packet; i.e., the SCTP packet is too short to contain all the bytes
5374 of the chunk as indicated by the chunk length.
5378 Stewart, et al. Informational [Page 96]
5380 RFC 4460 SCTP Errata April 2006
5383 2.44.3. Solution Description
5385 The new text adds a definition of 'partial chunks'.
5387 2.45. Non-unicast Addresses
5389 2.45.1. Description of the Problem
5391 Section 8.4 of RFC 2960 [5] forces the OOTB handling to discard all
5392 non-unicast addresses. This leaves future use of anycast addresses
5393 in question. With the addition of the add-ip feature, SCTP should be
5394 able to easily handle anycast INIT s that can be followed, after
5395 association setup, with a delete of the anycast address from the
5398 2.45.2. Text Changes to the Document
5401 Old text: (Section 8.4)
5403 8.4 Handle "Out of the blue" Packets
5405 An SCTP packet is called an "out of the blue" (OOTB) packet if
5406 it is correctly formed, i.e., passed the receiver's Adler-32
5407 check (see Section 6.8), but the receiver is not able to
5408 identify the association to which this packet belongs.
5410 The receiver of an OOTB packet MUST do the following:
5412 1) If the OOTB packet is to or from a non-unicast address,
5413 silently discard the packet. Otherwise,
5417 New text: (Section 8.4)
5420 8.4. Handle "Out of the Blue" Packets
5422 An SCTP packet is called an "out of the blue" (OOTB) packet if
5423 it is correctly formed (i.e., passed the receiver's CRC32c
5424 check; see Section 6.8), but the receiver is not able to identify
5425 the association to which this packet belongs.
5427 The receiver of an OOTB packet MUST do the following:
5429 1) If the OOTB packet is to or from a non-unicast address, a
5430 receiver SHOULD silently discard the packet. Otherwise,
5434 Stewart, et al. Informational [Page 97]
5436 RFC 4460 SCTP Errata April 2006
5439 2.45.3. Solution Description
5441 The loosening of the wording to a SHOULD will now allow future use of
5442 anycast addresses. Note that no changes are made to Section
5443 11.2.4.1, since responding to broadcast addresses could lead to
5444 flooding attacks and implementors should pay careful attention to
5447 2.46. Processing of ABORT Chunks
5449 2.46.1. Description of the Problem
5451 Section 3.3.7 of RFC 2960 [5] requires an SCTP endpoint to silently
5452 discard ABORT chunks received for associations that do not exist. It
5453 is not clear what this means in the COOKIE-WAIT state, for example.
5454 Therefore, it was not clear whether an ABORT sent in response to an
5455 INIT should be processed or silently discarded.
5457 2.46.2. Text Changes to the Document
5460 Old text: (Section 3.3.7)
5463 If an endpoint receives an ABORT with a format error or for an
5464 association that doesn't exist, it MUST silently discard it.
5467 New text: (Section 3.3.7)
5470 If an endpoint receives an ABORT with a format error or no
5471 TCB is found, it MUST silently discard it.
5473 2.46.3. Solution Description
5475 It is now clearly stated that an ABORT chunk should be processed
5476 whenever a TCB is found.
5490 Stewart, et al. Informational [Page 98]
5492 RFC 4460 SCTP Errata April 2006
5495 2.47. Sending of ABORT Chunks
5497 2.47.1. Description of the Problem
5499 Section 5.1 of RFC 2960 [5] requires that an ABORT chunk be sent in
5500 response to an INIT chunk when there is no listening end point. To
5501 make port scanning harder, someone might not want these ABORTs to be
5502 received by the sender of the INIT chunks. Currently, the only way
5503 to enforce this is by using a firewall that discards the packets
5504 containing the INIT chunks or the packets containing the ABORT
5505 chunks. It is desirable that the same can be done without a middle
5508 2.47.2. Text Changes to the Document
5511 Old text: (Section 5.1)
5514 If an endpoint receives an INIT, INIT ACK, or COOKIE ECHO chunk
5515 but decides not to establish the new association due to missing
5516 mandatory parameters in the received INIT or INIT ACK, invalid
5517 parameter values, or lack of local resources, it MUST respond with
5521 New text: (Section 5.1)
5524 If an endpoint receives an INIT, INIT ACK, or COOKIE ECHO chunk
5525 but decides not to establish the new association due to missing
5526 mandatory parameters in the received INIT or INIT ACK, invalid
5527 parameter values, or lack of local resources, it SHOULD respond
5528 with an ABORT chunk.
5530 2.47.3. Solution Description
5532 The requirement of sending ABORT chunks is relaxed such that an
5533 implementation can decide not to send ABORT chunks.
5535 2.48. Handling of Supported Address Types Parameter
5537 2.48.1. Description of the Problem
5539 The sender of the INIT chunk can include a 'Supported Address Types'
5540 parameter to indicate which address families are supported. It is
5541 unclear how an INIT chunk should be processed where the source
5542 address of the packet containing the INIT chunk or listed addresses
5546 Stewart, et al. Informational [Page 99]
5548 RFC 4460 SCTP Errata April 2006
5551 within the INIT chunk indicate that more address types are supported
5552 than those listed in the 'Supported Address Types' parameter.
5554 2.48.2. Text Changes to the Document
5556 The changes given here already include changes suggested in Section
5557 2.28 of this document.
5560 Old text: (Section 5.1.2)
5563 IMPLEMENTATION NOTE: In the case that the receiver of an INIT ACK
5564 fails to resolve the address parameter due to an unsupported type,
5565 it can abort the initiation process and then attempt a
5566 re-initiation by using a 'Supported Address Types' parameter in
5567 the new INIT to indicate what types of address it prefers.
5570 New text: (Section 5.1.2)
5573 IMPLEMENTATION NOTE: In the case that the receiver of an INIT ACK
5574 fails to resolve the address parameter due to an unsupported type,
5575 it can abort the initiation process and then attempt a re-
5576 initiation by using a 'Supported Address Types' parameter in the
5577 new INIT to indicate what types of address it prefers.
5579 IMPLEMENTATION NOTE: If an SCTP endpoint that only supports either
5580 IPv4 or IPv6 receives IPv4 and IPv6 addresses in an INIT or INIT-
5581 ACK chunk from its peer, it MUST use all the addresses belonging
5582 to the supported address family. The other addresses MAY be
5583 ignored. The endpoint SHOULD NOT respond with any kind of error
5586 IMPLEMENTATION NOTE: If an SCTP endpoint lists in the 'Supported
5587 Address Types' parameter either IPv4 or IPv6, but uses the other
5588 family for sending the packet containing the INIT chunk, or if it
5589 also lists addresses of the other family in the INIT chunk, then
5590 the address family that is not listed in the 'Supported Address
5591 Types' parameter SHOULD also be considered as supported by the
5592 receiver of the INIT chunk. The receiver of the INIT chunk SHOULD
5593 NOT respond with any kind of error indication.
5595 2.48.3. Solution Description
5597 It is now clearly described how these Supported Address Types
5598 parameters with incorrect data should be handled.
5602 Stewart, et al. Informational [Page 100]
5604 RFC 4460 SCTP Errata April 2006
5607 2.49. Handling of Unexpected Parameters
5609 2.49.1. Description of the Problem
5611 RFC 2960 [5] clearly describes how unknown parameters in the INIT and
5612 INIT-ACK chunk should be processed. But it is not described how
5613 unexpected parameters should be processed. A parameter is unexpected
5614 if it is known and is an optional parameter in either the INIT or
5615 INIT-ACK chunk but is received in the chunk for which it is not an
5616 optional parameter. For example, the 'Supported Address Types'
5617 parameter would be an unexpected parameter if contained in an INIT-
5620 2.49.2. Text Changes to the Document
5623 Old text: (Section 3.3.2)
5626 Note 4: This parameter, when present, specifies all the address
5627 types the sending endpoint can support. The absence of this
5628 parameter indicates that the sending endpoint can support any
5632 New text: (Section 3.3.2)
5635 Note 4: This parameter, when present, specifies all the address
5636 types the sending endpoint can support. The absence of this
5637 parameter indicates that the sending endpoint can support any
5640 IMPLEMENTATION NOTE: If an INIT chunk is received with known
5641 parameters that are not optional parameters of the INIT chunk
5642 then the receiver SHOULD process the INIT chunk and send back
5643 an INIT-ACK. The receiver of the INIT chunk MAY bundle an ERROR
5644 chunk with the COOKIE-ACK chunk later. However, restrictive
5645 implementations MAY send back an ABORT chunk in response to
5658 Stewart, et al. Informational [Page 101]
5660 RFC 4460 SCTP Errata April 2006
5664 Old text: (Section 3.3.3)
5667 IMPLEMENTATION NOTE: An implementation MUST be prepared to receive
5668 a INIT ACK that is quite large (more than 1500 bytes) due to the
5669 variable size of the state cookie AND the variable address list.
5670 For example if a responder to the INIT has 1000 IPv4 addresses
5671 it wishes to send, it would need at least 8,000 bytes to encode
5672 this in the INIT ACK.
5675 New text: (Section 3.3.3)
5678 IMPLEMENTATION NOTE: An implementation MUST be prepared to receive
5679 a INIT ACK that is quite large (more than 1500 bytes) due to the
5680 variable size of the state cookie AND the variable address list.
5681 For example, if a responder to the INIT has 1000 IPv4 addresses
5682 it wishes to send, it would need at least 8,000 bytes to encode
5683 this in the INIT ACK.
5685 IMPLEMENTATION NOTE: If an INIT-ACK chunk is received with known
5686 parameters that are not optional parameters of the INIT-ACK
5687 chunk, then the receiver SHOULD process the INIT-ACK chunk and
5688 send back a COOKIE-ECHO. The receiver of the INIT-ACK chunk
5689 MAY bundle an ERROR chunk with the COOKIE-ECHO chunk. However,
5690 restrictive implementations MAY send back an ABORT chunk in
5691 response to the INIT-ACK chunk.
5693 2.49.3. Solution Description
5695 It is now stated how unexpected parameters should be processed.
5697 2.50. Payload Protocol Identifier
5699 2.50.1. Description of the Problem
5701 The current description of the payload protocol identifier does NOT
5702 highlight the fact that the field is NOT necessarily in network byte
5714 Stewart, et al. Informational [Page 102]
5716 RFC 4460 SCTP Errata April 2006
5719 2.50.2. Text Changes to the Document
5722 Old text: (Section 3.3.1)
5724 Payload Protocol Identifier: 32 bits (unsigned integer)
5726 This value represents an application (or upper layer) specified
5727 protocol identifier. This value is passed to SCTP by its upper
5728 layer and sent to its peer. This identifier is not used by
5729 SCTP but can be used by certain network entities as well as
5730 the peer application to identify the type of information being
5731 carried in this DATA chunk. This field must be sent even in
5732 fragmented DATA chunks (to make sure it is available for agents
5733 in the middle of the network).
5735 The value 0 indicates no application identifier is specified by
5736 the upper layer for this payload data.
5739 New text: (Section 3.3.1)
5741 Payload Protocol Identifier: 32 bits (unsigned integer)
5743 This value represents an application (or upper layer) specified
5744 protocol identifier. This value is passed to SCTP by its upper
5745 layer and sent to its peer. This identifier is not used by
5746 SCTP but can be used by certain network entities, as well as by
5747 the peer application, to identify the type of information being
5748 carried in this DATA chunk. This field must be sent even in
5749 fragmented DATA chunks (to make sure it is available for agents
5750 in the middle of the network). Note that this field is NOT
5751 touched by an SCTP implementation, therefore its byte order is
5752 NOT necessarily Big Endian. The upper layer is responsible
5753 for any byte order conversions to this field.
5755 The value 0 indicates that no application identifier is
5756 specified by the upper layer for this payload data.
5758 2.50.3. Solution Description
5760 It is now explicitly stated that the upper layer is responsible for
5761 the byte order of this field.
5770 Stewart, et al. Informational [Page 103]
5772 RFC 4460 SCTP Errata April 2006
5775 2.51. Karn's Algorithm
5777 2.51.1. Description of the Problem
5779 The current wording of the use of Karn's algorithm is not descriptive
5780 enough to ensure that an implementation in a multi-homed association
5781 does not incorrectly mismeasure the RTT.
5783 2.51.2. Text Changes to the Document
5786 Old text: (Section 6.3.1)
5789 C5) Karn's algorithm: RTT measurements MUST NOT be made using
5790 packets that were retransmitted (and thus for which it is
5791 ambiguous whether the reply was for the first instance of the
5792 packet or a later instance)
5794 New text: (Section 6.3.1)
5797 C5) Karn's algorithm: RTT measurements MUST NOT be made using
5798 chunks that were retransmitted (and thus for which it is
5799 ambiguous whether the reply was for the first instance of
5800 the chunk or for a later instance)
5802 IMPLEMENTATION NOTE: RTT measurements should only be
5803 made using a chunk with TSN r if no chunk
5804 with TSN less than or equal to r is retransmitted
5805 since r is first sent.
5807 2.51.3. Solution Description
5809 The above clarification adds an implementation note that will provide
5810 additional guidance in the application of Karn's algorithm.
5812 2.52. Fast Retransmit Algorithm
5814 2.52.1. Description of the Problem
5816 The original SCTP specification is overly conservative in requiring 4
5817 missing reports before fast retransmitting a segment. TCP uses 3
5818 missing reports or 4 acknowledgements indicating that the same
5819 segment was received.
5826 Stewart, et al. Informational [Page 104]
5828 RFC 4460 SCTP Errata April 2006
5831 2.52.2. Text Changes to the Document
5837 7.2.4 Fast Retransmit on Gap Reports
5839 In the absence of data loss, an endpoint performs delayed
5840 acknowledgement. However, whenever an endpoint notices a hole in
5841 the arriving TSN sequence, it SHOULD start sending a SACK back
5842 every time a packet arrives carrying data until the
5845 Whenever an endpoint receives a SACK that indicates some TSN(s)
5846 missing, it SHOULD wait for 3 further miss indications (via
5847 subsequent SACK's) on the same TSN(s) before taking action with
5848 regard to Fast Retransmit.
5855 7.2.4. Fast Retransmit on Gap Reports
5857 In the absence of data loss, an endpoint performs delayed
5858 acknowledgement. However, whenever an endpoint notices a hole in
5859 the arriving TSN sequence, it SHOULD start sending a SACK back
5860 every time a packet arrives carrying data until the
5863 Whenever an endpoint receives a SACK that indicates that some
5864 TSNs are missing, it SHOULD wait for 2 further miss indications
5865 (via subsequent SACKs for a total of 3 missing reports) on the
5866 same TSNs before taking action with regard to Fast Retransmit.
5868 2.52.3. Solution Description
5870 The above changes will make SCTP and TCP behave similarly in terms of
5871 how fast they engage the Fast Retransmission algorithm upon receiving
5874 3. Security Considerations
5876 This document should add no additional security risks to SCTP and in
5877 fact SHOULD correct some original security flaws within the original
5878 document once it is incorporated into a RFC 2960 [5] BIS document.
5882 Stewart, et al. Informational [Page 105]
5884 RFC 4460 SCTP Errata April 2006
5889 The authors would like to thank the following people who have
5890 provided comments and input for this document:
5892 Barry Zuckerman, La Monte Yarroll, Qiaobing Xie, Wang Xiaopeng,
5893 Jonathan Wood, Jeff Waskow, Mike Turner, John Townsend, Sabina
5894 Torrente, Cliff Thomas, Yuji Suzuki, Manoj Solanki, Sverre Slotte,
5895 Keyur Shah, Jan Rovins, Ben Robinson, Renee Revis, Ian Periam, RC
5896 Monee, Sanjay Rao, Sujith Radhakrishnan, Heinz Prantner, Biren Patel,
5897 Nathalie Mouellic, Mitch Miers, Bernward Meyknecht, Stan McClellan,
5898 Oliver Mayor, Tomas Orti Martin, Sandeep Mahajan, David Lehmann,
5899 Jonathan Lee, Philippe Langlois, Karl Knutson, Joe Keller, Gareth
5900 Keily, Andreas Jungmaier, Janardhan Iyengar, Mutsuya Irie, John
5901 Hebert, Kausar Hassan, Fred Hasle, Dan Harrison, Jon Grim, Laurent
5902 Glaude, Steven Furniss, Atsushi Fukumoto, Ken Fujita, Steve Dimig,
5903 Thomas Curran, Serkan Cil, Melissa Campbell, Peter Butler, Rob
5904 Brennan, Harsh Bhondwe, Brian Bidulock, Caitlin Bestler, Jon Berger,
5905 Robby Benedyk, Stephen Baucke, Sandeep Balani, and Ronnie Sellar.
5907 A special thanks to Mark Allman, who should actually be a co-author
5908 for his work on the max-burst, but managed to wiggle out due to a
5909 technicality. Also, we would like to acknowledge Lyndon Ong and Phil
5910 Conrad for their valuable input and many contributions.
5912 5. IANA Considerations
5914 This document recommends changes for the RFC 2960 [5] BIS document.
5915 As such, even though it lists new error cause code, this document in
5916 itself does NOT define those new codes. Instead, the BIS document
5917 will make the needed changes to RFC 2960 [5] and thus its IANA
5918 section will require changes to be made.
5920 6. Normative References
5922 [1] Braden, R., "Requirements for Internet Hosts - Communication
5923 Layers", STD 3, RFC 1122, October 1989.
5925 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
5926 Levels", BCP 14, RFC 2119, March 1997.
5928 [3] Caro, A., Shah, K., Iyengar, J., Amer, P., and R. Stewart, "SCTP
5929 and TCP Variants: Congestion Control Under Multiple Losses",
5930 Technical Report TR2003-04, Computer and Information Sciences
5931 Department, University of Delaware, February 2003,
5932 <http://www.armandocaro.net/papers>.
5938 Stewart, et al. Informational [Page 106]
5940 RFC 4460 SCTP Errata April 2006
5943 [4] Caro, A., Amer, P., and R. Stewart, "Retransmission Schemes for
5944 End-to-end Failover with Transport Layer Multihoming", GLOBECOM,
5945 November 2004., <http://www.armandocaro.net/papers>.
5947 [5] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
5948 H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V.
5949 Paxson, "Stream Control Transmission Protocol", RFC 2960,
5952 [6] Stone, J., Stewart, R., and D. Otis, "Stream Control
5953 Transmission Protocol (SCTP) Checksum Change", RFC 3309,
5994 Stewart, et al. Informational [Page 107]
5996 RFC 4460 SCTP Errata April 2006
6008 EMail: rrs@cisco.com
6011 Ivan Arias-Rodriguez
6012 Nokia Research Center
6014 FIN-00045 Nokia Group
6017 EMail: ivan.arias-rodriguez@nokia.com
6021 Sun Microsystems, Inc.
6026 EMail: kacheong.poon@sun.com
6034 EMail: acaro@bbn.com
6035 URI: http://www.armandocaro.net
6039 Muenster Univ. of Applied Sciences
6044 EMail: tuexen@fh-muenster.de
6050 Stewart, et al. Informational [Page 108]
6052 RFC 4460 SCTP Errata April 2006
6055 Full Copyright Statement
6057 Copyright (C) The Internet Society (2006).
6059 This document is subject to the rights, licenses and restrictions
6060 contained in BCP 78, and except as set forth therein, the authors
6061 retain all their rights.
6063 This document and the information contained herein are provided on an
6064 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
6065 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
6066 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
6067 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
6068 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
6069 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
6071 Intellectual Property
6073 The IETF takes no position regarding the validity or scope of any
6074 Intellectual Property Rights or other rights that might be claimed to
6075 pertain to the implementation or use of the technology described in
6076 this document or the extent to which any license under such rights
6077 might or might not be available; nor does it represent that it has
6078 made any independent effort to identify any such rights. Information
6079 on the procedures with respect to rights in RFC documents can be
6080 found in BCP 78 and BCP 79.
6082 Copies of IPR disclosures made to the IETF Secretariat and any
6083 assurances of licenses to be made available, or the result of an
6084 attempt made to obtain a general license or permission for the use of
6085 such proprietary rights by implementers or users of this
6086 specification can be obtained from the IETF on-line IPR repository at
6087 http://www.ietf.org/ipr.
6089 The IETF invites any interested party to bring to its attention any
6090 copyrights, patents or patent applications, or other proprietary
6091 rights that may cover technology that may be required to implement
6092 this standard. Please address the information to the IETF at
6097 Funding for the RFC Editor function is provided by the IETF
6098 Administrative Support Activity (IASA).
6106 Stewart, et al. Informational [Page 109]
projects / platform / upstream / lksctp-tools.git / blob