idnits 2.17.1 draft-ietf-tsvwg-rfc4960-errata-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 3326 has weird spacing: '...ed long crc_c...' == Line 3547 has weird spacing: '...ed long crc_c...' -- The document date (October 22, 2018) is 2007 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC2434' is mentioned on line 3064, but not defined ** Obsolete undefined reference: RFC 2434 (Obsoleted by RFC 5226) == Missing Reference: 'RFC0813' is mentioned on line 429, but not defined ** Obsolete undefined reference: RFC 813 (Obsoleted by RFC 7805) == Missing Reference: 'WILLIAMS93' is mentioned on line 809, but not defined -- Looks like a reference, but probably isn't: '256' on line 3326 ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 2960 (Obsoleted by RFC 4960) -- Obsolete informational reference (is this intentional?): RFC 4460 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 6096 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 7053 (Obsoleted by RFC 9260) Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Stewart 3 Internet-Draft Netflix, Inc. 4 Intended status: Informational M. Tuexen 5 Expires: April 25, 2019 Muenster Univ. of Appl. Sciences 6 M. Proshin 7 Ericsson 8 October 22, 2018 10 RFC 4960 Errata and Issues 11 draft-ietf-tsvwg-rfc4960-errata-08.txt 13 Abstract 15 This document is a compilation of issues found since the publication 16 of RFC4960 in September 2007 based on experience with implementing, 17 testing, and using SCTP along with the suggested fixes. This 18 document provides deltas to RFC4960 and is organized in a time 19 ordered way. The issues are listed in the order they were brought 20 up. Because some text is changed several times the last delta in the 21 text is the one which should be applied. In addition to the delta a 22 description of the problem and the details of the solution are also 23 provided. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on April 25, 2019. 42 Copyright Notice 44 Copyright (c) 2018 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Corrections to RFC 4960 . . . . . . . . . . . . . . . . . . . 4 62 3.1. Path Error Counter Threshold Handling . . . . . . . . . . 4 63 3.2. Upper Layer Protocol Shutdown Request Handling . . . . . 5 64 3.3. Registration of New Chunk Types . . . . . . . . . . . . . 6 65 3.4. Variable Parameters for INIT Chunks . . . . . . . . . . . 7 66 3.5. CRC32c Sample Code on 64-bit Platforms . . . . . . . . . 8 67 3.6. Endpoint Failure Detection . . . . . . . . . . . . . . . 9 68 3.7. Data Transmission Rules . . . . . . . . . . . . . . . . . 10 69 3.8. T1-Cookie Timer . . . . . . . . . . . . . . . . . . . . . 11 70 3.9. Miscellaneous Typos . . . . . . . . . . . . . . . . . . . 12 71 3.10. CRC32c Sample Code . . . . . . . . . . . . . . . . . . . 19 72 3.11. partial_bytes_acked after T3-rtx Expiration . . . . . . . 20 73 3.12. Order of Adjustments of partial_bytes_acked and cwnd . . 21 74 3.13. HEARTBEAT ACK and the association error counter . . . . . 22 75 3.14. Path for Fast Retransmission . . . . . . . . . . . . . . 23 76 3.15. Transmittal in Fast Recovery . . . . . . . . . . . . . . 24 77 3.16. Initial Value of ssthresh . . . . . . . . . . . . . . . . 25 78 3.17. Automatically Confirmed Addresses . . . . . . . . . . . . 26 79 3.18. Only One Packet after Retransmission Timeout . . . . . . 27 80 3.19. INIT ACK Path for INIT in COOKIE-WAIT State . . . . . . . 28 81 3.20. Zero Window Probing and Unreachable Primary Path . . . . 29 82 3.21. Normative Language in Section 10 . . . . . . . . . . . . 30 83 3.22. Increase of partial_bytes_acked in Congestion Avoidance . 33 84 3.23. Inconsistency in Notifications Handling . . . . . . . . . 34 85 3.24. SACK.Delay Not Listed as a Protocol Parameter . . . . . . 40 86 3.25. Processing of Chunks in an Incoming SCTP Packet . . . . . 42 87 3.26. CWND Increase in Congestion Avoidance Phase . . . . . . . 43 88 3.27. Refresh of cwnd and ssthresh after Idle Period . . . . . 46 89 3.28. Window Updates After Receiver Window Opens Up . . . . . . 47 90 3.29. Path of DATA and Reply Chunks . . . . . . . . . . . . . . 48 91 3.30. Outstanding Data, Flightsize and Data In Flight Key Terms 50 92 3.31. CWND Degradation due to Max.Burst . . . . . . . . . . . . 52 93 3.32. Reduction of RTO.Initial . . . . . . . . . . . . . . . . 53 94 3.33. Ordering of Bundled SACK and ERROR Chunks . . . . . . . . 55 95 3.34. Undefined Parameter Returned by RECEIVE Primitive . . . . 56 96 3.35. DSCP Changes . . . . . . . . . . . . . . . . . . . . . . 57 97 3.36. Inconsistent Handling of ICMPv4 and ICMPv6 Messages . . . 58 98 3.37. Handling of Soft Errors . . . . . . . . . . . . . . . . . 60 99 3.38. Honoring CWND . . . . . . . . . . . . . . . . . . . . . . 60 100 3.39. Zero Window Probing . . . . . . . . . . . . . . . . . . . 62 101 3.40. Updating References Regarding ECN . . . . . . . . . . . . 64 102 3.41. Host Name Address Parameter Deprecated . . . . . . . . . 66 103 3.42. Conflicting Text Regarding the Supported Address Types 104 Parameter . . . . . . . . . . . . . . . . . . . . . . . . 70 105 3.43. Integration of RFC 6096 . . . . . . . . . . . . . . . . . 71 106 3.44. Integration of RFC 6335 . . . . . . . . . . . . . . . . . 73 107 3.45. Integration of RFC 7053 . . . . . . . . . . . . . . . . . 75 108 3.46. CRC32c Code Improvements . . . . . . . . . . . . . . . . 79 109 3.47. Clarification of Gap Ack Blocks in SACK Chunks . . . . . 89 110 3.48. Handling of SSN Wrap Arounds . . . . . . . . . . . . . . 91 111 3.49. Update RFC 2119 Boilerplate . . . . . . . . . . . . . . . 92 112 3.50. Missed Text Removal . . . . . . . . . . . . . . . . . . . 93 113 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 94 114 5. Security Considerations . . . . . . . . . . . . . . . . . . . 94 115 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 94 116 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 95 117 7.1. Normative References . . . . . . . . . . . . . . . . . . 95 118 7.2. Informative References . . . . . . . . . . . . . . . . . 95 119 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 96 121 1. Introduction 123 This document contains a compilation of all defects found up until 124 the publication of this document for [RFC4960] specifying the Stream 125 Control Transmission Protocol (SCTP). These defects may be of an 126 editorial or technical nature. This document may be thought of as a 127 companion document to be used in the implementation of SCTP to 128 clarify errors in the original SCTP document. 130 This document provides a history of the changes that will be compiled 131 into a BIS document for [RFC4960]. It is structured similar to 132 [RFC4460]. 134 Each error will be detailed within this document in the form of: 136 o The problem description, 137 o The text quoted from [RFC4960], 138 o The replacement text that should be placed into an upcoming BIS 139 document, 140 o A description of the solution. 142 Note that when reading this document one must use care to assure that 143 a field or item is not updated further on within the document. Since 144 this document is a historical record of the sequential changes that 145 have been found necessary at various inter-op events and through 146 discussion on the list, the last delta in the text is the one which 147 should be applied. 149 2. Conventions 151 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 152 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 153 "OPTIONAL" in this document are to be interpreted as described in 154 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 155 capitals, as shown here. 157 3. Corrections to RFC 4960 159 [NOTE to RFC-Editor: 161 References to obsoleted RFCs are in OLD TEXT sections and have the 162 corresponding references to the obsoleting RFCs in the NEW TEXT 163 sections. In addition to this, there are some references to the 164 obsoleted [RFC2960], which are intended. 166 ] 168 3.1. Path Error Counter Threshold Handling 170 3.1.1. Description of the Problem 172 The handling of the 'Path.Max.Retrans' parameter is described in 173 Section 8.2 and Section 8.3 of [RFC4960] in an inconsistent way. 174 Whereas Section 8.2 describes that a path is marked inactive when the 175 path error counter exceeds the threshold, Section 8.3 says the path 176 is marked inactive when the path error counter reaches the threshold. 178 This issue was reported as an Errata for [RFC4960] with Errata ID 179 1440. 181 3.1.2. Text Changes to the Document 182 --------- 183 Old text: (Section 8.3) 184 --------- 186 When the value of this counter reaches the protocol parameter 187 'Path.Max.Retrans', the endpoint should mark the corresponding 188 destination address as inactive if it is not so marked, and may also 189 optionally report to the upper layer the change of reachability of 190 this destination address. After this, the endpoint should continue 191 HEARTBEAT on this destination address but should stop increasing the 192 counter. 194 --------- 195 New text: (Section 8.3) 196 --------- 198 When the value of this counter exceeds the protocol parameter 199 'Path.Max.Retrans', the endpoint SHOULD mark the corresponding 200 destination address as inactive if it is not so marked, and MAY also 201 optionally report to the upper layer the change of reachability of 202 this destination address. After this, the endpoint SHOULD continue 203 HEARTBEAT on this destination address but SHOULD stop increasing the 204 counter. 206 This text has been modified by multiple errata. It is further 207 updated in Section 3.23. 209 3.1.3. Solution Description 211 The intended state change should happen when the threshold is 212 exceeded. 214 3.2. Upper Layer Protocol Shutdown Request Handling 216 3.2.1. Description of the Problem 218 Section 9.2 of [RFC4960] describes the handling of received SHUTDOWN 219 chunks in the SHUTDOWN-RECEIVED state instead of the handling of 220 shutdown requests from its upper layer in this state. 222 This issue was reported as an Errata for [RFC4960] with Errata ID 223 1574. 225 3.2.2. Text Changes to the Document 226 --------- 227 Old text: (Section 9.2) 228 --------- 230 Once an endpoint has reached the SHUTDOWN-RECEIVED state, it MUST NOT 231 send a SHUTDOWN in response to a ULP request, and should discard 232 subsequent SHUTDOWN chunks. 234 --------- 235 New text: (Section 9.2) 236 --------- 238 Once an endpoint has reached the SHUTDOWN-RECEIVED state, it MUST 239 ignore ULP shutdown requests, but MUST continue responding 240 to SHUTDOWN chunks from its peer. 242 This text is in final form, and is not further updated in this 243 document. 245 3.2.3. Solution Description 247 The text never intended the SCTP endpoint to ignore SHUTDOWN chunks 248 from its peer. If it did, the endpoints could never gracefully 249 terminate associations in some cases. 251 3.3. Registration of New Chunk Types 253 3.3.1. Description of the Problem 255 Section 14.1 of [RFC4960] should deal with new chunk types, however, 256 the text refers to parameter types. 258 This issue was reported as an Errata for [RFC4960] with Errata ID 259 2592. 261 3.3.2. Text Changes to the Document 262 --------- 263 Old text: (Section 14.1) 264 --------- 266 The assignment of new chunk parameter type codes is done through an 267 IETF Consensus action, as defined in [RFC2434]. Documentation of the 268 chunk parameter MUST contain the following information: 270 --------- 271 New text: (Section 14.1) 272 --------- 274 The assignment of new chunk type codes is done through an 275 IETF Consensus action, as defined in [RFC8126]. Documentation of the 276 chunk type MUST contain the following information: 278 This text has been modified by multiple errata. It is further 279 updated in Section 3.43. 281 3.3.3. Solution Description 283 Refer to chunk types as intended and change reference to [RFC8126]. 285 3.4. Variable Parameters for INIT Chunks 287 3.4.1. Description of the Problem 289 Newlines in wrong places break the layout of the table of variable 290 parameters for the INIT chunk in Section 3.3.2 of [RFC4960]. 292 This issue was reported as an Errata for [RFC4960] with Errata ID 293 3291 and Errata ID 3804. 295 3.4.2. Text Changes to the Document 296 --------- 297 Old text: (Section 3.3.2) 298 --------- 300 Variable Parameters Status Type Value 301 ------------------------------------------------------------- 302 IPv4 Address (Note 1) Optional 5 IPv6 Address 303 (Note 1) Optional 6 Cookie Preservative 304 Optional 9 Reserved for ECN Capable (Note 2) Optional 305 32768 (0x8000) Host Name Address (Note 3) Optional 306 11 Supported Address Types (Note 4) Optional 12 308 --------- 309 New text: (Section 3.3.2) 310 --------- 312 Variable Parameters Status Type Value 313 ------------------------------------------------------------- 314 IPv4 Address (Note 1) Optional 5 315 IPv6 Address (Note 1) Optional 6 316 Cookie Preservative Optional 9 317 Reserved for ECN Capable (Note 2) Optional 32768 (0x8000) 318 Host Name Address (Note 3) Optional 11 319 Supported Address Types (Note 4) Optional 12 321 This text is in final form, and is not further updated in this 322 document. 324 3.4.3. Solution Description 326 Fix the formatting of the table. 328 3.5. CRC32c Sample Code on 64-bit Platforms 330 3.5.1. Description of the Problem 332 The sample code for computing the CRC32c provided in [RFC4960] 333 assumes that a variable of type unsigned long uses 32 bits. This is 334 not true on some 64-bit platforms (for example the ones using LP64). 336 This issue was reported as an Errata for [RFC4960] with Errata ID 337 3423. 339 3.5.2. Text Changes to the Document 340 --------- 341 Old text: (Appendix C) 342 --------- 344 unsigned long 345 generate_crc32c(unsigned char *buffer, unsigned int length) 346 { 347 unsigned int i; 348 unsigned long crc32 = ~0L; 350 --------- 351 New text: (Appendix C) 352 --------- 354 unsigned long 355 generate_crc32c(unsigned char *buffer, unsigned int length) 356 { 357 unsigned int i; 358 unsigned long crc32 = 0xffffffffL; 360 This text has been modified by multiple errata. It is further 361 updated in Section 3.10 and in Section 3.46. 363 3.5.3. Solution Description 365 Use 0xffffffffL instead of ~0L which gives the same value on 366 platforms using 32 bits or 64 bits for variables of type unsigned 367 long. 369 3.6. Endpoint Failure Detection 371 3.6.1. Description of the Problem 373 The handling of the association error counter defined in Section 8.1 374 of [RFC4960] can result in an association failure even if the path 375 used for data transmission is available, but idle. 377 This issue was reported as an Errata for [RFC4960] with Errata ID 378 3788. 380 3.6.2. Text Changes to the Document 381 --------- 382 Old text: (Section 8.1) 383 --------- 385 An endpoint shall keep a counter on the total number of consecutive 386 retransmissions to its peer (this includes retransmissions to all the 387 destination transport addresses of the peer if it is multi-homed), 388 including unacknowledged HEARTBEAT chunks. 390 --------- 391 New text: (Section 8.1) 392 --------- 394 An endpoint SHOULD keep a counter on the total number of consecutive 395 retransmissions to its peer (this includes data retransmissions 396 to all the destination transport addresses of the peer if it is 397 multi-homed), including the number of unacknowledged HEARTBEAT 398 chunks observed on the path which is currently used for data 399 transfer. Unacknowledged HEARTBEAT chunks observed on paths 400 different from the path currently used for data transfer SHOULD 401 NOT increment the association error counter, as this could lead 402 to association closure even if the path which is currently used for 403 data transfer is available (but idle). 405 This text has been modified by multiple errata. It is further 406 updated in Section 3.23. 408 3.6.3. Solution Description 410 A more refined handling for the association error counter is defined. 412 3.7. Data Transmission Rules 414 3.7.1. Description of the Problem 416 When integrating the changes to Section 6.1 A) of [RFC2960] as 417 described in Section 2.15.2 of [RFC4460] some text was duplicated and 418 became the final paragraph of Section 6.1 A) of [RFC4960]. 420 This issue was reported as an Errata for [RFC4960] with Errata ID 421 4071. 423 3.7.2. Text Changes to the Document 424 --------- 425 Old text: (Section 6.1 A)) 426 --------- 428 The sender MUST also have an algorithm for sending new DATA chunks 429 to avoid silly window syndrome (SWS) as described in [RFC0813]. 430 The algorithm can be similar to the one described in Section 431 4.2.3.4 of [RFC1122]. 433 However, regardless of the value of rwnd (including if it is 0), 434 the data sender can always have one DATA chunk in flight to the 435 receiver if allowed by cwnd (see rule B below). This rule allows 436 the sender to probe for a change in rwnd that the sender missed 437 due to the SACK having been lost in transit from the data receiver 438 to the data sender. 440 --------- 441 New text: (Section 6.1 A)) 442 --------- 444 The sender MUST also have an algorithm for sending new DATA chunks 445 to avoid silly window syndrome (SWS) as described in [RFC1122]. 446 The algorithm can be similar to the one described in Section 447 4.2.3.4 of [RFC1122]. 449 This text is in final form, and is not further updated in this 450 document. 452 3.7.3. Solution Description 454 Last paragraph of Section 6.1 A) removed as intended in 455 Section 2.15.2 of [RFC4460]. 457 3.8. T1-Cookie Timer 459 3.8.1. Description of the Problem 461 Figure 4 of [RFC4960] illustrates the SCTP association setup. 462 However, it incorrectly shows that the T1-init timer is used in the 463 COOKIE-ECHOED state whereas the T1-cookie timer should have been used 464 instead. 466 This issue was reported as an Errata for [RFC4960] with Errata ID 467 4400. 469 3.8.2. Text Changes to the Document 471 --------- 472 Old text: (Section 5.1.6, Figure 4) 473 --------- 475 COOKIE ECHO [Cookie_Z] ------\ 476 (Start T1-init timer) \ 477 (Enter COOKIE-ECHOED state) \---> (build TCB enter ESTABLISHED 478 state) 479 /---- COOKIE-ACK 480 / 481 (Cancel T1-init timer, <-----/ 482 Enter ESTABLISHED state) 484 --------- 485 New text: (Section 5.1.6, Figure 4) 486 --------- 488 COOKIE ECHO [Cookie_Z] ------\ 489 (Start T1-cookie timer) \ 490 (Enter COOKIE-ECHOED state) \---> (build TCB enter ESTABLISHED 491 state) 492 /---- COOKIE-ACK 493 / 494 (Cancel T1-cookie timer, <---/ 495 Enter ESTABLISHED state) 497 This text has been modified by multiple errata. It is further 498 updated in Section 3.9. 500 3.8.3. Solution Description 502 Change the figure such that the T1-cookie timer is used instead of 503 the T1-init timer. 505 3.9. Miscellaneous Typos 507 3.9.1. Description of the Problem 509 While processing [RFC4960] some typos were not caught. 511 One typo was reported as an Errata for [RFC4960] with Errata ID 5003. 513 3.9.2. Text Changes to the Document 515 --------- 516 Old text: (Section 1.6) 517 --------- 519 Transmission Sequence Numbers wrap around when they reach 2**32 - 1. 520 That is, the next TSN a DATA chunk MUST use after transmitting TSN = 521 2*32 - 1 is TSN = 0. 523 --------- 524 New text: (Section 1.6) 525 --------- 527 Transmission Sequence Numbers wrap around when they reach 2**32 - 1. 528 That is, the next TSN a DATA chunk MUST use after transmitting TSN = 529 2**32 - 1 is TSN = 0. 531 This text is in final form, and is not further updated in this 532 document. 534 --------- 535 Old text: (Section 3.3.10.9) 536 --------- 538 No User Data: This error cause is returned to the originator of a 540 DATA chunk if a received DATA chunk has no user data. 542 --------- 543 New text: (Section 3.3.10.9) 544 --------- 546 No User Data: This error cause is returned to the originator of a 547 DATA chunk if a received DATA chunk has no user data. 549 This text is in final form, and is not further updated in this 550 document. 552 --------- 553 Old text: (Section 6.7, Figure 9) 554 --------- 556 Endpoint A Endpoint Z {App 557 sends 3 messages; strm 0} DATA [TSN=6,Strm=0,Seq=2] ---------- 558 -----> (ack delayed) (Start T3-rtx timer) 560 DATA [TSN=7,Strm=0,Seq=3] --------> X (lost) 562 DATA [TSN=8,Strm=0,Seq=4] ---------------> (gap detected, 563 immediately send ack) 564 /----- SACK [TSN Ack=6,Block=1, 565 / Start=2,End=2] 566 <-----/ (remove 6 from out-queue, 567 and mark 7 as "1" missing report) 569 --------- 570 New text: (Section 6.7, Figure 9) 571 --------- 573 Endpoint A Endpoint Z 574 {App sends 3 messages; strm 0} 575 DATA [TSN=6,Strm=0,Seq=2] ---------------> (ack delayed) 576 (Start T3-rtx timer) 578 DATA [TSN=7,Strm=0,Seq=3] --------> X (lost) 580 DATA [TSN=8,Strm=0,Seq=4] ---------------> (gap detected, 581 immediately send ack) 582 /----- SACK [TSN Ack=6,Block=1, 583 / Start=2,End=2] 584 <-----/ 585 (remove 6 from out-queue, 586 and mark 7 as "1" missing report) 588 This text is in final form, and is not further updated in this 589 document. 591 --------- 592 Old text: (Section 6.10) 593 --------- 595 An endpoint bundles chunks by simply including multiple chunks in one 596 outbound SCTP packet. The total size of the resultant IP datagram, 598 including the SCTP packet and IP headers, MUST be less that or equal 599 to the current Path MTU. 601 --------- 602 New text: (Section 6.10) 603 --------- 605 An endpoint bundles chunks by simply including multiple chunks in one 606 outbound SCTP packet. The total size of the resultant IP datagram, 607 including the SCTP packet and IP headers, MUST be less than or equal 608 to the current PMTU. 610 This text is in final form, and is not further updated in this 611 document. 613 --------- 614 Old text: (Section 10.1 O)) 615 --------- 617 o Receive Unacknowledged Message 619 Format: RECEIVE_UNACKED(data retrieval id, buffer address, buffer 620 size, [,stream id] [, stream sequence number] [,partial 621 flag] [,payload protocol-id]) 623 --------- 624 New text: (Section 10.1 O)) 625 --------- 627 O) Receive Unacknowledged Message 629 Format: RECEIVE_UNACKED(data retrieval id, buffer address, buffer 630 size [,stream id] [,stream sequence number] [,partial 631 flag] [,payload protocol-id]) 633 This text is in final form, and is not further updated in this 634 document. 636 --------- 637 Old text: (Section 10.1 M)) 638 --------- 640 M) Set Protocol Parameters 642 Format: SETPROTOCOLPARAMETERS(association id, 643 [,destination transport address,] 644 protocol parameter list) 646 --------- 647 New text: (Section 10.1 M)) 648 --------- 650 M) Set Protocol Parameters 652 Format: SETPROTOCOLPARAMETERS(association id, 653 [destination transport address,] 654 protocol parameter list) 656 This text is in final form, and is not further updated in this 657 document. 659 --------- 660 Old text: (Appendix C) 661 --------- 663 ICMP2) An implementation MAY ignore all ICMPv6 messages where the 664 type field is not "Destination Unreachable", "Parameter 665 Problem",, or "Packet Too Big". 667 --------- 668 New text: (Appendix C) 669 --------- 671 ICMP2) An implementation MAY ignore all ICMPv6 messages where the 672 type field is not "Destination Unreachable", "Parameter 673 Problem", or "Packet Too Big". 675 This text is in final form, and is not further updated in this 676 document. 678 --------- 679 Old text: (Appendix C) 680 --------- 682 ICMP7) If the ICMP message is either a v6 "Packet Too Big" or a v4 683 "Fragmentation Needed", an implementation MAY process this 684 information as defined for PATH MTU discovery. 686 --------- 687 New text: (Appendix C) 688 --------- 690 ICMP7) If the ICMP message is either a v6 "Packet Too Big" or a v4 691 "Fragmentation Needed", an implementation MAY process this 692 information as defined for PMTU discovery. 694 This text is in final form, and is not further updated in this 695 document. 697 --------- 698 Old text: (Section 5.4) 699 --------- 701 2) For the receiver of the COOKIE ECHO, the only CONFIRMED address 702 is the one to which the INIT-ACK was sent. 704 --------- 705 New text: (Section 5.4) 706 --------- 708 2) For the receiver of the COOKIE ECHO, the only CONFIRMED address 709 is the one to which the INIT ACK was sent. 711 This text is in final form, and is not further updated in this 712 document. 714 --------- 715 Old text: (Section 5.1.6, Figure 4) 716 --------- 718 COOKIE ECHO [Cookie_Z] ------\ 719 (Start T1-init timer) \ 720 (Enter COOKIE-ECHOED state) \---> (build TCB enter ESTABLISHED 721 state) 722 /---- COOKIE-ACK 723 / 724 (Cancel T1-init timer, <-----/ 725 Enter ESTABLISHED state) 727 --------- 728 New text: (Section 5.1.6, Figure 4) 729 --------- 731 COOKIE ECHO [Cookie_Z] ------\ 732 (Start T1-cookie timer) \ 733 (Enter COOKIE-ECHOED state) \---> (build TCB enter ESTABLISHED 734 state) 735 /---- COOKIE ACK 736 / 737 (Cancel T1-cookie timer, <---/ 738 Enter ESTABLISHED state) 740 This text has been modified by multiple errata. It includes 741 modifications from Section 3.8. It is in final form, and is not 742 further updated in this document. 744 --------- 745 Old text: (Section 5.2.5) 746 --------- 748 5.2.5. Handle Duplicate COOKIE-ACK. 750 --------- 751 New text: (Section 5.2.5) 752 --------- 754 5.2.5. Handle Duplicate COOKIE ACK. 756 This text is in final form, and is not further updated in this 757 document. 759 --------- 760 Old text: (Section 8.3) 761 --------- 763 By default, an SCTP endpoint SHOULD monitor the reachability of the 764 idle destination transport address(es) of its peer by sending a 765 HEARTBEAT chunk periodically to the destination transport 766 address(es). HEARTBEAT sending MAY begin upon reaching the 767 ESTABLISHED state and is discontinued after sending either SHUTDOWN 768 or SHUTDOWN-ACK. A receiver of a HEARTBEAT MUST respond to a 769 HEARTBEAT with a HEARTBEAT-ACK after entering the COOKIE-ECHOED state 770 (INIT sender) or the ESTABLISHED state (INIT receiver), up until 771 reaching the SHUTDOWN-SENT state (SHUTDOWN sender) or the SHUTDOWN- 772 ACK-SENT state (SHUTDOWN receiver). 774 --------- 775 New text: (Section 8.3) 776 --------- 777 By default, an SCTP endpoint SHOULD monitor the reachability of the 778 idle destination transport address(es) of its peer by sending a 779 HEARTBEAT chunk periodically to the destination transport 780 address(es). HEARTBEAT sending MAY begin upon reaching the 781 ESTABLISHED state and is discontinued after sending either SHUTDOWN 782 or SHUTDOWN ACK. A receiver of a HEARTBEAT MUST respond to a 783 HEARTBEAT with a HEARTBEAT ACK after entering the COOKIE-ECHOED state 784 (INIT sender) or the ESTABLISHED state (INIT receiver), up until 785 reaching the SHUTDOWN-SENT state (SHUTDOWN sender) or the SHUTDOWN- 786 ACK-SENT state (SHUTDOWN receiver). 788 This text is in final form, and is not further updated in this 789 document. 791 3.9.3. Solution Description 793 Typos fixed. 795 3.10. CRC32c Sample Code 797 3.10.1. Description of the Problem 799 The CRC32c computation is described in Appendix B of [RFC4960]. 800 However, the corresponding sample code and its explanation appears at 801 the end of Appendix C, which deals with ICMP handling. 803 3.10.2. Text Changes to the Document 805 Move all of Appendix C starting with the following sentence to the 806 end of Appendix B. 808 The following non-normative sample code is taken from an open-source 809 CRC generator [WILLIAMS93], using the "mirroring" technique and 810 yielding a lookup table for SCTP CRC32c with 256 entries, each 32 811 bits wide. 813 This text has been modified by multiple errata. It includes 814 modifications from Section 3.5. It is further updated in 815 Section 3.46. 817 3.10.3. Solution Description 819 Text moved to the appropriate location. 821 3.11. partial_bytes_acked after T3-rtx Expiration 823 3.11.1. Description of the Problem 825 Section 7.2.3 of [RFC4960] explicitly states that partial_bytes_acked 826 should be reset to 0 after packet loss detection from SACK but the 827 same is missed for T3-rtx timer expiration. 829 3.11.2. Text Changes to the Document 831 --------- 832 Old text: (Section 7.2.3) 833 --------- 835 When the T3-rtx timer expires on an address, SCTP should perform slow 836 start by: 838 ssthresh = max(cwnd/2, 4*MTU) 839 cwnd = 1*MTU 841 --------- 842 New text: (Section 7.2.3) 843 --------- 845 When the T3-rtx timer expires on an address, SCTP SHOULD perform slow 846 start by: 848 ssthresh = max(cwnd/2, 4*MTU) 849 cwnd = 1*MTU 850 partial_bytes_acked = 0 851 This text is in final form, and is not further updated in this 852 document. 854 3.11.3. Solution Description 856 Specify that partial_bytes_acked should be reset to 0 after T3-rtx 857 timer expiration. 859 3.12. Order of Adjustments of partial_bytes_acked and cwnd 861 3.12.1. Description of the Problem 863 Section 7.2.2 of [RFC4960] likely implies the wrong order of 864 adjustments applied to partial_bytes_acked and cwnd in the congestion 865 avoidance phase. 867 3.12.2. Text Changes to the Document 869 --------- 870 Old text: (Section 7.2.2) 871 --------- 873 o When partial_bytes_acked is equal to or greater than cwnd and 874 before the arrival of the SACK the sender had cwnd or more bytes 875 of data outstanding (i.e., before arrival of the SACK, flightsize 876 was greater than or equal to cwnd), increase cwnd by MTU, and 877 reset partial_bytes_acked to (partial_bytes_acked - cwnd). 879 --------- 880 New text: (Section 7.2.2) 881 --------- 883 o When partial_bytes_acked is equal to or greater than cwnd and 884 before the arrival of the SACK the sender had cwnd or more bytes 885 of data outstanding (i.e., before arrival of the SACK, flightsize 886 was greater than or equal to cwnd), partial_bytes_acked is reset 887 to (partial_bytes_acked - cwnd). Next, cwnd is increased by 1*MTU. 889 This text has been modified by multiple errata. It is further 890 updated in Section 3.26. 892 3.12.3. Solution Description 894 The new text defines the exact order of adjustments of 895 partial_bytes_acked and cwnd in the congestion avoidance phase. 897 3.13. HEARTBEAT ACK and the association error counter 899 3.13.1. Description of the Problem 901 Section 8.1 and Section 8.3 of [RFC4960] prescribe that the receiver 902 of a HEARTBEAT ACK must reset the association overall error counter. 903 In some circumstances, e.g. when a router discards DATA chunks but 904 not HEARTBEAT chunks due to the larger size of the DATA chunk, it 905 might be better to not clear the association error counter on 906 reception of the HEARTBEAT ACK and reset it only on reception of the 907 SACK to avoid stalling the association. 909 3.13.2. Text Changes to the Document 911 --------- 912 Old text: (Section 8.1) 913 --------- 915 The counter shall be reset each time a DATA chunk sent to that peer 916 endpoint is acknowledged (by the reception of a SACK) or a HEARTBEAT 917 ACK is received from the peer endpoint. 919 --------- 920 New text: (Section 8.1) 921 --------- 923 The counter MUST be reset each time a DATA chunk sent to that peer 924 endpoint is acknowledged (by the reception of a SACK). When a 925 HEARTBEAT ACK is received from the peer endpoint, the counter SHOULD 926 also be reset. The receiver of the HEARTBEAT ACK MAY choose not to 927 clear the counter if there is outstanding data on the association. 928 This allows for handling the possible difference in reachability 929 based on DATA chunks and HEARTBEAT chunks. 931 This text is in final form, and is not further updated in this 932 document. 934 --------- 935 Old text: (Section 8.3) 936 --------- 938 Upon the receipt of the HEARTBEAT ACK, the sender of the HEARTBEAT 939 should clear the error counter of the destination transport address 940 to which the HEARTBEAT was sent, and mark the destination transport 941 address as active if it is not so marked. The endpoint may 942 optionally report to the upper layer when an inactive destination 943 address is marked as active due to the reception of the latest 944 HEARTBEAT ACK. The receiver of the HEARTBEAT ACK must also clear the 945 association overall error count as well (as defined in Section 8.1). 947 --------- 948 New text: (Section 8.3) 949 --------- 951 Upon the receipt of the HEARTBEAT ACK, the sender of the HEARTBEAT 952 MUST clear the error counter of the destination transport address 953 to which the HEARTBEAT was sent, and mark the destination transport 954 address as active if it is not so marked. The endpoint MAY 955 optionally report to the upper layer when an inactive destination 956 address is marked as active due to the reception of the latest 957 HEARTBEAT ACK. The receiver of the HEARTBEAT ACK SHOULD also clear 958 the association overall error counter (as defined in Section 8.1). 960 This text has been modified by multiple errata. It is further 961 updated in Section 3.23. 963 3.13.3. Solution Description 965 The new text provides a possibility to not reset the association 966 overall error counter when a HEARTBEAT ACK is received if there are 967 valid reasons for it. 969 3.14. Path for Fast Retransmission 971 3.14.1. Description of the Problem 973 [RFC4960] clearly describes where to retransmit data that is timed 974 out when the peer is multi-homed but the same is not stated for fast 975 retransmissions. 977 3.14.2. Text Changes to the Document 978 --------- 979 Old text: (Section 6.4) 980 --------- 982 Furthermore, when its peer is multi-homed, an endpoint SHOULD try to 983 retransmit a chunk that timed out to an active destination transport 984 address that is different from the last destination address to which 985 the DATA chunk was sent. 987 --------- 988 New text: (Section 6.4) 989 --------- 991 Furthermore, when its peer is multi-homed, an endpoint SHOULD try to 992 retransmit a chunk that timed out to an active destination transport 993 address that is different from the last destination address to which 994 the DATA chunk was sent. 996 When its peer is multi-homed, an endpoint SHOULD send fast 997 retransmissions to the same destination transport address where the 998 original data was sent to. If the primary path has been changed and the 999 original data was sent to the old primary path before the fast 1000 retransmit, the implementation MAY send it to the new primary path. 1002 This text is in final form, and is not further updated in this 1003 document. 1005 3.14.3. Solution Description 1007 The new text clarifies where to send fast retransmissions. 1009 3.15. Transmittal in Fast Recovery 1011 3.15.1. Description of the Problem 1013 The Fast Retransmit on Gap Reports algorithm intends that only the 1014 very first packet may be sent regardless of cwnd in the Fast Recovery 1015 phase but rule 3) of [RFC4960], Section 7.2.4, misses this 1016 clarification. 1018 3.15.2. Text Changes to the Document 1019 --------- 1020 Old text: (Section 7.2.4) 1021 --------- 1023 3) Determine how many of the earliest (i.e., lowest TSN) DATA chunks 1024 marked for retransmission will fit into a single packet, subject 1025 to constraint of the path MTU of the destination transport 1026 address to which the packet is being sent. Call this value K. 1027 Retransmit those K DATA chunks in a single packet. When a Fast 1028 Retransmit is being performed, the sender SHOULD ignore the value 1029 of cwnd and SHOULD NOT delay retransmission for this single 1030 packet. 1032 --------- 1033 New text: (Section 7.2.4) 1034 --------- 1036 3) If not in Fast Recovery, determine how many of the earliest 1037 (i.e., lowest TSN) DATA chunks marked for retransmission will fit 1038 into a single packet, subject to constraint of the PMTU of 1039 the destination transport address to which the packet is being 1040 sent. Call this value K. Retransmit those K DATA chunks in a 1041 single packet. When a Fast Retransmit is being performed, the 1042 sender SHOULD ignore the value of cwnd and SHOULD NOT delay 1043 retransmission for this single packet. 1045 This text is in final form, and is not further updated in this 1046 document. 1048 3.15.3. Solution Description 1050 The new text explicitly specifies to send only the first packet in 1051 the Fast Recovery phase disregarding cwnd limitations. 1053 3.16. Initial Value of ssthresh 1055 3.16.1. Description of the Problem 1057 The initial value of ssthresh should be set arbitrarily high. Using 1058 the advertised receiver window of the peer is inappropriate if the 1059 peer increases its window after the handshake. Furthermore, use a 1060 higher requirements level, since not following the advice may result 1061 in performance problems. 1063 3.16.2. Text Changes to the Document 1065 --------- 1066 Old text: (Section 7.2.1) 1067 --------- 1069 o The initial value of ssthresh MAY be arbitrarily high (for 1070 example, implementations MAY use the size of the receiver 1071 advertised window). 1073 --------- 1074 New text: (Section 7.2.1) 1075 --------- 1077 o The initial value of ssthresh SHOULD be arbitrarily high (e.g., 1078 the size of the largest possible advertised window). 1080 This text is in final form, and is not further updated in this 1081 document. 1083 3.16.3. Solution Description 1085 Use the same value as suggested in [RFC5681], Section 3.1, as an 1086 appropriate initial value. Furthermore, use the same requirements 1087 level. 1089 3.17. Automatically Confirmed Addresses 1091 3.17.1. Description of the Problem 1093 The Path Verification procedure of [RFC4960] prescribes that any 1094 address passed to the sender of the INIT by its upper layer is 1095 automatically CONFIRMED. This, however, is unclear if only addresses 1096 in the request to initiate association establishment are considered 1097 or any addresses provided by the upper layer in any requests (e.g. in 1098 'Set Primary'). 1100 3.17.2. Text Changes to the Document 1101 --------- 1102 Old text: (Section 5.4) 1103 --------- 1105 1) Any address passed to the sender of the INIT by its upper layer 1106 is automatically considered to be CONFIRMED. 1108 --------- 1109 New text: (Section 5.4) 1110 --------- 1112 1) Any addresses passed to the sender of the INIT by its upper 1113 layer in the request to initialize an association are 1114 automatically considered to be CONFIRMED. 1116 This text is in final form, and is not further updated in this 1117 document. 1119 3.17.3. Solution Description 1121 The new text clarifies that only addresses provided by the upper 1122 layer in the request to initialize an association are automatically 1123 confirmed. 1125 3.18. Only One Packet after Retransmission Timeout 1127 3.18.1. Description of the Problem 1129 [RFC4960] is not completely clear when it describes data transmission 1130 after T3-rtx timer expiration. Section 7.2.1 does not specify how 1131 many packets are allowed to be sent after T3-rtx timer expiration if 1132 more than one packet fit into cwnd. At the same time, Section 7.2.3 1133 has the text without normative language saying that SCTP should 1134 ensure that no more than one packet will be in flight after T3-rtx 1135 timer expiration until successful acknowledgment. It makes the text 1136 inconsistent. 1138 3.18.2. Text Changes to the Document 1139 --------- 1140 Old text: (Section 7.2.1) 1141 --------- 1143 o The initial cwnd after a retransmission timeout MUST be no more 1144 than 1*MTU. 1146 --------- 1147 New text: (Section 7.2.1) 1148 --------- 1150 o The initial cwnd after a retransmission timeout MUST be no more 1151 than 1*MTU and only one packet is allowed to be in flight 1152 until successful acknowledgement. 1154 This text is in final form, and is not further updated in this 1155 document. 1157 3.18.3. Solution Description 1159 The new text clearly specifies that only one packet is allowed to be 1160 sent after T3-rtx timer expiration until successful acknowledgement. 1162 3.19. INIT ACK Path for INIT in COOKIE-WAIT State 1164 3.19.1. Description of the Problem 1166 In case of an INIT received in the COOKIE-WAIT state [RFC4960] 1167 prescribes to send an INIT ACK to the same destination address to 1168 which the original INIT has been sent. This text does not address 1169 the possibility of the upper layer to provide multiple remote IP 1170 addresses while requesting the association establishment. If the 1171 upper layer has provided multiple IP addresses and only a subset of 1172 these addresses are supported by the peer then the destination 1173 address of the original INIT may be absent in the incoming INIT and 1174 sending INIT ACK to that address is useless. 1176 3.19.2. Text Changes to the Document 1177 --------- 1178 Old text: (Section 5.2.1) 1179 --------- 1181 Upon receipt of an INIT in the COOKIE-WAIT state, an endpoint MUST 1182 respond with an INIT ACK using the same parameters it sent in its 1183 original INIT chunk (including its Initiate Tag, unchanged). When 1184 responding, the endpoint MUST send the INIT ACK back to the same 1185 address that the original INIT (sent by this endpoint) was sent. 1187 --------- 1188 New text: (Section 5.2.1) 1189 --------- 1191 Upon receipt of an INIT in the COOKIE-WAIT state, an endpoint MUST 1192 respond with an INIT ACK using the same parameters it sent in its 1193 original INIT chunk (including its Initiate Tag, unchanged). When 1194 responding, the following rules MUST be applied: 1196 1) The INIT ACK MUST only be sent to an address passed by the upper 1197 layer in the request to initialize the association. 1199 2) The INIT ACK MUST only be sent to an address reported in the 1200 incoming INIT. 1202 3) The INIT ACK SHOULD be sent to the source address of the 1203 received INIT. 1205 This text is in final form, and is not further updated in this 1206 document. 1208 3.19.3. Solution Description 1210 The new text requires sending INIT ACK to a destination address that 1211 is passed by the upper layer and reported in the incoming INIT. If 1212 the source address of the INIT meets these conditions, sending the 1213 INIT ACK to the source address of the INIT is the preferred behavior. 1215 3.20. Zero Window Probing and Unreachable Primary Path 1217 3.20.1. Description of the Problem 1219 Section 6.1 of [RFC4960] states that when sending zero window probes, 1220 SCTP should neither increment the association counter nor increment 1221 the destination address error counter if it continues to receive new 1222 packets from the peer. However, the reception of new packets from 1223 the peer does not guarantee the peer's reachability and, if the 1224 destination address becomes unreachable during zero window probing, 1225 SCTP cannot get an updated rwnd until it switches the destination 1226 address for probes. 1228 3.20.2. Text Changes to the Document 1230 --------- 1231 Old text: (Section 6.1) 1232 --------- 1234 If the sender continues to receive new packets from the receiver 1235 while doing zero window probing, the unacknowledged window probes 1236 should not increment the error counter for the association or any 1237 destination transport address. This is because the receiver MAY 1238 keep its window closed for an indefinite time. Refer to Section 1239 6.2 on the receiver behavior when it advertises a zero window. 1241 --------- 1242 New text: (Section 6.1) 1243 --------- 1245 If the sender continues to receive SACKs from the peer 1246 while doing zero window probing, the unacknowledged window probes 1247 SHOULD NOT increment the error counter for the association or any 1248 destination transport address. This is because the receiver could 1249 keep its window closed for an indefinite time. Section 6.2 describes 1250 the receiver behavior when it advertises a zero window. 1252 This text is in final form, and is not further updated in this 1253 document. 1255 3.20.3. Solution Description 1257 The new text clarifies that if the receiver continues to send SACKs, 1258 the sender of probes should not increment the error counter of the 1259 association and the destination address even if the SACKs do not 1260 acknowledge the probes. 1262 3.21. Normative Language in Section 10 1264 3.21.1. Description of the Problem 1266 Section 10 of [RFC4960] is informative and, therefore, normative 1267 language such as MUST and MAY cannot be used there. However, there 1268 are several places in Section 10 where MUST and MAY are used. 1270 3.21.2. Text Changes to the Document 1272 --------- 1273 Old text: (Section 10.1 E)) 1274 --------- 1276 o no-bundle flag - instructs SCTP not to bundle this user data with 1277 other outbound DATA chunks. SCTP MAY still bundle even when this 1278 flag is present, when faced with network congestion. 1280 --------- 1281 New text: (Section 10.1 E)) 1282 --------- 1284 o no-bundle flag - instructs SCTP not to bundle this user data with 1285 other outbound DATA chunks. SCTP may still bundle even when this 1286 flag is present, when faced with network congestion. 1288 This text is in final form, and is not further updated in this 1289 document. 1291 --------- 1292 Old text: (Section 10.1 G)) 1293 --------- 1295 o Stream Sequence Number - the Stream Sequence Number assigned by 1296 the sending SCTP peer. 1298 o partial flag - if this returned flag is set to 1, then this 1299 Receive contains a partial delivery of the whole message. When 1300 this flag is set, the stream id and Stream Sequence Number MUST 1301 accompany this receive. When this flag is set to 0, it indicates 1302 that no more deliveries will be received for this Stream Sequence 1303 Number. 1305 --------- 1306 New text: (Section 10.1 G)) 1307 --------- 1309 o stream sequence number - the Stream Sequence Number assigned by 1310 the sending SCTP peer. 1312 o partial flag - if this returned flag is set to 1, then this 1313 primitive contains a partial delivery of the whole message. When 1314 this flag is set, the stream id and stream sequence number must 1315 accompany this primitive. When this flag is set to 0, it indicates 1316 that no more deliveries will be received for this stream sequence 1317 number. 1319 This text is in final form, and is not further updated in this 1320 document. 1322 --------- 1323 Old text: (Section 10.1 N)) 1324 --------- 1326 o Stream Sequence Number - this value is returned indicating the 1327 Stream Sequence Number that was associated with the message. 1329 o partial flag - if this returned flag is set to 1, then this 1330 message is a partial delivery of the whole message. When this 1331 flag is set, the stream id and Stream Sequence Number MUST 1332 accompany this receive. When this flag is set to 0, it indicates 1333 that no more deliveries will be received for this Stream Sequence 1334 Number. 1336 --------- 1337 New text: (Section 10.1 N)) 1338 --------- 1340 o stream sequence number - this value is returned indicating the 1341 Stream Sequence Number that was associated with the message. 1343 o partial flag - if this returned flag is set to 1, then this 1344 message is a partial delivery of the whole message. When this 1345 flag is set, the stream id and stream sequence number must 1346 accompany this primitive. When this flag is set to 0, it indicates 1347 that no more deliveries will be received for this stream sequence 1348 number. 1350 This text is in final form, and is not further updated in this 1351 document. 1353 --------- 1354 Old text: (Section 10.1 O)) 1355 --------- 1357 o Stream Sequence Number - this value is returned indicating the 1358 Stream Sequence Number that was associated with the message. 1360 o partial flag - if this returned flag is set to 1, then this 1361 message is a partial delivery of the whole message. When this 1362 flag is set, the stream id and Stream Sequence Number MUST 1363 accompany this receive. When this flag is set to 0, it indicates 1364 that no more deliveries will be received for this Stream Sequence 1365 Number. 1367 --------- 1368 New text: (Section 10.1 O)) 1369 --------- 1371 o stream sequence number - this value is returned indicating the 1372 Stream Sequence Number that was associated with the message. 1374 o partial flag - if this returned flag is set to 1, then this 1375 message is a partial delivery of the whole message. When this 1376 flag is set, the stream id and stream sequence number must 1377 accompany this primitive. When this flag is set to 0, it indicates 1378 that no more deliveries will be received for this stream sequence 1379 number. 1381 This text is in final form, and is not further updated in this 1382 document. 1384 3.21.3. Solution Description 1386 The normative language is removed from Section 10. In addition, the 1387 consistency of the text has been improved. 1389 3.22. Increase of partial_bytes_acked in Congestion Avoidance 1391 3.22.1. Description of the Problem 1393 Two issues have been discovered with the partial_bytes_acked handling 1394 described in Section 7.2.2 of [RFC4960]: 1396 o If the Cumulative TSN Ack Point is not advanced but the SACK chunk 1397 acknowledges new TSNs in the Gap Ack Blocks, these newly 1398 acknowledged TSNs are not considered for partial_bytes_acked 1399 although these TSNs were successfully received by the peer. 1401 o Duplicate TSNs are not considered in partial_bytes_acked although 1402 they confirm that the DATA chunks were successfully received by 1403 the peer. 1405 3.22.2. Text Changes to the Document 1407 --------- 1408 Old text: (Section 7.2.2) 1409 --------- 1411 o Whenever cwnd is greater than ssthresh, upon each SACK arrival 1412 that advances the Cumulative TSN Ack Point, increase 1413 partial_bytes_acked by the total number of bytes of all new chunks 1414 acknowledged in that SACK including chunks acknowledged by the new 1415 Cumulative TSN Ack and by Gap Ack Blocks. 1417 --------- 1418 New text: (Section 7.2.2) 1419 --------- 1421 o Whenever cwnd is greater than ssthresh, upon each SACK arrival, 1422 increase partial_bytes_acked by the total number of bytes of all 1423 new chunks acknowledged in that SACK including chunks acknowledged 1424 by the new Cumulative TSN Ack, by Gap Ack Blocks and by the number 1425 of bytes of duplicated chunks reported in Duplicate TSNs. 1427 This text has been modified by multiple errata. It is further 1428 updated in Section 3.26. 1430 3.22.3. Solution Description 1432 Now partial_bytes_acked is increased by TSNs reported as duplicated 1433 as well as TSNs newly acknowledged in Gap Ack Blocks even if the 1434 Cumulative TSN Ack Point is not advanced. 1436 3.23. Inconsistency in Notifications Handling 1438 3.23.1. Description of the Problem 1440 [RFC4960] uses inconsistent normative and non-normative language when 1441 describing rules for sending notifications to the upper layer. E.g. 1442 Section 8.2 of [RFC4960] says that when a destination address becomes 1443 inactive due to an unacknowledged DATA chunk or HEARTBEAT chunk, SCTP 1444 SHOULD send a notification to the upper layer while Section 8.3 of 1445 [RFC4960] says that when a destination address becomes inactive due 1446 to an unacknowledged HEARTBEAT chunk, SCTP may send a notification to 1447 the upper layer. 1449 This makes the text inconsistent. 1451 3.23.2. Text Changes to the Document 1453 --------- 1454 Old text: (Section 8.1) 1455 --------- 1457 An endpoint shall keep a counter on the total number of consecutive 1458 retransmissions to its peer (this includes retransmissions to all the 1459 destination transport addresses of the peer if it is multi-homed), 1460 including unacknowledged HEARTBEAT chunks. 1462 --------- 1463 New text: (Section 8.1) 1464 --------- 1466 An endpoint SHOULD keep a counter on the total number of consecutive 1467 retransmissions to its peer (this includes data retransmissions 1468 to all the destination transport addresses of the peer if it is 1469 multi-homed), including the number of unacknowledged HEARTBEAT 1470 chunks observed on the path which currently is used for data 1471 transfer. Unacknowledged HEARTBEAT chunks observed on paths 1472 different from the path currently used for data transfer SHOULD 1473 NOT increment the association error counter, as this could lead 1474 to association closure even if the path which currently is used for 1475 data transfer is available (but idle). If the value of this 1476 counter exceeds the limit indicated in the protocol parameter 1477 'Association.Max.Retrans', the endpoint SHOULD consider the peer 1478 endpoint unreachable and SHALL stop transmitting any more data to it 1479 (and thus the association enters the CLOSED state). In addition, the 1480 endpoint SHOULD report the failure to the upper layer and optionally 1481 report back all outstanding user data remaining in its outbound 1482 queue. The association is automatically closed when the peer 1483 endpoint becomes unreachable. 1485 This text has been modified by multiple errata. It includes 1486 modifications from Section 3.6. It is in final form, and is not 1487 further updated in this document. 1489 --------- 1490 Old text: (Section 8.2) 1491 --------- 1493 When an outstanding TSN is acknowledged or a HEARTBEAT sent to that 1494 address is acknowledged with a HEARTBEAT ACK, the endpoint shall 1495 clear the error counter of the destination transport address to which 1496 the DATA chunk was last sent (or HEARTBEAT was sent). When the peer 1497 endpoint is multi-homed and the last chunk sent to it was a 1498 retransmission to an alternate address, there exists an ambiguity as 1499 to whether or not the acknowledgement should be credited to the 1500 address of the last chunk sent. However, this ambiguity does not 1501 seem to bear any significant consequence to SCTP behavior. If this 1502 ambiguity is undesirable, the transmitter may choose not to clear the 1503 error counter if the last chunk sent was a retransmission. 1505 --------- 1506 New text: (Section 8.2) 1507 --------- 1509 When an outstanding TSN is acknowledged or a HEARTBEAT sent to that 1510 address is acknowledged with a HEARTBEAT ACK, the endpoint SHOULD 1511 clear the error counter of the destination transport address to which 1512 the DATA chunk was last sent (or HEARTBEAT was sent), and SHOULD 1513 also report to the upper layer when an inactive destination address 1514 is marked as active. When the peer endpoint is multi-homed and the 1515 last chunk sent to it was a retransmission to an alternate address, 1516 there exists an ambiguity as to whether or not the acknowledgement 1517 could be credited to the address of the last chunk sent. However, 1518 this ambiguity does not seem to bear any significant consequence to 1519 SCTP behavior. If this ambiguity is undesirable, the transmitter MAY 1520 choose not to clear the error counter if the last chunk sent was a 1521 retransmission. 1523 This text is in final form, and is not further updated in this 1524 document. 1526 --------- 1527 Old text: (Section 8.3) 1528 --------- 1530 When the value of this counter reaches the protocol parameter 1531 'Path.Max.Retrans', the endpoint should mark the corresponding 1532 destination address as inactive if it is not so marked, and may also 1533 optionally report to the upper layer the change of reachability of 1534 this destination address. After this, the endpoint should continue 1535 HEARTBEAT on this destination address but should stop increasing the 1536 counter. 1538 --------- 1539 New text: (Section 8.3) 1540 --------- 1542 When the value of this counter exceeds the protocol parameter 1543 'Path.Max.Retrans', the endpoint SHOULD mark the corresponding 1544 destination address as inactive if it is not so marked, and SHOULD 1545 also report to the upper layer the change of reachability of this 1546 destination address. After this, the endpoint SHOULD continue 1547 HEARTBEAT on this destination address but SHOULD stop increasing the 1548 counter. 1550 This text has been modified by multiple errata. It includes 1551 modifications from Section 3.1. It is in final form, and is not 1552 further updated in this document. 1554 --------- 1555 Old text: (Section 8.3) 1556 --------- 1558 Upon the receipt of the HEARTBEAT ACK, the sender of the HEARTBEAT 1559 should clear the error counter of the destination transport address 1560 to which the HEARTBEAT was sent, and mark the destination transport 1561 address as active if it is not so marked. The endpoint may 1562 optionally report to the upper layer when an inactive destination 1563 address is marked as active due to the reception of the latest 1564 HEARTBEAT ACK. The receiver of the HEARTBEAT ACK must also clear the 1565 association overall error count as well (as defined in Section 8.1). 1567 --------- 1568 New text: (Section 8.3) 1569 --------- 1571 Upon the receipt of the HEARTBEAT ACK, the sender of the HEARTBEAT 1572 SHOULD clear the error counter of the destination transport address 1573 to which the HEARTBEAT was sent, and mark the destination transport 1574 address as active if it is not so marked. The endpoint SHOULD 1575 report to the upper layer when an inactive destination address 1576 is marked as active due to the reception of the latest 1577 HEARTBEAT ACK. The receiver of the HEARTBEAT ACK SHOULD also clear 1578 the association overall error counter (as defined in Section 8.1). 1580 This text has been modified by multiple errata. It includes 1581 modifications from Section 3.13. It is in final form, and is not 1582 further updated in this document. 1584 --------- 1585 Old text: (Section 9.2) 1586 --------- 1588 An endpoint should limit the number of retransmissions of the 1589 SHUTDOWN chunk to the protocol parameter 'Association.Max.Retrans'. 1590 If this threshold is exceeded, the endpoint should destroy the TCB 1591 and MUST report the peer endpoint unreachable to the upper layer (and 1592 thus the association enters the CLOSED state). 1594 --------- 1595 New text: (Section 9.2) 1596 --------- 1598 An endpoint SHOULD limit the number of retransmissions of the 1599 SHUTDOWN chunk to the protocol parameter 'Association.Max.Retrans'. 1600 If this threshold is exceeded, the endpoint SHOULD destroy the TCB 1601 and SHOULD report the peer endpoint unreachable to the upper layer 1602 (and thus the association enters the CLOSED state). 1604 This text is in final form, and is not further updated in this 1605 document. 1607 --------- 1608 Old text: (Section 9.2) 1609 --------- 1611 The sender of the SHUTDOWN ACK should limit the number of 1612 retransmissions of the SHUTDOWN ACK chunk to the protocol parameter 1613 'Association.Max.Retrans'. If this threshold is exceeded, the 1614 endpoint should destroy the TCB and may report the peer endpoint 1615 unreachable to the upper layer (and thus the association enters the 1616 CLOSED state). 1618 --------- 1619 New text: (Section 9.2) 1620 --------- 1622 The sender of the SHUTDOWN ACK SHOULD limit the number of 1623 retransmissions of the SHUTDOWN ACK chunk to the protocol parameter 1624 'Association.Max.Retrans'. If this threshold is exceeded, the 1625 endpoint SHOULD destroy the TCB and SHOULD report the peer endpoint 1626 unreachable to the upper layer (and thus the association enters the 1627 CLOSED state). 1629 This text is in final form, and is not further updated in this 1630 document. 1632 3.23.3. Solution Description 1634 The inconsistencies are removed by using consistently SHOULD. 1636 3.24. SACK.Delay Not Listed as a Protocol Parameter 1638 3.24.1. Description of the Problem 1640 SCTP as specified in [RFC4960] supports delaying SACKs. The timer 1641 value for this is a parameter and Section 6.2 of [RFC4960] specifies 1642 a default and maximum value for it. However, defining a name for 1643 this parameter and listing it in the table of protocol parameters in 1644 Section 15 of [RFC4960] is missing. 1646 This issue was reported as an Errata for [RFC4960] with Errata ID 1647 4656. 1649 3.24.2. Text Changes to the Document 1651 --------- 1652 Old text: (Section 6.2) 1653 --------- 1655 An implementation MUST NOT allow the maximum delay to be configured 1656 to be more than 500 ms. In other words, an implementation MAY lower 1657 this value below 500 ms but MUST NOT raise it above 500 ms. 1659 --------- 1660 New text: (Section 6.2) 1661 --------- 1663 An implementation MUST NOT allow the maximum delay (protocol 1664 parameter 'SACK.Delay') to be configured to be more than 500 ms. 1665 In other words, an implementation MAY lower the value of 1666 SACK.Delay below 500 ms but MUST NOT raise it above 500 ms. 1668 This text is in final form, and is not further updated in this 1669 document. 1671 --------- 1672 Old text: (Section 15) 1673 --------- 1675 The following protocol parameters are RECOMMENDED: 1677 RTO.Initial - 3 seconds 1678 RTO.Min - 1 second 1679 RTO.Max - 60 seconds 1680 Max.Burst - 4 1681 RTO.Alpha - 1/8 1682 RTO.Beta - 1/4 1683 Valid.Cookie.Life - 60 seconds 1684 Association.Max.Retrans - 10 attempts 1685 Path.Max.Retrans - 5 attempts (per destination address) 1686 Max.Init.Retransmits - 8 attempts 1687 HB.interval - 30 seconds 1688 HB.Max.Burst - 1 1690 --------- 1691 New text: (Section 15) 1692 --------- 1694 The following protocol parameters are RECOMMENDED: 1696 RTO.Initial - 3 seconds 1697 RTO.Min - 1 second 1698 RTO.Max - 60 seconds 1699 Max.Burst - 4 1700 RTO.Alpha - 1/8 1701 RTO.Beta - 1/4 1702 Valid.Cookie.Life - 60 seconds 1703 Association.Max.Retrans - 10 attempts 1704 Path.Max.Retrans - 5 attempts (per destination address) 1705 Max.Init.Retransmits - 8 attempts 1706 HB.interval - 30 seconds 1707 HB.Max.Burst - 1 1708 SACK.Delay - 200 milliseconds 1710 This text has been modified by multiple errata. It is further 1711 updated in Section 3.32. 1713 3.24.3. Solution Description 1715 The parameter was given a name and added to the list of protocol 1716 parameters. 1718 3.25. Processing of Chunks in an Incoming SCTP Packet 1720 3.25.1. Description of the Problem 1722 There are a few places in [RFC4960] where the receiver of a packet 1723 must discard it while processing the chunks of the packet. It is 1724 unclear whether the receiver has to rollback state changes already 1725 performed while processing the packet or not. 1727 The intention of [RFC4960] is to process an incoming packet chunk by 1728 chunk and not to perform any prescreening of chunks in the received 1729 packet. Thus, by discarding one chunk the receiver also causes 1730 discarding of all further chunks. 1732 3.25.2. Text Changes to the Document 1734 --------- 1735 Old text: (Section 3.2) 1736 --------- 1738 00 - Stop processing this SCTP packet and discard it, do not 1739 process any further chunks within it. 1741 01 - Stop processing this SCTP packet and discard it, do not 1742 process any further chunks within it, and report the 1743 unrecognized chunk in an 'Unrecognized Chunk Type'. 1745 --------- 1746 New text: (Section 3.2) 1747 --------- 1749 00 - Stop processing this SCTP packet, discard the unrecognized 1750 chunk and all further chunks. 1752 01 - Stop processing this SCTP packet, discard the unrecognized 1753 chunk and all further chunks, and report the unrecognized 1754 chunk in an 'Unrecognized Chunk Type'. 1756 This text is in final form, and is not further updated in this 1757 document. 1759 --------- 1760 Old text: (Section 11.3) 1761 --------- 1763 It is helpful for some firewalls if they can inspect just the first 1764 fragment of a fragmented SCTP packet and unambiguously determine 1765 whether it corresponds to an INIT chunk (for further information, 1766 please refer to [RFC1858]). Accordingly, we stress the requirements, 1767 stated in Section 3.1, that (1) an INIT chunk MUST NOT be bundled 1768 with any other chunk in a packet, and (2) a packet containing an INIT 1769 chunk MUST have a zero Verification Tag. Furthermore, we require 1770 that the receiver of an INIT chunk MUST enforce these rules by 1771 silently discarding an arriving packet with an INIT chunk that is 1772 bundled with other chunks or has a non-zero verification tag and 1773 contains an INIT-chunk. 1775 --------- 1776 New text: (Section 11.3) 1777 --------- 1779 It is helpful for some firewalls if they can inspect just the first 1780 fragment of a fragmented SCTP packet and unambiguously determine 1781 whether it corresponds to an INIT chunk (for further information, 1782 please refer to [RFC1858]). Accordingly, we stress the requirements, 1783 stated in Section 3.1, that (1) an INIT chunk MUST NOT be bundled 1784 with any other chunk in a packet, and (2) a packet containing an INIT 1785 chunk MUST have a zero Verification Tag. 1786 The receiver of an INIT chunk MUST silently discard the INIT chunk and 1787 all further chunks if the INIT chunk is bundled with other chunks or 1788 the packet has a non-zero verification tag. 1790 This text is in final form, and is not further updated in this 1791 document. 1793 3.25.3. Solution Description 1795 The new text makes it clear that chunks can be processed from the 1796 beginning to the end and no rollback or pre-screening is required. 1798 3.26. CWND Increase in Congestion Avoidance Phase 1800 3.26.1. Description of the Problem 1802 [RFC4960] in Section 7.2.2 prescribes to increase cwnd by 1*MTU per 1803 RTT if the sender has cwnd or more bytes of data outstanding to the 1804 corresponding address in the Congestion Avoidance phase. However, 1805 this is described without normative language. Moreover, 1806 Section 7.2.2 includes an algorithm how an implementation can achieve 1807 this but this algorithm is underspecified and actually allows 1808 increasing cwnd by more than 1*MTU per RTT. 1810 3.26.2. Text Changes to the Document 1812 --------- 1813 Old text: (Section 7.2.2) 1814 --------- 1816 When cwnd is greater than ssthresh, cwnd should be incremented by 1817 1*MTU per RTT if the sender has cwnd or more bytes of data 1818 outstanding for the corresponding transport address. 1820 --------- 1821 New text: (Section 7.2.2) 1822 --------- 1824 When cwnd is greater than ssthresh, cwnd SHOULD be incremented by 1825 1*MTU per RTT if the sender has cwnd or more bytes of data 1826 outstanding for the corresponding transport address. The basic 1827 guidelines for incrementing cwnd during congestion avoidance are: 1829 o SCTP MAY increment cwnd by 1*MTU. 1831 o SCTP SHOULD increment cwnd by one 1*MTU once per RTT when 1832 the sender has cwnd or more bytes of data outstanding for 1833 the corresponding transport address. 1835 o SCTP MUST NOT increment cwnd by more than 1*MTU per RTT. 1837 This text is in final form, and is not further updated in this 1838 document. 1840 --------- 1841 Old text: (Section 7.2.2) 1842 --------- 1844 o Whenever cwnd is greater than ssthresh, upon each SACK arrival 1845 that advances the Cumulative TSN Ack Point, increase 1846 partial_bytes_acked by the total number of bytes of all new chunks 1847 acknowledged in that SACK including chunks acknowledged by the new 1848 Cumulative TSN Ack and by Gap Ack Blocks. 1850 o When partial_bytes_acked is equal to or greater than cwnd and 1851 before the arrival of the SACK the sender had cwnd or more bytes 1852 of data outstanding (i.e., before arrival of the SACK, flightsize 1853 was greater than or equal to cwnd), increase cwnd by MTU, and 1854 reset partial_bytes_acked to (partial_bytes_acked - cwnd). 1856 --------- 1857 New text: (Section 7.2.2) 1858 --------- 1860 o Whenever cwnd is greater than ssthresh, upon each SACK arrival, 1861 increase partial_bytes_acked by the total number of bytes of all 1862 new chunks acknowledged in that SACK including chunks acknowledged 1863 by the new Cumulative TSN Ack, by Gap Ack Blocks and by the number 1864 of bytes of duplicated chunks reported in Duplicate TSNs. 1866 o When partial_bytes_acked is greater than cwnd and before the 1867 arrival of the SACK the sender had less than cwnd bytes of data 1868 outstanding (i.e., before arrival of the SACK, flightsize was less 1869 than cwnd), reset partial_bytes_acked to cwnd. 1871 o When partial_bytes_acked is equal to or greater than cwnd and 1872 before the arrival of the SACK the sender had cwnd or more bytes 1873 of data outstanding (i.e., before arrival of the SACK, flightsize 1874 was greater than or equal to cwnd), partial_bytes_acked is reset 1875 to (partial_bytes_acked - cwnd). Next, cwnd is increased by 1*MTU. 1877 This text has been modified by multiple errata. It includes 1878 modifications from Section 3.12 and Section 3.22. It is in final 1879 form, and is not further updated in this document. 1881 3.26.3. Solution Description 1883 The basic guidelines for incrementing cwnd during the congestion 1884 avoidance phase are added into Section 7.2.2. The guidelines include 1885 the normative language and are aligned with [RFC5681]. 1887 The algorithm from Section 7.2.2 is improved to not allow increasing 1888 cwnd by more than 1*MTU per RTT. 1890 3.27. Refresh of cwnd and ssthresh after Idle Period 1892 3.27.1. Description of the Problem 1894 [RFC4960] prescribes to adjust cwnd per RTO if the endpoint does not 1895 transmit data on a given transport address. In addition to that, it 1896 prescribes to set cwnd to the initial value after a sufficiently long 1897 idle period. The latter is excessive. Moreover, it is unclear what 1898 is a sufficiently long idle period. 1900 [RFC4960] doesn't specify the handling of ssthresh in the idle case. 1901 If ssthresh is reduced due to a packet loss, ssthresh is never 1902 recovered. So traffic can end up in Congestion Avoidance all the 1903 time, resulting in a low sending rate and bad performance. The 1904 problem is even more serious for SCTP because in a multi-homed SCTP 1905 association traffic that switches back to the previously failed 1906 primary path will also lead to the situation where traffic ends up in 1907 Congestion Avoidance. 1909 3.27.2. Text Changes to the Document 1911 --------- 1912 Old text: (Section 7.2.1) 1913 --------- 1915 o The initial cwnd before DATA transmission or after a sufficiently 1916 long idle period MUST be set to min(4*MTU, max (2*MTU, 4380 1917 bytes)). 1919 --------- 1920 New text: (Section 7.2.1) 1921 --------- 1923 o The initial cwnd before DATA transmission MUST be set to 1924 min(4*MTU, max (2*MTU, 4380 bytes)). 1926 --------- 1927 Old text: (Section 7.2.1) 1928 --------- 1930 o When the endpoint does not transmit data on a given transport 1931 address, the cwnd of the transport address should be adjusted to 1932 max(cwnd/2, 4*MTU) per RTO. 1934 --------- 1935 New text: (Section 7.2.1) 1936 --------- 1937 o While the endpoint does not transmit data on a given transport 1938 address, the cwnd of the transport address SHOULD be adjusted to 1939 max(cwnd/2, 4*MTU) once per RTO. Before the first cwnd adjustment, 1940 the ssthresh of the transport address SHOULD be set to the cwnd. 1942 This text is in final form, and is not further updated in this 1943 document. 1945 3.27.3. Solution Description 1947 A rule about cwnd adjustment after a sufficiently long idle period is 1948 removed. 1950 The text is updated to describe the ssthresh handling. When the idle 1951 period is detected, the cwnd value is stored to the ssthresh value. 1953 3.28. Window Updates After Receiver Window Opens Up 1955 3.28.1. Description of the Problem 1957 The sending of SACK chunks for window updates is only indirectly 1958 referenced in [RFC4960], Section 6.2, where it is stated that an SCTP 1959 receiver must not generate more than one SACK for every incoming 1960 packet, other than to update the offered window. 1962 However, the sending of window updates when the receiver window opens 1963 up is necessary to avoid performance problems. 1965 3.28.2. Text Changes to the Document 1966 --------- 1967 Old text: (Section 6.2) 1968 --------- 1970 An SCTP receiver MUST NOT generate more than one SACK for every 1971 incoming packet, other than to update the offered window as the 1972 receiving application consumes new data. 1974 --------- 1975 New text: (Section 6.2) 1976 --------- 1978 An SCTP receiver MUST NOT generate more than one SACK for every 1979 incoming packet, other than to update the offered window as the 1980 receiving application consumes new data. When the window opens 1981 up, an SCTP receiver SHOULD send additional SACK chunks to update 1982 the window even if no new data is received. 1983 The receiver MUST avoid sending a large number of window updates, 1984 in particular large bursts of them. 1985 One way to achieve this is to send a window update only if the 1986 window can be increased by at least a quarter of the receive 1987 buffer size of the association. 1989 This text is in final form, and is not further updated in this 1990 document. 1992 3.28.3. Solution Description 1994 The new text makes clear that additional SACK chunks for window 1995 updates should be sent as long as excessive bursts are avoided. 1997 3.29. Path of DATA and Reply Chunks 1999 3.29.1. Description of the Problem 2001 Section 6.4 of [RFC4960] describes the transmission policy for multi- 2002 homed SCTP endpoints. However, there are the following issues with 2003 it: 2005 o It states that a SACK should be sent to the source address of an 2006 incoming DATA. However, it is known that other SACK policies 2007 (e.g. sending SACKs always to the primary path) may be more 2008 beneficial in some situations. 2009 o Initially it states that an endpoint should always transmit DATA 2010 chunks to the primary path. Then it states that the rule for 2011 transmittal of reply chunks should also be followed if the 2012 endpoint is bundling DATA chunks together with the reply chunk 2013 which contradicts with the first statement to always transmit DATA 2014 chunks to the primary path. Some implementations were having 2015 problems with it and sent DATA chunks bundled with reply chunks to 2016 a different destination address than the primary path that caused 2017 many gaps. 2019 3.29.2. Text Changes to the Document 2021 --------- 2022 Old text: (Section 6.4) 2023 --------- 2025 An endpoint SHOULD transmit reply chunks (e.g., SACK, HEARTBEAT ACK, 2026 etc.) to the same destination transport address from which it 2027 received the DATA or control chunk to which it is replying. This 2028 rule should also be followed if the endpoint is bundling DATA chunks 2029 together with the reply chunk. 2031 However, when acknowledging multiple DATA chunks received in packets 2032 from different source addresses in a single SACK, the SACK chunk may 2033 be transmitted to one of the destination transport addresses from 2034 which the DATA or control chunks being acknowledged were received. 2036 --------- 2037 New text: (Section 6.4) 2038 --------- 2040 An endpoint SHOULD transmit reply chunks (e.g., INIT ACK, COOKIE ACK, 2041 HEARTBEAT ACK, etc.) in response to control chunks to the same 2042 destination transport address from which it received the control 2043 chunk to which it is replying. 2045 The selection of the destination transport address for packets 2046 containing SACK chunks is implementation dependent. However, an endpoint 2047 SHOULD NOT vary the destination transport address of a SACK when it 2048 receives DATA chunks coming from the same source address. 2050 When acknowledging multiple DATA chunks received in packets 2051 from different source addresses in a single SACK, the SACK chunk MAY 2052 be transmitted to one of the destination transport addresses from 2053 which the DATA or control chunks being acknowledged were received. 2055 This text is in final form, and is not further updated in this 2056 document. 2058 3.29.3. Solution Description 2060 The SACK transmission policy is left implementation dependent but it 2061 is specified to not vary the destination address of a packet 2062 containing a SACK chunk unless there are reasons for it as it may 2063 negatively impact RTT measurement. 2065 A confusing statement that prescribes to follow the rule for 2066 transmittal of reply chunks when the endpoint is bundling DATA chunks 2067 together with the reply chunk is removed. 2069 3.30. Outstanding Data, Flightsize and Data In Flight Key Terms 2071 3.30.1. Description of the Problem 2073 [RFC4960] uses outstanding data, flightsize and data in flight key 2074 terms in formulas and statements but their definitions are not 2075 provided in Section 1.3. Furthermore, outstanding data does not 2076 include DATA chunks which are classified as lost but which have not 2077 been retransmitted yet and there is a paragraph in Section 6.1 of 2078 [RFC4960] where this statement is broken. 2080 3.30.2. Text Changes to the Document 2081 --------- 2082 Old text: (Section 1.3) 2083 --------- 2085 o Congestion window (cwnd): An SCTP variable that limits the data, 2086 in number of bytes, a sender can send to a particular destination 2087 transport address before receiving an acknowledgement. 2089 ... 2091 o Outstanding TSN (at an SCTP endpoint): A TSN (and the associated 2092 DATA chunk) that has been sent by the endpoint but for which it 2093 has not yet received an acknowledgement. 2095 --------- 2096 New text: (Section 1.3) 2097 --------- 2099 o Outstanding TSN (at an SCTP endpoint): A TSN (and the associated 2100 DATA chunk) that has been sent by the endpoint but for which it 2101 has not yet received an acknowledgement. 2103 o Outstanding data (or Data outstanding or Data in flight): The 2104 total amount of the DATA chunks associated with outstanding TSNs. 2105 A retransmitted DATA chunk is counted once in outstanding data. 2106 A DATA chunk which is classified as lost but which has not been 2107 retransmitted yet is not in outstanding data. 2109 o Flightsize: The amount of bytes of outstanding data to a 2110 particular destination transport address at any given time. 2112 o Congestion window (cwnd): An SCTP variable that limits outstanding 2113 data, in number of bytes, a sender can send to a particular 2114 destination transport address before receiving an acknowledgement. 2116 This text is in final form, and is not further updated in this 2117 document. 2119 --------- 2120 Old text: (Section 6.1) 2121 --------- 2123 C) When the time comes for the sender to transmit, before sending new 2124 DATA chunks, the sender MUST first transmit any outstanding DATA 2125 chunks that are marked for retransmission (limited by the current 2126 cwnd). 2128 --------- 2129 New text: (Section 6.1) 2130 --------- 2132 C) When the time comes for the sender to transmit, before sending new 2133 DATA chunks, the sender MUST first transmit any DATA chunks that 2134 are marked for retransmission (limited by the current cwnd). 2136 This text is in final form, and is not further updated in this 2137 document. 2139 3.30.3. Solution Description 2141 Now Section 1.3, Key Terms, includes explanations of outstanding 2142 data, data in flight and flightsize key terms. Section 6.1 is 2143 corrected to properly use the outstanding data term. 2145 3.31. CWND Degradation due to Max.Burst 2147 3.31.1. Description of the Problem 2149 Some implementations were experiencing a degradation of cwnd because 2150 of the Max.Burst limit. This was due to misinterpretation of the 2151 suggestion in [RFC4960], Section 6.1, on how to use the Max.Burst 2152 parameter when calculating the number of packets to transmit. 2154 3.31.2. Text Changes to the Document 2155 --------- 2156 Old text: (Section 6.1) 2157 --------- 2159 D) When the time comes for the sender to transmit new DATA chunks, 2160 the protocol parameter Max.Burst SHOULD be used to limit the 2161 number of packets sent. The limit MAY be applied by adjusting 2162 cwnd as follows: 2164 if((flightsize + Max.Burst*MTU) < cwnd) cwnd = flightsize + 2165 Max.Burst*MTU 2167 Or it MAY be applied by strictly limiting the number of packets 2168 emitted by the output routine. 2170 --------- 2171 New text: (Section 6.1) 2172 --------- 2174 D) When the time comes for the sender to transmit new DATA chunks, 2175 the protocol parameter Max.Burst SHOULD be used to limit the 2176 number of packets sent. The limit MAY be applied by adjusting 2177 cwnd temporarily as follows: 2179 if ((flightsize + Max.Burst*MTU) < cwnd) 2180 cwnd = flightsize + Max.Burst*MTU 2182 Or it MAY be applied by strictly limiting the number of packets 2183 emitted by the output routine. When calculating the number of 2184 packets to transmit and particularly using the formula above, 2185 cwnd SHOULD NOT be changed permanently. 2187 This text is in final form, and is not further updated in this 2188 document. 2190 3.31.3. Solution Description 2192 The new text clarifies that cwnd should not be changed when applying 2193 the Max.Burst limit. This mitigates packet bursts related to the 2194 reception of SACK chunks, but not bursts related to an application 2195 sending a burst of user messages. 2197 3.32. Reduction of RTO.Initial 2198 3.32.1. Description of the Problem 2200 [RFC4960] uses 3 seconds as the default value for RTO.Initial in 2201 accordance with Section 4.3.2.1 of [RFC1122]. [RFC6298] updates 2202 [RFC1122] and lowers the initial value of the retransmission timer 2203 from 3 seconds to 1 second. 2205 3.32.2. Text Changes to the Document 2207 --------- 2208 Old text: (Section 15) 2209 --------- 2211 The following protocol parameters are RECOMMENDED: 2213 RTO.Initial - 3 seconds 2214 RTO.Min - 1 second 2215 RTO.Max - 60 seconds 2216 Max.Burst - 4 2217 RTO.Alpha - 1/8 2218 RTO.Beta - 1/4 2219 Valid.Cookie.Life - 60 seconds 2220 Association.Max.Retrans - 10 attempts 2221 Path.Max.Retrans - 5 attempts (per destination address) 2222 Max.Init.Retransmits - 8 attempts 2223 HB.interval - 30 seconds 2224 HB.Max.Burst - 1 2226 --------- 2227 New text: (Section 15) 2228 --------- 2230 The following protocol parameters are RECOMMENDED: 2232 RTO.Initial - 1 second 2233 RTO.Min - 1 second 2234 RTO.Max - 60 seconds 2235 Max.Burst - 4 2236 RTO.Alpha - 1/8 2237 RTO.Beta - 1/4 2238 Valid.Cookie.Life - 60 seconds 2239 Association.Max.Retrans - 10 attempts 2240 Path.Max.Retrans - 5 attempts (per destination address) 2241 Max.Init.Retransmits - 8 attempts 2242 HB.interval - 30 seconds 2243 HB.Max.Burst - 1 2244 SACK.Delay - 200 milliseconds 2246 This text has been modified by multiple errata. It includes 2247 modifications from Section 3.24. It is in final form, and is not 2248 further updated in this document. 2250 3.32.3. Solution Description 2252 The value RTO.Initial has been lowered to 1 second to be in tune with 2253 [RFC6298]. 2255 3.33. Ordering of Bundled SACK and ERROR Chunks 2257 3.33.1. Description of the Problem 2259 When an SCTP endpoint receives a DATA chunk with an invalid stream 2260 identifier it shall acknowledge it by sending a SACK chunk and 2261 indicate that the stream identifier was invalid by sending an ERROR 2262 chunk. These two chunks may be bundled. However, [RFC4960] requires 2263 in case of bundling that the ERROR chunk follows the SACK chunk. 2264 This restriction of the ordering is not necessary and might only 2265 limit interoperability. 2267 3.33.2. Text Changes to the Document 2269 --------- 2270 Old text: (Section 6.5) 2271 --------- 2273 Every DATA chunk MUST carry a valid stream identifier. If an 2274 endpoint receives a DATA chunk with an invalid stream identifier, it 2275 shall acknowledge the reception of the DATA chunk following the 2276 normal procedure, immediately send an ERROR chunk with cause set to 2277 "Invalid Stream Identifier" (see Section 3.3.10), and discard the 2278 DATA chunk. The endpoint may bundle the ERROR chunk in the same 2279 packet as the SACK as long as the ERROR follows the SACK. 2281 --------- 2282 New text: (Section 6.5) 2283 --------- 2285 Every DATA chunk MUST carry a valid stream identifier. If an 2286 endpoint receives a DATA chunk with an invalid stream identifier, it 2287 SHOULD acknowledge the reception of the DATA chunk following the 2288 normal procedure, immediately send an ERROR chunk with cause set to 2289 "Invalid Stream Identifier" (see Section 3.3.10), and discard the 2290 DATA chunk. The endpoint MAY bundle the ERROR chunk and the SACK Chunk 2291 in the same packet. 2293 This text is in final form, and is not further updated in this 2294 document. 2296 3.33.3. Solution Description 2298 The unnecessary restriction regarding the ordering of the SACK and 2299 ERROR chunk has been removed. 2301 3.34. Undefined Parameter Returned by RECEIVE Primitive 2303 3.34.1. Description of the Problem 2305 [RFC4960] provides a description of an abstract API. In the 2306 definition of the RECEIVE primitive an optional parameter with name 2307 "delivery number" is mentioned. However, no definition of this 2308 parameter is given in [RFC4960] and the parameter is unnecessary. 2310 3.34.2. Text Changes to the Document 2312 --------- 2313 Old text: (Section 10.1 G)) 2314 --------- 2316 G) Receive 2318 Format: RECEIVE(association id, buffer address, buffer size 2319 [,stream id]) 2320 -> byte count [,transport address] [,stream id] [,stream sequence 2321 number] [,partial flag] [,delivery number] [,payload protocol-id] 2323 --------- 2324 New text: (Section 10.1 G)) 2325 --------- 2327 G) Receive 2329 Format: RECEIVE(association id, buffer address, buffer size 2330 [,stream id]) 2331 -> byte count [,transport address] [,stream id] [,stream sequence 2332 number] [,partial flag] [,payload protocol-id] 2334 This text is in final form, and is not further updated in this 2335 document. 2337 3.34.3. Solution Description 2339 The undefined parameter has been removed. 2341 3.35. DSCP Changes 2343 3.35.1. Description of the Problem 2345 The upper layer can change the Differentiated Services Code Point 2346 (DSCP) used for packets being sent. A change of the DSCP can result 2347 in packets hitting different queues on the path and, therefore, the 2348 congestion control should be initialized when the DSCP is changed by 2349 the upper layer. This is not described in [RFC4960]. 2351 3.35.2. Text Changes to the Document 2353 --------- 2354 New text: (Section 7.2.5) 2355 --------- 2356 7.2.5. Change of Differentiated Services Code Points 2358 SCTP implementations MAY allow an application to configure the 2359 Differentiated Services Code Point (DSCP) used for sending packets. 2360 If a DSCP change might result in outgoing packets being queued in 2361 different queues, the congestion control parameters for all affected 2362 destination addresses MUST be reset to their initial values. 2364 This text is in final form, and is not further updated in this 2365 document. 2367 --------- 2368 Old text: (Section 10.1 M)) 2369 --------- 2371 Mandatory attributes: 2373 o association id - local handle to the SCTP association. 2375 o protocol parameter list - the specific names and values of the 2376 protocol parameters (e.g., Association.Max.Retrans; see Section 2377 15) that the SCTP user wishes to customize. 2379 --------- 2380 New text: (Section 10.1 M)) 2381 --------- 2383 Mandatory attributes: 2385 o association id - local handle to the SCTP association. 2387 o protocol parameter list - the specific names and values of the 2388 protocol parameters (e.g., Association.Max.Retrans; see Section 2389 15, or other parameters like the DSCP) that the SCTP user wishes 2390 to customize. 2392 This text is in final form, and is not further updated in this 2393 document. 2395 3.35.3. Solution Description 2397 Text describing the required action on DSCP changes has been added. 2399 3.36. Inconsistent Handling of ICMPv4 and ICMPv6 Messages 2401 3.36.1. Description of the Problem 2403 Appendix C of [RFC4960] describes the handling of ICMPv4 and ICMPv6 2404 messages. The handling of ICMP messages indicating that the port 2405 number is unreachable described in the enumeration is not consistent 2406 with the description given in [RFC4960] after the enumeration. 2407 Furthermore, the text explicitly describes the handling of ICMPv6 2408 packets indicating reachability problems, but does not do the same 2409 for the corresponding ICMPv4 packets. 2411 3.36.2. Text Changes to the Document 2413 --------- 2414 Old text: (Appendix C) 2415 --------- 2417 ICMP3) An implementation MAY ignore any ICMPv4 messages where the 2418 code does not indicate "Protocol Unreachable" or 2419 "Fragmentation Needed". 2421 --------- 2422 New text: (Appendix C) 2423 --------- 2425 ICMP3) An implementation SHOULD ignore any ICMP messages where the 2426 code indicates "Port Unreachable". 2428 This text is in final form, and is not further updated in this 2429 document. 2431 --------- 2432 Old text: (Appendix C) 2433 --------- 2435 ICMP9) If the ICMPv6 code is "Destination Unreachable", the 2436 implementation MAY mark the destination into the unreachable 2437 state or alternatively increment the path error counter. 2439 --------- 2440 New text: (Appendix C) 2441 --------- 2443 ICMP9) If the ICMP type is "Destination Unreachable", the 2444 implementation MAY mark the destination into the unreachable 2445 state or alternatively increment the path error counter. 2447 This text has been modified by multiple errata. It is further 2448 updated in Section 3.37. 2450 3.36.3. Solution Description 2452 The text has been changed to describe the intended handling of ICMP 2453 messages indicating that the port number is unreachable by replacing 2454 the third rule. Furthermore, remove the limitation to ICMPv6 in the 2455 ninth rule. 2457 3.37. Handling of Soft Errors 2459 3.37.1. Description of the Problem 2461 [RFC1122] defines the handling of soft errors and hard errors for 2462 TCP. Appendix C of [RFC4960] only deals with hard errors. 2464 3.37.2. Text Changes to the Document 2466 --------- 2467 Old text: (Appendix C) 2468 --------- 2470 ICMP9) If the ICMPv6 code is "Destination Unreachable", the 2471 implementation MAY mark the destination into the unreachable 2472 state or alternatively increment the path error counter. 2474 --------- 2475 New text: (Appendix C) 2476 --------- 2478 ICMP9) If the ICMP type is "Destination Unreachable", the 2479 implementation MAY mark the destination into the unreachable 2480 state or alternatively increment the path error counter. 2481 SCTP MAY provide information to the upper layer indicating 2482 the reception of ICMP messages when reporting a network status 2483 change. 2485 This text has been modified by multiple errata. It includes 2486 modifications from Section 3.36. It is in final form, and is not 2487 further updated in this document. 2489 3.37.3. Solution Description 2491 Text has been added allowing SCTP to notify the application in case 2492 of soft errors. 2494 3.38. Honoring CWND 2496 3.38.1. Description of the Problem 2498 When using the slow start algorithm, SCTP increases the congestion 2499 window only when it is being fully utilized. Since SCTP uses DATA 2500 chunks and does not use the congestion window to fragment user 2501 messages, this requires that some overbooking of the congestion 2502 window is allowed. 2504 3.38.2. Text Changes to the Document 2506 --------- 2507 Old text: (Section 6.1) 2508 --------- 2510 B) At any given time, the sender MUST NOT transmit new data to a 2511 given transport address if it has cwnd or more bytes of data 2512 outstanding to that transport address. 2514 --------- 2515 New text: (Section 6.1) 2516 --------- 2518 B) At any given time, the sender MUST NOT transmit new data to a 2519 given transport address if it has cwnd + (PMTU - 1) or more bytes 2520 of data outstanding to that transport address. If data is 2521 available the sender SHOULD exceed cwnd by up to (PMTU-1) bytes on 2522 a new data transmission if the flightsize does not currently reach 2523 cwnd. The breach of cwnd MUST constitute one packet only. 2525 This text is in final form, and is not further updated in this 2526 document. 2528 --------- 2529 Old text: (Section 7.2.1) 2530 --------- 2532 o Whenever cwnd is greater than zero, the endpoint is allowed to 2533 have cwnd bytes of data outstanding on that transport address. 2535 --------- 2536 New text: (Section 7.2.1) 2537 --------- 2538 o Whenever cwnd is greater than zero, the endpoint is allowed to 2539 have cwnd bytes of data outstanding on that transport address. 2540 A limited overbooking as described in B) of Section 6.1 SHOULD 2541 be supported. 2543 This text is in final form, and is not further updated in this 2544 document. 2546 3.38.3. Solution Description 2548 Text was added to clarify how the cwnd limit should be handled. 2550 3.39. Zero Window Probing 2552 3.39.1. Description of the Problem 2554 The text describing zero window probing was not clearly handling the 2555 case where the window was not zero, but too small for the next DATA 2556 chunk to be transmitted. Even in this case, zero window probing has 2557 to be performed to avoid deadlocks. 2559 3.39.2. Text Changes to the Document 2560 --------- 2561 Old text: (Section 6.1) 2562 --------- 2564 A) At any given time, the data sender MUST NOT transmit new data to 2565 any destination transport address if its peer's rwnd indicates 2566 that the peer has no buffer space (i.e., rwnd is 0; see Section 2567 6.2.1). However, regardless of the value of rwnd (including if it 2568 is 0), the data sender can always have one DATA chunk in flight to 2569 the receiver if allowed by cwnd (see rule B, below). This rule 2570 allows the sender to probe for a change in rwnd that the sender 2571 missed due to the SACK's having been lost in transit from the data 2572 receiver to the data sender. 2574 When the receiver's advertised window is zero, this probe is 2575 called a zero window probe. Note that a zero window probe SHOULD 2576 only be sent when all outstanding DATA chunks have been 2577 cumulatively acknowledged and no DATA chunks are in flight. Zero 2578 window probing MUST be supported. 2580 --------- 2581 New text: (Section 6.1) 2582 --------- 2584 A) At any given time, the data sender MUST NOT transmit new data to 2585 any destination transport address if its peer's rwnd indicates 2586 that the peer has no buffer space (i.e., rwnd is smaller than the 2587 size of the next DATA chunk; see Section 6.2.1). 2588 However, regardless of the value of rwnd (including if it is 0), 2589 the data sender can always have one DATA chunk in flight to 2590 the receiver if allowed by cwnd (see rule B, below). This rule 2591 allows the sender to probe for a change in rwnd that the sender 2592 missed due to the SACK's having been lost in transit from the data 2593 receiver to the data sender. 2595 When the receiver has no buffer space, this probe is 2596 called a zero window probe. Note that a zero window probe SHOULD 2597 only be sent when all outstanding DATA chunks have been 2598 cumulatively acknowledged and no DATA chunks are in flight. Zero 2599 window probing MUST be supported. 2601 This text is in final form, and is not further updated in this 2602 document. 2604 3.39.3. Solution Description 2606 The terminology is used in a cleaner way. 2608 3.40. Updating References Regarding ECN 2610 3.40.1. Description of the Problem 2612 [RFC4960] refers for ECN only to [RFC3168], which will be updated by 2613 [RFC8311]. This needs to be reflected when referring to ECN. 2615 3.40.2. Text Changes to the Document 2617 --------- 2618 Old text: (Appendix A) 2619 --------- 2621 ECN [RFC3168] describes a proposed extension to IP that details a 2622 method to become aware of congestion outside of datagram loss. 2624 --------- 2625 New text: (Appendix A) 2626 --------- 2628 ECN as specified in [RFC3168] updated by [RFC8311] describes an 2629 extension to IP that details a method to become aware of congestion 2630 outside of datagram loss. 2632 This text is in final form, and is not further updated in this 2633 document. 2635 --------- 2636 Old text: (Appendix A) 2637 --------- 2639 In general, [RFC3168] should be followed with the following 2640 exceptions. 2642 --------- 2643 New text: (Appendix A) 2644 --------- 2646 In general, [RFC3168] updated by [RFC8311] SHOULD be followed with the 2647 following exceptions. 2649 This text is in final form, and is not further updated in this 2650 document. 2652 --------- 2653 Old text: (Appendix A) 2654 --------- 2656 [RFC3168] details negotiation of ECN during the SYN and SYN-ACK 2657 stages of a TCP connection. 2659 --------- 2660 New text: (Appendix A) 2661 --------- 2663 [RFC3168] updated by [RFC8311] details negotiation of ECN during the 2664 SYN and SYN-ACK stages of a TCP connection. 2666 This text is in final form, and is not further updated in this 2667 document. 2669 --------- 2670 Old text: (Appendix A) 2671 --------- 2673 [RFC3168] details a specific bit for a receiver to send back in its 2674 TCP acknowledgements to notify the sender of the Congestion 2675 Experienced (CE) bit having arrived from the network. 2677 --------- 2678 New text: (Appendix A) 2679 --------- 2681 [RFC3168] updated by [RFC8311] details a specific bit for a receiver 2682 to send back in its TCP acknowledgements to notify the sender of the 2683 Congestion Experienced (CE) bit having arrived from the network. 2685 This text is in final form, and is not further updated in this 2686 document. 2688 --------- 2689 Old text: (Appendix A) 2690 --------- 2692 [RFC3168] details a specific bit for a sender to send in the header 2693 of its next outbound TCP segment to indicate to its peer that it has 2694 reduced its congestion window. 2695 --------- 2696 New text: (Appendix A) 2697 --------- 2699 [RFC3168] updated by [RFC8311] details a specific bit for a sender 2700 to send in the header of its next outbound TCP segment to indicate to 2701 its peer that it has reduced its congestion window. 2703 This text is in final form, and is not further updated in this 2704 document. 2706 3.40.3. Solution Description 2708 References to [RFC8311] have been added. While there, some 2709 wordsmithing has been performed. 2711 3.41. Host Name Address Parameter Deprecated 2713 3.41.1. Description of the Problem 2715 [RFC4960] defines three types of address parameters to be used with 2716 INIT and INIT ACK chunks: 2718 1. IPv4 Address parameters. 2719 2. IPv6 Address parameters. 2720 3. Host Name Address parameters. 2722 The first two are supported by the SCTP kernel implementations of 2723 FreeBSD, Linux and Solaris, but the third one is not. In addition, 2724 the first two where successfully tested in all nine interoperability 2725 tests for SCTP, but the third one has never been successfully tested. 2726 Therefore, the Host Name Address parameter should be deprecated. 2728 3.41.2. Text Changes to the Document 2729 --------- 2730 Old text: (Section 3.3.2) 2731 --------- 2733 Note 3: An INIT chunk MUST NOT contain more than one Host Name 2734 Address parameter. Moreover, the sender of the INIT MUST NOT combine 2735 any other address types with the Host Name Address in the INIT. The 2736 receiver of INIT MUST ignore any other address types if the Host Name 2737 Address parameter is present in the received INIT chunk. 2739 --------- 2740 New text: (Section 3.3.2) 2741 --------- 2743 Note 3: An INIT chunk MUST NOT contain the Host Name Address 2744 parameter. The receiver of an INIT chunk containing a Host Name 2745 Address parameter MUST send an ABORT and MAY include an Error Cause 2746 indicating an Unresolvable Address. 2748 This text is in final form, and is not further updated in this 2749 document. 2751 --------- 2752 Old text: (Section 3.3.2.1) 2753 --------- 2755 The sender of INIT uses this parameter to pass its Host Name (in 2756 place of its IP addresses) to its peer. The peer is responsible for 2757 resolving the name. Using this parameter might make it more likely 2758 for the association to work across a NAT box. 2760 --------- 2761 New text: (Section 3.3.2.1) 2762 --------- 2764 The sender of an INIT chunk MUST NOT include this parameter. The 2765 usage of the Host Name Address parameter is deprecated. 2767 This text is in final form, and is not further updated in this 2768 document. 2770 --------- 2771 Old text: (Section 3.3.2.1) 2772 --------- 2774 Address Type: 16 bits (unsigned integer) 2776 This is filled with the type value of the corresponding address 2777 TLV (e.g., IPv4 = 5, IPv6 = 6, Host name = 11). 2779 --------- 2780 New text: (Section 3.3.2.1) 2781 --------- 2782 Address Type: 16 bits (unsigned integer) 2784 This is filled with the type value of the corresponding address 2785 TLV (e.g., IPv4 = 5, IPv6 = 6). The value indicating the Host 2786 Name Address parameter (Host name = 11) MUST NOT be used. 2788 This text is in final form, and is not further updated in this 2789 document. 2791 --------- 2792 Old text: (Section 3.3.3) 2793 --------- 2795 Note 3: The INIT ACK chunks MUST NOT contain more than one Host Name 2796 Address parameter. Moreover, the sender of the INIT ACK MUST NOT 2797 combine any other address types with the Host Name Address in the 2798 INIT ACK. The receiver of the INIT ACK MUST ignore any other address 2799 types if the Host Name Address parameter is present. 2801 --------- 2802 New text: (Section 3.3.3) 2803 --------- 2805 Note 3: An INIT ACK chunk MUST NOT contain the Host Name Address 2806 parameter. The receiver of INIT ACK chunks containing a Host Name 2807 Address parameter MUST send an ABORT and MAY include an Error Cause 2808 indicating an Unresolvable Address. 2810 This text is in final form, and is not further updated in this 2811 document. 2813 --------- 2814 Old text: (Section 5.1.2) 2815 --------- 2817 B) If there is a Host Name parameter present in the received INIT or 2818 INIT ACK chunk, the endpoint shall resolve that host name to a 2819 list of IP address(es) and derive the transport address(es) of 2820 this peer by combining the resolved IP address(es) with the SCTP 2821 source port. 2823 The endpoint MUST ignore any other IP Address parameters if they 2824 are also present in the received INIT or INIT ACK chunk. 2826 The time at which the receiver of an INIT resolves the host name 2827 has potential security implications to SCTP. If the receiver of 2828 an INIT resolves the host name upon the reception of the chunk, 2829 and the mechanism the receiver uses to resolve the host name 2830 involves potential long delay (e.g., DNS query), the receiver may 2831 open itself up to resource attacks for the period of time while it 2832 is waiting for the name resolution results before it can build the 2833 State Cookie and release local resources. 2835 Therefore, in cases where the name translation involves potential 2836 long delay, the receiver of the INIT MUST postpone the name 2837 resolution till the reception of the COOKIE ECHO chunk from the 2838 peer. In such a case, the receiver of the INIT SHOULD build the 2839 State Cookie using the received Host Name (instead of destination 2840 transport addresses) and send the INIT ACK to the source IP 2841 address from which the INIT was received. 2843 The receiver of an INIT ACK shall always immediately attempt to 2844 resolve the name upon the reception of the chunk. 2846 The receiver of the INIT or INIT ACK MUST NOT send user data 2847 (piggy-backed or stand-alone) to its peer until the host name is 2848 successfully resolved. 2850 If the name resolution is not successful, the endpoint MUST 2851 immediately send an ABORT with "Unresolvable Address" error cause 2852 to its peer. The ABORT shall be sent to the source IP address 2853 from which the last peer packet was received. 2855 --------- 2856 New text: (Section 5.1.2) 2857 --------- 2859 B) If there is a Host Name parameter present in the received INIT or 2860 INIT ACK chunk, the endpoint MUST immediately send an ABORT and 2861 MAY include an Error Cause indicating an Unresolvable Address to 2862 its peer. The ABORT SHALL be sent to the source IP address 2863 from which the last peer packet was received. 2865 This text is in final form, and is not further updated in this 2866 document. 2868 --------- 2869 Old text: (Section 11.2.4.1) 2870 --------- 2872 The use of the host name feature in the INIT chunk could be used to 2873 flood a target DNS server. A large backlog of DNS queries, resolving 2874 the host name received in the INIT chunk to IP addresses, could be 2875 accomplished by sending INITs to multiple hosts in a given domain. 2876 In addition, an attacker could use the host name feature in an 2877 indirect attack on a third party by sending large numbers of INITs to 2878 random hosts containing the host name of the target. In addition to 2879 the strain on DNS resources, this could also result in large numbers 2880 of INIT ACKs being sent to the target. One method to protect against 2881 this type of attack is to verify that the IP addresses received from 2882 DNS include the source IP address of the original INIT. If the list 2883 of IP addresses received from DNS does not include the source IP 2884 address of the INIT, the endpoint MAY silently discard the INIT. 2885 This last option will not protect against the attack against the DNS. 2887 --------- 2888 New text: (Section 11.2.4.1) 2889 --------- 2891 The support of the Host Name Address parameter has been removed from 2892 the protocol. Endpoints receiving INIT or INIT ACK chunks containing 2893 the Host Name Address parameter MUST send an ABORT chunk in response 2894 and MAY include an Error Cause indicating an Unresolvable Address. 2896 This text is in final form, and is not further updated in this 2897 document. 2899 3.41.3. Solution Description 2901 The usage of the Host Name Address parameter has been deprecated. 2903 3.42. Conflicting Text Regarding the Supported Address Types Parameter 2905 3.42.1. Description of the Problem 2907 When receiving an SCTP packet containing an INIT chunk sent from an 2908 address for which the corresponding address type is not listed in the 2909 Supported Address Types, there is conflicting text in Section 5.1.2 2910 of [RFC4960]. It is stated that the association MUST be aborted and 2911 also that the association SHOULD be established and there SHOULD NOT 2912 be any error indication. 2914 3.42.2. Text Changes to the Document 2916 --------- 2917 Old text: (Section 5.1.2) 2918 --------- 2920 The sender of INIT may include a 'Supported Address Types' parameter 2921 in the INIT to indicate what types of address are acceptable. When 2922 this parameter is present, the receiver of INIT (initiate) MUST 2923 either use one of the address types indicated in the Supported 2924 Address Types parameter when responding to the INIT, or abort the 2925 association with an "Unresolvable Address" error cause if it is 2926 unwilling or incapable of using any of the address types indicated by 2927 its peer. 2929 --------- 2930 New text: (Section 5.1.2) 2931 --------- 2933 The sender of INIT chunks MAY include a 'Supported Address Types' 2934 parameter in the INIT to indicate what types of addresses are 2935 acceptable. 2937 This text is in final form, and is not further updated in this 2938 document. 2940 3.42.3. Solution Description 2942 The conflicting text has been removed. 2944 3.43. Integration of RFC 6096 2946 3.43.1. Description of the Problem 2948 [RFC6096] updates [RFC4960] by adding a Chunk Flags Registry. This 2949 should be integrated into the base specification. 2951 3.43.2. Text Changes to the Document 2953 --------- 2954 Old text: (Section 14.1) 2955 --------- 2957 14.1. IETF-Defined Chunk Extension 2959 The assignment of new chunk parameter type codes is done through an 2960 IETF Consensus action, as defined in [RFC2434]. Documentation of the 2961 chunk parameter MUST contain the following information: 2963 a) A long and short name for the new chunk type. 2965 b) A detailed description of the structure of the chunk, which MUST 2966 conform to the basic structure defined in Section 3.2. 2968 c) A detailed definition and description of the intended use of each 2969 field within the chunk, including the chunk flags if any. 2971 d) A detailed procedural description of the use of the new chunk type 2972 within the operation of the protocol. 2974 The last chunk type (255) is reserved for future extension if 2975 necessary. 2977 --------- 2978 New text: (Section 14.1) 2979 --------- 2981 14.1. IETF-Defined Chunk Extension 2983 The assignment of new chunk type codes is done through an IETF Review 2984 action, as defined in [RFC8126]. Documentation of a new chunk MUST 2985 contain the following information: 2987 a) A long and short name for the new chunk type; 2989 b) A detailed description of the structure of the chunk, which MUST 2990 conform to the basic structure defined in Section 3.2 of 2991 [RFC4960]; 2993 c) A detailed definition and description of the intended use of each 2994 field within the chunk, including the chunk flags if any. 2995 Defined chunk flags will be used as initial entries in the chunk 2996 flags table for the new chunk type; 2998 d) A detailed procedural description of the use of the new chunk 2999 type within the operation of the protocol. 3001 The last chunk type (255) is reserved for future extension if 3002 necessary. 3004 For each new chunk type, IANA creates a registration table for the 3005 chunk flags of that type. The procedure for registering particular 3006 chunk flags is described in the following Section 14.2. 3008 This text has been modified by multiple errata. It includes 3009 modifications from Section 3.3. It is in final form, and is not 3010 further updated in this document. 3012 --------- 3013 New text: (Section 14.2) 3014 --------- 3016 14.2. New IETF Chunk Flags Registration 3018 The assignment of new chunk flags is done through an RFC required 3019 action, as defined in [RFC8126]. Documentation of the chunk flags 3020 MUST contain the following information: 3022 a) A name for the new chunk flag; 3024 b) A detailed procedural description of the use of the new chunk 3025 flag within the operation of the protocol. It MUST be considered 3026 that implementations not supporting the flag will send '0' on 3027 transmit and just ignore it on receipt. 3029 IANA selects a chunk flags value. This MUST be one of 0x01, 0x02, 3030 0x04, 0x08, 0x10, 0x20, 0x40, or 0x80, which MUST be unique within 3031 the chunk flag values for the specific chunk type. 3033 This text is in final form, and is not further updated in this 3034 document. 3036 Please note that Sections 14.2, 14.3, 14.4, and 14.5 need to be 3037 renumbered. 3039 3.43.3. Solution Description 3041 [RFC6096] was integrated and the reference updated to [RFC8126]. 3043 3.44. Integration of RFC 6335 3045 3.44.1. Description of the Problem 3047 [RFC6335] updates [RFC4960] by updating Procedures for the Port 3048 Numbers Registry. This should be integrated into the base 3049 specification. While there, update the reference to the RFC giving 3050 guidelines for writing IANA sections to [RFC8126]. 3052 3.44.2. Text Changes to the Document 3054 --------- 3055 Old text: (Section 14.5) 3056 --------- 3058 SCTP services may use contact port numbers to provide service to 3059 unknown callers, as in TCP and UDP. IANA is therefore requested to 3060 open the existing Port Numbers registry for SCTP using the following 3061 rules, which we intend to mesh well with existing Port Numbers 3062 registration procedures. An IESG-appointed Expert Reviewer supports 3063 IANA in evaluating SCTP port allocation requests, according to the 3064 procedure defined in [RFC2434]. 3066 Port numbers are divided into three ranges. The Well Known Ports are 3067 those from 0 through 1023, the Registered Ports are those from 1024 3068 through 49151, and the Dynamic and/or Private Ports are those from 3069 49152 through 65535. Well Known and Registered Ports are intended 3070 for use by server applications that desire a default contact point on 3071 a system. On most systems, Well Known Ports can only be used by 3072 system (or root) processes or by programs executed by privileged 3073 users, while Registered Ports can be used by ordinary user processes 3074 or programs executed by ordinary users. Dynamic and/or Private Ports 3075 are intended for temporary use, including client-side ports, out-of- 3076 band negotiated ports, and application testing prior to registration 3077 of a dedicated port; they MUST NOT be registered. 3079 The Port Numbers registry should accept registrations for SCTP ports 3080 in the Well Known Ports and Registered Ports ranges. Well Known and 3081 Registered Ports SHOULD NOT be used without registration. Although 3082 in some cases -- such as porting an application from TCP to SCTP -- 3083 it may seem natural to use an SCTP port before registration 3084 completes, we emphasize that IANA will not guarantee registration of 3085 particular Well Known and Registered Ports. Registrations should be 3086 requested as early as possible. 3088 Each port registration SHALL include the following information: 3090 o A short port name, consisting entirely of letters (A-Z and a-z), 3091 digits (0-9), and punctuation characters from "-_+./*" (not 3092 including the quotes). 3094 o The port number that is requested for registration. 3096 o A short English phrase describing the port's purpose. 3098 o Name and contact information for the person or entity performing 3099 the registration, and possibly a reference to a document defining 3100 the port's use. Registrations coming from IETF working groups 3101 need only name the working group, but indicating a contact person 3102 is recommended. 3104 Registrants are encouraged to follow these guidelines when submitting 3105 a registration. 3107 o A port name SHOULD NOT be registered for more than one SCTP port 3108 number. 3110 o A port name registered for TCP MAY be registered for SCTP as well. 3111 Any such registration SHOULD use the same port number as the 3112 existing TCP registration. 3114 o Concrete intent to use a port SHOULD precede port registration. 3115 For example, existing TCP ports SHOULD NOT be registered in 3116 advance of any intent to use those ports for SCTP. 3118 --------- 3119 New text: (Section 14.5) 3120 --------- 3122 SCTP services can use contact port numbers to provide service to 3123 unknown callers, as in TCP and UDP. IANA is therefore requested to 3124 open the existing Port Numbers registry for SCTP using the following 3125 rules, which we intend to mesh well with existing Port Numbers 3126 registration procedures. An IESG-appointed Expert Reviewer supports 3127 IANA in evaluating SCTP port allocation requests, according to the 3128 procedure defined in [RFC8126]. The details of this process are 3129 defined in [RFC6335]. 3131 This text is in final form, and is not further updated in this 3132 document. 3134 3.44.3. Solution Description 3136 [RFC6335] was integrated and the reference was updated to [RFC8126]. 3138 3.45. Integration of RFC 7053 3140 3.45.1. Description of the Problem 3142 [RFC7053] updates [RFC4960] by adding the I bit to the DATA chunk. 3143 This should be integrated into the base specification. 3145 3.45.2. Text Changes to the Document 3147 --------- 3148 Old text: (Section 3.3.1) 3149 --------- 3151 The following format MUST be used for the DATA chunk: 3153 0 1 2 3 3154 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3156 | Type = 0 | Reserved|U|B|E| Length | 3157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3158 | TSN | 3159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3160 | Stream Identifier S | Stream Sequence Number n | 3161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3162 | Payload Protocol Identifier | 3163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3164 \ \ 3165 / User Data (seq n of Stream S) / 3166 \ \ 3167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3169 Reserved: 5 bits 3171 Should be set to all '0's and ignored by the receiver. 3173 --------- 3174 New text: (Section 3.3.1) 3175 --------- 3177 0 1 2 3 3178 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3180 | Type = 0 | Res |I|U|B|E| Length | 3181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3182 | TSN | 3183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3184 | Stream Identifier S | Stream Sequence Number n | 3185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3186 | Payload Protocol Identifier | 3187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3188 \ \ 3189 / User Data (seq n of Stream S) / 3190 \ \ 3191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3193 Res: 4 bits 3195 SHOULD be set to all '0's and ignored by the receiver. 3197 I bit: 1 bit 3199 The (I)mmediate Bit MAY be set by the sender, whenever the sender of 3200 a DATA chunk can benefit from the corresponding SACK chunk being sent 3201 back without delay. See [RFC7053] for a discussion about 3202 This text is in final form, and is not further updated in this 3203 document. 3205 --------- 3206 New text: (Append to Section 6.1) 3207 --------- 3209 Whenever the sender of a DATA chunk can benefit from the 3210 corresponding SACK chunk being sent back without delay, the sender 3211 MAY set the I bit in the DATA chunk header. Please note that why the 3212 sender has set the I bit is irrelevant to the receiver. 3214 Reasons for setting the I bit include, but are not limited to (see 3215 Section 4 of [RFC7053] for the benefits): 3217 o The application requests to set the I bit of the last DATA chunk 3218 of a user message when providing the user message to the SCTP 3219 implementation (see Section 7). 3221 o The sender is in the SHUTDOWN-PENDING state. 3223 o The sending of a DATA chunk fills the congestion or receiver 3224 window. 3226 This text is in final form, and is not further updated in this 3227 document. 3229 --------- 3230 Old text: (Section 6.2) 3231 --------- 3233 Note: The SHUTDOWN chunk does not contain Gap Ack Block fields. 3234 Therefore, the endpoint should use a SACK instead of the SHUTDOWN 3235 chunk to acknowledge DATA chunks received out of order. 3237 --------- 3238 New text: (Section 6.2) 3239 --------- 3241 Note: The SHUTDOWN chunk does not contain Gap Ack Block fields. 3242 Therefore, the endpoint SHOULD use a SACK instead of the SHUTDOWN 3243 chunk to acknowledge DATA chunks received out of order. 3245 Upon receipt of an SCTP packet containing a DATA chunk with the I bit 3246 set, the receiver SHOULD NOT delay the sending of the corresponding 3247 SACK chunk, i.e., the receiver SHOULD immediately respond with the 3248 corresponding SACK chunk. 3250 Please note that this change is only about adding a paragraph. 3252 This text is in final form, and is not further updated in this 3253 document. 3255 --------- 3256 Old text: (Section 10.1 E)) 3257 --------- 3259 E) Send 3261 Format: SEND(association id, buffer address, byte count [,context] 3262 [,stream id] [,life time] [,destination transport address] 3263 [,unordered flag] [,no-bundle flag] [,payload protocol-id] ) 3264 -> result 3266 --------- 3267 New text: (Section 10.1 E)) 3268 --------- 3270 E) Send 3272 Format: SEND(association id, buffer address, byte count [,context] 3273 [,stream id] [,life time] [,destination transport address] 3274 [,unordered flag] [,no-bundle flag] [,payload protocol-id] 3275 [,sack immediately] ) 3276 -> result 3278 This text is in final form, and is not further updated in this 3279 document. 3281 --------- 3282 New text: (Append optional parameter in Subsection E of Section 10.1) 3283 --------- 3285 o sack immediately - set the I bit on the last DATA chunk used for 3286 sending buffer. 3288 This text is in final form, and is not further updated in this 3289 document. 3291 3.45.3. Solution Description 3293 [RFC7053] was integrated. 3295 3.46. CRC32c Code Improvements 3297 3.46.1. Description of the Problem 3299 The code given for the CRC32c computations uses types like long which 3300 may have different length on different operating systems or 3301 processors. Therefore, the code is changed to use specific types 3302 like uint32_t. 3304 While there, fix also some syntax errors and a comment. 3306 3.46.2. Text Changes to the Document 3308 --------- 3309 Old text: (Appendix C) 3310 --------- 3311 /*************************************************************/ 3312 /* Note Definition for Ross Williams table generator would */ 3313 /* be: TB_WIDTH=4, TB_POLLY=0x1EDC6F41, TB_REVER=TRUE */ 3314 /* For Mr. Williams direct calculation code use the settings */ 3315 /* cm_width=32, cm_poly=0x1EDC6F41, cm_init=0xFFFFFFFF, */ 3316 /* cm_refin=TRUE, cm_refot=TRUE, cm_xorort=0x00000000 */ 3317 /*************************************************************/ 3319 /* Example of the crc table file */ 3320 #ifndef __crc32cr_table_h__ 3321 #define __crc32cr_table_h__ 3323 #define CRC32C_POLY 0x1EDC6F41 3324 #define CRC32C(c,d) (c=(c>>8)^crc_c[(c^(d))&0xFF]) 3326 unsigned long crc_c[256] = 3327 { 3328 0x00000000L, 0xF26B8303L, 0xE13B70F7L, 0x1350F3F4L, 3329 0xC79A971FL, 0x35F1141CL, 0x26A1E7E8L, 0xD4CA64EBL, 3330 0x8AD958CFL, 0x78B2DBCCL, 0x6BE22838L, 0x9989AB3BL, 3331 0x4D43CFD0L, 0xBF284CD3L, 0xAC78BF27L, 0x5E133C24L, 3332 0x105EC76FL, 0xE235446CL, 0xF165B798L, 0x030E349BL, 3333 0xD7C45070L, 0x25AFD373L, 0x36FF2087L, 0xC494A384L, 3334 0x9A879FA0L, 0x68EC1CA3L, 0x7BBCEF57L, 0x89D76C54L, 3335 0x5D1D08BFL, 0xAF768BBCL, 0xBC267848L, 0x4E4DFB4BL, 3336 0x20BD8EDEL, 0xD2D60DDDL, 0xC186FE29L, 0x33ED7D2AL, 3337 0xE72719C1L, 0x154C9AC2L, 0x061C6936L, 0xF477EA35L, 3338 0xAA64D611L, 0x580F5512L, 0x4B5FA6E6L, 0xB93425E5L, 3339 0x6DFE410EL, 0x9F95C20DL, 0x8CC531F9L, 0x7EAEB2FAL, 3340 0x30E349B1L, 0xC288CAB2L, 0xD1D83946L, 0x23B3BA45L, 3341 0xF779DEAEL, 0x05125DADL, 0x1642AE59L, 0xE4292D5AL, 3342 0xBA3A117EL, 0x4851927DL, 0x5B016189L, 0xA96AE28AL, 3343 0x7DA08661L, 0x8FCB0562L, 0x9C9BF696L, 0x6EF07595L, 3344 0x417B1DBCL, 0xB3109EBFL, 0xA0406D4BL, 0x522BEE48L, 3345 0x86E18AA3L, 0x748A09A0L, 0x67DAFA54L, 0x95B17957L, 3346 0xCBA24573L, 0x39C9C670L, 0x2A993584L, 0xD8F2B687L, 3347 0x0C38D26CL, 0xFE53516FL, 0xED03A29BL, 0x1F682198L, 3348 0x5125DAD3L, 0xA34E59D0L, 0xB01EAA24L, 0x42752927L, 3349 0x96BF4DCCL, 0x64D4CECFL, 0x77843D3BL, 0x85EFBE38L, 3350 0xDBFC821CL, 0x2997011FL, 0x3AC7F2EBL, 0xC8AC71E8L, 3351 0x1C661503L, 0xEE0D9600L, 0xFD5D65F4L, 0x0F36E6F7L, 3352 0x61C69362L, 0x93AD1061L, 0x80FDE395L, 0x72966096L, 3353 0xA65C047DL, 0x5437877EL, 0x4767748AL, 0xB50CF789L, 3354 0xEB1FCBADL, 0x197448AEL, 0x0A24BB5AL, 0xF84F3859L, 3355 0x2C855CB2L, 0xDEEEDFB1L, 0xCDBE2C45L, 0x3FD5AF46L, 3356 0x7198540DL, 0x83F3D70EL, 0x90A324FAL, 0x62C8A7F9L, 3357 0xB602C312L, 0x44694011L, 0x5739B3E5L, 0xA55230E6L, 3358 0xFB410CC2L, 0x092A8FC1L, 0x1A7A7C35L, 0xE811FF36L, 3359 0x3CDB9BDDL, 0xCEB018DEL, 0xDDE0EB2AL, 0x2F8B6829L, 3360 0x82F63B78L, 0x709DB87BL, 0x63CD4B8FL, 0x91A6C88CL, 3361 0x456CAC67L, 0xB7072F64L, 0xA457DC90L, 0x563C5F93L, 3362 0x082F63B7L, 0xFA44E0B4L, 0xE9141340L, 0x1B7F9043L, 3363 0xCFB5F4A8L, 0x3DDE77ABL, 0x2E8E845FL, 0xDCE5075CL, 3364 0x92A8FC17L, 0x60C37F14L, 0x73938CE0L, 0x81F80FE3L, 3365 0x55326B08L, 0xA759E80BL, 0xB4091BFFL, 0x466298FCL, 3366 0x1871A4D8L, 0xEA1A27DBL, 0xF94AD42FL, 0x0B21572CL, 3367 0xDFEB33C7L, 0x2D80B0C4L, 0x3ED04330L, 0xCCBBC033L, 3368 0xA24BB5A6L, 0x502036A5L, 0x4370C551L, 0xB11B4652L, 3369 0x65D122B9L, 0x97BAA1BAL, 0x84EA524EL, 0x7681D14DL, 3370 0x2892ED69L, 0xDAF96E6AL, 0xC9A99D9EL, 0x3BC21E9DL, 3371 0xEF087A76L, 0x1D63F975L, 0x0E330A81L, 0xFC588982L, 3372 0xB21572C9L, 0x407EF1CAL, 0x532E023EL, 0xA145813DL, 3373 0x758FE5D6L, 0x87E466D5L, 0x94B49521L, 0x66DF1622L, 3374 0x38CC2A06L, 0xCAA7A905L, 0xD9F75AF1L, 0x2B9CD9F2L, 3375 0xFF56BD19L, 0x0D3D3E1AL, 0x1E6DCDEEL, 0xEC064EEDL, 3376 0xC38D26C4L, 0x31E6A5C7L, 0x22B65633L, 0xD0DDD530L, 3377 0x0417B1DBL, 0xF67C32D8L, 0xE52CC12CL, 0x1747422FL, 3378 0x49547E0BL, 0xBB3FFD08L, 0xA86F0EFCL, 0x5A048DFFL, 3379 0x8ECEE914L, 0x7CA56A17L, 0x6FF599E3L, 0x9D9E1AE0L, 3380 0xD3D3E1ABL, 0x21B862A8L, 0x32E8915CL, 0xC083125FL, 3381 0x144976B4L, 0xE622F5B7L, 0xF5720643L, 0x07198540L, 3382 0x590AB964L, 0xAB613A67L, 0xB831C993L, 0x4A5A4A90L, 3383 0x9E902E7BL, 0x6CFBAD78L, 0x7FAB5E8CL, 0x8DC0DD8FL, 3384 0xE330A81AL, 0x115B2B19L, 0x020BD8EDL, 0xF0605BEEL, 3385 0x24AA3F05L, 0xD6C1BC06L, 0xC5914FF2L, 0x37FACCF1L, 3386 0x69E9F0D5L, 0x9B8273D6L, 0x88D28022L, 0x7AB90321L, 3387 0xAE7367CAL, 0x5C18E4C9L, 0x4F48173DL, 0xBD23943EL, 3388 0xF36E6F75L, 0x0105EC76L, 0x12551F82L, 0xE03E9C81L, 3389 0x34F4F86AL, 0xC69F7B69L, 0xD5CF889DL, 0x27A40B9EL, 3390 0x79B737BAL, 0x8BDCB4B9L, 0x988C474DL, 0x6AE7C44EL, 3391 0xBE2DA0A5L, 0x4C4623A6L, 0x5F16D052L, 0xAD7D5351L, 3392 }; 3394 #endif 3396 --------- 3397 New text: (Appendix B) 3398 --------- 3400 3401 /*************************************************************/ 3402 /* Note Definition for Ross Williams table generator would */ 3403 /* be: TB_WIDTH=4, TB_POLLY=0x1EDC6F41, TB_REVER=TRUE */ 3404 /* For Mr. Williams direct calculation code use the settings */ 3405 /* cm_width=32, cm_poly=0x1EDC6F41, cm_init=0xFFFFFFFF, */ 3406 /* cm_refin=TRUE, cm_refot=TRUE, cm_xorort=0x00000000 */ 3407 /*************************************************************/ 3409 /* Example of the crc table file */ 3410 #ifndef __crc32cr_h__ 3411 #define __crc32cr_h__ 3413 #define CRC32C_POLY 0x1EDC6F41UL 3414 #define CRC32C(c,d) (c=(c>>8)^crc_c[(c^(d))&0xFF]) 3416 uint32_t crc_c[256] = 3417 { 3418 0x00000000UL, 0xF26B8303UL, 0xE13B70F7UL, 0x1350F3F4UL, 3419 0xC79A971FUL, 0x35F1141CUL, 0x26A1E7E8UL, 0xD4CA64EBUL, 3420 0x8AD958CFUL, 0x78B2DBCCUL, 0x6BE22838UL, 0x9989AB3BUL, 3421 0x4D43CFD0UL, 0xBF284CD3UL, 0xAC78BF27UL, 0x5E133C24UL, 3422 0x105EC76FUL, 0xE235446CUL, 0xF165B798UL, 0x030E349BUL, 3423 0xD7C45070UL, 0x25AFD373UL, 0x36FF2087UL, 0xC494A384UL, 3424 0x9A879FA0UL, 0x68EC1CA3UL, 0x7BBCEF57UL, 0x89D76C54UL, 3425 0x5D1D08BFUL, 0xAF768BBCUL, 0xBC267848UL, 0x4E4DFB4BUL, 3426 0x20BD8EDEUL, 0xD2D60DDDUL, 0xC186FE29UL, 0x33ED7D2AUL, 3427 0xE72719C1UL, 0x154C9AC2UL, 0x061C6936UL, 0xF477EA35UL, 3428 0xAA64D611UL, 0x580F5512UL, 0x4B5FA6E6UL, 0xB93425E5UL, 3429 0x6DFE410EUL, 0x9F95C20DUL, 0x8CC531F9UL, 0x7EAEB2FAUL, 3430 0x30E349B1UL, 0xC288CAB2UL, 0xD1D83946UL, 0x23B3BA45UL, 3431 0xF779DEAEUL, 0x05125DADUL, 0x1642AE59UL, 0xE4292D5AUL, 3432 0xBA3A117EUL, 0x4851927DUL, 0x5B016189UL, 0xA96AE28AUL, 3433 0x7DA08661UL, 0x8FCB0562UL, 0x9C9BF696UL, 0x6EF07595UL, 3434 0x417B1DBCUL, 0xB3109EBFUL, 0xA0406D4BUL, 0x522BEE48UL, 3435 0x86E18AA3UL, 0x748A09A0UL, 0x67DAFA54UL, 0x95B17957UL, 3436 0xCBA24573UL, 0x39C9C670UL, 0x2A993584UL, 0xD8F2B687UL, 3437 0x0C38D26CUL, 0xFE53516FUL, 0xED03A29BUL, 0x1F682198UL, 3438 0x5125DAD3UL, 0xA34E59D0UL, 0xB01EAA24UL, 0x42752927UL, 3439 0x96BF4DCCUL, 0x64D4CECFUL, 0x77843D3BUL, 0x85EFBE38UL, 3440 0xDBFC821CUL, 0x2997011FUL, 0x3AC7F2EBUL, 0xC8AC71E8UL, 3441 0x1C661503UL, 0xEE0D9600UL, 0xFD5D65F4UL, 0x0F36E6F7UL, 3442 0x61C69362UL, 0x93AD1061UL, 0x80FDE395UL, 0x72966096UL, 3443 0xA65C047DUL, 0x5437877EUL, 0x4767748AUL, 0xB50CF789UL, 3444 0xEB1FCBADUL, 0x197448AEUL, 0x0A24BB5AUL, 0xF84F3859UL, 3445 0x2C855CB2UL, 0xDEEEDFB1UL, 0xCDBE2C45UL, 0x3FD5AF46UL, 3446 0x7198540DUL, 0x83F3D70EUL, 0x90A324FAUL, 0x62C8A7F9UL, 3447 0xB602C312UL, 0x44694011UL, 0x5739B3E5UL, 0xA55230E6UL, 3448 0xFB410CC2UL, 0x092A8FC1UL, 0x1A7A7C35UL, 0xE811FF36UL, 3449 0x3CDB9BDDUL, 0xCEB018DEUL, 0xDDE0EB2AUL, 0x2F8B6829UL, 3450 0x82F63B78UL, 0x709DB87BUL, 0x63CD4B8FUL, 0x91A6C88CUL, 3451 0x456CAC67UL, 0xB7072F64UL, 0xA457DC90UL, 0x563C5F93UL, 3452 0x082F63B7UL, 0xFA44E0B4UL, 0xE9141340UL, 0x1B7F9043UL, 3453 0xCFB5F4A8UL, 0x3DDE77ABUL, 0x2E8E845FUL, 0xDCE5075CUL, 3454 0x92A8FC17UL, 0x60C37F14UL, 0x73938CE0UL, 0x81F80FE3UL, 3455 0x55326B08UL, 0xA759E80BUL, 0xB4091BFFUL, 0x466298FCUL, 3456 0x1871A4D8UL, 0xEA1A27DBUL, 0xF94AD42FUL, 0x0B21572CUL, 3457 0xDFEB33C7UL, 0x2D80B0C4UL, 0x3ED04330UL, 0xCCBBC033UL, 3458 0xA24BB5A6UL, 0x502036A5UL, 0x4370C551UL, 0xB11B4652UL, 3459 0x65D122B9UL, 0x97BAA1BAUL, 0x84EA524EUL, 0x7681D14DUL, 3460 0x2892ED69UL, 0xDAF96E6AUL, 0xC9A99D9EUL, 0x3BC21E9DUL, 3461 0xEF087A76UL, 0x1D63F975UL, 0x0E330A81UL, 0xFC588982UL, 3462 0xB21572C9UL, 0x407EF1CAUL, 0x532E023EUL, 0xA145813DUL, 3463 0x758FE5D6UL, 0x87E466D5UL, 0x94B49521UL, 0x66DF1622UL, 3464 0x38CC2A06UL, 0xCAA7A905UL, 0xD9F75AF1UL, 0x2B9CD9F2UL, 3465 0xFF56BD19UL, 0x0D3D3E1AUL, 0x1E6DCDEEUL, 0xEC064EEDUL, 3466 0xC38D26C4UL, 0x31E6A5C7UL, 0x22B65633UL, 0xD0DDD530UL, 3467 0x0417B1DBUL, 0xF67C32D8UL, 0xE52CC12CUL, 0x1747422FUL, 3468 0x49547E0BUL, 0xBB3FFD08UL, 0xA86F0EFCUL, 0x5A048DFFUL, 3469 0x8ECEE914UL, 0x7CA56A17UL, 0x6FF599E3UL, 0x9D9E1AE0UL, 3470 0xD3D3E1ABUL, 0x21B862A8UL, 0x32E8915CUL, 0xC083125FUL, 3471 0x144976B4UL, 0xE622F5B7UL, 0xF5720643UL, 0x07198540UL, 3472 0x590AB964UL, 0xAB613A67UL, 0xB831C993UL, 0x4A5A4A90UL, 3473 0x9E902E7BUL, 0x6CFBAD78UL, 0x7FAB5E8CUL, 0x8DC0DD8FUL, 3474 0xE330A81AUL, 0x115B2B19UL, 0x020BD8EDUL, 0xF0605BEEUL, 3475 0x24AA3F05UL, 0xD6C1BC06UL, 0xC5914FF2UL, 0x37FACCF1UL, 3476 0x69E9F0D5UL, 0x9B8273D6UL, 0x88D28022UL, 0x7AB90321UL, 3477 0xAE7367CAUL, 0x5C18E4C9UL, 0x4F48173DUL, 0xBD23943EUL, 3478 0xF36E6F75UL, 0x0105EC76UL, 0x12551F82UL, 0xE03E9C81UL, 3479 0x34F4F86AUL, 0xC69F7B69UL, 0xD5CF889DUL, 0x27A40B9EUL, 3480 0x79B737BAUL, 0x8BDCB4B9UL, 0x988C474DUL, 0x6AE7C44EUL, 3481 0xBE2DA0A5UL, 0x4C4623A6UL, 0x5F16D052UL, 0xAD7D5351UL, 3482 }; 3484 #endif 3485 This text has been modified by multiple errata. It includes 3486 modifications from Section 3.10. It is in final form, and is not 3487 further updated in this document. 3489 --------- 3490 Old text: (Appendix C) 3491 --------- 3493 /* Example of table build routine */ 3495 #include 3496 #include 3498 #define OUTPUT_FILE "crc32cr.h" 3499 #define CRC32C_POLY 0x1EDC6F41L 3500 FILE *tf; 3501 unsigned long 3502 reflect_32 (unsigned long b) 3503 { 3504 int i; 3505 unsigned long rw = 0L; 3507 for (i = 0; i < 32; i++){ 3508 if (b & 1) 3509 rw |= 1 << (31 - i); 3510 b >>= 1; 3511 } 3512 return (rw); 3513 } 3515 unsigned long 3516 build_crc_table (int index) 3517 { 3518 int i; 3519 unsigned long rb; 3521 rb = reflect_32 (index); 3523 for (i = 0; i < 8; i++){ 3524 if (rb & 0x80000000L) 3525 rb = (rb << 1) ^ CRC32C_POLY; 3526 else 3527 rb <<= 1; 3528 } 3529 return (reflect_32 (rb)); 3530 } 3531 main () 3532 { 3533 int i; 3535 printf ("\nGenerating CRC-32c table file <%s>\n", 3536 OUTPUT_FILE); 3537 if ((tf = fopen (OUTPUT_FILE, "w")) == NULL){ 3538 printf ("Unable to open %s\n", OUTPUT_FILE); 3539 exit (1); 3540 } 3541 fprintf (tf, "#ifndef __crc32cr_table_h__\n"); 3542 fprintf (tf, "#define __crc32cr_table_h__\n\n"); 3543 fprintf (tf, "#define CRC32C_POLY 0x%08lX\n", 3544 CRC32C_POLY); 3545 fprintf (tf, 3546 "#define CRC32C(c,d) (c=(c>>8)^crc_c[(c^(d))&0xFF])\n"); 3547 fprintf (tf, "\nunsigned long crc_c[256] =\n{\n"); 3548 for (i = 0; i < 256; i++){ 3549 fprintf (tf, "0x%08lXL, ", build_crc_table (i)); 3550 if ((i & 3) == 3) 3551 fprintf (tf, "\n"); 3552 } 3553 fprintf (tf, "};\n\n#endif\n"); 3555 if (fclose (tf) != 0) 3556 printf ("Unable to close <%s>." OUTPUT_FILE); 3557 else 3558 printf ("\nThe CRC-32c table has been written to <%s>.\n", 3559 OUTPUT_FILE); 3560 } 3562 --------- 3563 New text: (Appendix B) 3564 --------- 3566 /* Example of table build routine */ 3568 #include 3569 #include 3571 #define OUTPUT_FILE "crc32cr.h" 3572 #define CRC32C_POLY 0x1EDC6F41UL 3574 static FILE *tf; 3576 static uint32_t 3577 reflect_32(uint32_t b) 3578 { 3579 int i; 3580 uint32_t rw = 0UL; 3582 for (i = 0; i < 32; i++) { 3583 if (b & 1) 3584 rw |= 1 << (31 - i); 3585 b >>= 1; 3586 } 3587 return (rw); 3588 } 3590 static uint32_t 3591 build_crc_table(int index) 3592 { 3593 int i; 3594 uint32_t rb; 3596 rb = reflect_32(index); 3598 for (i = 0; i < 8; i++) { 3599 if (rb & 0x80000000UL) 3600 rb = (rb << 1) ^ (uint32_t)CRC32C_POLY; 3601 else 3602 rb <<= 1; 3603 } 3604 return (reflect_32(rb)); 3605 } 3607 int 3608 main (void) 3609 { 3610 int i; 3612 printf("\nGenerating CRC-32c table file <%s>\n", 3613 OUTPUT_FILE); 3614 if ((tf = fopen(OUTPUT_FILE, "w")) == NULL) { 3615 printf ("Unable to open %s\n", OUTPUT_FILE); 3616 exit (1); 3617 } 3618 fprintf(tf, "#ifndef __crc32cr_h__\n"); 3619 fprintf(tf, "#define __crc32cr_h__\n\n"); 3620 fprintf(tf, "#define CRC32C_POLY 0x%08XUL\n", 3621 (uint32_t)CRC32C_POLY); 3622 fprintf(tf, 3623 "#define CRC32C(c,d) (c=(c>>8)^crc_c[(c^(d))&0xFF])\n"); 3624 fprintf(tf, "\nuint32_t crc_c[256] =\n{\n"); 3625 for (i = 0; i < 256; i++) { 3626 fprintf(tf, "0x%08XUL,", build_crc_table (i)); 3627 if ((i & 3) == 3) 3628 fprintf(tf, "\n"); 3629 else 3630 fprintf(tf, " "); 3631 } 3632 fprintf(tf, "};\n\n#endif\n"); 3634 if (fclose (tf) != 0) 3635 printf("Unable to close <%s>.", OUTPUT_FILE); 3636 else 3637 printf("\nThe CRC-32c table has been written to <%s>.\n", 3638 OUTPUT_FILE); 3639 } 3641 This text has been modified by multiple errata. It includes 3642 modifications from Section 3.10. It is in final form, and is not 3643 further updated in this document. 3645 --------- 3646 Old text: (Appendix C) 3647 --------- 3649 /* Example of crc insertion */ 3651 #include "crc32cr.h" 3653 unsigned long 3654 generate_crc32c(unsigned char *buffer, unsigned int length) 3655 { 3656 unsigned int i; 3657 unsigned long crc32 = ~0L; 3658 unsigned long result; 3659 unsigned char byte0,byte1,byte2,byte3; 3661 for (i = 0; i < length; i++){ 3662 CRC32C(crc32, buffer[i]); 3663 } 3665 result = ~crc32; 3667 /* result now holds the negated polynomial remainder; 3668 * since the table and algorithm is "reflected" [williams95]. 3669 * That is, result has the same value as if we mapped the message 3670 * to a polynomial, computed the host-bit-order polynomial 3671 * remainder, performed final negation, then did an end-for-end 3672 * bit-reversal. 3674 * Note that a 32-bit bit-reversal is identical to four inplace 3675 * 8-bit reversals followed by an end-for-end byteswap. 3676 * In other words, the bytes of each bit are in the right order, 3677 * but the bytes have been byteswapped. So we now do an explicit 3678 * byteswap. On a little-endian machine, this byteswap and 3679 * the final ntohl cancel out and could be elided. 3680 */ 3682 byte0 = result & 0xff; 3683 byte1 = (result>>8) & 0xff; 3684 byte2 = (result>>16) & 0xff; 3685 byte3 = (result>>24) & 0xff; 3686 crc32 = ((byte0 << 24) | 3687 (byte1 << 16) | 3688 (byte2 << 8) | 3689 byte3); 3690 return ( crc32 ); 3691 } 3693 int 3694 insert_crc32(unsigned char *buffer, unsigned int length) 3695 { 3696 SCTP_message *message; 3697 unsigned long crc32; 3698 message = (SCTP_message *) buffer; 3699 message->common_header.checksum = 0L; 3700 crc32 = generate_crc32c(buffer,length); 3701 /* and insert it into the message */ 3702 message->common_header.checksum = htonl(crc32); 3703 return 1; 3704 } 3706 int 3707 validate_crc32(unsigned char *buffer, unsigned int length) 3708 { 3709 SCTP_message *message; 3710 unsigned int i; 3711 unsigned long original_crc32; 3712 unsigned long crc32 = ~0L; 3714 /* save and zero checksum */ 3715 message = (SCTP_message *) buffer; 3716 original_crc32 = ntohl(message->common_header.checksum); 3717 message->common_header.checksum = 0L; 3718 crc32 = generate_crc32c(buffer,length); 3719 return ((original_crc32 == crc32)? 1 : -1); 3720 } 3721 --------- 3722 New text: (Appendix B) 3723 --------- 3725 /* Example of crc insertion */ 3727 #include "crc32cr.h" 3729 uint32_t 3730 generate_crc32c(unsigned char *buffer, unsigned int length) 3731 { 3732 unsigned int i; 3733 uint32_t crc32 = 0xffffffffUL; 3734 uint32_t result; 3735 uint8_t byte0, byte1, byte2, byte3; 3737 for (i = 0; i < length; i++) { 3738 CRC32C(crc32, buffer[i]); 3739 } 3741 result = ~crc32; 3743 /* result now holds the negated polynomial remainder; 3744 * since the table and algorithm is "reflected" [williams95]. 3745 * That is, result has the same value as if we mapped the message 3746 * to a polynomial, computed the host-bit-order polynomial 3747 * remainder, performed final negation, then did an end-for-end 3748 * bit-reversal. 3749 * Note that a 32-bit bit-reversal is identical to four inplace 3750 * 8-bit reversals followed by an end-for-end byteswap. 3751 * In other words, the bits of each byte are in the right order, 3752 * but the bytes have been byteswapped. So we now do an explicit 3753 * byteswap. On a little-endian machine, this byteswap and 3754 * the final ntohl cancel out and could be elided. 3755 */ 3757 byte0 = result & 0xff; 3758 byte1 = (result>>8) & 0xff; 3759 byte2 = (result>>16) & 0xff; 3760 byte3 = (result>>24) & 0xff; 3761 crc32 = ((byte0 << 24) | 3762 (byte1 << 16) | 3763 (byte2 << 8) | 3764 byte3); 3765 return (crc32); 3766 } 3768 int 3769 insert_crc32(unsigned char *buffer, unsigned int length) 3770 { 3771 SCTP_message *message; 3772 uint32_t crc32; 3773 message = (SCTP_message *) buffer; 3774 message->common_header.checksum = 0UL; 3775 crc32 = generate_crc32c(buffer,length); 3776 /* and insert it into the message */ 3777 message->common_header.checksum = htonl(crc32); 3778 return 1; 3779 } 3781 int 3782 validate_crc32(unsigned char *buffer, unsigned int length) 3783 { 3784 SCTP_message *message; 3785 unsigned int i; 3786 uint32_t original_crc32; 3787 uint32_t crc32; 3789 /* save and zero checksum */ 3790 message = (SCTP_message *)buffer; 3791 original_crc32 = ntohl(message->common_header.checksum); 3792 message->common_header.checksum = 0L; 3793 crc32 = generate_crc32c(buffer, length); 3794 return ((original_crc32 == crc32)? 1 : -1); 3795 } 3796 3798 This text has been modified by multiple errata. It includes 3799 modifications from Section 3.5 and Section 3.10. It is in final 3800 form, and is not further updated in this document. 3802 3.46.3. Solution Description 3804 The code was changed to use platform independent types. 3806 3.47. Clarification of Gap Ack Blocks in SACK Chunks 3808 3.47.1. Description of the Problem 3810 The Gap Ack Blocks in the SACK chunk are intended to be isolated. 3811 However, this is not mentioned with normative text. 3813 This issue was reported as part of an Errata for [RFC4960] with 3814 Errata ID 5202. 3816 3.47.2. Text Changes to the Document 3818 --------- 3819 Old text: (Section 3.3.4) 3820 --------- 3822 The SACK also contains zero or more Gap Ack Blocks. Each Gap Ack 3823 Block acknowledges a subsequence of TSNs received following a break 3824 in the sequence of received TSNs. By definition, all TSNs 3825 acknowledged by Gap Ack Blocks are greater than the value of the 3826 Cumulative TSN Ack. 3828 --------- 3829 New text: (Section 3.3.4) 3830 --------- 3832 The SACK also contains zero or more Gap Ack Blocks. Each Gap Ack 3833 Block acknowledges a subsequence of TSNs received following a break 3834 in the sequence of received TSNs. The Gap Ack Blocks SHOULD be isolated. 3835 This means that the TSN just before each Gap Ack Block and the TSN just 3836 after each Gap Ack Block has not been received. By definition, all TSNs 3837 acknowledged by Gap Ack Blocks are greater than the value of the 3838 Cumulative TSN Ack. 3840 This text is in final form, and is not further updated in this 3841 document. 3843 --------- 3844 Old text: (Section 3.3.4) 3845 --------- 3847 Gap Ack Blocks: 3849 These fields contain the Gap Ack Blocks. They are repeated for 3850 each Gap Ack Block up to the number of Gap Ack Blocks defined in 3851 the Number of Gap Ack Blocks field. All DATA chunks with TSNs 3852 greater than or equal to (Cumulative TSN Ack + Gap Ack Block 3853 Start) and less than or equal to (Cumulative TSN Ack + Gap Ack 3854 Block End) of each Gap Ack Block are assumed to have been received 3855 correctly. 3857 --------- 3858 New text: (Section 3.3.4) 3859 --------- 3861 Gap Ack Blocks: 3863 These fields contain the Gap Ack Blocks. They are repeated for 3864 each Gap Ack Block up to the number of Gap Ack Blocks defined in 3865 the Number of Gap Ack Blocks field. All DATA chunks with TSNs 3866 greater than or equal to (Cumulative TSN Ack + Gap Ack Block 3867 Start) and less than or equal to (Cumulative TSN Ack + Gap Ack 3868 Block End) of each Gap Ack Block are assumed to have been received 3869 correctly. Gap Ack Blocks SHOULD be isolated. That means that 3870 the DATA chunks with TSN equal to (Cumulative TSN Ack + Gap Ack 3871 Block Start - 1) and (Cumulative TSN Ack + Gap Ack Block End + 1) 3872 have not been received. 3874 This text is in final form, and is not further updated in this 3875 document. 3877 3.47.3. Solution Description 3879 Normative text describing the intended usage of Gap Ack Blocks has 3880 been added. 3882 3.48. Handling of SSN Wrap Arounds 3884 3.48.1. Description of the Problem 3886 The Stream Sequence Number (SSN) is used for preserving the ordering 3887 of user messages within each SCTP stream. The SSN is limited to 16 3888 bits. Therefore, multiple wrap arounds of the SSN might happen 3889 within the current send window. To allow the receiver to deliver 3890 ordered user messages in the correct sequence, the sender should 3891 limit the number of user messages per stream. 3893 3.48.2. Text Changes to the Document 3895 --------- 3896 Old text: (Section 6.1) 3897 --------- 3899 Note: The data sender SHOULD NOT use a TSN that is more than 2**31 - 3900 1 above the beginning TSN of the current send window. 3902 --------- 3903 New text: (Section 6.1) 3904 --------- 3906 Note: The data sender SHOULD NOT use a TSN that is more than 2**31 - 3907 1 above the beginning TSN of the current send window. 3908 Note: For each stream, the data sender SHOULD NOT have more than 2**16-1 3909 ordered user messages in the current send window. 3911 This text is in final form, and is not further updated in this 3912 document. 3914 3.48.3. Solution Description 3916 The data sender is required to limit the number of ordered user 3917 messages within the current send window. 3919 3.49. Update RFC 2119 Boilerplate 3921 3.49.1. Description of the Problem 3923 The text to be used to refer to the [RFC2119] terms has been updated 3924 by [RFC8174]. 3926 3.49.2. Text Changes to the Document 3927 --------- 3928 Old text: (Section 2) 3929 --------- 3931 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 3932 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 3933 document are to be interpreted as described in RFC 2119 [RFC2119]. 3935 --------- 3936 New text: (Section 2) 3937 --------- 3939 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 3940 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 3941 "OPTIONAL" in this document are to be interpreted as described in 3942 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 3943 capitals, as shown here. 3945 This text is in final form, and is not further updated in this 3946 document. 3948 3.49.3. Solution Description 3950 The text has been updated to the one specified in [RFC8174]. 3952 3.50. Missed Text Removal 3954 3.50.1. Description of the Problem 3956 When integrating the changes to Section 7.2.4 of [RFC2960] as 3957 described in Section 2.8.2 of [RFC4460] some text was not removed and 3958 is therefore still in [RFC4960]. 3960 3.50.2. Text Changes to the Document 3961 --------- 3962 Old text: (Section 7.2.4) 3963 --------- 3965 A straightforward implementation of the above keeps a counter for 3966 each TSN hole reported by a SACK. The counter increments for each 3967 consecutive SACK reporting the TSN hole. After reaching 3 and 3968 starting the Fast-Retransmit procedure, the counter resets to 0. 3969 Because cwnd in SCTP indirectly bounds the number of outstanding 3970 TSN's, the effect of TCP Fast Recovery is achieved automatically with 3971 no adjustment to the congestion control window size. 3973 --------- 3974 New text: (Section 7.2.4) 3975 --------- 3977 This text is in final form, and is not further updated in this 3978 document. 3980 3.50.3. Solution Description 3982 The text has finally been removed. 3984 4. IANA Considerations 3986 Section 3.44 of this document updates the port number registry for 3987 SCTP to be consistent with [RFC6335]. IANA is requested to review 3988 Section 3.44. 3990 IANA is only requested to check if it is OK to make the proposed text 3991 change in an upcoming standards track document that updates 3992 [RFC4960]. IANA is not asked to perform any other action and this 3993 document does not request IANA to make a change to any registry. 3995 5. Security Considerations 3997 This document does not add any security considerations to those given 3998 in [RFC4960]. 4000 6. Acknowledgments 4002 The authors wish to thank Pontus Andersson, Eric W. Biederman, 4003 Cedric Bonnet, Spencer Dawkins, Gorry Fairhurst, Benjamin Kaduk, 4004 Mirja Kuehlewind, Peter Lei, Gyula Marosi, Lionel Morand, Jeff 4005 Morriss, Karen E. E. Nielsen, Tom Petch, Kacheong Poon, Julien 4006 Pourtet, Irene Ruengeler, Michael Welzl, and Qiaobing Xie for their 4007 invaluable comments. 4009 7. References 4011 7.1. Normative References 4013 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 4014 Requirement Levels", BCP 14, RFC 2119, 4015 DOI 10.17487/RFC2119, March 1997, 4016 . 4018 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 4019 RFC 4960, DOI 10.17487/RFC4960, September 2007, 4020 . 4022 7.2. Informative References 4024 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 4025 Communication Layers", STD 3, RFC 1122, 4026 DOI 10.17487/RFC1122, October 1989, 4027 . 4029 [RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security 4030 Considerations for IP Fragment Filtering", RFC 1858, 4031 DOI 10.17487/RFC1858, October 1995, 4032 . 4034 [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., 4035 Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., 4036 Zhang, L., and V. Paxson, "Stream Control Transmission 4037 Protocol", RFC 2960, DOI 10.17487/RFC2960, October 2000, 4038 . 4040 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 4041 of Explicit Congestion Notification (ECN) to IP", 4042 RFC 3168, DOI 10.17487/RFC3168, September 2001, 4043 . 4045 [RFC4460] Stewart, R., Arias-Rodriguez, I., Poon, K., Caro, A., and 4046 M. Tuexen, "Stream Control Transmission Protocol (SCTP) 4047 Specification Errata and Issues", RFC 4460, 4048 DOI 10.17487/RFC4460, April 2006, 4049 . 4051 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 4052 Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, 4053 . 4055 [RFC6096] Tuexen, M. and R. Stewart, "Stream Control Transmission 4056 Protocol (SCTP) Chunk Flags Registration", RFC 6096, 4057 DOI 10.17487/RFC6096, January 2011, 4058 . 4060 [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, 4061 "Computing TCP's Retransmission Timer", RFC 6298, 4062 DOI 10.17487/RFC6298, June 2011, 4063 . 4065 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 4066 Cheshire, "Internet Assigned Numbers Authority (IANA) 4067 Procedures for the Management of the Service Name and 4068 Transport Protocol Port Number Registry", BCP 165, 4069 RFC 6335, DOI 10.17487/RFC6335, August 2011, 4070 . 4072 [RFC7053] Tuexen, M., Ruengeler, I., and R. Stewart, "SACK- 4073 IMMEDIATELY Extension for the Stream Control Transmission 4074 Protocol", RFC 7053, DOI 10.17487/RFC7053, November 2013, 4075 . 4077 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 4078 Writing an IANA Considerations Section in RFCs", BCP 26, 4079 RFC 8126, DOI 10.17487/RFC8126, June 2017, 4080 . 4082 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 4083 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 4084 May 2017, . 4086 [RFC8311] Black, D., "Relaxing Restrictions on Explicit Congestion 4087 Notification (ECN) Experimentation", RFC 8311, 4088 DOI 10.17487/RFC8311, January 2018, 4089 . 4091 Authors' Addresses 4093 Randall R. Stewart 4094 Netflix, Inc. 4095 Chapin, SC 29036 4096 United States 4098 Email: randall@lakerest.net 4099 Michael Tuexen 4100 Muenster University of Applied Sciences 4101 Stegerwaldstrasse 39 4102 48565 Steinfurt 4103 Germany 4105 Email: tuexen@fh-muenster.de 4107 Maksim Proshin 4108 Ericsson 4109 Kistavaegen 25 4110 Stockholm 164 80 4111 Sweden 4113 Email: mproshin@tieto.mera.ru