idnits 2.17.1 draft-ietf-tsvwg-rfc4960-errata-06.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 3156 has weird spacing: '...ed long crc_c...' == Line 3377 has weird spacing: '...ed long crc_c...' -- The document date (May 21, 2018) is 2160 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 2909, but not defined ** Obsolete undefined reference: RFC 2434 (Obsoleted by RFC 5226) == Missing Reference: 'RFC0813' is mentioned on line 411, but not defined ** Obsolete undefined reference: RFC 813 (Obsoleted by RFC 7805) == Missing Reference: 'WILLIAMS93' is mentioned on line 744, but not defined -- Looks like a reference, but probably isn't: '256' on line 3156 ** 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: November 22, 2018 Muenster Univ. of Appl. Sciences 6 M. Proshin 7 Ericsson 8 May 21, 2018 10 RFC 4960 Errata and Issues 11 draft-ietf-tsvwg-rfc4960-errata-06.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 November 22, 2018. 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 . . . . . 21 75 3.14. Path for Fast Retransmission . . . . . . . . . . . . . . 23 76 3.15. Transmittal in Fast Recovery . . . . . . . . . . . . . . 24 77 3.16. Initial Value of ssthresh . . . . . . . . . . . . . . . . 24 78 3.17. Automatically Confirmed Addresses . . . . . . . . . . . . 25 79 3.18. Only One Packet after Retransmission Timeout . . . . . . 26 80 3.19. INIT ACK Path for INIT in COOKIE-WAIT State . . . . . . . 27 81 3.20. Zero Window Probing and Unreachable Primary Path . . . . 28 82 3.21. Normative Language in Section 10 . . . . . . . . . . . . 29 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 . . . . . . 38 86 3.25. Processing of Chunks in an Incoming SCTP Packet . . . . . 40 87 3.26. CWND Increase in Congestion Avoidance Phase . . . . . . . 41 88 3.27. Refresh of cwnd and ssthresh after Idle Period . . . . . 43 89 3.28. Window Updates After Receiver Window Opens Up . . . . . . 44 90 3.29. Path of DATA and Reply Chunks . . . . . . . . . . . . . . 45 91 3.30. Outstanding Data, Flightsize and Data In Flight Key Terms 47 92 3.31. CWND Degradation due to Max.Burst . . . . . . . . . . . . 48 93 3.32. Reduction of RTO.Initial . . . . . . . . . . . . . . . . 49 94 3.33. Ordering of Bundled SACK and ERROR Chunks . . . . . . . . 51 95 3.34. Undefined Parameter Returned by RECEIVE Primitive . . . . 51 96 3.35. DSCP Changes . . . . . . . . . . . . . . . . . . . . . . 52 97 3.36. Inconsistent Handling of ICMPv4 and ICMPv6 Messages . . . 54 98 3.37. Handling of Soft Errors . . . . . . . . . . . . . . . . . 55 99 3.38. Honoring CWND . . . . . . . . . . . . . . . . . . . . . . 56 100 3.39. Zero Window Probing . . . . . . . . . . . . . . . . . . . 57 101 3.40. Updating References Regarding ECN . . . . . . . . . . . . 59 102 3.41. Host Name Address Parameter Deprecated . . . . . . . . . 60 103 3.42. Conflicting Text Regarding the Supported Address Types 104 Parameter . . . . . . . . . . . . . . . . . . . . . . . . 64 105 3.43. Integration of RFC 6096 . . . . . . . . . . . . . . . . . 65 106 3.44. Integration of RFC 6335 . . . . . . . . . . . . . . . . . 67 107 3.45. Integration of RFC 7053 . . . . . . . . . . . . . . . . . 69 108 3.46. CRC32c Code Improvements . . . . . . . . . . . . . . . . 72 109 3.47. Clarification of Gap Ack Blocks in SACK Chunks . . . . . 82 110 3.48. Handling of SSN Wrap Arounds . . . . . . . . . . . . . . 84 111 3.49. Update RFC 2119 Boilerplate . . . . . . . . . . . . . . . 85 112 3.50. Missed Text Removal . . . . . . . . . . . . . . . . . . . 85 113 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 86 114 5. Security Considerations . . . . . . . . . . . . . . . . . . . 86 115 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 86 116 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 86 117 7.1. Normative References . . . . . . . . . . . . . . . . . . 87 118 7.2. Informative References . . . . . . . . . . . . . . . . . 87 119 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 88 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 3.1.3. Solution Description 208 The intended state change should happen when the threshold is 209 exceeded. 211 3.2. Upper Layer Protocol Shutdown Request Handling 213 3.2.1. Description of the Problem 215 Section 9.2 of [RFC4960] describes the handling of received SHUTDOWN 216 chunks in the SHUTDOWN-RECEIVED state instead of the handling of 217 shutdown requests from its upper layer in this state. 219 This issue was reported as an Errata for [RFC4960] with Errata ID 220 1574. 222 3.2.2. Text Changes to the Document 223 --------- 224 Old text: (Section 9.2) 225 --------- 227 Once an endpoint has reached the SHUTDOWN-RECEIVED state, it MUST NOT 228 send a SHUTDOWN in response to a ULP request, and should discard 229 subsequent SHUTDOWN chunks. 231 --------- 232 New text: (Section 9.2) 233 --------- 235 Once an endpoint has reached the SHUTDOWN-RECEIVED state, it MUST 236 ignore ULP shutdown requests, but MUST continue responding 237 to SHUTDOWN chunks from its peer. 239 3.2.3. Solution Description 241 The text never intended the SCTP endpoint to ignore SHUTDOWN chunks 242 from its peer. If it did, the endpoints could never gracefully 243 terminate associations in some cases. 245 3.3. Registration of New Chunk Types 247 3.3.1. Description of the Problem 249 Section 14.1 of [RFC4960] should deal with new chunk types, however, 250 the text refers to parameter types. 252 This issue was reported as an Errata for [RFC4960] with Errata ID 253 2592. 255 3.3.2. Text Changes to the Document 256 --------- 257 Old text: (Section 14.1) 258 --------- 260 The assignment of new chunk parameter type codes is done through an 261 IETF Consensus action, as defined in [RFC2434]. Documentation of the 262 chunk parameter MUST contain the following information: 264 --------- 265 New text: (Section 14.1) 266 --------- 268 The assignment of new chunk type codes is done through an 269 IETF Consensus action, as defined in [RFC8126]. Documentation of the 270 chunk type MUST contain the following information: 272 3.3.3. Solution Description 274 Refer to chunk types as intended and change reference to [RFC8126]. 276 3.4. Variable Parameters for INIT Chunks 278 3.4.1. Description of the Problem 280 Newlines in wrong places break the layout of the table of variable 281 parameters for the INIT chunk in Section 3.3.2 of [RFC4960]. 283 This issue was reported as an Errata for [RFC4960] with Errata ID 284 3291 and Errata ID 3804. 286 3.4.2. Text Changes to the Document 287 --------- 288 Old text: (Section 3.3.2) 289 --------- 291 Variable Parameters Status Type Value 292 ------------------------------------------------------------- 293 IPv4 Address (Note 1) Optional 5 IPv6 Address 294 (Note 1) Optional 6 Cookie Preservative 295 Optional 9 Reserved for ECN Capable (Note 2) Optional 296 32768 (0x8000) Host Name Address (Note 3) Optional 297 11 Supported Address Types (Note 4) Optional 12 299 --------- 300 New text: (Section 3.3.2) 301 --------- 303 Variable Parameters Status Type Value 304 ------------------------------------------------------------- 305 IPv4 Address (Note 1) Optional 5 306 IPv6 Address (Note 1) Optional 6 307 Cookie Preservative Optional 9 308 Reserved for ECN Capable (Note 2) Optional 32768 (0x8000) 309 Host Name Address (Note 3) Optional 11 310 Supported Address Types (Note 4) Optional 12 312 3.4.3. Solution Description 314 Fix the formatting of the table. 316 3.5. CRC32c Sample Code on 64-bit Platforms 318 3.5.1. Description of the Problem 320 The sample code for computing the CRC32c provided in [RFC4960] 321 assumes that a variable of type unsigned long uses 32 bits. This is 322 not true on some 64-bit platforms (for example the ones using LP64). 324 This issue was reported as an Errata for [RFC4960] with Errata ID 325 3423. 327 3.5.2. Text Changes to the Document 328 --------- 329 Old text: (Appendix C) 330 --------- 332 unsigned long 333 generate_crc32c(unsigned char *buffer, unsigned int length) 334 { 335 unsigned int i; 336 unsigned long crc32 = ~0L; 338 --------- 339 New text: (Appendix C) 340 --------- 342 unsigned long 343 generate_crc32c(unsigned char *buffer, unsigned int length) 344 { 345 unsigned int i; 346 unsigned long crc32 = 0xffffffffL; 348 3.5.3. Solution Description 350 Use 0xffffffffL instead of ~0L which gives the same value on 351 platforms using 32 bits or 64 bits for variables of type unsigned 352 long. 354 3.6. Endpoint Failure Detection 356 3.6.1. Description of the Problem 358 The handling of the association error counter defined in Section 8.1 359 of [RFC4960] can result in an association failure even if the path 360 used for data transmission is available, but idle. 362 This issue was reported as an Errata for [RFC4960] with Errata ID 363 3788. 365 3.6.2. Text Changes to the Document 366 --------- 367 Old text: (Section 8.1) 368 --------- 370 An endpoint shall keep a counter on the total number of consecutive 371 retransmissions to its peer (this includes retransmissions to all the 372 destination transport addresses of the peer if it is multi-homed), 373 including unacknowledged HEARTBEAT chunks. 375 --------- 376 New text: (Section 8.1) 377 --------- 379 An endpoint SHOULD keep a counter on the total number of consecutive 380 retransmissions to its peer (this includes data retransmissions 381 to all the destination transport addresses of the peer if it is 382 multi-homed), including the number of unacknowledged HEARTBEAT 383 chunks observed on the path which is currently used for data 384 transfer. Unacknowledged HEARTBEAT chunks observed on paths 385 different from the path currently used for data transfer SHOULD 386 NOT increment the association error counter, as this could lead 387 to association closure even if the path which is currently used for 388 data transfer is available (but idle). 390 3.6.3. Solution Description 392 A more refined handling for the association error counter is defined. 394 3.7. Data Transmission Rules 396 3.7.1. Description of the Problem 398 When integrating the changes to Section 6.1 A) of [RFC2960] as 399 described in Section 2.15.2 of [RFC4460] some text was duplicated and 400 became the final paragraph of Section 6.1 A) of [RFC4960]. 402 This issue was reported as an Errata for [RFC4960] with Errata ID 403 4071. 405 3.7.2. Text Changes to the Document 406 --------- 407 Old text: (Section 6.1 A)) 408 --------- 410 The sender MUST also have an algorithm for sending new DATA chunks 411 to avoid silly window syndrome (SWS) as described in [RFC0813]. 412 The algorithm can be similar to the one described in Section 413 4.2.3.4 of [RFC1122]. 415 However, regardless of the value of rwnd (including if it is 0), 416 the data sender can always have one DATA chunk in flight to the 417 receiver if allowed by cwnd (see rule B below). This rule allows 418 the sender to probe for a change in rwnd that the sender missed 419 due to the SACK having been lost in transit from the data receiver 420 to the data sender. 422 --------- 423 New text: (Section 6.1 A)) 424 --------- 426 The sender MUST also have an algorithm for sending new DATA chunks 427 to avoid silly window syndrome (SWS) as described in [RFC1122]. 428 The algorithm can be similar to the one described in Section 429 4.2.3.4 of [RFC1122]. 431 3.7.3. Solution Description 433 Last paragraph of Section 6.1 A) removed as intended in 434 Section 2.15.2 of [RFC4460]. 436 3.8. T1-Cookie Timer 438 3.8.1. Description of the Problem 440 Figure 4 of [RFC4960] illustrates the SCTP association setup. 441 However, it incorrectly shows that the T1-init timer is used in the 442 COOKIE-ECHOED state whereas the T1-cookie timer should have been used 443 instead. 445 This issue was reported as an Errata for [RFC4960] with Errata ID 446 4400. 448 3.8.2. Text Changes to the Document 449 --------- 450 Old text: (Section 5.1.6, Figure 4) 451 --------- 453 COOKIE ECHO [Cookie_Z] ------\ 454 (Start T1-init timer) \ 455 (Enter COOKIE-ECHOED state) \---> (build TCB enter ESTABLISHED 456 state) 457 /---- COOKIE-ACK 458 / 459 (Cancel T1-init timer, <-----/ 460 Enter ESTABLISHED state) 462 --------- 463 New text: (Section 5.1.6, Figure 4) 464 --------- 466 COOKIE ECHO [Cookie_Z] ------\ 467 (Start T1-cookie timer) \ 468 (Enter COOKIE-ECHOED state) \---> (build TCB enter ESTABLISHED 469 state) 470 /---- COOKIE-ACK 471 / 472 (Cancel T1-cookie timer, <---/ 473 Enter ESTABLISHED state) 475 3.8.3. Solution Description 477 Change the figure such that the T1-cookie timer is used instead of 478 the T1-init timer. 480 3.9. Miscellaneous Typos 482 3.9.1. Description of the Problem 484 While processing [RFC4960] some typos were not caught. 486 3.9.2. Text Changes to the Document 487 --------- 488 Old text: (Section 1.6) 489 --------- 491 Transmission Sequence Numbers wrap around when they reach 2**32 - 1. 492 That is, the next TSN a DATA chunk MUST use after transmitting TSN = 493 2*32 - 1 is TSN = 0. 495 --------- 496 New text: (Section 1.6) 497 --------- 499 Transmission Sequence Numbers wrap around when they reach 2**32 - 1. 500 That is, the next TSN a DATA chunk MUST use after transmitting TSN = 501 2**32 - 1 is TSN = 0. 503 --------- 504 Old text: (Section 3.3.10.9) 505 --------- 507 No User Data: This error cause is returned to the originator of a 509 DATA chunk if a received DATA chunk has no user data. 511 --------- 512 New text: (Section 3.3.10.9) 513 --------- 515 No User Data: This error cause is returned to the originator of a 516 DATA chunk if a received DATA chunk has no user data. 518 --------- 519 Old text: (Section 6.7, Figure 9) 520 --------- 522 Endpoint A Endpoint Z {App 523 sends 3 messages; strm 0} DATA [TSN=6,Strm=0,Seq=2] ---------- 524 -----> (ack delayed) (Start T3-rtx timer) 526 DATA [TSN=7,Strm=0,Seq=3] --------> X (lost) 528 DATA [TSN=8,Strm=0,Seq=4] ---------------> (gap detected, 529 immediately send ack) 530 /----- SACK [TSN Ack=6,Block=1, 531 / Start=2,End=2] 532 <-----/ (remove 6 from out-queue, 533 and mark 7 as "1" missing report) 535 --------- 536 New text: (Section 6.7, Figure 9) 537 --------- 539 Endpoint A Endpoint Z 540 {App sends 3 messages; strm 0} 541 DATA [TSN=6,Strm=0,Seq=2] ---------------> (ack delayed) 542 (Start T3-rtx timer) 544 DATA [TSN=7,Strm=0,Seq=3] --------> X (lost) 546 DATA [TSN=8,Strm=0,Seq=4] ---------------> (gap detected, 547 immediately send ack) 548 /----- SACK [TSN Ack=6,Block=1, 549 / Start=2,End=2] 550 <-----/ 551 (remove 6 from out-queue, 552 and mark 7 as "1" missing report) 554 --------- 555 Old text: (Section 6.10) 556 --------- 558 An endpoint bundles chunks by simply including multiple chunks in one 559 outbound SCTP packet. The total size of the resultant IP datagram, 561 including the SCTP packet and IP headers, MUST be less that or equal 562 to the current Path MTU. 564 --------- 565 New text: (Section 6.10) 566 --------- 568 An endpoint bundles chunks by simply including multiple chunks in one 569 outbound SCTP packet. The total size of the resultant IP datagram, 570 including the SCTP packet and IP headers, MUST be less than or equal 571 to the current PMTU. 573 --------- 574 Old text: (Section 10.1) 575 --------- 577 o Receive Unacknowledged Message 579 Format: RECEIVE_UNACKED(data retrieval id, buffer address, buffer 580 size, [,stream id] [, stream sequence number] [,partial 581 flag] [,payload protocol-id]) 583 --------- 584 New text: (Section 10.1) 585 --------- 587 O) Receive Unacknowledged Message 589 Format: RECEIVE_UNACKED(data retrieval id, buffer address, buffer 590 size [,stream id] [,stream sequence number] [,partial 591 flag] [,payload protocol-id]) 593 --------- 594 Old text: (Section 10.1) 595 --------- 597 M) Set Protocol Parameters 599 Format: SETPROTOCOLPARAMETERS(association id, 600 [,destination transport address,] 601 protocol parameter list) 603 --------- 604 New text: (Section 10.1) 605 --------- 607 M) Set Protocol Parameters 609 Format: SETPROTOCOLPARAMETERS(association id, 610 [destination transport address,] 611 protocol parameter list) 613 --------- 614 Old text: (Appendix C) 615 --------- 617 ICMP2) An implementation MAY ignore all ICMPv6 messages where the 618 type field is not "Destination Unreachable", "Parameter 619 Problem",, or "Packet Too Big". 621 --------- 622 New text: (Appendix C) 623 --------- 625 ICMP2) An implementation MAY ignore all ICMPv6 messages where the 626 type field is not "Destination Unreachable", "Parameter 627 Problem", or "Packet Too Big". 629 --------- 630 Old text: (Appendix C) 631 --------- 633 ICMP7) If the ICMP message is either a v6 "Packet Too Big" or a v4 634 "Fragmentation Needed", an implementation MAY process this 635 information as defined for PATH MTU discovery. 637 --------- 638 New text: (Appendix C) 639 --------- 641 ICMP7) If the ICMP message is either a v6 "Packet Too Big" or a v4 642 "Fragmentation Needed", an implementation MAY process this 643 information as defined for PMTU discovery. 645 --------- 646 Old text: (Section 5.4) 647 --------- 649 2) For the receiver of the COOKIE ECHO, the only CONFIRMED address 650 is the one to which the INIT-ACK was sent. 652 --------- 653 New text: (Section 5.4) 654 --------- 656 2) For the receiver of the COOKIE ECHO, the only CONFIRMED address 657 is the one to which the INIT ACK was sent. 659 --------- 660 Old text: (Section 5.1.6, Figure 4) 661 --------- 663 COOKIE ECHO [Cookie_Z] ------\ 664 (Start T1-init timer) \ 665 (Enter COOKIE-ECHOED state) \---> (build TCB enter ESTABLISHED 666 state) 667 /---- COOKIE-ACK 668 / 669 (Cancel T1-init timer, <-----/ 670 Enter ESTABLISHED state) 672 --------- 673 New text: (Section 5.1.6, Figure 4) 674 --------- 676 COOKIE ECHO [Cookie_Z] ------\ 677 (Start T1-cookie timer) \ 678 (Enter COOKIE-ECHOED state) \---> (build TCB enter ESTABLISHED 679 state) 680 /---- COOKIE ACK 681 / 682 (Cancel T1-cookie timer, <---/ 683 Enter ESTABLISHED state) 685 --------- 686 Old text: (Section 5.2.5) 687 --------- 689 5.2.5. Handle Duplicate COOKIE-ACK. 691 --------- 692 New text: (Section 5.2.5) 693 --------- 695 5.2.5. Handle Duplicate COOKIE ACK. 697 --------- 698 Old text: (Section 8.3) 699 --------- 701 By default, an SCTP endpoint SHOULD monitor the reachability of the 702 idle destination transport address(es) of its peer by sending a 703 HEARTBEAT chunk periodically to the destination transport 704 address(es). HEARTBEAT sending MAY begin upon reaching the 705 ESTABLISHED state and is discontinued after sending either SHUTDOWN 706 or SHUTDOWN-ACK. A receiver of a HEARTBEAT MUST respond to a 707 HEARTBEAT with a HEARTBEAT-ACK after entering the COOKIE-ECHOED state 708 (INIT sender) or the ESTABLISHED state (INIT receiver), up until 709 reaching the SHUTDOWN-SENT state (SHUTDOWN sender) or the SHUTDOWN- 710 ACK-SENT state (SHUTDOWN receiver). 712 --------- 713 New text: (Section 8.3) 714 --------- 715 By default, an SCTP endpoint SHOULD monitor the reachability of the 716 idle destination transport address(es) of its peer by sending a 717 HEARTBEAT chunk periodically to the destination transport 718 address(es). HEARTBEAT sending MAY begin upon reaching the 719 ESTABLISHED state and is discontinued after sending either SHUTDOWN 720 or SHUTDOWN ACK. A receiver of a HEARTBEAT MUST respond to a 721 HEARTBEAT with a HEARTBEAT ACK after entering the COOKIE-ECHOED state 722 (INIT sender) or the ESTABLISHED state (INIT receiver), up until 723 reaching the SHUTDOWN-SENT state (SHUTDOWN sender) or the SHUTDOWN- 724 ACK-SENT state (SHUTDOWN receiver). 726 3.9.3. Solution Description 728 Typos fixed. 730 3.10. CRC32c Sample Code 732 3.10.1. Description of the Problem 734 The CRC32c computation is described in Appendix B of [RFC4960]. 735 However, the corresponding sample code and its explanation appears at 736 the end of Appendix C, which deals with ICMP handling. 738 3.10.2. Text Changes to the Document 740 Move all of Appendix C starting with the following sentence to the 741 end of Appendix B. 743 The following non-normative sample code is taken from an open-source 744 CRC generator [WILLIAMS93], using the "mirroring" technique and 745 yielding a lookup table for SCTP CRC32c with 256 entries, each 32 746 bits wide. 748 3.10.3. Solution Description 750 Text moved to the appropriate location. 752 3.11. partial_bytes_acked after T3-rtx Expiration 754 3.11.1. Description of the Problem 756 Section 7.2.3 of [RFC4960] explicitly states that partial_bytes_acked 757 should be reset to 0 after packet loss detection from SACK but the 758 same is missed for T3-rtx timer expiration. 760 3.11.2. Text Changes to the Document 762 --------- 763 Old text: (Section 7.2.3) 764 --------- 766 When the T3-rtx timer expires on an address, SCTP should perform slow 767 start by: 769 ssthresh = max(cwnd/2, 4*MTU) 770 cwnd = 1*MTU 772 --------- 773 New text: (Section 7.2.3) 774 --------- 776 When the T3-rtx timer expires on an address, SCTP SHOULD perform slow 777 start by: 779 ssthresh = max(cwnd/2, 4*MTU) 780 cwnd = 1*MTU 781 partial_bytes_acked = 0 783 3.11.3. Solution Description 785 Specify that partial_bytes_acked should be reset to 0 after T3-rtx 786 timer expiration. 788 3.12. Order of Adjustments of partial_bytes_acked and cwnd 790 3.12.1. Description of the Problem 792 Section 7.2.2 of [RFC4960] likely implies the wrong order of of 793 adjustments applied to partial_bytes_acked and cwnd in the congestion 794 avoidance phase. 796 3.12.2. Text Changes to the Document 798 --------- 799 Old text: (Section 7.2.2) 800 --------- 802 o When partial_bytes_acked is equal to or greater than cwnd and 803 before the arrival of the SACK the sender had cwnd or more bytes 804 of data outstanding (i.e., before arrival of the SACK, flightsize 805 was greater than or equal to cwnd), increase cwnd by MTU, and 806 reset partial_bytes_acked to (partial_bytes_acked - cwnd). 808 --------- 809 New text: (Section 7.2.2) 810 --------- 812 o When partial_bytes_acked is equal to or greater than cwnd and 813 before the arrival of the SACK the sender had cwnd or more bytes 814 of data outstanding (i.e., before arrival of the SACK, flightsize 815 was greater than or equal to cwnd), partial_bytes_acked is reset 816 to (partial_bytes_acked - cwnd). Next, cwnd is increased by 1*MTU. 818 3.12.3. Solution Description 820 The new text defines the exact order of adjustments of 821 partial_bytes_acked and cwnd in the congestion avoidance phase. 823 3.13. HEARTBEAT ACK and the association error counter 825 3.13.1. Description of the Problem 827 Section 8.1 and Section 8.3 of [RFC4960] prescribe that the receiver 828 of a HEARTBEAT ACK must reset the association overall error counter. 829 In some circumstances, e.g. when a router discards DATA chunks but 830 not HEARTBEAT chunks due to the larger size of the DATA chunk, it 831 might be better to not clear the association error counter on 832 reception of the HEARTBEAT ACK and reset it only on reception of the 833 SACK to avoid stalling the association. 835 3.13.2. Text Changes to the Document 837 --------- 838 Old text: (Section 8.1) 839 --------- 841 The counter shall be reset each time a DATA chunk sent to that peer 842 endpoint is acknowledged (by the reception of a SACK) or a HEARTBEAT 843 ACK is received from the peer endpoint. 845 --------- 846 New text: (Section 8.1) 847 --------- 849 The counter MUST be reset each time a DATA chunk sent to that peer 850 endpoint is acknowledged (by the reception of a SACK). When a 851 HEARTBEAT ACK is received from the peer endpoint, the counter SHOULD 852 also be reset. The receiver of the HEARTBEAT ACK MAY choose not to 853 clear the counter if there is outstanding data on the association. 854 This allows for handling the possible difference in reachability 855 based on DATA chunks and HEARTBEAT chunks. 857 --------- 858 Old text: (Section 8.3) 859 --------- 861 Upon the receipt of the HEARTBEAT ACK, the sender of the HEARTBEAT 862 should clear the error counter of the destination transport address 863 to which the HEARTBEAT was sent, and mark the destination transport 864 address as active if it is not so marked. The endpoint may 865 optionally report to the upper layer when an inactive destination 866 address is marked as active due to the reception of the latest 867 HEARTBEAT ACK. The receiver of the HEARTBEAT ACK must also clear the 868 association overall error count as well (as defined in Section 8.1). 870 --------- 871 New text: (Section 8.3) 872 --------- 874 Upon the receipt of the HEARTBEAT ACK, the sender of the HEARTBEAT 875 MUST clear the error counter of the destination transport address 876 to which the HEARTBEAT was sent, and mark the destination transport 877 address as active if it is not so marked. The endpoint MAY 878 optionally report to the upper layer when an inactive destination 879 address is marked as active due to the reception of the latest 880 HEARTBEAT ACK. The receiver of the HEARTBEAT ACK SHOULD also clear 881 the association overall error counter (as defined in Section 8.1). 883 3.13.3. Solution Description 885 The new text provides a possibility to not reset the association 886 overall error counter when a HEARTBEAT ACK is received if there are 887 valid reasons for it. 889 3.14. Path for Fast Retransmission 891 3.14.1. Description of the Problem 893 [RFC4960] clearly describes where to retransmit data that is timed 894 out when the peer is multi-homed but the same is not stated for fast 895 retransmissions. 897 3.14.2. Text Changes to the Document 899 --------- 900 Old text: (Section 6.4) 901 --------- 903 Furthermore, when its peer is multi-homed, an endpoint SHOULD try to 904 retransmit a chunk that timed out to an active destination transport 905 address that is different from the last destination address to which 906 the DATA chunk was sent. 908 --------- 909 New text: (Section 6.4) 910 --------- 912 Furthermore, when its peer is multi-homed, an endpoint SHOULD try to 913 retransmit a chunk that timed out to an active destination transport 914 address that is different from the last destination address to which 915 the DATA chunk was sent. 917 When its peer is multi-homed, an endpoint SHOULD send fast 918 retransmissions to the same destination transport address where the 919 original data was sent to. If the primary path has been changed and the 920 original data was sent there before the fast retransmit, the 921 implementation MAY send it to the new primary path. 923 3.14.3. Solution Description 925 The new text clarifies where to send fast retransmissions. 927 3.15. Transmittal in Fast Recovery 929 3.15.1. Description of the Problem 931 The Fast Retransmit on Gap Reports algorithm intends that only the 932 very first packet may be sent regardless of cwnd in the Fast Recovery 933 phase but rule 3) of [RFC4960], Section 7.2.4, misses this 934 clarification. 936 3.15.2. Text Changes to the Document 938 --------- 939 Old text: (Section 7.2.4) 940 --------- 942 3) Determine how many of the earliest (i.e., lowest TSN) DATA chunks 943 marked for retransmission will fit into a single packet, subject 944 to constraint of the path MTU of the destination transport 945 address to which the packet is being sent. Call this value K. 946 Retransmit those K DATA chunks in a single packet. When a Fast 947 Retransmit is being performed, the sender SHOULD ignore the value 948 of cwnd and SHOULD NOT delay retransmission for this single 949 packet. 951 --------- 952 New text: (Section 7.2.4) 953 --------- 955 3) If not in Fast Recovery, determine how many of the earliest 956 (i.e., lowest TSN) DATA chunks marked for retransmission will fit 957 into a single packet, subject to constraint of the PMTU of 958 the destination transport address to which the packet is being 959 sent. Call this value K. Retransmit those K DATA chunks in a 960 single packet. When a Fast Retransmit is being performed, the 961 sender SHOULD ignore the value of cwnd and SHOULD NOT delay 962 retransmission for this single packet. 964 3.15.3. Solution Description 966 The new text explicitly specifies to send only the first packet in 967 the Fast Recovery phase disregarding cwnd limitations. 969 3.16. Initial Value of ssthresh 970 3.16.1. Description of the Problem 972 The initial value of ssthresh should be set arbitrarily high. Using 973 the advertised receiver window of the peer is inappropriate if the 974 peer increases its window after the handshake. Furthermore, use a 975 higher requirements level, since not following the advice may result 976 in performance problems. 978 3.16.2. Text Changes to the Document 980 --------- 981 Old text: (Section 7.2.1) 982 --------- 984 o The initial value of ssthresh MAY be arbitrarily high (for 985 example, implementations MAY use the size of the receiver 986 advertised window). 988 --------- 989 New text: (Section 7.2.1) 990 --------- 992 o The initial value of ssthresh SHOULD be arbitrarily high (e.g., 993 the size of the largest possible advertised window). 995 3.16.3. Solution Description 997 Use the same value as suggested in [RFC5681], Section 3.1, as an 998 appropriate initial value. Furthermore, use the same requirements 999 level. 1001 3.17. Automatically Confirmed Addresses 1003 3.17.1. Description of the Problem 1005 The Path Verification procedure of [RFC4960] prescribes that any 1006 address passed to the sender of the INIT by its upper layer is 1007 automatically CONFIRMED. This, however, is unclear if only addresses 1008 in the request to initiate association establishment are considered 1009 or any addresses provided by the upper layer in any requests (e.g. in 1010 'Set Primary'). 1012 3.17.2. Text Changes to the Document 1013 --------- 1014 Old text: (Section 5.4) 1015 --------- 1017 1) Any address passed to the sender of the INIT by its upper layer 1018 is automatically considered to be CONFIRMED. 1020 --------- 1021 New text: (Section 5.4) 1022 --------- 1024 1) Any addresses passed to the sender of the INIT by its upper 1025 layer in the request to initialize an association are 1026 automatically considered to be CONFIRMED. 1028 3.17.3. Solution Description 1030 The new text clarifies that only addresses provided by the upper 1031 layer in the request to initialize an association are automatically 1032 confirmed. 1034 3.18. Only One Packet after Retransmission Timeout 1036 3.18.1. Description of the Problem 1038 [RFC4960] is not completely clear when it describes data transmission 1039 after T3-rtx timer expiration. Section 7.2.1 does not specify how 1040 many packets are allowed to be sent after T3-rtx timer expiration if 1041 more than one packet fit into cwnd. At the same time, Section 7.2.3 1042 has the text without normative language saying that SCTP should 1043 ensure that no more than one packet will be in flight after T3-rtx 1044 timer expiration until successful acknowledgment. It makes the text 1045 inconsistent. 1047 3.18.2. Text Changes to the Document 1048 --------- 1049 Old text: (Section 7.2.1) 1050 --------- 1052 o The initial cwnd after a retransmission timeout MUST be no more 1053 than 1*MTU. 1055 --------- 1056 New text: (Section 7.2.1) 1057 --------- 1059 o The initial cwnd after a retransmission timeout MUST be no more 1060 than 1*MTU and only one packet is allowed to be in flight 1061 until successful acknowledgement. 1063 3.18.3. Solution Description 1065 The new text clearly specifies that only one packet is allowed to be 1066 sent after T3-rtx timer expiration until successful acknowledgement. 1068 3.19. INIT ACK Path for INIT in COOKIE-WAIT State 1070 3.19.1. Description of the Problem 1072 In case of an INIT received in the COOKIE-WAIT state [RFC4960] 1073 prescribes to send an INIT ACK to the same destination address to 1074 which the original INIT has been sent. This text does not address 1075 the possibility of the upper layer to provide multiple remote IP 1076 addresses while requesting the association establishment. If the 1077 upper layer has provided multiple IP addresses and only a subset of 1078 these addresses are supported by the peer then the destination 1079 address of the original INIT may be absent in the incoming INIT and 1080 sending INIT ACK to that address is useless. 1082 3.19.2. Text Changes to the Document 1083 --------- 1084 Old text: (Section 5.2.1) 1085 --------- 1087 Upon receipt of an INIT in the COOKIE-WAIT state, an endpoint MUST 1088 respond with an INIT ACK using the same parameters it sent in its 1089 original INIT chunk (including its Initiate Tag, unchanged). When 1090 responding, the endpoint MUST send the INIT ACK back to the same 1091 address that the original INIT (sent by this endpoint) was sent. 1093 --------- 1094 New text: (Section 5.2.1) 1095 --------- 1097 Upon receipt of an INIT in the COOKIE-WAIT state, an endpoint MUST 1098 respond with an INIT ACK using the same parameters it sent in its 1099 original INIT chunk (including its Initiate Tag, unchanged). When 1100 responding, the following rules MUST be applied: 1102 1) The INIT ACK MUST only be sent to an address passed by the upper 1103 layer in the request to initialize the association. 1105 2) The INIT ACK MUST only be sent to an address reported in the 1106 incoming INIT. 1108 3) The INIT ACK SHOULD be sent to the source address of the 1109 received INIT. 1111 3.19.3. Solution Description 1113 The new text requires sending INIT ACK to a destination address that 1114 is passed by the upper layer and reported in the incoming INIT. If 1115 the source address of the INIT meets these conditions, sending the 1116 INIT ACK to the source address of the INIT is the preferred behavior. 1118 3.20. Zero Window Probing and Unreachable Primary Path 1120 3.20.1. Description of the Problem 1122 Section 6.1 of [RFC4960] states that when sending zero window probes, 1123 SCTP should neither increment the association counter nor increment 1124 the destination address error counter if it continues to receive new 1125 packets from the peer. However, the reception of new packets from 1126 the peer does not guarantee the peer's reachability and, if the 1127 destination address becomes unreachable during zero window probing, 1128 SCTP cannot get an updated rwnd until it switches the destination 1129 address for probes. 1131 3.20.2. Text Changes to the Document 1133 --------- 1134 Old text: (Section 6.1) 1135 --------- 1137 If the sender continues to receive new packets from the receiver 1138 while doing zero window probing, the unacknowledged window probes 1139 should not increment the error counter for the association or any 1140 destination transport address. This is because the receiver MAY 1141 keep its window closed for an indefinite time. Refer to Section 1142 6.2 on the receiver behavior when it advertises a zero window. 1144 --------- 1145 New text: (Section 6.1) 1146 --------- 1148 If the sender continues to receive SACKs from the peer 1149 while doing zero window probing, the unacknowledged window probes 1150 SHOULD NOT increment the error counter for the association or any 1151 destination transport address. This is because the receiver could 1152 keep its window closed for an indefinite time. Section 6.2 describes 1153 the receiver behavior when it advertises a zero window. 1155 3.20.3. Solution Description 1157 The new text clarifies that if the receiver continues to send SACKs, 1158 the sender of probes should not increment the error counter of the 1159 association and the destination address even if the SACKs do not 1160 acknowledge the probes. 1162 3.21. Normative Language in Section 10 1164 3.21.1. Description of the Problem 1166 Section 10 of [RFC4960] is informative and, therefore, normative 1167 language such as MUST and MAY cannot be used there. However, there 1168 are several places in Section 10 where MUST and MAY are used. 1170 3.21.2. Text Changes to the Document 1172 --------- 1173 Old text: (Section 10.1) 1174 --------- 1176 E) Send 1178 Format: SEND(association id, buffer address, byte count [,context] 1180 [,stream id] [,life time] [,destination transport address] 1181 [,unordered flag] [,no-bundle flag] [,payload protocol-id] ) 1182 -> result 1184 ... 1186 o no-bundle flag - instructs SCTP not to bundle this user data with 1187 other outbound DATA chunks. SCTP MAY still bundle even when this 1188 flag is present, when faced with network congestion. 1190 --------- 1191 New text: (Section 10.1) 1192 --------- 1194 E) Send 1196 Format: SEND(association id, buffer address, byte count [,context] 1197 [,stream id] [,life time] [,destination transport address] 1198 [,unordered flag] [,no-bundle flag] [,payload protocol-id] ) 1199 -> result 1201 ... 1203 o no-bundle flag - instructs SCTP not to bundle this user data with 1204 other outbound DATA chunks. SCTP may still bundle even when this 1205 flag is present, when faced with network congestion. 1207 --------- 1208 Old text: (Section 10.1) 1209 --------- 1211 G) Receive 1213 Format: RECEIVE(association id, buffer address, buffer size 1214 [,stream id]) 1215 -> byte count [,transport address] [,stream id] [,stream sequence 1216 number] [,partial flag] [,delivery number] [,payload protocol-id] 1218 ... 1220 o Stream Sequence Number - the Stream Sequence Number assigned by 1221 the sending SCTP peer. 1223 o partial flag - if this returned flag is set to 1, then this 1224 Receive contains a partial delivery of the whole message. When 1225 this flag is set, the stream id and Stream Sequence Number MUST 1226 accompany this receive. When this flag is set to 0, it indicates 1227 that no more deliveries will be received for this Stream Sequence 1228 Number. 1230 --------- 1231 New text: (Section 10.1) 1232 --------- 1234 G) Receive 1236 Format: RECEIVE(association id, buffer address, buffer size 1237 [,stream id]) 1238 -> byte count [,transport address] [,stream id] [,stream sequence 1239 number] [,partial flag] [,delivery number] [,payload protocol-id] 1241 ... 1243 o stream sequence number - the Stream Sequence Number assigned by 1244 the sending SCTP peer. 1246 o partial flag - if this returned flag is set to 1, then this 1247 primitive contains a partial delivery of the whole message. When 1248 this flag is set, the stream id and stream sequence number must 1249 accompany this primitive. When this flag is set to 0, it indicates 1250 that no more deliveries will be received for this stream sequence 1251 number. 1253 --------- 1254 Old text: (Section 10.1) 1255 --------- 1257 N) Receive Unsent Message 1259 Format: RECEIVE_UNSENT(data retrieval id, buffer address, buffer 1260 size [,stream id] [, stream sequence number] [,partial 1261 flag] [,payload protocol-id]) 1263 ... 1265 o Stream Sequence Number - this value is returned indicating the 1266 Stream Sequence Number that was associated with the message. 1268 o partial flag - if this returned flag is set to 1, then this 1269 message is a partial delivery of the whole message. When this 1270 flag is set, the stream id and Stream Sequence Number MUST 1271 accompany this receive. When this flag is set to 0, it indicates 1272 that no more deliveries will be received for this Stream Sequence 1273 Number. 1275 --------- 1276 New text: (Section 10.1) 1277 --------- 1279 N) Receive Unsent Message 1281 Format: RECEIVE_UNSENT(data retrieval id, buffer address, buffer 1282 size [,stream id] [, stream sequence number] [,partial 1283 flag] [,payload protocol-id]) 1285 ... 1287 o stream sequence number - this value is returned indicating the 1288 Stream Sequence Number that was associated with the message. 1290 o partial flag - if this returned flag is set to 1, then this 1291 message is a partial delivery of the whole message. When this 1292 flag is set, the stream id and stream sequence number must 1293 accompany this primitive. When this flag is set to 0, it indicates 1294 that no more deliveries will be received for this stream sequence 1295 number. 1297 --------- 1298 Old text: (Section 10.1) 1299 --------- 1301 O) Receive Unacknowledged Message 1303 Format: RECEIVE_UNACKED(data retrieval id, buffer address, buffer 1304 size [,stream id] [,stream sequence number] [,partial 1305 flag] [,payload protocol-id]) 1307 ... 1309 o Stream Sequence Number - this value is returned indicating the 1310 Stream Sequence Number that was associated with the message. 1312 o partial flag - if this returned flag is set to 1, then this 1313 message is a partial delivery of the whole message. When this 1314 flag is set, the stream id and Stream Sequence Number MUST 1315 accompany this receive. When this flag is set to 0, it indicates 1316 that no more deliveries will be received for this Stream Sequence 1317 Number. 1319 --------- 1320 New text: (Section 10.1) 1321 --------- 1323 O) Receive Unacknowledged Message 1324 Format: RECEIVE_UNACKED(data retrieval id, buffer address, buffer 1325 size [,stream id] [,stream sequence number] [,partial 1326 flag] [,payload protocol-id]) 1328 ... 1330 o stream sequence number - this value is returned indicating the 1331 Stream Sequence Number that was associated with the message. 1333 o partial flag - if this returned flag is set to 1, then this 1334 message is a partial delivery of the whole message. When this 1335 flag is set, the stream id and stream sequence number must 1336 accompany this primitive. When this flag is set to 0, it indicates 1337 that no more deliveries will be received for this stream sequence 1338 number. 1340 3.21.3. Solution Description 1342 The normative language is removed from Section 10. In addition, the 1343 consistency of the text has been improved. 1345 3.22. Increase of partial_bytes_acked in Congestion Avoidance 1347 3.22.1. Description of the Problem 1349 Two issues have been discovered with the partial_bytes_acked handling 1350 described in Section 7.2.2 of [RFC4960]: 1352 o If the Cumulative TSN Ack Point is not advanced but the SACK chunk 1353 acknowledges new TSNs in the Gap Ack Blocks, these newly 1354 acknowledged TSNs are not considered for partial_bytes_acked 1355 although these TSNs were successfully received by the peer. 1356 o Duplicate TSNs are not considered in partial_bytes_acked although 1357 they confirm that the DATA chunks were successfully received by 1358 the peer. 1360 3.22.2. Text Changes to the Document 1361 --------- 1362 Old text: (Section 7.2.2) 1363 --------- 1365 o Whenever cwnd is greater than ssthresh, upon each SACK arrival 1366 that advances the Cumulative TSN Ack Point, increase 1367 partial_bytes_acked by the total number of bytes of all new chunks 1368 acknowledged in that SACK including chunks acknowledged by the new 1369 Cumulative TSN Ack and by Gap Ack Blocks. 1371 --------- 1372 New text: (Section 7.2.2) 1373 --------- 1375 o Whenever cwnd is greater than ssthresh, upon each SACK arrival, 1376 increase partial_bytes_acked by the total number of bytes of all 1377 new chunks acknowledged in that SACK including chunks acknowledged 1378 by the new Cumulative TSN Ack, by Gap Ack Blocks and by the number 1379 of bytes of duplicated chunks reported in Duplicate TSNs. 1381 3.22.3. Solution Description 1383 Now partial_bytes_acked is increased by TSNs reported as duplicated 1384 as well as TSNs newly acknowledged in Gap Ack Blocks even if the 1385 Cumulative TSN Ack Point is not advanced. 1387 3.23. Inconsistency in Notifications Handling 1389 3.23.1. Description of the Problem 1391 [RFC4960] uses inconsistent normative and non-normative language when 1392 describing rules for sending notifications to the upper layer. E.g. 1393 Section 8.2 of [RFC4960] says that when a destination address becomes 1394 inactive due to an unacknowledged DATA chunk or HEARTBEAT chunk, SCTP 1395 SHOULD send a notification to the upper layer while Section 8.3 of 1396 [RFC4960] says that when a destination address becomes inactive due 1397 to an unacknowledged HEARTBEAT chunk, SCTP may send a notification to 1398 the upper layer. 1400 This makes the text inconsistent. 1402 3.23.2. Text Changes to the Document 1404 The following change is based on the change described in Section 3.6. 1406 --------- 1407 Old text: (Section 8.1) 1408 --------- 1410 An endpoint shall keep a counter on the total number of consecutive 1411 retransmissions to its peer (this includes data retransmissions 1412 to all the destination transport addresses of the peer if it is 1413 multi-homed), including the number of unacknowledged HEARTBEAT 1414 chunks observed on the path which currently is used for data 1415 transfer. Unacknowledged HEARTBEAT chunks observed on paths 1416 different from the path currently used for data transfer shall 1417 not increment the association error counter, as this could lead 1418 to association closure even if the path which currently is used for 1419 data transfer is available (but idle). If the value of this 1420 counter exceeds the limit indicated in the protocol parameter 1421 'Association.Max.Retrans', the endpoint shall consider the peer 1422 endpoint unreachable and shall stop transmitting any more data to it 1423 (and thus the association enters the CLOSED state). In addition, the 1424 endpoint MAY report the failure to the upper layer and optionally 1425 report back all outstanding user data remaining in its outbound 1426 queue. The association is automatically closed when the peer 1427 endpoint becomes unreachable. 1429 --------- 1430 New text: (Section 8.1) 1431 --------- 1433 An endpoint SHOULD keep a counter on the total number of consecutive 1434 retransmissions to its peer (this includes data retransmissions 1435 to all the destination transport addresses of the peer if it is 1436 multi-homed), including the number of unacknowledged HEARTBEAT 1437 chunks observed on the path which currently is used for data 1438 transfer. Unacknowledged HEARTBEAT chunks observed on paths 1439 different from the path currently used for data transfer SHOULD 1440 NOT increment the association error counter, as this could lead 1441 to association closure even if the path which currently is used for 1442 data transfer is available (but idle). If the value of this 1443 counter exceeds the limit indicated in the protocol parameter 1444 'Association.Max.Retrans', the endpoint SHOULD consider the peer 1445 endpoint unreachable and SHALL stop transmitting any more data to it 1446 (and thus the association enters the CLOSED state). In addition, the 1447 endpoint SHOULD report the failure to the upper layer and optionally 1448 report back all outstanding user data remaining in its outbound 1449 queue. The association is automatically closed when the peer 1450 endpoint becomes unreachable. 1452 The following changes are based on [RFC4960]. 1454 --------- 1455 Old text: (Section 8.2) 1456 --------- 1458 When an outstanding TSN is acknowledged or a HEARTBEAT sent to that 1459 address is acknowledged with a HEARTBEAT ACK, the endpoint shall 1460 clear the error counter of the destination transport address to which 1461 the DATA chunk was last sent (or HEARTBEAT was sent). When the peer 1462 endpoint is multi-homed and the last chunk sent to it was a 1463 retransmission to an alternate address, there exists an ambiguity as 1464 to whether or not the acknowledgement should be credited to the 1465 address of the last chunk sent. However, this ambiguity does not 1466 seem to bear any significant consequence to SCTP behavior. If this 1467 ambiguity is undesirable, the transmitter may choose not to clear the 1468 error counter if the last chunk sent was a retransmission. 1470 --------- 1471 New text: (Section 8.2) 1472 --------- 1474 When an outstanding TSN is acknowledged or a HEARTBEAT sent to that 1475 address is acknowledged with a HEARTBEAT ACK, the endpoint SHOULD 1476 clear the error counter of the destination transport address to which 1477 the DATA chunk was last sent (or HEARTBEAT was sent), and SHOULD 1478 also report to the upper layer when an inactive destination address 1479 is marked as active. When the peer endpoint is multi-homed and the 1480 last chunk sent to it was a retransmission to an alternate address, 1481 there exists an ambiguity as to whether or not the acknowledgement 1482 could be credited to the address of the last chunk sent. However, 1483 this ambiguity does not seem to bear any significant consequence to 1484 SCTP behavior. If this ambiguity is undesirable, the transmitter MAY 1485 choose not to clear the error counter if the last chunk sent was a 1486 retransmission. 1488 --------- 1489 Old text: (Section 8.3) 1490 --------- 1492 When the value of this counter reaches the protocol parameter 1493 'Path.Max.Retrans', the endpoint should mark the corresponding 1494 destination address as inactive if it is not so marked, and may also 1495 optionally report to the upper layer the change of reachability of 1496 this destination address. After this, the endpoint should continue 1497 HEARTBEAT on this destination address but should stop increasing the 1498 counter. 1500 --------- 1501 New text: (Section 8.3) 1502 --------- 1504 When the value of this counter exceeds the protocol parameter 1505 'Path.Max.Retrans', the endpoint SHOULD mark the corresponding 1506 destination address as inactive if it is not so marked, and SHOULD 1507 also report to the upper layer the change of reachability of this 1508 destination address. After this, the endpoint SHOULD continue 1509 HEARTBEAT on this destination address but SHOULD stop increasing the 1510 counter. 1512 --------- 1513 Old text: (Section 8.3) 1514 --------- 1516 Upon the receipt of the HEARTBEAT ACK, the sender of the HEARTBEAT 1517 should clear the error counter of the destination transport address 1518 to which the HEARTBEAT was sent, and mark the destination transport 1519 address as active if it is not so marked. The endpoint may 1520 optionally report to the upper layer when an inactive destination 1521 address is marked as active due to the reception of the latest 1522 HEARTBEAT ACK. The receiver of the HEARTBEAT ACK must also clear the 1523 association overall error count as well (as defined in Section 8.1). 1525 --------- 1526 New text: (Section 8.3) 1527 --------- 1529 Upon the receipt of the HEARTBEAT ACK, the sender of the HEARTBEAT 1530 SHOULD clear the error counter of the destination transport address 1531 to which the HEARTBEAT was sent, and mark the destination transport 1532 address as active if it is not so marked. The endpoint SHOULD 1533 report to the upper layer when an inactive destination address 1534 is marked as active due to the reception of the latest 1535 HEARTBEAT ACK. The receiver of the HEARTBEAT ACK SHOULD also clear 1536 the association overall error counter (as defined in Section 8.1). 1538 --------- 1539 Old text: (Section 9.2) 1540 --------- 1542 An endpoint should limit the number of retransmissions of the 1543 SHUTDOWN chunk to the protocol parameter 'Association.Max.Retrans'. 1544 If this threshold is exceeded, the endpoint should destroy the TCB 1545 and MUST report the peer endpoint unreachable to the upper layer (and 1546 thus the association enters the CLOSED state). 1548 --------- 1549 New text: (Section 9.2) 1550 --------- 1552 An endpoint SHOULD limit the number of retransmissions of the 1553 SHUTDOWN chunk to the protocol parameter 'Association.Max.Retrans'. 1554 If this threshold is exceeded, the endpoint SHOULD destroy the TCB 1555 and SHOULD report the peer endpoint unreachable to the upper layer 1556 (and thus the association enters the CLOSED state). 1558 --------- 1559 Old text: (Section 9.2) 1560 --------- 1562 The sender of the SHUTDOWN ACK should limit the number of 1563 retransmissions of the SHUTDOWN ACK chunk to the protocol parameter 1564 'Association.Max.Retrans'. If this threshold is exceeded, the 1565 endpoint should destroy the TCB and may report the peer endpoint 1566 unreachable to the upper layer (and thus the association enters the 1567 CLOSED state). 1569 --------- 1570 New text: (Section 9.2) 1571 --------- 1573 The sender of the SHUTDOWN ACK SHOULD limit the number of 1574 retransmissions of the SHUTDOWN ACK chunk to the protocol parameter 1575 'Association.Max.Retrans'. If this threshold is exceeded, the 1576 endpoint SHOULD destroy the TCB and SHOULD report the peer endpoint 1577 unreachable to the upper layer (and thus the association enters the 1578 CLOSED state). 1580 3.23.3. Solution Description 1582 The inconsistencies are removed by using consistently SHOULD. 1584 3.24. SACK.Delay Not Listed as a Protocol Parameter 1586 3.24.1. Description of the Problem 1588 SCTP as specified in [RFC4960] supports delaying SACKs. The timer 1589 value for this is a parameter and Section 6.2 of [RFC4960] specifies 1590 a default and maximum value for it. However, defining a name for 1591 this parameter and listing it in the table of protocol parameters in 1592 Section 15 of [RFC4960] is missing. 1594 This issue was reported as an Errata for [RFC4960] with Errata ID 1595 4656. 1597 3.24.2. Text Changes to the Document 1599 --------- 1600 Old text: (Section 6.2) 1601 --------- 1603 An implementation MUST NOT allow the maximum delay to be configured 1604 to be more than 500 ms. In other words, an implementation MAY lower 1605 this value below 500 ms but MUST NOT raise it above 500 ms. 1607 --------- 1608 New text: (Section 6.2) 1609 --------- 1611 An implementation MUST NOT allow the maximum delay (protocol 1612 parameter 'SACK.Delay') to be configured to be more than 500 ms. 1613 In other words, an implementation MAY lower the value of 1614 SACK.Delay below 500 ms but MUST NOT raise it above 500 ms. 1616 --------- 1617 Old text: (Section 15) 1618 --------- 1620 The following protocol parameters are RECOMMENDED: 1622 RTO.Initial - 3 seconds 1623 RTO.Min - 1 second 1624 RTO.Max - 60 seconds 1625 Max.Burst - 4 1626 RTO.Alpha - 1/8 1627 RTO.Beta - 1/4 1628 Valid.Cookie.Life - 60 seconds 1629 Association.Max.Retrans - 10 attempts 1630 Path.Max.Retrans - 5 attempts (per destination address) 1631 Max.Init.Retransmits - 8 attempts 1632 HB.interval - 30 seconds 1633 HB.Max.Burst - 1 1635 --------- 1636 New text: (Section 15) 1637 --------- 1639 The following protocol parameters are RECOMMENDED: 1641 RTO.Initial - 3 seconds 1642 RTO.Min - 1 second 1643 RTO.Max - 60 seconds 1644 Max.Burst - 4 1645 RTO.Alpha - 1/8 1646 RTO.Beta - 1/4 1647 Valid.Cookie.Life - 60 seconds 1648 Association.Max.Retrans - 10 attempts 1649 Path.Max.Retrans - 5 attempts (per destination address) 1650 Max.Init.Retransmits - 8 attempts 1651 HB.interval - 30 seconds 1652 HB.Max.Burst - 1 1653 SACK.Delay - 200 milliseconds 1655 3.24.3. Solution Description 1657 The parameter was given a name and added to the list of protocol 1658 parameters. 1660 3.25. Processing of Chunks in an Incoming SCTP Packet 1662 3.25.1. Description of the Problem 1664 There are a few places in [RFC4960] where the receiver of a packet 1665 must discard it while processing the chunks of the packet. It is 1666 unclear whether the receiver has to rollback state changes already 1667 performed while processing the packet or not. 1669 The intention of [RFC4960] is to process an incoming packet chunk by 1670 chunk and not to perform any prescreening of chunks in the received 1671 packet. Thus, by discarding one chunk the receiver also causes 1672 discarding of all further chunks. 1674 3.25.2. Text Changes to the Document 1676 --------- 1677 Old text: (Section 3.2) 1678 --------- 1680 00 - Stop processing this SCTP packet and discard it, do not 1681 process any further chunks within it. 1683 01 - Stop processing this SCTP packet and discard it, do not 1684 process any further chunks within it, and report the 1685 unrecognized chunk in an 'Unrecognized Chunk Type'. 1687 --------- 1688 New text: (Section 3.2) 1689 --------- 1691 00 - Stop processing this SCTP packet, discard the unrecognized 1692 chunk and all further chunks. 1694 01 - Stop processing this SCTP packet, discard the unrecognized 1695 chunk and all further chunks, and report the unrecognized 1696 chunk in an 'Unrecognized Chunk Type'. 1698 --------- 1699 Old text: (Section 11.3) 1700 --------- 1702 It is helpful for some firewalls if they can inspect just the first 1703 fragment of a fragmented SCTP packet and unambiguously determine 1704 whether it corresponds to an INIT chunk (for further information, 1705 please refer to [RFC1858]). Accordingly, we stress the requirements, 1706 stated in Section 3.1, that (1) an INIT chunk MUST NOT be bundled 1707 with any other chunk in a packet, and (2) a packet containing an INIT 1708 chunk MUST have a zero Verification Tag. Furthermore, we require 1709 that the receiver of an INIT chunk MUST enforce these rules by 1710 silently discarding an arriving packet with an INIT chunk that is 1711 bundled with other chunks or has a non-zero verification tag and 1712 contains an INIT-chunk. 1714 --------- 1715 New text: (Section 11.3) 1716 --------- 1718 It is helpful for some firewalls if they can inspect just the first 1719 fragment of a fragmented SCTP packet and unambiguously determine 1720 whether it corresponds to an INIT chunk (for further information, 1721 please refer to [RFC1858]). Accordingly, we stress the requirements, 1722 stated in Section 3.1, that (1) an INIT chunk MUST NOT be bundled 1723 with any other chunk in a packet, and (2) a packet containing an INIT 1724 chunk MUST have a zero Verification Tag. 1725 The receiver of an INIT chunk MUST silently discard the INIT chunk and 1726 all further chunks if the INIT chunk is bundled with other chunks or 1727 the packet has a non-zero verification tag. 1729 3.25.3. Solution Description 1731 The new text makes it clear that chunks can be processed from the 1732 beginning to the end and no rollback or pre-screening is required. 1734 3.26. CWND Increase in Congestion Avoidance Phase 1736 3.26.1. Description of the Problem 1738 [RFC4960] in Section 7.2.2 prescribes to increase cwnd by 1*MTU per 1739 RTT if the sender has cwnd or more bytes of data outstanding to the 1740 corresponding address in the Congestion Avoidance phase. However, 1741 this is described without normative language. Moreover, 1742 Section 7.2.2 includes an algorithm how an implementation can achieve 1743 this but this algorithm is underspecified and actually allows 1744 increasing cwnd by more than 1*MTU per RTT. 1746 3.26.2. Text Changes to the Document 1748 --------- 1749 Old text: (Section 7.2.2) 1750 --------- 1752 When cwnd is greater than ssthresh, cwnd should be incremented by 1753 1*MTU per RTT if the sender has cwnd or more bytes of data 1754 outstanding for the corresponding transport address. 1756 --------- 1757 New text: (Section 7.2.2) 1758 --------- 1760 When cwnd is greater than ssthresh, cwnd SHOULD be incremented by 1761 1*MTU per RTT if the sender has cwnd or more bytes of data 1762 outstanding for the corresponding transport address. The basic 1763 guidelines for incrementing cwnd during congestion avoidance are: 1765 o SCTP MAY increment cwnd by 1*MTU. 1767 o SCTP SHOULD increment cwnd by one 1*MTU once per RTT when 1768 the sender has cwnd or more bytes of data outstanding for 1769 the corresponding transport address. 1771 o SCTP MUST NOT increment cwnd by more than 1*MTU per RTT. 1773 --------- 1774 Old text: (Section 7.2.2) 1775 --------- 1777 o Whenever cwnd is greater than ssthresh, upon each SACK arrival 1778 that advances the Cumulative TSN Ack Point, increase 1779 partial_bytes_acked by the total number of bytes of all new chunks 1780 acknowledged in that SACK including chunks acknowledged by the new 1781 Cumulative TSN Ack and by Gap Ack Blocks. 1783 o When partial_bytes_acked is equal to or greater than cwnd and 1784 before the arrival of the SACK the sender had cwnd or more bytes 1785 of data outstanding (i.e., before arrival of the SACK, flightsize 1786 was greater than or equal to cwnd), increase cwnd by MTU, and 1787 reset partial_bytes_acked to (partial_bytes_acked - cwnd). 1789 --------- 1790 New text: (Section 7.2.2) 1791 --------- 1793 o Whenever cwnd is greater than ssthresh, upon each SACK arrival, 1794 increase partial_bytes_acked by the total number of bytes of all 1795 new chunks acknowledged in that SACK including chunks acknowledged 1796 by the new Cumulative TSN Ack, by Gap Ack Blocks and by the number 1797 of bytes of duplicated chunks reported in Duplicate TSNs. 1799 o When partial_bytes_acked is greater than cwnd and before the 1800 arrival of the SACK the sender had less than cwnd bytes of data 1801 outstanding (i.e., before arrival of the SACK, flightsize was less 1802 than cwnd), reset partial_bytes_acked to cwnd. 1804 o When partial_bytes_acked is equal to or greater than cwnd and 1805 before the arrival of the SACK the sender had cwnd or more bytes 1806 of data outstanding (i.e., before arrival of the SACK, flightsize 1807 was greater than or equal to cwnd), partial_bytes_acked is reset 1808 to (partial_bytes_acked - cwnd). Next, cwnd is increased by 1*MTU. 1810 3.26.3. Solution Description 1812 The basic guidelines for incrementing cwnd during the congestion 1813 avoidance phase are added into Section 7.2.2. The guidelines include 1814 the normative language and are aligned with [RFC5681]. 1816 The algorithm from Section 7.2.2 is improved to not allow increasing 1817 cwnd by more than 1*MTU per RTT. 1819 3.27. Refresh of cwnd and ssthresh after Idle Period 1821 3.27.1. Description of the Problem 1823 [RFC4960] prescribes to adjust cwnd per RTO if the endpoint does not 1824 transmit data on a given transport address. In addition to that, it 1825 prescribes to set cwnd to the initial value after a sufficiently long 1826 idle period. The latter is excessive. Moreover, it is unclear what 1827 is a sufficiently long idle period. 1829 [RFC4960] doesn't specify the handling of ssthresh in the idle case. 1830 If ssthresh is reduced due to a packet loss, ssthresh is never 1831 recovered. So traffic can end up in Congestion Avoidance all the 1832 time, resulting in a low sending rate and bad performance. The 1833 problem is even more serious for SCTP because in a multi-homed SCTP 1834 association traffic that switches back to the previously failed 1835 primary path will also lead to the situation where traffic ends up in 1836 Congestion Avoidance. 1838 3.27.2. Text Changes to the Document 1840 --------- 1841 Old text: (Section 7.2.1) 1842 --------- 1844 o The initial cwnd before DATA transmission or after a sufficiently 1845 long idle period MUST be set to min(4*MTU, max (2*MTU, 4380 1846 bytes)). 1848 --------- 1849 New text: (Section 7.2.1) 1850 --------- 1852 o The initial cwnd before DATA transmission MUST be set to 1853 min(4*MTU, max (2*MTU, 4380 bytes)). 1855 --------- 1856 Old text: (Section 7.2.1) 1857 --------- 1859 o When the endpoint does not transmit data on a given transport 1860 address, the cwnd of the transport address should be adjusted to 1861 max(cwnd/2, 4*MTU) per RTO. 1863 --------- 1864 New text: (Section 7.2.1) 1865 --------- 1866 o When the endpoint does not transmit data on a given transport 1867 address, the cwnd of the transport address SHOULD be adjusted to 1868 max(cwnd/2, 4*MTU) per RTO. At the first cwnd adjustment, the 1869 ssthresh of the transport address SHOULD be adjusted to the cwnd. 1871 3.27.3. Solution Description 1873 A rule about cwnd adjustment after a sufficiently long idle period is 1874 removed. 1876 The text is updated to refresh ssthresh after the idle period. When 1877 the idle period is detected, the cwnd value is stored to the ssthresh 1878 value. 1880 3.28. Window Updates After Receiver Window Opens Up 1881 3.28.1. Description of the Problem 1883 The sending of SACK chunks for window updates is only indirectly 1884 referenced in [RFC4960], Section 6.2, where it is stated that an SCTP 1885 receiver must not generate more than one SACK for every incoming 1886 packet, other than to update the offered window. 1888 However, the sending of window updates when the receiver window opens 1889 up is necessary to avoid performance problems. 1891 3.28.2. Text Changes to the Document 1893 --------- 1894 Old text: (Section 6.2) 1895 --------- 1897 An SCTP receiver MUST NOT generate more than one SACK for every 1898 incoming packet, other than to update the offered window as the 1899 receiving application consumes new data. 1901 --------- 1902 New text: (Section 6.2) 1903 --------- 1905 An SCTP receiver MUST NOT generate more than one SACK for every 1906 incoming packet, other than to update the offered window as the 1907 receiving application consumes new data. When the window opens 1908 up, an SCTP receiver SHOULD send additional SACK chunks to update 1909 the window even if no new data is received. The receiver MUST avoid 1910 sending large bursts of window updates. 1912 3.28.3. Solution Description 1914 The new text makes clear that additional SACK chunks for window 1915 updates should be sent as long as excessive bursts are avoided. 1917 3.29. Path of DATA and Reply Chunks 1919 3.29.1. Description of the Problem 1921 Section 6.4 of [RFC4960] describes the transmission policy for multi- 1922 homed SCTP endpoints. However, there are the following issues with 1923 it: 1925 o It states that a SACK should be sent to the source address of an 1926 incoming DATA. However, it is known that other SACK policies 1927 (e.g. sending SACKs always to the primary path) may be more 1928 beneficial in some situations. 1929 o Initially it states that an endpoint should always transmit DATA 1930 chunks to the primary path. Then it states that the rule for 1931 transmittal of reply chunks should also be followed if the 1932 endpoint is bundling DATA chunks together with the reply chunk 1933 which contradicts with the first statement to always transmit DATA 1934 chunks to the primary path. Some implementations were having 1935 problems with it and sent DATA chunks bundled with reply chunks to 1936 a different destination address than the primary path that caused 1937 many gaps. 1939 3.29.2. Text Changes to the Document 1941 --------- 1942 Old text: (Section 6.4) 1943 --------- 1945 An endpoint SHOULD transmit reply chunks (e.g., SACK, HEARTBEAT ACK, 1946 etc.) to the same destination transport address from which it 1947 received the DATA or control chunk to which it is replying. This 1948 rule should also be followed if the endpoint is bundling DATA chunks 1949 together with the reply chunk. 1951 However, when acknowledging multiple DATA chunks received in packets 1952 from different source addresses in a single SACK, the SACK chunk may 1953 be transmitted to one of the destination transport addresses from 1954 which the DATA or control chunks being acknowledged were received. 1956 --------- 1957 New text: (Section 6.4) 1958 --------- 1960 An endpoint SHOULD transmit reply chunks (e.g., INIT ACK, COOKIE ACK, 1961 HEARTBEAT ACK, etc.) in response to control chunks to the same 1962 destination transport address from which it received the control 1963 chunk to which it is replying. 1965 The selection of the destination transport address for packets 1966 containing SACK chunks is implementation dependent. However, an endpoint 1967 SHOULD NOT vary the destination transport address of a SACK when it 1968 receives DATA chunks coming from the same source address. 1970 When acknowledging multiple DATA chunks received in packets 1971 from different source addresses in a single SACK, the SACK chunk MAY 1972 be transmitted to one of the destination transport addresses from 1973 which the DATA or control chunks being acknowledged were received. 1975 3.29.3. Solution Description 1977 The SACK transmission policy is left implementation dependent but it 1978 is specified to not vary the destination address of a packet 1979 containing a SACK chunk unless there are reasons for it as it may 1980 negatively impact RTT measurement. 1982 A confusing statement that prescribes to follow the rule for 1983 transmittal of reply chunks when the endpoint is bundling DATA chunks 1984 together with the reply chunk is removed. 1986 3.30. Outstanding Data, Flightsize and Data In Flight Key Terms 1988 3.30.1. Description of the Problem 1990 [RFC4960] uses outstanding data, flightsize and data in flight key 1991 terms in formulas and statements but their definitions are not 1992 provided in Section 1.3. Furthermore, outstanding data does not 1993 include DATA chunks which are classified as lost but which have not 1994 been retransmitted yet and there is a paragraph in Section 6.1 of 1995 [RFC4960] where this statement is broken. 1997 3.30.2. Text Changes to the Document 1999 --------- 2000 Old text: (Section 1.3) 2001 --------- 2003 o Congestion window (cwnd): An SCTP variable that limits the data, 2004 in number of bytes, a sender can send to a particular destination 2005 transport address before receiving an acknowledgement. 2007 ... 2009 o Outstanding TSN (at an SCTP endpoint): A TSN (and the associated 2010 DATA chunk) that has been sent by the endpoint but for which it 2011 has not yet received an acknowledgement. 2013 --------- 2014 New text: (Section 1.3) 2015 --------- 2017 o Outstanding TSN (at an SCTP endpoint): A TSN (and the associated 2018 DATA chunk) that has been sent by the endpoint but for which it 2019 has not yet received an acknowledgement. 2021 o Outstanding data (or Data outstanding or Data in flight): The 2022 total amount of the DATA chunks associated with outstanding TSNs. 2024 A retransmitted DATA chunk is counted once in outstanding data. 2025 A DATA chunk which is classified as lost but which has not been 2026 retransmitted yet is not in outstanding data. 2028 o Flightsize: The amount of bytes of outstanding data to a 2029 particular destination transport address at any given time. 2031 o Congestion window (cwnd): An SCTP variable that limits outstanding 2032 data, in number of bytes, a sender can send to a particular 2033 destination transport address before receiving an acknowledgement. 2035 --------- 2036 Old text: (Section 6.1) 2037 --------- 2039 C) When the time comes for the sender to transmit, before sending new 2040 DATA chunks, the sender MUST first transmit any outstanding DATA 2041 chunks that are marked for retransmission (limited by the current 2042 cwnd). 2044 --------- 2045 New text: (Section 6.1) 2046 --------- 2048 C) When the time comes for the sender to transmit, before sending new 2049 DATA chunks, the sender MUST first transmit any DATA chunks that 2050 are marked for retransmission (limited by the current cwnd). 2052 3.30.3. Solution Description 2054 Now Section 1.3, Key Terms, includes explanations of outstanding 2055 data, data in flight and flightsize key terms. Section 6.1 is 2056 corrected to properly use the outstanding data term. 2058 3.31. CWND Degradation due to Max.Burst 2060 3.31.1. Description of the Problem 2062 Some implementations were experiencing a degradation of cwnd because 2063 of the Max.Burst limit. This was due to misinterpretation of the 2064 suggestion in [RFC4960], Section 6.1, on how to use the Max.Burst 2065 parameter when calculating the number of packets to transmit. 2067 3.31.2. Text Changes to the Document 2068 --------- 2069 Old text: (Section 6.1) 2070 --------- 2072 D) When the time comes for the sender to transmit new DATA chunks, 2073 the protocol parameter Max.Burst SHOULD be used to limit the 2074 number of packets sent. The limit MAY be applied by adjusting 2075 cwnd as follows: 2077 if((flightsize + Max.Burst*MTU) < cwnd) cwnd = flightsize + 2078 Max.Burst*MTU 2080 Or it MAY be applied by strictly limiting the number of packets 2081 emitted by the output routine. 2083 --------- 2084 New text: (Section 6.1) 2085 --------- 2087 D) When the time comes for the sender to transmit new DATA chunks, 2088 the protocol parameter Max.Burst SHOULD be used to limit the 2089 number of packets sent. The limit MAY be applied by adjusting 2090 cwnd temporarily as follows: 2092 if ((flightsize + Max.Burst*MTU) < cwnd) 2093 cwnd = flightsize + Max.Burst*MTU 2095 Or it MAY be applied by strictly limiting the number of packets 2096 emitted by the output routine. When calculating the number of 2097 packets to transmit and particularly using the formula above, 2098 cwnd SHOULD NOT be changed permanently. 2100 3.31.3. Solution Description 2102 The new text clarifies that cwnd should not be changed when applying 2103 the Max.Burst limit. This mitigates packet bursts related to the 2104 reception of SACK chunks, but not bursts related to an application 2105 sending a burst of user messages. 2107 3.32. Reduction of RTO.Initial 2109 3.32.1. Description of the Problem 2111 [RFC4960] uses 3 seconds as the default value for RTO.Initial in 2112 accordance with Section 4.3.2.1 of [RFC1122]. [RFC6298] updates 2113 [RFC1122] and lowers the initial value of the retransmission timer 2114 from 3 seconds to 1 second. 2116 3.32.2. Text Changes to the Document 2118 --------- 2119 Old text: (Section 15) 2120 --------- 2122 The following protocol parameters are RECOMMENDED: 2124 RTO.Initial - 3 seconds 2125 RTO.Min - 1 second 2126 RTO.Max - 60 seconds 2127 Max.Burst - 4 2128 RTO.Alpha - 1/8 2129 RTO.Beta - 1/4 2130 Valid.Cookie.Life - 60 seconds 2131 Association.Max.Retrans - 10 attempts 2132 Path.Max.Retrans - 5 attempts (per destination address) 2133 Max.Init.Retransmits - 8 attempts 2134 HB.interval - 30 seconds 2135 HB.Max.Burst - 1 2136 SACK.Delay - 200 milliseconds 2138 --------- 2139 New text: (Section 15) 2140 --------- 2142 The following protocol parameters are RECOMMENDED: 2144 RTO.Initial - 1 second 2145 RTO.Min - 1 second 2146 RTO.Max - 60 seconds 2147 Max.Burst - 4 2148 RTO.Alpha - 1/8 2149 RTO.Beta - 1/4 2150 Valid.Cookie.Life - 60 seconds 2151 Association.Max.Retrans - 10 attempts 2152 Path.Max.Retrans - 5 attempts (per destination address) 2153 Max.Init.Retransmits - 8 attempts 2154 HB.interval - 30 seconds 2155 HB.Max.Burst - 1 2156 SACK.Delay - 200 milliseconds 2158 3.32.3. Solution Description 2160 The value RTO.Initial has been lowered to 1 second to be in tune with 2161 [RFC6298]. 2163 3.33. Ordering of Bundled SACK and ERROR Chunks 2165 3.33.1. Description of the Problem 2167 When an SCTP endpoint receives a DATA chunk with an invalid stream 2168 identifier it shall acknowledge it by sending a SACK chunk and 2169 indicate that the stream identifier was invalid by sending an ERROR 2170 chunk. These two chunks may be bundled. However, [RFC4960] requires 2171 in case of bundling that the ERROR chunk follows the SACK chunk. 2172 This restriction of the ordering is not necessary and might only 2173 limit interoperability. 2175 3.33.2. Text Changes to the Document 2177 --------- 2178 Old text: (Section 6.5) 2179 --------- 2181 Every DATA chunk MUST carry a valid stream identifier. If an 2182 endpoint receives a DATA chunk with an invalid stream identifier, it 2183 shall acknowledge the reception of the DATA chunk following the 2184 normal procedure, immediately send an ERROR chunk with cause set to 2185 "Invalid Stream Identifier" (see Section 3.3.10), and discard the 2186 DATA chunk. The endpoint may bundle the ERROR chunk in the same 2187 packet as the SACK as long as the ERROR follows the SACK. 2189 --------- 2190 New text: (Section 6.5) 2191 --------- 2193 Every DATA chunk MUST carry a valid stream identifier. If an 2194 endpoint receives a DATA chunk with an invalid stream identifier, it 2195 SHOULD acknowledge the reception of the DATA chunk following the 2196 normal procedure, immediately send an ERROR chunk with cause set to 2197 "Invalid Stream Identifier" (see Section 3.3.10), and discard the 2198 DATA chunk. The endpoint MAY bundle the ERROR chunk and the SACK Chunk 2199 in the same packet. 2201 3.33.3. Solution Description 2203 The unnecessary restriction regarding the ordering of the SACK and 2204 ERROR chunk has been removed. 2206 3.34. Undefined Parameter Returned by RECEIVE Primitive 2207 3.34.1. Description of the Problem 2209 [RFC4960] provides a description of an abstract API. In the 2210 definition of the RECEIVE primitive an optional parameter with name 2211 "delivery number" is mentioned. However, no definition of this 2212 parameter is given in [RFC4960] and the parameter is unnecessary. 2214 3.34.2. Text Changes to the Document 2216 --------- 2217 Old text: (Section 10.1) 2218 --------- 2220 G) Receive 2222 Format: RECEIVE(association id, buffer address, buffer size 2223 [,stream id]) 2224 -> byte count [,transport address] [,stream id] [,stream sequence 2225 number] [,partial flag] [,delivery number] [,payload protocol-id] 2227 --------- 2228 New text: (Section 10.1) 2229 --------- 2231 G) Receive 2233 Format: RECEIVE(association id, buffer address, buffer size 2234 [,stream id]) 2235 -> byte count [,transport address] [,stream id] [,stream sequence 2236 number] [,partial flag] [,payload protocol-id] 2238 3.34.3. Solution Description 2240 The undefined parameter has been removed. 2242 3.35. DSCP Changes 2244 3.35.1. Description of the Problem 2246 The upper layer can change the Differentiated Services Code Point 2247 (DSCP) used for packets being sent. A change of the DSCP can result 2248 in packets hitting different queues on the path and, therefore, the 2249 congestion control should be initialized when the DSCP is changed by 2250 the upper layer. This is not described in [RFC4960]. 2252 3.35.2. Text Changes to the Document 2254 --------- 2255 New text: (Section 7.2.5) 2256 --------- 2258 SCTP implementations MAY allow an application to configure the 2259 Differentiated Services Code Point (DSCP) used for sending packets. 2260 If a DSCP change might result in outgoing packets being queued in 2261 different queues, the congestion control parameters for all affected 2262 destination addresses MUST be reset to their initial values. 2264 --------- 2265 Old text: (Section 10.1) 2266 --------- 2268 M) Set Protocol Parameters 2270 Format: SETPROTOCOLPARAMETERS(association id, 2271 [,destination transport address,] 2272 protocol parameter list) 2273 -> result 2275 This primitive allows the local SCTP to customize the protocol 2276 parameters. 2278 Mandatory attributes: 2280 o association id - local handle to the SCTP association. 2282 o protocol parameter list - the specific names and values of the 2283 protocol parameters (e.g., Association.Max.Retrans; see Section 2284 15) that the SCTP user wishes to customize. 2286 --------- 2287 Old text: (Section 10.1) 2288 --------- 2290 M) Set Protocol Parameters 2292 Format: SETPROTOCOLPARAMETERS(association id, 2293 [,destination transport address,] 2294 protocol parameter list) 2295 -> result 2297 This primitive allows the local SCTP to customize the protocol 2298 parameters. 2300 Mandatory attributes: 2302 o association id - local handle to the SCTP association. 2304 o protocol parameter list - the specific names and values of the 2305 protocol parameters (e.g., Association.Max.Retrans; see Section 2306 15, or other parameters like the DSCP) that the SCTP user wishes 2307 to customize. 2309 3.35.3. Solution Description 2311 Text describing the required action on DSCP changes has been added. 2313 3.36. Inconsistent Handling of ICMPv4 and ICMPv6 Messages 2315 3.36.1. Description of the Problem 2317 Appendix C of [RFC4960] describes the handling of ICMPv4 and ICMPv6 2318 messages. The text explicitly describes the handling of ICMPv6 2319 packets indicating reachability problems, but does not do the same 2320 for the corresponding ICMPv4 packets. 2322 3.36.2. Text Changes to the Document 2323 --------- 2324 Old text: (Appendix C) 2325 --------- 2327 ICMP3) An implementation MAY ignore any ICMPv4 messages where the 2328 code does not indicate "Protocol Unreachable" or 2329 "Fragmentation Needed". 2331 --------- 2332 New text: 2333 --------- 2335 ICMP3) An implementation SHOULD ignore any ICMPv4 messages where the 2336 code indicates "Port Unreachable". 2338 --------- 2339 Old text: (Appendix C) 2340 --------- 2342 ICMP9) If the ICMPv6 code is "Destination Unreachable", the 2343 implementation MAY mark the destination into the unreachable 2344 state or alternatively increment the path error counter. 2346 --------- 2347 New text: 2348 --------- 2350 ICMP9) If the ICMP type is "Destination Unreachable", the 2351 implementation MAY mark the destination into the unreachable 2352 state or alternatively increment the path error counter. 2354 3.36.3. Solution Description 2356 The text has been changed to not limit the processing of ICMPv4 2357 packets with type "Destination Unreachable" by rewording the third 2358 rule. Furthermore, remove the limitation to ICMPv6 in the ninth 2359 rule. 2361 3.37. Handling of Soft Errors 2363 3.37.1. Description of the Problem 2365 [RFC1122] defines the handling of soft errors and hard errors for 2366 TCP. Appendix C of [RFC4960] only deals with hard errors. 2368 3.37.2. Text Changes to the Document 2370 --------- 2371 Old text: (Appendix C) 2372 --------- 2374 ICMP8) If the ICMP type is "Destination Unreachable", the 2375 implementation MAY mark the destination into the unreachable 2376 state or alternatively increment the path error counter. 2378 --------- 2379 New text: (Appendix C) 2380 --------- 2382 ICMP8) If the ICMP type is "Destination Unreachable", the 2383 implementation MAY mark the destination into the unreachable 2384 state or alternatively increment the path error counter. 2385 SCTP MAY provide information to the upper layer indicating 2386 the reception of ICMP messages when reporting a network status 2387 change. 2389 3.37.3. Solution Description 2391 Text has been added allowing SCTP to notify the application in case 2392 of soft errors. 2394 3.38. Honoring CWND 2396 3.38.1. Description of the Problem 2398 When using the slow start algorithm, SCTP increases the congestion 2399 window only when it is being fully utilized. Since SCTP uses DATA 2400 chunks and does not use the congestion window to fragment user 2401 messages, this requires that some overbooking of the congestion 2402 window is allowed. 2404 3.38.2. Text Changes to the Document 2405 --------- 2406 Old text: (Section 6.1) 2407 --------- 2409 B) At any given time, the sender MUST NOT transmit new data to a 2410 given transport address if it has cwnd or more bytes of data 2411 outstanding to that transport address. 2413 --------- 2414 New text: (Section 6.1) 2415 --------- 2417 B) At any given time, the sender MUST NOT transmit new data to a 2418 given transport address if it has cwnd + (PMTU - 1) or more bytes 2419 of data outstanding to that transport address. If data is 2420 available the sender SHOULD exceed cwnd by up to (PMTU-1) bytes on 2421 a new data transmission if the flightsize does not currently reach 2422 cwnd. The breach of cwnd MUST constitute one packet only. 2424 --------- 2425 Old text: (Section 7.2.1) 2426 --------- 2428 o Whenever cwnd is greater than zero, the endpoint is allowed to 2429 have cwnd bytes of data outstanding on that transport address. 2431 --------- 2432 New text: (Section 7.2.1) 2433 --------- 2434 o Whenever cwnd is greater than zero, the endpoint is allowed to 2435 have cwnd bytes of data outstanding on that transport address. 2436 A limited overbooking as described in B) of Section 6.1 SHOULD 2437 be supported. 2439 3.38.3. Solution Description 2441 Text was added to clarify how the cwnd limit should be handled. 2443 3.39. Zero Window Probing 2445 3.39.1. Description of the Problem 2447 The text describing zero window probing was not clearly handling the 2448 case where the window was not zero, but too small for the next DATA 2449 chunk to be transmitted. Even in this case, zero window probing has 2450 to be performed to avoid deadlocks. 2452 3.39.2. Text Changes to the Document 2454 --------- 2455 Old text: (Section 6.1) 2456 --------- 2458 A) At any given time, the data sender MUST NOT transmit new data to 2459 any destination transport address if its peer's rwnd indicates 2460 that the peer has no buffer space (i.e., rwnd is 0; see Section 2461 6.2.1). However, regardless of the value of rwnd (including if it 2462 is 0), the data sender can always have one DATA chunk in flight to 2463 the receiver if allowed by cwnd (see rule B, below). This rule 2464 allows the sender to probe for a change in rwnd that the sender 2465 missed due to the SACK's having been lost in transit from the data 2466 receiver to the data sender. 2468 When the receiver's advertised window is zero, this probe is 2469 called a zero window probe. Note that a zero window probe SHOULD 2470 only be sent when all outstanding DATA chunks have been 2471 cumulatively acknowledged and no DATA chunks are in flight. Zero 2472 window probing MUST be supported. 2474 --------- 2475 New text: (Section 6.1) 2476 --------- 2478 A) At any given time, the data sender MUST NOT transmit new data to 2479 any destination transport address if its peer's rwnd indicates 2480 that the peer has no buffer space (i.e., rwnd is smaller than the 2481 size of the next DATA chunk; see Section 6.2.1). 2482 However, regardless of the value of rwnd (including if it is 0), 2483 the data sender can always have one DATA chunk in flight to 2484 the receiver if allowed by cwnd (see rule B, below). This rule 2485 allows the sender to probe for a change in rwnd that the sender 2486 missed due to the SACK's having been lost in transit from the data 2487 receiver to the data sender. 2489 When the receiver has no buffer space, this probe is 2490 called a zero window probe. Note that a zero window probe SHOULD 2491 only be sent when all outstanding DATA chunks have been 2492 cumulatively acknowledged and no DATA chunks are in flight. Zero 2493 window probing MUST be supported. 2495 3.39.3. Solution Description 2497 The terminology is used in a cleaner way. 2499 3.40. Updating References Regarding ECN 2501 3.40.1. Description of the Problem 2503 [RFC4960] refers for ECN only to [RFC3168], which will be updated by 2504 [RFC8311]. This needs to be reflected when referring to ECN. 2506 3.40.2. Text Changes to the Document 2508 --------- 2509 Old text: (Appendix A) 2510 --------- 2512 ECN [RFC3168] describes a proposed extension to IP that details a 2513 method to become aware of congestion outside of datagram loss. 2515 --------- 2516 New text: (Appendix A) 2517 --------- 2519 ECN as specified in [RFC3168] updated by [RFC8311] describes a proposed 2520 extension to IP that details a method to become aware of congestion 2521 outside of datagram loss. 2523 --------- 2524 Old text: (Appendix A) 2525 --------- 2527 In general, [RFC3168] should be followed with the following 2528 exceptions. 2530 --------- 2531 New text: (Appendix A) 2532 --------- 2534 In general, [RFC3168] updated by [RFC8311] SHOULD be followed with the 2535 following exceptions. 2537 --------- 2538 Old text: (Appendix A) 2539 --------- 2541 [RFC3168] details negotiation of ECN during the SYN and SYN-ACK 2542 stages of a TCP connection. 2544 --------- 2545 New text: (Appendix A) 2546 --------- 2548 [RFC3168] updated by [RFC8311] details negotiation of ECN during the 2549 SYN and SYN-ACK stages of a TCP connection. 2551 --------- 2552 Old text: (Appendix A) 2553 --------- 2555 [RFC3168] details a specific bit for a receiver to send back in its 2556 TCP acknowledgements to notify the sender of the Congestion 2557 Experienced (CE) bit having arrived from the network. 2559 --------- 2560 New text: (Appendix A) 2561 --------- 2563 [RFC3168] updated by [RFC8311] details a specific bit for a receiver 2564 to send back in its TCP acknowledgements to notify the sender of the 2565 Congestion Experienced (CE) bit having arrived from the network. 2567 --------- 2568 Old text: (Appendix A) 2569 --------- 2571 [RFC3168] details a specific bit for a sender to send in the header 2572 of its next outbound TCP segment to indicate to its peer that it has 2573 reduced its congestion window. 2574 --------- 2575 New text: (Appendix A) 2576 --------- 2578 [RFC3168] updated by [RFC8311] details a specific bit for a sender 2579 to send in the header of its next outbound TCP segment to indicate to 2580 its peer that it has reduced its congestion window. 2582 3.40.3. Solution Description 2584 References to [RFC8311] have been added. 2586 3.41. Host Name Address Parameter Deprecated 2588 3.41.1. Description of the Problem 2590 [RFC4960] defines three types of address parameters to be used with 2591 INIT and INIT ACK chunks: 2593 1. IPv4 Address parameters. 2594 2. IPv6 Address parameters. 2595 3. Host Name Address parameters. 2597 The first two are supported by the SCTP kernel implementations of 2598 FreeBSD, Linux and Solaris, but the third one is not. In addition, 2599 the first two where successfully tested in all nine interoperability 2600 tests for SCTP, but the third one has never been successfully tested. 2601 Therefore, the Host Name Address parameter should be deprecated. 2603 3.41.2. Text Changes to the Document 2605 --------- 2606 Old text: (Section 3.3.2) 2607 --------- 2609 Note 3: An INIT chunk MUST NOT contain more than one Host Name 2610 Address parameter. Moreover, the sender of the INIT MUST NOT combine 2611 any other address types with the Host Name Address in the INIT. The 2612 receiver of INIT MUST ignore any other address types if the Host Name 2613 Address parameter is present in the received INIT chunk. 2615 --------- 2616 New text: (Section 3.3.2) 2617 --------- 2619 Note 3: An INIT chunk MUST NOT contain the Host Name Address 2620 parameter. The receiver of an INIT chunk containing a Host Name 2621 Address parameter MUST send an ABORT and MAY include an Error Cause 2622 indicating an Unresolvable Address. 2624 --------- 2625 Old text: (Section 3.3.2.1) 2626 --------- 2628 The sender of INIT uses this parameter to pass its Host Name (in 2629 place of its IP addresses) to its peer. The peer is responsible for 2630 resolving the name. Using this parameter might make it more likely 2631 for the association to work across a NAT box. 2633 --------- 2634 New text: (Section 3.3.2.1) 2635 --------- 2637 The sender of an INIT chunk MUST NOT include this parameter. The 2638 usage of the Host Name Address parameter is deprecated. 2640 --------- 2641 Old text: (Section 3.3.2.1) 2642 --------- 2644 Address Type: 16 bits (unsigned integer) 2645 This is filled with the type value of the corresponding address 2646 TLV (e.g., IPv4 = 5, IPv6 = 6, Host name = 11). 2648 --------- 2649 New text: (Section 3.3.2.1) 2650 --------- 2651 Address Type: 16 bits (unsigned integer) 2653 This is filled with the type value of the corresponding address 2654 TLV (e.g., IPv4 = 5, IPv6 = 6). The value indicating the Host 2655 Name Address parameter (Host name = 11) MUST NOT be used. 2657 --------- 2658 Old text: (Section 3.3.3) 2659 --------- 2661 Note 3: The INIT ACK chunks MUST NOT contain more than one Host Name 2662 Address parameter. Moreover, the sender of the INIT ACK MUST NOT 2663 combine any other address types with the Host Name Address in the 2664 INIT ACK. The receiver of the INIT ACK MUST ignore any other address 2665 types if the Host Name Address parameter is present. 2667 --------- 2668 New text: (Section 3.3.3) 2669 --------- 2671 Note 3: An INIT ACK chunk MUST NOT contain the Host Name Address 2672 parameter. The receiver of INIT ACK chunks containing a Host Name 2673 Address parameter MUST send an ABORT and MAY include an Error Cause 2674 indicating an Unresolvable Address. 2676 --------- 2677 Old text: (Section 5.1.2) 2678 --------- 2680 B) If there is a Host Name parameter present in the received INIT or 2681 INIT ACK chunk, the endpoint shall resolve that host name to a 2682 list of IP address(es) and derive the transport address(es) of 2683 this peer by combining the resolved IP address(es) with the SCTP 2684 source port. 2686 The endpoint MUST ignore any other IP Address parameters if they 2687 are also present in the received INIT or INIT ACK chunk. 2689 The time at which the receiver of an INIT resolves the host name 2690 has potential security implications to SCTP. If the receiver of 2691 an INIT resolves the host name upon the reception of the chunk, 2692 and the mechanism the receiver uses to resolve the host name 2693 involves potential long delay (e.g., DNS query), the receiver may 2694 open itself up to resource attacks for the period of time while it 2695 is waiting for the name resolution results before it can build the 2696 State Cookie and release local resources. 2698 Therefore, in cases where the name translation involves potential 2699 long delay, the receiver of the INIT MUST postpone the name 2700 resolution till the reception of the COOKIE ECHO chunk from the 2701 peer. In such a case, the receiver of the INIT SHOULD build the 2702 State Cookie using the received Host Name (instead of destination 2703 transport addresses) and send the INIT ACK to the source IP 2704 address from which the INIT was received. 2706 The receiver of an INIT ACK shall always immediately attempt to 2707 resolve the name upon the reception of the chunk. 2709 The receiver of the INIT or INIT ACK MUST NOT send user data 2710 (piggy-backed or stand-alone) to its peer until the host name is 2711 successfully resolved. 2713 If the name resolution is not successful, the endpoint MUST 2714 immediately send an ABORT with "Unresolvable Address" error cause 2715 to its peer. The ABORT shall be sent to the source IP address 2716 from which the last peer packet was received. 2718 --------- 2719 New text: (Section 5.1.2) 2720 --------- 2722 B) If there is a Host Name parameter present in the received INIT or 2723 INIT ACK chunk, the endpoint MUST immediately send an ABORT and 2724 MAY include an Error Cause indicating an Unresolvable Address to 2725 its peer. The ABORT SHALL be sent to the source IP address 2726 from which the last peer packet was received. 2728 --------- 2729 Old text: (Section 11.2.4.1) 2730 --------- 2732 The use of the host name feature in the INIT chunk could be used to 2733 flood a target DNS server. A large backlog of DNS queries, resolving 2734 the host name received in the INIT chunk to IP addresses, could be 2735 accomplished by sending INITs to multiple hosts in a given domain. 2736 In addition, an attacker could use the host name feature in an 2737 indirect attack on a third party by sending large numbers of INITs to 2738 random hosts containing the host name of the target. In addition to 2739 the strain on DNS resources, this could also result in large numbers 2740 of INIT ACKs being sent to the target. One method to protect against 2741 this type of attack is to verify that the IP addresses received from 2742 DNS include the source IP address of the original INIT. If the list 2743 of IP addresses received from DNS does not include the source IP 2744 address of the INIT, the endpoint MAY silently discard the INIT. 2745 This last option will not protect against the attack against the DNS. 2747 --------- 2748 New text: (Section 11.2.4.1) 2749 --------- 2751 The support of the Host Name Address parameter has been removed from 2752 the protocol. Endpoints receiving INIT or INIT ACK chunks containing 2753 the Host Name Address parameter MUST send an ABORT chunk in response 2754 and MAY include an Error Cause indicating an Unresolvable Address. 2756 3.41.3. Solution Description 2758 The usage of the Host Name Address parameter has been deprecated. 2760 3.42. Conflicting Text Regarding the Supported Address Types Parameter 2762 3.42.1. Description of the Problem 2764 When receiving an SCTP packet containing an INIT chunk sent from an 2765 address for which the corresponding address type is not listed in the 2766 Supported Address Types, there is conflicting text in Section 5.1.2 2767 of [RFC4960]. It is stated that the association MUST be aborted and 2768 also that the association SHOULD be established and there SHOULD NOT 2769 be any error indication. 2771 3.42.2. Text Changes to the Document 2772 --------- 2773 Old text: (Section 5.1.2) 2774 --------- 2776 The sender of INIT may include a 'Supported Address Types' parameter 2777 in the INIT to indicate what types of address are acceptable. When 2778 this parameter is present, the receiver of INIT (initiate) MUST 2779 either use one of the address types indicated in the Supported 2780 Address Types parameter when responding to the INIT, or abort the 2781 association with an "Unresolvable Address" error cause if it is 2782 unwilling or incapable of using any of the address types indicated by 2783 its peer. 2785 --------- 2786 New text: (Section 5.1.2) 2787 --------- 2789 The sender of INIT chunks MAY include a 'Supported Address Types' 2790 parameter in the INIT to indicate what types of addresses are 2791 acceptable. 2793 3.42.3. Solution Description 2795 The conflicting text has been removed. 2797 3.43. Integration of RFC 6096 2799 3.43.1. Description of the Problem 2801 [RFC6096] updates [RFC4960] by adding a Chunk Flags Registry. This 2802 should be integrated into the base specification. 2804 3.43.2. Text Changes to the Document 2806 --------- 2807 Old text: (Section 14.1) 2808 --------- 2810 14.1. IETF-Defined Chunk Extension 2812 The assignment of new chunk parameter type codes is done through an 2813 IETF Consensus action, as defined in [RFC2434]. Documentation of the 2814 chunk parameter MUST contain the following information: 2816 a) A long and short name for the new chunk type. 2818 b) A detailed description of the structure of the chunk, which MUST 2819 conform to the basic structure defined in Section 3.2. 2821 c) A detailed definition and description of the intended use of each 2822 field within the chunk, including the chunk flags if any. 2824 d) A detailed procedural description of the use of the new chunk type 2825 within the operation of the protocol. 2827 The last chunk type (255) is reserved for future extension if 2828 necessary. 2830 --------- 2831 New text: (Section 14.1) 2832 --------- 2834 14.1. IETF-Defined Chunk Extension 2836 The assignment of new chunk type codes is done through an IETF Review 2837 action, as defined in [RFC8126]. Documentation of a new chunk MUST 2838 contain the following information: 2840 a) A long and short name for the new chunk type; 2842 b) A detailed description of the structure of the chunk, which MUST 2843 conform to the basic structure defined in Section 3.2 of 2844 [RFC4960]; 2846 c) A detailed definition and description of the intended use of each 2847 field within the chunk, including the chunk flags if any. 2848 Defined chunk flags will be used as initial entries in the chunk 2849 flags table for the new chunk type; 2851 d) A detailed procedural description of the use of the new chunk 2852 type within the operation of the protocol. 2854 The last chunk type (255) is reserved for future extension if 2855 necessary. 2857 For each new chunk type, IANA creates a registration table for the 2858 chunk flags of that type. The procedure for registering particular 2859 chunk flags is described in the following Section 14.2. 2861 --------- 2862 New text: (Section 14.2) 2863 --------- 2865 14.2. New IETF Chunk Flags Registration 2866 The assignment of new chunk flags is done through an RFC required 2867 action, as defined in [RFC8126]. Documentation of the chunk flags 2868 MUST contain the following information: 2870 a) A name for the new chunk flag; 2872 b) A detailed procedural description of the use of the new chunk 2873 flag within the operation of the protocol. It MUST be considered 2874 that implementations not supporting the flag will send '0' on 2875 transmit and just ignore it on receipt. 2877 IANA selects a chunk flags value. This MUST be one of 0x01, 0x02, 2878 0x04, 0x08, 0x10, 0x20, 0x40, or 0x80, which MUST be unique within 2879 the chunk flag values for the specific chunk type. 2881 Please note that Sections 14.2, 14.3, 14.4, and 14.5 need to be 2882 renumbered. 2884 3.43.3. Solution Description 2886 [RFC6096] was integrated and the reference updated to [RFC8126]. 2888 3.44. Integration of RFC 6335 2890 3.44.1. Description of the Problem 2892 [RFC6335] updates [RFC4960] by updating Procedures for the Port 2893 Numbers Registry. This should be integrated into the base 2894 specification. While there, update the reference to the RFC giving 2895 guidelines for writing IANA sections to [RFC8126]. 2897 3.44.2. Text Changes to the Document 2899 --------- 2900 Old text: (Section 14.5) 2901 --------- 2903 SCTP services may use contact port numbers to provide service to 2904 unknown callers, as in TCP and UDP. IANA is therefore requested to 2905 open the existing Port Numbers registry for SCTP using the following 2906 rules, which we intend to mesh well with existing Port Numbers 2907 registration procedures. An IESG-appointed Expert Reviewer supports 2908 IANA in evaluating SCTP port allocation requests, according to the 2909 procedure defined in [RFC2434]. 2911 Port numbers are divided into three ranges. The Well Known Ports are 2912 those from 0 through 1023, the Registered Ports are those from 1024 2913 through 49151, and the Dynamic and/or Private Ports are those from 2914 49152 through 65535. Well Known and Registered Ports are intended 2915 for use by server applications that desire a default contact point on 2916 a system. On most systems, Well Known Ports can only be used by 2917 system (or root) processes or by programs executed by privileged 2918 users, while Registered Ports can be used by ordinary user processes 2919 or programs executed by ordinary users. Dynamic and/or Private Ports 2920 are intended for temporary use, including client-side ports, out-of- 2921 band negotiated ports, and application testing prior to registration 2922 of a dedicated port; they MUST NOT be registered. 2924 The Port Numbers registry should accept registrations for SCTP ports 2925 in the Well Known Ports and Registered Ports ranges. Well Known and 2926 Registered Ports SHOULD NOT be used without registration. Although 2927 in some cases -- such as porting an application from TCP to SCTP -- 2928 it may seem natural to use an SCTP port before registration 2929 completes, we emphasize that IANA will not guarantee registration of 2930 particular Well Known and Registered Ports. Registrations should be 2931 requested as early as possible. 2933 Each port registration SHALL include the following information: 2935 o A short port name, consisting entirely of letters (A-Z and a-z), 2936 digits (0-9), and punctuation characters from "-_+./*" (not 2937 including the quotes). 2939 o The port number that is requested for registration. 2941 o A short English phrase describing the port's purpose. 2943 o Name and contact information for the person or entity performing 2944 the registration, and possibly a reference to a document defining 2945 the port's use. Registrations coming from IETF working groups 2946 need only name the working group, but indicating a contact person 2947 is recommended. 2949 Registrants are encouraged to follow these guidelines when submitting 2950 a registration. 2952 o A port name SHOULD NOT be registered for more than one SCTP port 2953 number. 2955 o A port name registered for TCP MAY be registered for SCTP as well. 2956 Any such registration SHOULD use the same port number as the 2957 existing TCP registration. 2959 o Concrete intent to use a port SHOULD precede port registration. 2960 For example, existing TCP ports SHOULD NOT be registered in 2961 advance of any intent to use those ports for SCTP. 2963 --------- 2964 New text: (Section 14.5) 2965 --------- 2967 SCTP services can use contact port numbers to provide service to 2968 unknown callers, as in TCP and UDP. IANA is therefore requested to 2969 open the existing Port Numbers registry for SCTP using the following 2970 rules, which we intend to mesh well with existing Port Numbers 2971 registration procedures. An IESG-appointed Expert Reviewer supports 2972 IANA in evaluating SCTP port allocation requests, according to the 2973 procedure defined in [RFC8126]. The details of this process are 2974 defined in [RFC6335]. 2976 3.44.3. Solution Description 2978 [RFC6335] was integrated and the reference was updated to [RFC8126]. 2980 3.45. Integration of RFC 7053 2982 3.45.1. Description of the Problem 2984 [RFC7053] updates [RFC4960] by adding the I bit to the DATA chunk. 2985 This should be integrated into the base specification. 2987 3.45.2. Text Changes to the Document 2989 --------- 2990 Old text: (Section 3.3.1) 2991 --------- 2993 The following format MUST be used for the DATA chunk: 2995 0 1 2 3 2996 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 2997 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2998 | Type = 0 | Reserved|U|B|E| Length | 2999 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3000 | TSN | 3001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3002 | Stream Identifier S | Stream Sequence Number n | 3003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3004 | Payload Protocol Identifier | 3005 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3006 \ \ 3007 / User Data (seq n of Stream S) / 3008 \ \ 3009 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3011 Reserved: 5 bits 3013 Should be set to all '0's and ignored by the receiver. 3015 --------- 3016 New text: (Section 3.3.1) 3017 --------- 3019 0 1 2 3 3020 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 3021 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3022 | Type = 0 | Res |I|U|B|E| Length | 3023 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3024 | TSN | 3025 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3026 | Stream Identifier S | Stream Sequence Number n | 3027 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3028 | Payload Protocol Identifier | 3029 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3030 \ \ 3031 / User Data (seq n of Stream S) / 3032 \ \ 3033 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3035 Res: 4 bits 3037 SHOULD be set to all '0's and ignored by the receiver. 3039 I bit: 1 bit 3041 The (I)mmediate Bit MAY be set by the sender, whenever the sender of 3042 a DATA chunk can benefit from the corresponding SACK chunk being sent 3043 back without delay. See [RFC7053] for a discussion about 3045 --------- 3046 New text: (Append to Section 6.1) 3047 --------- 3049 Whenever the sender of a DATA chunk can benefit from the 3050 corresponding SACK chunk being sent back without delay, the sender 3051 MAY set the I bit in the DATA chunk header. Please note that why the 3052 sender has set the I bit is irrelevant to the receiver. 3054 Reasons for setting the I bit include, but are not limited to (see 3055 Section 4 of [RFC7053] for the benefits): 3057 o The application requests to set the I bit of the last DATA chunk 3058 of a user message when providing the user message to the SCTP 3059 implementation (see Section 7). 3061 o The sender is in the SHUTDOWN-PENDING state. 3063 o The sending of a DATA chunk fills the congestion or receiver 3064 window. 3066 --------- 3067 Old text: (Section 6.2) 3068 --------- 3070 Note: The SHUTDOWN chunk does not contain Gap Ack Block fields. 3071 Therefore, the endpoint should use a SACK instead of the SHUTDOWN 3072 chunk to acknowledge DATA chunks received out of order. 3074 --------- 3075 New text: (Section 6.2) 3076 --------- 3078 Note: The SHUTDOWN chunk does not contain Gap Ack Block fields. 3079 Therefore, the endpoint SHOULD use a SACK instead of the SHUTDOWN 3080 chunk to acknowledge DATA chunks received out of order. 3082 Upon receipt of an SCTP packet containing a DATA chunk with the I bit 3083 set, the receiver SHOULD NOT delay the sending of the corresponding 3084 SACK chunk, i.e., the receiver SHOULD immediately respond with the 3085 corresponding SACK chunk. 3087 --------- 3088 Old text: (Section 10.1) 3089 --------- 3091 E) Send 3093 Format: SEND(association id, buffer address, byte count [,context] 3094 [,stream id] [,life time] [,destination transport address] 3095 [,unordered flag] [,no-bundle flag] [,payload protocol-id] ) 3096 -> result 3098 --------- 3099 New text: (Section 10.1) 3100 --------- 3102 E) Send 3104 Format: SEND(association id, buffer address, byte count [,context] 3105 [,stream id] [,life time] [,destination transport address] 3107 [,unordered flag] [,no-bundle flag] [,payload protocol-id] 3108 [,sack immediately] ) 3109 -> result 3111 --------- 3112 New text: (Append optional parameter in Subsection E of Section 10.1) 3113 --------- 3115 o sack immediately - set the I bit on the last DATA chunk used for 3116 sending buffer. 3118 Please note that the change in Section 6.2 is only about adding a 3119 paragraph. 3121 3.45.3. Solution Description 3123 [RFC7053] was integrated. 3125 3.46. CRC32c Code Improvements 3127 3.46.1. Description of the Problem 3129 The code given for the CRC32c computations uses types like long which 3130 may have different length on different operating systems or 3131 processors. Therefore, the code is changed to use specific types 3132 like uint32_t. 3134 While there, fix also some syntax errors and a comment. 3136 3.46.2. Text Changes to the Document 3138 --------- 3139 Old text: (Appendix B) 3140 --------- 3141 /*************************************************************/ 3142 /* Note Definition for Ross Williams table generator would */ 3143 /* be: TB_WIDTH=4, TB_POLLY=0x1EDC6F41, TB_REVER=TRUE */ 3144 /* For Mr. Williams direct calculation code use the settings */ 3145 /* cm_width=32, cm_poly=0x1EDC6F41, cm_init=0xFFFFFFFF, */ 3146 /* cm_refin=TRUE, cm_refot=TRUE, cm_xorort=0x00000000 */ 3147 /*************************************************************/ 3149 /* Example of the crc table file */ 3150 #ifndef __crc32cr_table_h__ 3151 #define __crc32cr_table_h__ 3153 #define CRC32C_POLY 0x1EDC6F41 3154 #define CRC32C(c,d) (c=(c>>8)^crc_c[(c^(d))&0xFF]) 3156 unsigned long crc_c[256] = 3157 { 3158 0x00000000L, 0xF26B8303L, 0xE13B70F7L, 0x1350F3F4L, 3159 0xC79A971FL, 0x35F1141CL, 0x26A1E7E8L, 0xD4CA64EBL, 3160 0x8AD958CFL, 0x78B2DBCCL, 0x6BE22838L, 0x9989AB3BL, 3161 0x4D43CFD0L, 0xBF284CD3L, 0xAC78BF27L, 0x5E133C24L, 3162 0x105EC76FL, 0xE235446CL, 0xF165B798L, 0x030E349BL, 3163 0xD7C45070L, 0x25AFD373L, 0x36FF2087L, 0xC494A384L, 3164 0x9A879FA0L, 0x68EC1CA3L, 0x7BBCEF57L, 0x89D76C54L, 3165 0x5D1D08BFL, 0xAF768BBCL, 0xBC267848L, 0x4E4DFB4BL, 3166 0x20BD8EDEL, 0xD2D60DDDL, 0xC186FE29L, 0x33ED7D2AL, 3167 0xE72719C1L, 0x154C9AC2L, 0x061C6936L, 0xF477EA35L, 3168 0xAA64D611L, 0x580F5512L, 0x4B5FA6E6L, 0xB93425E5L, 3169 0x6DFE410EL, 0x9F95C20DL, 0x8CC531F9L, 0x7EAEB2FAL, 3170 0x30E349B1L, 0xC288CAB2L, 0xD1D83946L, 0x23B3BA45L, 3172 0xF779DEAEL, 0x05125DADL, 0x1642AE59L, 0xE4292D5AL, 3173 0xBA3A117EL, 0x4851927DL, 0x5B016189L, 0xA96AE28AL, 3174 0x7DA08661L, 0x8FCB0562L, 0x9C9BF696L, 0x6EF07595L, 3175 0x417B1DBCL, 0xB3109EBFL, 0xA0406D4BL, 0x522BEE48L, 3176 0x86E18AA3L, 0x748A09A0L, 0x67DAFA54L, 0x95B17957L, 3177 0xCBA24573L, 0x39C9C670L, 0x2A993584L, 0xD8F2B687L, 3178 0x0C38D26CL, 0xFE53516FL, 0xED03A29BL, 0x1F682198L, 3179 0x5125DAD3L, 0xA34E59D0L, 0xB01EAA24L, 0x42752927L, 3180 0x96BF4DCCL, 0x64D4CECFL, 0x77843D3BL, 0x85EFBE38L, 3181 0xDBFC821CL, 0x2997011FL, 0x3AC7F2EBL, 0xC8AC71E8L, 3182 0x1C661503L, 0xEE0D9600L, 0xFD5D65F4L, 0x0F36E6F7L, 3183 0x61C69362L, 0x93AD1061L, 0x80FDE395L, 0x72966096L, 3184 0xA65C047DL, 0x5437877EL, 0x4767748AL, 0xB50CF789L, 3185 0xEB1FCBADL, 0x197448AEL, 0x0A24BB5AL, 0xF84F3859L, 3186 0x2C855CB2L, 0xDEEEDFB1L, 0xCDBE2C45L, 0x3FD5AF46L, 3187 0x7198540DL, 0x83F3D70EL, 0x90A324FAL, 0x62C8A7F9L, 3188 0xB602C312L, 0x44694011L, 0x5739B3E5L, 0xA55230E6L, 3189 0xFB410CC2L, 0x092A8FC1L, 0x1A7A7C35L, 0xE811FF36L, 3190 0x3CDB9BDDL, 0xCEB018DEL, 0xDDE0EB2AL, 0x2F8B6829L, 3191 0x82F63B78L, 0x709DB87BL, 0x63CD4B8FL, 0x91A6C88CL, 3192 0x456CAC67L, 0xB7072F64L, 0xA457DC90L, 0x563C5F93L, 3193 0x082F63B7L, 0xFA44E0B4L, 0xE9141340L, 0x1B7F9043L, 3194 0xCFB5F4A8L, 0x3DDE77ABL, 0x2E8E845FL, 0xDCE5075CL, 3195 0x92A8FC17L, 0x60C37F14L, 0x73938CE0L, 0x81F80FE3L, 3196 0x55326B08L, 0xA759E80BL, 0xB4091BFFL, 0x466298FCL, 3197 0x1871A4D8L, 0xEA1A27DBL, 0xF94AD42FL, 0x0B21572CL, 3198 0xDFEB33C7L, 0x2D80B0C4L, 0x3ED04330L, 0xCCBBC033L, 3199 0xA24BB5A6L, 0x502036A5L, 0x4370C551L, 0xB11B4652L, 3200 0x65D122B9L, 0x97BAA1BAL, 0x84EA524EL, 0x7681D14DL, 3201 0x2892ED69L, 0xDAF96E6AL, 0xC9A99D9EL, 0x3BC21E9DL, 3202 0xEF087A76L, 0x1D63F975L, 0x0E330A81L, 0xFC588982L, 3203 0xB21572C9L, 0x407EF1CAL, 0x532E023EL, 0xA145813DL, 3204 0x758FE5D6L, 0x87E466D5L, 0x94B49521L, 0x66DF1622L, 3205 0x38CC2A06L, 0xCAA7A905L, 0xD9F75AF1L, 0x2B9CD9F2L, 3206 0xFF56BD19L, 0x0D3D3E1AL, 0x1E6DCDEEL, 0xEC064EEDL, 3207 0xC38D26C4L, 0x31E6A5C7L, 0x22B65633L, 0xD0DDD530L, 3208 0x0417B1DBL, 0xF67C32D8L, 0xE52CC12CL, 0x1747422FL, 3209 0x49547E0BL, 0xBB3FFD08L, 0xA86F0EFCL, 0x5A048DFFL, 3210 0x8ECEE914L, 0x7CA56A17L, 0x6FF599E3L, 0x9D9E1AE0L, 3211 0xD3D3E1ABL, 0x21B862A8L, 0x32E8915CL, 0xC083125FL, 3212 0x144976B4L, 0xE622F5B7L, 0xF5720643L, 0x07198540L, 3213 0x590AB964L, 0xAB613A67L, 0xB831C993L, 0x4A5A4A90L, 3214 0x9E902E7BL, 0x6CFBAD78L, 0x7FAB5E8CL, 0x8DC0DD8FL, 3215 0xE330A81AL, 0x115B2B19L, 0x020BD8EDL, 0xF0605BEEL, 3216 0x24AA3F05L, 0xD6C1BC06L, 0xC5914FF2L, 0x37FACCF1L, 3217 0x69E9F0D5L, 0x9B8273D6L, 0x88D28022L, 0x7AB90321L, 3218 0xAE7367CAL, 0x5C18E4C9L, 0x4F48173DL, 0xBD23943EL, 3219 0xF36E6F75L, 0x0105EC76L, 0x12551F82L, 0xE03E9C81L, 3221 0x34F4F86AL, 0xC69F7B69L, 0xD5CF889DL, 0x27A40B9EL, 3222 0x79B737BAL, 0x8BDCB4B9L, 0x988C474DL, 0x6AE7C44EL, 3223 0xBE2DA0A5L, 0x4C4623A6L, 0x5F16D052L, 0xAD7D5351L, 3224 }; 3226 #endif 3228 --------- 3229 New text: (Appendix B) 3230 --------- 3232 3233 /*************************************************************/ 3234 /* Note Definition for Ross Williams table generator would */ 3235 /* be: TB_WIDTH=4, TB_POLLY=0x1EDC6F41, TB_REVER=TRUE */ 3236 /* For Mr. Williams direct calculation code use the settings */ 3237 /* cm_width=32, cm_poly=0x1EDC6F41, cm_init=0xFFFFFFFF, */ 3238 /* cm_refin=TRUE, cm_refot=TRUE, cm_xorort=0x00000000 */ 3239 /*************************************************************/ 3241 /* Example of the crc table file */ 3242 #ifndef __crc32cr_h__ 3243 #define __crc32cr_h__ 3245 #define CRC32C_POLY 0x1EDC6F41UL 3246 #define CRC32C(c,d) (c=(c>>8)^crc_c[(c^(d))&0xFF]) 3248 uint32_t crc_c[256] = 3249 { 3250 0x00000000UL, 0xF26B8303UL, 0xE13B70F7UL, 0x1350F3F4UL, 3251 0xC79A971FUL, 0x35F1141CUL, 0x26A1E7E8UL, 0xD4CA64EBUL, 3252 0x8AD958CFUL, 0x78B2DBCCUL, 0x6BE22838UL, 0x9989AB3BUL, 3253 0x4D43CFD0UL, 0xBF284CD3UL, 0xAC78BF27UL, 0x5E133C24UL, 3254 0x105EC76FUL, 0xE235446CUL, 0xF165B798UL, 0x030E349BUL, 3255 0xD7C45070UL, 0x25AFD373UL, 0x36FF2087UL, 0xC494A384UL, 3256 0x9A879FA0UL, 0x68EC1CA3UL, 0x7BBCEF57UL, 0x89D76C54UL, 3257 0x5D1D08BFUL, 0xAF768BBCUL, 0xBC267848UL, 0x4E4DFB4BUL, 3258 0x20BD8EDEUL, 0xD2D60DDDUL, 0xC186FE29UL, 0x33ED7D2AUL, 3259 0xE72719C1UL, 0x154C9AC2UL, 0x061C6936UL, 0xF477EA35UL, 3260 0xAA64D611UL, 0x580F5512UL, 0x4B5FA6E6UL, 0xB93425E5UL, 3261 0x6DFE410EUL, 0x9F95C20DUL, 0x8CC531F9UL, 0x7EAEB2FAUL, 3262 0x30E349B1UL, 0xC288CAB2UL, 0xD1D83946UL, 0x23B3BA45UL, 3263 0xF779DEAEUL, 0x05125DADUL, 0x1642AE59UL, 0xE4292D5AUL, 3264 0xBA3A117EUL, 0x4851927DUL, 0x5B016189UL, 0xA96AE28AUL, 3265 0x7DA08661UL, 0x8FCB0562UL, 0x9C9BF696UL, 0x6EF07595UL, 3266 0x417B1DBCUL, 0xB3109EBFUL, 0xA0406D4BUL, 0x522BEE48UL, 3267 0x86E18AA3UL, 0x748A09A0UL, 0x67DAFA54UL, 0x95B17957UL, 3268 0xCBA24573UL, 0x39C9C670UL, 0x2A993584UL, 0xD8F2B687UL, 3269 0x0C38D26CUL, 0xFE53516FUL, 0xED03A29BUL, 0x1F682198UL, 3270 0x5125DAD3UL, 0xA34E59D0UL, 0xB01EAA24UL, 0x42752927UL, 3271 0x96BF4DCCUL, 0x64D4CECFUL, 0x77843D3BUL, 0x85EFBE38UL, 3272 0xDBFC821CUL, 0x2997011FUL, 0x3AC7F2EBUL, 0xC8AC71E8UL, 3273 0x1C661503UL, 0xEE0D9600UL, 0xFD5D65F4UL, 0x0F36E6F7UL, 3274 0x61C69362UL, 0x93AD1061UL, 0x80FDE395UL, 0x72966096UL, 3275 0xA65C047DUL, 0x5437877EUL, 0x4767748AUL, 0xB50CF789UL, 3276 0xEB1FCBADUL, 0x197448AEUL, 0x0A24BB5AUL, 0xF84F3859UL, 3277 0x2C855CB2UL, 0xDEEEDFB1UL, 0xCDBE2C45UL, 0x3FD5AF46UL, 3278 0x7198540DUL, 0x83F3D70EUL, 0x90A324FAUL, 0x62C8A7F9UL, 3279 0xB602C312UL, 0x44694011UL, 0x5739B3E5UL, 0xA55230E6UL, 3280 0xFB410CC2UL, 0x092A8FC1UL, 0x1A7A7C35UL, 0xE811FF36UL, 3281 0x3CDB9BDDUL, 0xCEB018DEUL, 0xDDE0EB2AUL, 0x2F8B6829UL, 3282 0x82F63B78UL, 0x709DB87BUL, 0x63CD4B8FUL, 0x91A6C88CUL, 3283 0x456CAC67UL, 0xB7072F64UL, 0xA457DC90UL, 0x563C5F93UL, 3284 0x082F63B7UL, 0xFA44E0B4UL, 0xE9141340UL, 0x1B7F9043UL, 3285 0xCFB5F4A8UL, 0x3DDE77ABUL, 0x2E8E845FUL, 0xDCE5075CUL, 3286 0x92A8FC17UL, 0x60C37F14UL, 0x73938CE0UL, 0x81F80FE3UL, 3287 0x55326B08UL, 0xA759E80BUL, 0xB4091BFFUL, 0x466298FCUL, 3288 0x1871A4D8UL, 0xEA1A27DBUL, 0xF94AD42FUL, 0x0B21572CUL, 3289 0xDFEB33C7UL, 0x2D80B0C4UL, 0x3ED04330UL, 0xCCBBC033UL, 3290 0xA24BB5A6UL, 0x502036A5UL, 0x4370C551UL, 0xB11B4652UL, 3291 0x65D122B9UL, 0x97BAA1BAUL, 0x84EA524EUL, 0x7681D14DUL, 3292 0x2892ED69UL, 0xDAF96E6AUL, 0xC9A99D9EUL, 0x3BC21E9DUL, 3293 0xEF087A76UL, 0x1D63F975UL, 0x0E330A81UL, 0xFC588982UL, 3294 0xB21572C9UL, 0x407EF1CAUL, 0x532E023EUL, 0xA145813DUL, 3295 0x758FE5D6UL, 0x87E466D5UL, 0x94B49521UL, 0x66DF1622UL, 3296 0x38CC2A06UL, 0xCAA7A905UL, 0xD9F75AF1UL, 0x2B9CD9F2UL, 3297 0xFF56BD19UL, 0x0D3D3E1AUL, 0x1E6DCDEEUL, 0xEC064EEDUL, 3298 0xC38D26C4UL, 0x31E6A5C7UL, 0x22B65633UL, 0xD0DDD530UL, 3299 0x0417B1DBUL, 0xF67C32D8UL, 0xE52CC12CUL, 0x1747422FUL, 3300 0x49547E0BUL, 0xBB3FFD08UL, 0xA86F0EFCUL, 0x5A048DFFUL, 3301 0x8ECEE914UL, 0x7CA56A17UL, 0x6FF599E3UL, 0x9D9E1AE0UL, 3302 0xD3D3E1ABUL, 0x21B862A8UL, 0x32E8915CUL, 0xC083125FUL, 3303 0x144976B4UL, 0xE622F5B7UL, 0xF5720643UL, 0x07198540UL, 3304 0x590AB964UL, 0xAB613A67UL, 0xB831C993UL, 0x4A5A4A90UL, 3305 0x9E902E7BUL, 0x6CFBAD78UL, 0x7FAB5E8CUL, 0x8DC0DD8FUL, 3306 0xE330A81AUL, 0x115B2B19UL, 0x020BD8EDUL, 0xF0605BEEUL, 3307 0x24AA3F05UL, 0xD6C1BC06UL, 0xC5914FF2UL, 0x37FACCF1UL, 3308 0x69E9F0D5UL, 0x9B8273D6UL, 0x88D28022UL, 0x7AB90321UL, 3309 0xAE7367CAUL, 0x5C18E4C9UL, 0x4F48173DUL, 0xBD23943EUL, 3310 0xF36E6F75UL, 0x0105EC76UL, 0x12551F82UL, 0xE03E9C81UL, 3311 0x34F4F86AUL, 0xC69F7B69UL, 0xD5CF889DUL, 0x27A40B9EUL, 3312 0x79B737BAUL, 0x8BDCB4B9UL, 0x988C474DUL, 0x6AE7C44EUL, 3313 0xBE2DA0A5UL, 0x4C4623A6UL, 0x5F16D052UL, 0xAD7D5351UL, 3314 }; 3316 #endif 3318 --------- 3319 Old text: (Appendix B) 3320 --------- 3322 /* Example of table build routine */ 3324 #include 3325 #include 3327 #define OUTPUT_FILE "crc32cr.h" 3328 #define CRC32C_POLY 0x1EDC6F41L 3329 FILE *tf; 3330 unsigned long 3331 reflect_32 (unsigned long b) 3332 { 3333 int i; 3334 unsigned long rw = 0L; 3336 for (i = 0; i < 32; i++){ 3337 if (b & 1) 3338 rw |= 1 << (31 - i); 3339 b >>= 1; 3340 } 3341 return (rw); 3342 } 3344 unsigned long 3345 build_crc_table (int index) 3346 { 3347 int i; 3348 unsigned long rb; 3350 rb = reflect_32 (index); 3352 for (i = 0; i < 8; i++){ 3353 if (rb & 0x80000000L) 3354 rb = (rb << 1) ^ CRC32C_POLY; 3355 else 3356 rb <<= 1; 3357 } 3358 return (reflect_32 (rb)); 3359 } 3361 main () 3362 { 3363 int i; 3365 printf ("\nGenerating CRC-32c table file <%s>\n", 3366 OUTPUT_FILE); 3367 if ((tf = fopen (OUTPUT_FILE, "w")) == NULL){ 3368 printf ("Unable to open %s\n", OUTPUT_FILE); 3369 exit (1); 3370 } 3371 fprintf (tf, "#ifndef __crc32cr_table_h__\n"); 3372 fprintf (tf, "#define __crc32cr_table_h__\n\n"); 3373 fprintf (tf, "#define CRC32C_POLY 0x%08lX\n", 3374 CRC32C_POLY); 3375 fprintf (tf, 3376 "#define CRC32C(c,d) (c=(c>>8)^crc_c[(c^(d))&0xFF])\n"); 3377 fprintf (tf, "\nunsigned long crc_c[256] =\n{\n"); 3378 for (i = 0; i < 256; i++){ 3379 fprintf (tf, "0x%08lXL, ", build_crc_table (i)); 3380 if ((i & 3) == 3) 3381 fprintf (tf, "\n"); 3382 } 3383 fprintf (tf, "};\n\n#endif\n"); 3385 if (fclose (tf) != 0) 3386 printf ("Unable to close <%s>." OUTPUT_FILE); 3387 else 3388 printf ("\nThe CRC-32c table has been written to <%s>.\n", 3389 OUTPUT_FILE); 3390 } 3392 --------- 3393 New text: (Appendix B) 3394 --------- 3396 /* Example of table build routine */ 3398 #include 3399 #include 3401 #define OUTPUT_FILE "crc32cr.h" 3402 #define CRC32C_POLY 0x1EDC6F41UL 3404 static FILE *tf; 3406 static uint32_t 3407 reflect_32(uint32_t b) 3408 { 3409 int i; 3410 uint32_t rw = 0UL; 3412 for (i = 0; i < 32; i++) { 3413 if (b & 1) 3414 rw |= 1 << (31 - i); 3415 b >>= 1; 3416 } 3417 return (rw); 3418 } 3420 static uint32_t 3421 build_crc_table(int index) 3422 { 3423 int i; 3424 uint32_t rb; 3426 rb = reflect_32(index); 3428 for (i = 0; i < 8; i++) { 3429 if (rb & 0x80000000UL) 3430 rb = (rb << 1) ^ (uint32_t)CRC32C_POLY; 3431 else 3432 rb <<= 1; 3433 } 3434 return (reflect_32(rb)); 3435 } 3437 int 3438 main (void) 3439 { 3440 int i; 3441 printf("\nGenerating CRC-32c table file <%s>\n", 3442 OUTPUT_FILE); 3443 if ((tf = fopen(OUTPUT_FILE, "w")) == NULL) { 3444 printf ("Unable to open %s\n", OUTPUT_FILE); 3445 exit (1); 3446 } 3447 fprintf(tf, "#ifndef __crc32cr_h__\n"); 3448 fprintf(tf, "#define __crc32cr_h__\n\n"); 3449 fprintf(tf, "#define CRC32C_POLY 0x%08XUL\n", 3450 (uint32_t)CRC32C_POLY); 3451 fprintf(tf, 3452 "#define CRC32C(c,d) (c=(c>>8)^crc_c[(c^(d))&0xFF])\n"); 3453 fprintf(tf, "\nuint32_t crc_c[256] =\n{\n"); 3454 for (i = 0; i < 256; i++) { 3455 fprintf(tf, "0x%08XUL,", build_crc_table (i)); 3456 if ((i & 3) == 3) 3457 fprintf(tf, "\n"); 3458 else 3459 fprintf(tf, " "); 3460 } 3461 fprintf(tf, "};\n\n#endif\n"); 3463 if (fclose (tf) != 0) 3464 printf("Unable to close <%s>.", OUTPUT_FILE); 3465 else 3466 printf("\nThe CRC-32c table has been written to <%s>.\n", 3467 OUTPUT_FILE); 3468 } 3470 --------- 3471 Old text: (Appendix B) 3472 --------- 3474 /* Example of crc insertion */ 3476 #include "crc32cr.h" 3478 unsigned long 3479 generate_crc32c(unsigned char *buffer, unsigned int length) 3480 { 3481 unsigned int i; 3482 unsigned long crc32 = ~0L; 3483 unsigned long result; 3484 unsigned char byte0,byte1,byte2,byte3; 3486 for (i = 0; i < length; i++){ 3487 CRC32C(crc32, buffer[i]); 3488 } 3489 result = ~crc32; 3491 /* result now holds the negated polynomial remainder; 3492 * since the table and algorithm is "reflected" [williams95]. 3493 * That is, result has the same value as if we mapped the message 3494 * to a polynomial, computed the host-bit-order polynomial 3495 * remainder, performed final negation, then did an end-for-end 3496 * bit-reversal. 3497 * Note that a 32-bit bit-reversal is identical to four inplace 3498 * 8-bit reversals followed by an end-for-end byteswap. 3499 * In other words, the bytes of each bit are in the right order, 3500 * but the bytes have been byteswapped. So we now do an explicit 3501 * byteswap. On a little-endian machine, this byteswap and 3502 * the final ntohl cancel out and could be elided. 3503 */ 3505 byte0 = result & 0xff; 3506 byte1 = (result>>8) & 0xff; 3507 byte2 = (result>>16) & 0xff; 3508 byte3 = (result>>24) & 0xff; 3509 crc32 = ((byte0 << 24) | 3510 (byte1 << 16) | 3511 (byte2 << 8) | 3512 byte3); 3513 return ( crc32 ); 3514 } 3516 int 3517 insert_crc32(unsigned char *buffer, unsigned int length) 3518 { 3519 SCTP_message *message; 3520 unsigned long crc32; 3521 message = (SCTP_message *) buffer; 3522 message->common_header.checksum = 0L; 3523 crc32 = generate_crc32c(buffer,length); 3524 /* and insert it into the message */ 3525 message->common_header.checksum = htonl(crc32); 3526 return 1; 3527 } 3529 int 3530 validate_crc32(unsigned char *buffer, unsigned int length) 3531 { 3532 SCTP_message *message; 3533 unsigned int i; 3534 unsigned long original_crc32; 3535 unsigned long crc32 = ~0L; 3536 /* save and zero checksum */ 3537 message = (SCTP_message *) buffer; 3538 original_crc32 = ntohl(message->common_header.checksum); 3539 message->common_header.checksum = 0L; 3540 crc32 = generate_crc32c(buffer,length); 3541 return ((original_crc32 == crc32)? 1 : -1); 3542 } 3544 --------- 3545 New text: (Appendix B) 3546 --------- 3548 /* Example of crc insertion */ 3550 #include "crc32cr.h" 3552 uint32_t 3553 generate_crc32c(unsigned char *buffer, unsigned int length) 3554 { 3555 unsigned int i; 3556 uint32_t crc32 = 0xffffffffUL; 3557 uint32_t result; 3558 uint8_t byte0, byte1, byte2, byte3; 3560 for (i = 0; i < length; i++) { 3561 CRC32C(crc32, buffer[i]); 3562 } 3564 result = ~crc32; 3566 /* result now holds the negated polynomial remainder; 3567 * since the table and algorithm is "reflected" [williams95]. 3568 * That is, result has the same value as if we mapped the message 3569 * to a polynomial, computed the host-bit-order polynomial 3570 * remainder, performed final negation, then did an end-for-end 3571 * bit-reversal. 3572 * Note that a 32-bit bit-reversal is identical to four inplace 3573 * 8-bit reversals followed by an end-for-end byteswap. 3574 * In other words, the bits of each byte are in the right order, 3575 * but the bytes have been byteswapped. So we now do an explicit 3576 * byteswap. On a little-endian machine, this byteswap and 3577 * the final ntohl cancel out and could be elided. 3578 */ 3580 byte0 = result & 0xff; 3581 byte1 = (result>>8) & 0xff; 3582 byte2 = (result>>16) & 0xff; 3583 byte3 = (result>>24) & 0xff; 3584 crc32 = ((byte0 << 24) | 3585 (byte1 << 16) | 3586 (byte2 << 8) | 3587 byte3); 3588 return (crc32); 3589 } 3591 int 3592 insert_crc32(unsigned char *buffer, unsigned int length) 3593 { 3594 SCTP_message *message; 3595 uint32_t crc32; 3596 message = (SCTP_message *) buffer; 3597 message->common_header.checksum = 0UL; 3598 crc32 = generate_crc32c(buffer,length); 3599 /* and insert it into the message */ 3600 message->common_header.checksum = htonl(crc32); 3601 return 1; 3602 } 3604 int 3605 validate_crc32(unsigned char *buffer, unsigned int length) 3606 { 3607 SCTP_message *message; 3608 unsigned int i; 3609 uint32_t original_crc32; 3610 uint32_t crc32; 3612 /* save and zero checksum */ 3613 message = (SCTP_message *)buffer; 3614 original_crc32 = ntohl(message->common_header.checksum); 3615 message->common_header.checksum = 0L; 3616 crc32 = generate_crc32c(buffer, length); 3617 return ((original_crc32 == crc32)? 1 : -1); 3618 } 3619 3621 3.46.3. Solution Description 3623 The code was changed to use platform independent types. 3625 3.47. Clarification of Gap Ack Blocks in SACK Chunks 3626 3.47.1. Description of the Problem 3628 The Gap Ack Blocks in the SACK chunk are intended to be isolated. 3629 However, this is not mentioned with normative text. 3631 3.47.2. Text Changes to the Document 3633 --------- 3634 Old text: (Section 3.3.4) 3635 --------- 3637 The SACK also contains zero or more Gap Ack Blocks. Each Gap Ack 3638 Block acknowledges a subsequence of TSNs received following a break 3639 in the sequence of received TSNs. By definition, all TSNs 3640 acknowledged by Gap Ack Blocks are greater than the value of the 3641 Cumulative TSN Ack. 3643 --------- 3644 New text: (Section 3.3.4) 3645 --------- 3647 The SACK also contains zero or more Gap Ack Blocks. Each Gap Ack 3648 Block acknowledges a subsequence of TSNs received following a break 3649 in the sequence of received TSNs. The Gap Ack Blocks SHOULD be isolated. 3650 This means that the TSN just before each Gap Ack Block and the TSN just 3651 after each Gap Ack Block has not been received. By definition, all TSNs 3652 acknowledged by Gap Ack Blocks are greater than the value of the 3653 Cumulative TSN Ack. 3655 --------- 3656 Old text: (Section 3.3.4) 3657 --------- 3659 Gap Ack Blocks: 3661 These fields contain the Gap Ack Blocks. They are repeated for 3662 each Gap Ack Block up to the number of Gap Ack Blocks defined in 3663 the Number of Gap Ack Blocks field. All DATA chunks with TSNs 3664 greater than or equal to (Cumulative TSN Ack + Gap Ack Block 3665 Start) and less than or equal to (Cumulative TSN Ack + Gap Ack 3666 Block End) of each Gap Ack Block are assumed to have been received 3667 correctly. 3669 --------- 3670 New text: (Section 3.3.4) 3671 --------- 3673 Gap Ack Blocks: 3675 These fields contain the Gap Ack Blocks. They are repeated for 3676 each Gap Ack Block up to the number of Gap Ack Blocks defined in 3677 the Number of Gap Ack Blocks field. All DATA chunks with TSNs 3678 greater than or equal to (Cumulative TSN Ack + Gap Ack Block 3679 Start) and less than or equal to (Cumulative TSN Ack + Gap Ack 3680 Block End) of each Gap Ack Block are assumed to have been received 3681 correctly. Gap Ack Blocks SHOULD be isolated. That means that 3682 the DATA chunks with TSN equal to (Cumulative TSN Ack + Gap Ack 3683 Block Start - 1) and (Cumulative TSN Ack + Gap Ack Block End + 1) 3684 have not been received. 3686 3.47.3. Solution Description 3688 Normative text describing the intended usage of Gap Ack Blocks has 3689 been added. 3691 3.48. Handling of SSN Wrap Arounds 3693 3.48.1. Description of the Problem 3695 The Stream Sequence Number (SSN) is used for preserving the ordering 3696 of user messages within each SCTP stream. The SSN is limited to 16 3697 bits. Therefore, multiple wrap arounds of the SSN might happen 3698 within the current send window. To allow the receiver to deliver 3699 ordered user messages in the correct sequence, the sender should 3700 limit the number of user messages per stream. 3702 3.48.2. Text Changes to the Document 3704 --------- 3705 Old text: (Section 6.1) 3706 --------- 3708 Note: The data sender SHOULD NOT use a TSN that is more than 2**31 - 3709 1 above the beginning TSN of the current send window. 3711 --------- 3712 New text: (Section 6.1) 3713 --------- 3715 Note: The data sender SHOULD NOT use a TSN that is more than 2**31 - 3716 1 above the beginning TSN of the current send window. 3717 Note: For each stream, the data sender SHOULD NOT have more than 2**16-1 3718 ordered user messages in the current send window. 3720 3.48.3. Solution Description 3722 The data sender is required to limit the number of ordered user 3723 messages within the current send window. 3725 3.49. Update RFC 2119 Boilerplate 3727 3.49.1. Description of the Problem 3729 The text to be used to refer to the [RFC2119] terms has been updated 3730 by [RFC8174]. 3732 3.49.2. Text Changes to the Document 3734 --------- 3735 Old text: (Section 2) 3736 --------- 3738 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 3739 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 3740 document are to be interpreted as described in RFC 2119 [RFC2119]. 3742 --------- 3743 New text: (Section 2) 3744 --------- 3746 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 3747 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 3748 "OPTIONAL" in this document are to be interpreted as described in 3749 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 3750 capitals, as shown here. 3752 3.49.3. Solution Description 3754 The text has been updated to the one specified in [RFC8174]. 3756 3.50. Missed Text Removal 3758 3.50.1. Description of the Problem 3760 When integrating the changes to Section 7.2.4 of [RFC2960] as 3761 described in Section 2.8.2 of [RFC4460] some text was not removed and 3762 is therefore still in [RFC4960]. 3764 3.50.2. Text Changes to the Document 3766 --------- 3767 Old text: (Section 7.2.4) 3768 --------- 3770 A straightforward implementation of the above keeps a counter for 3771 each TSN hole reported by a SACK. The counter increments for each 3772 consecutive SACK reporting the TSN hole. After reaching 3 and 3773 starting the Fast-Retransmit procedure, the counter resets to 0. 3774 Because cwnd in SCTP indirectly bounds the number of outstanding 3775 TSN's, the effect of TCP Fast Recovery is achieved automatically with 3776 no adjustment to the congestion control window size. 3778 --------- 3779 New text: (Section 7.2.4) 3780 --------- 3782 3.50.3. Solution Description 3784 The text has finally been removed. 3786 4. IANA Considerations 3788 Section 3.44 of this document updates the port number registry for 3789 SCTP to be consistent with [RFC6335]. IANA is requested to review 3790 Section 3.44. 3792 5. Security Considerations 3794 This document does not add any security considerations to those given 3795 in [RFC4960]. 3797 6. Acknowledgments 3799 The authors wish to thank Pontus Andersson, Eric W. Biederman, 3800 Cedric Bonnet, Spencer Dawkins, Gorry Fairhurst, Peter Lei, Gyula 3801 Marosi, Lionel Morand, Jeff Morriss, Karen E. E. Nielsen, Tom 3802 Petch, Kacheong Poon, Julien Pourtet, Irene Ruengeler, Michael Welzl, 3803 and Qiaobing Xie for their invaluable comments. 3805 7. References 3806 7.1. Normative References 3808 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3809 Requirement Levels", BCP 14, RFC 2119, 3810 DOI 10.17487/RFC2119, March 1997, 3811 . 3813 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 3814 RFC 4960, DOI 10.17487/RFC4960, September 2007, 3815 . 3817 7.2. Informative References 3819 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 3820 Communication Layers", STD 3, RFC 1122, 3821 DOI 10.17487/RFC1122, October 1989, 3822 . 3824 [RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security 3825 Considerations for IP Fragment Filtering", RFC 1858, 3826 DOI 10.17487/RFC1858, October 1995, 3827 . 3829 [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., 3830 Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., 3831 Zhang, L., and V. Paxson, "Stream Control Transmission 3832 Protocol", RFC 2960, DOI 10.17487/RFC2960, October 2000, 3833 . 3835 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 3836 of Explicit Congestion Notification (ECN) to IP", 3837 RFC 3168, DOI 10.17487/RFC3168, September 2001, 3838 . 3840 [RFC4460] Stewart, R., Arias-Rodriguez, I., Poon, K., Caro, A., and 3841 M. Tuexen, "Stream Control Transmission Protocol (SCTP) 3842 Specification Errata and Issues", RFC 4460, 3843 DOI 10.17487/RFC4460, April 2006, 3844 . 3846 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 3847 Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, 3848 . 3850 [RFC6096] Tuexen, M. and R. Stewart, "Stream Control Transmission 3851 Protocol (SCTP) Chunk Flags Registration", RFC 6096, 3852 DOI 10.17487/RFC6096, January 2011, 3853 . 3855 [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, 3856 "Computing TCP's Retransmission Timer", RFC 6298, 3857 DOI 10.17487/RFC6298, June 2011, 3858 . 3860 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 3861 Cheshire, "Internet Assigned Numbers Authority (IANA) 3862 Procedures for the Management of the Service Name and 3863 Transport Protocol Port Number Registry", BCP 165, 3864 RFC 6335, DOI 10.17487/RFC6335, August 2011, 3865 . 3867 [RFC7053] Tuexen, M., Ruengeler, I., and R. Stewart, "SACK- 3868 IMMEDIATELY Extension for the Stream Control Transmission 3869 Protocol", RFC 7053, DOI 10.17487/RFC7053, November 2013, 3870 . 3872 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 3873 Writing an IANA Considerations Section in RFCs", BCP 26, 3874 RFC 8126, DOI 10.17487/RFC8126, June 2017, 3875 . 3877 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 3878 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 3879 May 2017, . 3881 [RFC8311] Black, D., "Relaxing Restrictions on Explicit Congestion 3882 Notification (ECN) Experimentation", RFC 8311, 3883 DOI 10.17487/RFC8311, January 2018, 3884 . 3886 Authors' Addresses 3888 Randall R. Stewart 3889 Netflix, Inc. 3890 Chapin, SC 29036 3891 United States 3893 Email: randall@lakerest.net 3895 Michael Tuexen 3896 Muenster University of Applied Sciences 3897 Stegerwaldstrasse 39 3898 48565 Steinfurt 3899 Germany 3901 Email: tuexen@fh-muenster.de 3902 Maksim Proshin 3903 Ericsson 3904 Kistavaegen 25 3905 Stockholm 164 80 3906 Sweden 3908 Email: mproshin@tieto.mera.ru