idnits 2.17.1 draft-ietf-tsvwg-rfc4960-errata-07.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 3169 has weird spacing: '...ed long crc_c...' == Line 3390 has weird spacing: '...ed long crc_c...' -- The document date (July 16, 2018) is 2111 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 2922, 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 746, but not defined -- Looks like a reference, but probably isn't: '256' on line 3169 ** 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: January 17, 2019 Muenster Univ. of Appl. Sciences 6 M. Proshin 7 Ericsson 8 July 16, 2018 10 RFC 4960 Errata and Issues 11 draft-ietf-tsvwg-rfc4960-errata-07.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 January 17, 2019. 42 Copyright Notice 44 Copyright (c) 2018 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Corrections to RFC 4960 . . . . . . . . . . . . . . . . . . . 4 62 3.1. Path Error Counter Threshold Handling . . . . . . . . . . 4 63 3.2. Upper Layer Protocol Shutdown Request Handling . . . . . 5 64 3.3. Registration of New Chunk Types . . . . . . . . . . . . . 6 65 3.4. Variable Parameters for INIT Chunks . . . . . . . . . . . 7 66 3.5. CRC32c Sample Code on 64-bit Platforms . . . . . . . . . 8 67 3.6. Endpoint Failure Detection . . . . . . . . . . . . . . . 9 68 3.7. Data Transmission Rules . . . . . . . . . . . . . . . . . 10 69 3.8. T1-Cookie Timer . . . . . . . . . . . . . . . . . . . . . 11 70 3.9. Miscellaneous Typos . . . . . . . . . . . . . . . . . . . 12 71 3.10. CRC32c Sample Code . . . . . . . . . . . . . . . . . . . 19 72 3.11. partial_bytes_acked after T3-rtx Expiration . . . . . . . 20 73 3.12. Order of Adjustments of partial_bytes_acked and cwnd . . 21 74 3.13. HEARTBEAT ACK and the association error counter . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . . . 87 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 One typo was reported as an Errata for [RFC4960] with Errata ID 5003. 488 3.9.2. Text Changes to the Document 489 --------- 490 Old text: (Section 1.6) 491 --------- 493 Transmission Sequence Numbers wrap around when they reach 2**32 - 1. 494 That is, the next TSN a DATA chunk MUST use after transmitting TSN = 495 2*32 - 1 is TSN = 0. 497 --------- 498 New text: (Section 1.6) 499 --------- 501 Transmission Sequence Numbers wrap around when they reach 2**32 - 1. 502 That is, the next TSN a DATA chunk MUST use after transmitting TSN = 503 2**32 - 1 is TSN = 0. 505 --------- 506 Old text: (Section 3.3.10.9) 507 --------- 509 No User Data: This error cause is returned to the originator of a 511 DATA chunk if a received DATA chunk has no user data. 513 --------- 514 New text: (Section 3.3.10.9) 515 --------- 517 No User Data: This error cause is returned to the originator of a 518 DATA chunk if a received DATA chunk has no user data. 520 --------- 521 Old text: (Section 6.7, Figure 9) 522 --------- 524 Endpoint A Endpoint Z {App 525 sends 3 messages; strm 0} DATA [TSN=6,Strm=0,Seq=2] ---------- 526 -----> (ack delayed) (Start T3-rtx timer) 528 DATA [TSN=7,Strm=0,Seq=3] --------> X (lost) 530 DATA [TSN=8,Strm=0,Seq=4] ---------------> (gap detected, 531 immediately send ack) 532 /----- SACK [TSN Ack=6,Block=1, 533 / Start=2,End=2] 534 <-----/ (remove 6 from out-queue, 535 and mark 7 as "1" missing report) 537 --------- 538 New text: (Section 6.7, Figure 9) 539 --------- 541 Endpoint A Endpoint Z 542 {App sends 3 messages; strm 0} 543 DATA [TSN=6,Strm=0,Seq=2] ---------------> (ack delayed) 544 (Start T3-rtx timer) 546 DATA [TSN=7,Strm=0,Seq=3] --------> X (lost) 548 DATA [TSN=8,Strm=0,Seq=4] ---------------> (gap detected, 549 immediately send ack) 550 /----- SACK [TSN Ack=6,Block=1, 551 / Start=2,End=2] 552 <-----/ 553 (remove 6 from out-queue, 554 and mark 7 as "1" missing report) 556 --------- 557 Old text: (Section 6.10) 558 --------- 560 An endpoint bundles chunks by simply including multiple chunks in one 561 outbound SCTP packet. The total size of the resultant IP datagram, 563 including the SCTP packet and IP headers, MUST be less that or equal 564 to the current Path MTU. 566 --------- 567 New text: (Section 6.10) 568 --------- 570 An endpoint bundles chunks by simply including multiple chunks in one 571 outbound SCTP packet. The total size of the resultant IP datagram, 572 including the SCTP packet and IP headers, MUST be less than or equal 573 to the current PMTU. 575 --------- 576 Old text: (Section 10.1) 577 --------- 579 o Receive Unacknowledged Message 581 Format: RECEIVE_UNACKED(data retrieval id, buffer address, buffer 582 size, [,stream id] [, stream sequence number] [,partial 583 flag] [,payload protocol-id]) 585 --------- 586 New text: (Section 10.1) 587 --------- 589 O) Receive Unacknowledged Message 591 Format: RECEIVE_UNACKED(data retrieval id, buffer address, buffer 592 size [,stream id] [,stream sequence number] [,partial 593 flag] [,payload protocol-id]) 595 --------- 596 Old text: (Section 10.1) 597 --------- 599 M) Set Protocol Parameters 601 Format: SETPROTOCOLPARAMETERS(association id, 602 [,destination transport address,] 603 protocol parameter list) 605 --------- 606 New text: (Section 10.1) 607 --------- 609 M) Set Protocol Parameters 611 Format: SETPROTOCOLPARAMETERS(association id, 612 [destination transport address,] 613 protocol parameter list) 615 --------- 616 Old text: (Appendix C) 617 --------- 619 ICMP2) An implementation MAY ignore all ICMPv6 messages where the 620 type field is not "Destination Unreachable", "Parameter 621 Problem",, or "Packet Too Big". 623 --------- 624 New text: (Appendix C) 625 --------- 627 ICMP2) An implementation MAY ignore all ICMPv6 messages where the 628 type field is not "Destination Unreachable", "Parameter 629 Problem", or "Packet Too Big". 631 --------- 632 Old text: (Appendix C) 633 --------- 635 ICMP7) If the ICMP message is either a v6 "Packet Too Big" or a v4 636 "Fragmentation Needed", an implementation MAY process this 637 information as defined for PATH MTU discovery. 639 --------- 640 New text: (Appendix C) 641 --------- 643 ICMP7) If the ICMP message is either a v6 "Packet Too Big" or a v4 644 "Fragmentation Needed", an implementation MAY process this 645 information as defined for PMTU discovery. 647 --------- 648 Old text: (Section 5.4) 649 --------- 651 2) For the receiver of the COOKIE ECHO, the only CONFIRMED address 652 is the one to which the INIT-ACK was sent. 654 --------- 655 New text: (Section 5.4) 656 --------- 658 2) For the receiver of the COOKIE ECHO, the only CONFIRMED address 659 is the one to which the INIT ACK was sent. 661 --------- 662 Old text: (Section 5.1.6, Figure 4) 663 --------- 665 COOKIE ECHO [Cookie_Z] ------\ 666 (Start T1-init timer) \ 667 (Enter COOKIE-ECHOED state) \---> (build TCB enter ESTABLISHED 668 state) 669 /---- COOKIE-ACK 670 / 671 (Cancel T1-init timer, <-----/ 672 Enter ESTABLISHED state) 674 --------- 675 New text: (Section 5.1.6, Figure 4) 676 --------- 678 COOKIE ECHO [Cookie_Z] ------\ 679 (Start T1-cookie timer) \ 680 (Enter COOKIE-ECHOED state) \---> (build TCB enter ESTABLISHED 681 state) 682 /---- COOKIE ACK 683 / 684 (Cancel T1-cookie timer, <---/ 685 Enter ESTABLISHED state) 687 --------- 688 Old text: (Section 5.2.5) 689 --------- 691 5.2.5. Handle Duplicate COOKIE-ACK. 693 --------- 694 New text: (Section 5.2.5) 695 --------- 697 5.2.5. Handle Duplicate COOKIE ACK. 699 --------- 700 Old text: (Section 8.3) 701 --------- 703 By default, an SCTP endpoint SHOULD monitor the reachability of the 704 idle destination transport address(es) of its peer by sending a 705 HEARTBEAT chunk periodically to the destination transport 706 address(es). HEARTBEAT sending MAY begin upon reaching the 707 ESTABLISHED state and is discontinued after sending either SHUTDOWN 708 or SHUTDOWN-ACK. A receiver of a HEARTBEAT MUST respond to a 709 HEARTBEAT with a HEARTBEAT-ACK after entering the COOKIE-ECHOED state 710 (INIT sender) or the ESTABLISHED state (INIT receiver), up until 711 reaching the SHUTDOWN-SENT state (SHUTDOWN sender) or the SHUTDOWN- 712 ACK-SENT state (SHUTDOWN receiver). 714 --------- 715 New text: (Section 8.3) 716 --------- 717 By default, an SCTP endpoint SHOULD monitor the reachability of the 718 idle destination transport address(es) of its peer by sending a 719 HEARTBEAT chunk periodically to the destination transport 720 address(es). HEARTBEAT sending MAY begin upon reaching the 721 ESTABLISHED state and is discontinued after sending either SHUTDOWN 722 or SHUTDOWN ACK. A receiver of a HEARTBEAT MUST respond to a 723 HEARTBEAT with a HEARTBEAT ACK after entering the COOKIE-ECHOED state 724 (INIT sender) or the ESTABLISHED state (INIT receiver), up until 725 reaching the SHUTDOWN-SENT state (SHUTDOWN sender) or the SHUTDOWN- 726 ACK-SENT state (SHUTDOWN receiver). 728 3.9.3. Solution Description 730 Typos fixed. 732 3.10. CRC32c Sample Code 734 3.10.1. Description of the Problem 736 The CRC32c computation is described in Appendix B of [RFC4960]. 737 However, the corresponding sample code and its explanation appears at 738 the end of Appendix C, which deals with ICMP handling. 740 3.10.2. Text Changes to the Document 742 Move all of Appendix C starting with the following sentence to the 743 end of Appendix B. 745 The following non-normative sample code is taken from an open-source 746 CRC generator [WILLIAMS93], using the "mirroring" technique and 747 yielding a lookup table for SCTP CRC32c with 256 entries, each 32 748 bits wide. 750 3.10.3. Solution Description 752 Text moved to the appropriate location. 754 3.11. partial_bytes_acked after T3-rtx Expiration 756 3.11.1. Description of the Problem 758 Section 7.2.3 of [RFC4960] explicitly states that partial_bytes_acked 759 should be reset to 0 after packet loss detection from SACK but the 760 same is missed for T3-rtx timer expiration. 762 3.11.2. Text Changes to the Document 764 --------- 765 Old text: (Section 7.2.3) 766 --------- 768 When the T3-rtx timer expires on an address, SCTP should perform slow 769 start by: 771 ssthresh = max(cwnd/2, 4*MTU) 772 cwnd = 1*MTU 774 --------- 775 New text: (Section 7.2.3) 776 --------- 778 When the T3-rtx timer expires on an address, SCTP SHOULD perform slow 779 start by: 781 ssthresh = max(cwnd/2, 4*MTU) 782 cwnd = 1*MTU 783 partial_bytes_acked = 0 785 3.11.3. Solution Description 787 Specify that partial_bytes_acked should be reset to 0 after T3-rtx 788 timer expiration. 790 3.12. Order of Adjustments of partial_bytes_acked and cwnd 792 3.12.1. Description of the Problem 794 Section 7.2.2 of [RFC4960] likely implies the wrong order of 795 adjustments applied to partial_bytes_acked and cwnd in the congestion 796 avoidance phase. 798 3.12.2. Text Changes to the Document 800 --------- 801 Old text: (Section 7.2.2) 802 --------- 804 o When partial_bytes_acked is equal to or greater than cwnd and 805 before the arrival of the SACK the sender had cwnd or more bytes 806 of data outstanding (i.e., before arrival of the SACK, flightsize 807 was greater than or equal to cwnd), increase cwnd by MTU, and 808 reset partial_bytes_acked to (partial_bytes_acked - cwnd). 810 --------- 811 New text: (Section 7.2.2) 812 --------- 814 o When partial_bytes_acked is equal to or greater than cwnd and 815 before the arrival of the SACK the sender had cwnd or more bytes 816 of data outstanding (i.e., before arrival of the SACK, flightsize 817 was greater than or equal to cwnd), partial_bytes_acked is reset 818 to (partial_bytes_acked - cwnd). Next, cwnd is increased by 1*MTU. 820 3.12.3. Solution Description 822 The new text defines the exact order of adjustments of 823 partial_bytes_acked and cwnd in the congestion avoidance phase. 825 3.13. HEARTBEAT ACK and the association error counter 827 3.13.1. Description of the Problem 829 Section 8.1 and Section 8.3 of [RFC4960] prescribe that the receiver 830 of a HEARTBEAT ACK must reset the association overall error counter. 831 In some circumstances, e.g. when a router discards DATA chunks but 832 not HEARTBEAT chunks due to the larger size of the DATA chunk, it 833 might be better to not clear the association error counter on 834 reception of the HEARTBEAT ACK and reset it only on reception of the 835 SACK to avoid stalling the association. 837 3.13.2. Text Changes to the Document 839 --------- 840 Old text: (Section 8.1) 841 --------- 843 The counter shall be reset each time a DATA chunk sent to that peer 844 endpoint is acknowledged (by the reception of a SACK) or a HEARTBEAT 845 ACK is received from the peer endpoint. 847 --------- 848 New text: (Section 8.1) 849 --------- 851 The counter MUST be reset each time a DATA chunk sent to that peer 852 endpoint is acknowledged (by the reception of a SACK). When a 853 HEARTBEAT ACK is received from the peer endpoint, the counter SHOULD 854 also be reset. The receiver of the HEARTBEAT ACK MAY choose not to 855 clear the counter if there is outstanding data on the association. 856 This allows for handling the possible difference in reachability 857 based on DATA chunks and HEARTBEAT chunks. 859 --------- 860 Old text: (Section 8.3) 861 --------- 863 Upon the receipt of the HEARTBEAT ACK, the sender of the HEARTBEAT 864 should clear the error counter of the destination transport address 865 to which the HEARTBEAT was sent, and mark the destination transport 866 address as active if it is not so marked. The endpoint may 867 optionally report to the upper layer when an inactive destination 868 address is marked as active due to the reception of the latest 869 HEARTBEAT ACK. The receiver of the HEARTBEAT ACK must also clear the 870 association overall error count as well (as defined in Section 8.1). 872 --------- 873 New text: (Section 8.3) 874 --------- 876 Upon the receipt of the HEARTBEAT ACK, the sender of the HEARTBEAT 877 MUST clear the error counter of the destination transport address 878 to which the HEARTBEAT was sent, and mark the destination transport 879 address as active if it is not so marked. The endpoint MAY 880 optionally report to the upper layer when an inactive destination 881 address is marked as active due to the reception of the latest 882 HEARTBEAT ACK. The receiver of the HEARTBEAT ACK SHOULD also clear 883 the association overall error counter (as defined in Section 8.1). 885 3.13.3. Solution Description 887 The new text provides a possibility to not reset the association 888 overall error counter when a HEARTBEAT ACK is received if there are 889 valid reasons for it. 891 3.14. Path for Fast Retransmission 893 3.14.1. Description of the Problem 895 [RFC4960] clearly describes where to retransmit data that is timed 896 out when the peer is multi-homed but the same is not stated for fast 897 retransmissions. 899 3.14.2. Text Changes to the Document 901 --------- 902 Old text: (Section 6.4) 903 --------- 905 Furthermore, when its peer is multi-homed, an endpoint SHOULD try to 906 retransmit a chunk that timed out to an active destination transport 907 address that is different from the last destination address to which 908 the DATA chunk was sent. 910 --------- 911 New text: (Section 6.4) 912 --------- 914 Furthermore, when its peer is multi-homed, an endpoint SHOULD try to 915 retransmit a chunk that timed out to an active destination transport 916 address that is different from the last destination address to which 917 the DATA chunk was sent. 919 When its peer is multi-homed, an endpoint SHOULD send fast 920 retransmissions to the same destination transport address where the 921 original data was sent to. If the primary path has been changed and the 922 original data was sent to the old primary path before the fast 923 retransmit, the implementation MAY send it to the new primary path. 925 3.14.3. Solution Description 927 The new text clarifies where to send fast retransmissions. 929 3.15. Transmittal in Fast Recovery 931 3.15.1. Description of the Problem 933 The Fast Retransmit on Gap Reports algorithm intends that only the 934 very first packet may be sent regardless of cwnd in the Fast Recovery 935 phase but rule 3) of [RFC4960], Section 7.2.4, misses this 936 clarification. 938 3.15.2. Text Changes to the Document 940 --------- 941 Old text: (Section 7.2.4) 942 --------- 944 3) Determine how many of the earliest (i.e., lowest TSN) DATA chunks 945 marked for retransmission will fit into a single packet, subject 946 to constraint of the path MTU of the destination transport 947 address to which the packet is being sent. Call this value K. 948 Retransmit those K DATA chunks in a single packet. When a Fast 949 Retransmit is being performed, the sender SHOULD ignore the value 950 of cwnd and SHOULD NOT delay retransmission for this single 951 packet. 953 --------- 954 New text: (Section 7.2.4) 955 --------- 957 3) If not in Fast Recovery, determine how many of the earliest 958 (i.e., lowest TSN) DATA chunks marked for retransmission will fit 959 into a single packet, subject to constraint of the PMTU of 960 the destination transport address to which the packet is being 961 sent. Call this value K. Retransmit those K DATA chunks in a 962 single packet. When a Fast Retransmit is being performed, the 963 sender SHOULD ignore the value of cwnd and SHOULD NOT delay 964 retransmission for this single packet. 966 3.15.3. Solution Description 968 The new text explicitly specifies to send only the first packet in 969 the Fast Recovery phase disregarding cwnd limitations. 971 3.16. Initial Value of ssthresh 972 3.16.1. Description of the Problem 974 The initial value of ssthresh should be set arbitrarily high. Using 975 the advertised receiver window of the peer is inappropriate if the 976 peer increases its window after the handshake. Furthermore, use a 977 higher requirements level, since not following the advice may result 978 in performance problems. 980 3.16.2. Text Changes to the Document 982 --------- 983 Old text: (Section 7.2.1) 984 --------- 986 o The initial value of ssthresh MAY be arbitrarily high (for 987 example, implementations MAY use the size of the receiver 988 advertised window). 990 --------- 991 New text: (Section 7.2.1) 992 --------- 994 o The initial value of ssthresh SHOULD be arbitrarily high (e.g., 995 the size of the largest possible advertised window). 997 3.16.3. Solution Description 999 Use the same value as suggested in [RFC5681], Section 3.1, as an 1000 appropriate initial value. Furthermore, use the same requirements 1001 level. 1003 3.17. Automatically Confirmed Addresses 1005 3.17.1. Description of the Problem 1007 The Path Verification procedure of [RFC4960] prescribes that any 1008 address passed to the sender of the INIT by its upper layer is 1009 automatically CONFIRMED. This, however, is unclear if only addresses 1010 in the request to initiate association establishment are considered 1011 or any addresses provided by the upper layer in any requests (e.g. in 1012 'Set Primary'). 1014 3.17.2. Text Changes to the Document 1015 --------- 1016 Old text: (Section 5.4) 1017 --------- 1019 1) Any address passed to the sender of the INIT by its upper layer 1020 is automatically considered to be CONFIRMED. 1022 --------- 1023 New text: (Section 5.4) 1024 --------- 1026 1) Any addresses passed to the sender of the INIT by its upper 1027 layer in the request to initialize an association are 1028 automatically considered to be CONFIRMED. 1030 3.17.3. Solution Description 1032 The new text clarifies that only addresses provided by the upper 1033 layer in the request to initialize an association are automatically 1034 confirmed. 1036 3.18. Only One Packet after Retransmission Timeout 1038 3.18.1. Description of the Problem 1040 [RFC4960] is not completely clear when it describes data transmission 1041 after T3-rtx timer expiration. Section 7.2.1 does not specify how 1042 many packets are allowed to be sent after T3-rtx timer expiration if 1043 more than one packet fit into cwnd. At the same time, Section 7.2.3 1044 has the text without normative language saying that SCTP should 1045 ensure that no more than one packet will be in flight after T3-rtx 1046 timer expiration until successful acknowledgment. It makes the text 1047 inconsistent. 1049 3.18.2. Text Changes to the Document 1050 --------- 1051 Old text: (Section 7.2.1) 1052 --------- 1054 o The initial cwnd after a retransmission timeout MUST be no more 1055 than 1*MTU. 1057 --------- 1058 New text: (Section 7.2.1) 1059 --------- 1061 o The initial cwnd after a retransmission timeout MUST be no more 1062 than 1*MTU and only one packet is allowed to be in flight 1063 until successful acknowledgement. 1065 3.18.3. Solution Description 1067 The new text clearly specifies that only one packet is allowed to be 1068 sent after T3-rtx timer expiration until successful acknowledgement. 1070 3.19. INIT ACK Path for INIT in COOKIE-WAIT State 1072 3.19.1. Description of the Problem 1074 In case of an INIT received in the COOKIE-WAIT state [RFC4960] 1075 prescribes to send an INIT ACK to the same destination address to 1076 which the original INIT has been sent. This text does not address 1077 the possibility of the upper layer to provide multiple remote IP 1078 addresses while requesting the association establishment. If the 1079 upper layer has provided multiple IP addresses and only a subset of 1080 these addresses are supported by the peer then the destination 1081 address of the original INIT may be absent in the incoming INIT and 1082 sending INIT ACK to that address is useless. 1084 3.19.2. Text Changes to the Document 1085 --------- 1086 Old text: (Section 5.2.1) 1087 --------- 1089 Upon receipt of an INIT in the COOKIE-WAIT state, an endpoint MUST 1090 respond with an INIT ACK using the same parameters it sent in its 1091 original INIT chunk (including its Initiate Tag, unchanged). When 1092 responding, the endpoint MUST send the INIT ACK back to the same 1093 address that the original INIT (sent by this endpoint) was sent. 1095 --------- 1096 New text: (Section 5.2.1) 1097 --------- 1099 Upon receipt of an INIT in the COOKIE-WAIT state, an endpoint MUST 1100 respond with an INIT ACK using the same parameters it sent in its 1101 original INIT chunk (including its Initiate Tag, unchanged). When 1102 responding, the following rules MUST be applied: 1104 1) The INIT ACK MUST only be sent to an address passed by the upper 1105 layer in the request to initialize the association. 1107 2) The INIT ACK MUST only be sent to an address reported in the 1108 incoming INIT. 1110 3) The INIT ACK SHOULD be sent to the source address of the 1111 received INIT. 1113 3.19.3. Solution Description 1115 The new text requires sending INIT ACK to a destination address that 1116 is passed by the upper layer and reported in the incoming INIT. If 1117 the source address of the INIT meets these conditions, sending the 1118 INIT ACK to the source address of the INIT is the preferred behavior. 1120 3.20. Zero Window Probing and Unreachable Primary Path 1122 3.20.1. Description of the Problem 1124 Section 6.1 of [RFC4960] states that when sending zero window probes, 1125 SCTP should neither increment the association counter nor increment 1126 the destination address error counter if it continues to receive new 1127 packets from the peer. However, the reception of new packets from 1128 the peer does not guarantee the peer's reachability and, if the 1129 destination address becomes unreachable during zero window probing, 1130 SCTP cannot get an updated rwnd until it switches the destination 1131 address for probes. 1133 3.20.2. Text Changes to the Document 1135 --------- 1136 Old text: (Section 6.1) 1137 --------- 1139 If the sender continues to receive new packets from the receiver 1140 while doing zero window probing, the unacknowledged window probes 1141 should not increment the error counter for the association or any 1142 destination transport address. This is because the receiver MAY 1143 keep its window closed for an indefinite time. Refer to Section 1144 6.2 on the receiver behavior when it advertises a zero window. 1146 --------- 1147 New text: (Section 6.1) 1148 --------- 1150 If the sender continues to receive SACKs from the peer 1151 while doing zero window probing, the unacknowledged window probes 1152 SHOULD NOT increment the error counter for the association or any 1153 destination transport address. This is because the receiver could 1154 keep its window closed for an indefinite time. Section 6.2 describes 1155 the receiver behavior when it advertises a zero window. 1157 3.20.3. Solution Description 1159 The new text clarifies that if the receiver continues to send SACKs, 1160 the sender of probes should not increment the error counter of the 1161 association and the destination address even if the SACKs do not 1162 acknowledge the probes. 1164 3.21. Normative Language in Section 10 1166 3.21.1. Description of the Problem 1168 Section 10 of [RFC4960] is informative and, therefore, normative 1169 language such as MUST and MAY cannot be used there. However, there 1170 are several places in Section 10 where MUST and MAY are used. 1172 3.21.2. Text Changes to the Document 1174 --------- 1175 Old text: (Section 10.1) 1176 --------- 1178 E) Send 1180 Format: SEND(association id, buffer address, byte count [,context] 1182 [,stream id] [,life time] [,destination transport address] 1183 [,unordered flag] [,no-bundle flag] [,payload protocol-id] ) 1184 -> result 1186 ... 1188 o no-bundle flag - instructs SCTP not to bundle this user data with 1189 other outbound DATA chunks. SCTP MAY still bundle even when this 1190 flag is present, when faced with network congestion. 1192 --------- 1193 New text: (Section 10.1) 1194 --------- 1196 E) Send 1198 Format: SEND(association id, buffer address, byte count [,context] 1199 [,stream id] [,life time] [,destination transport address] 1200 [,unordered flag] [,no-bundle flag] [,payload protocol-id] ) 1201 -> result 1203 ... 1205 o no-bundle flag - instructs SCTP not to bundle this user data with 1206 other outbound DATA chunks. SCTP may still bundle even when this 1207 flag is present, when faced with network congestion. 1209 --------- 1210 Old text: (Section 10.1) 1211 --------- 1213 G) Receive 1215 Format: RECEIVE(association id, buffer address, buffer size 1216 [,stream id]) 1217 -> byte count [,transport address] [,stream id] [,stream sequence 1218 number] [,partial flag] [,delivery number] [,payload protocol-id] 1220 ... 1222 o Stream Sequence Number - the Stream Sequence Number assigned by 1223 the sending SCTP peer. 1225 o partial flag - if this returned flag is set to 1, then this 1226 Receive contains a partial delivery of the whole message. When 1227 this flag is set, the stream id and Stream Sequence Number MUST 1228 accompany this receive. When this flag is set to 0, it indicates 1229 that no more deliveries will be received for this Stream Sequence 1230 Number. 1232 --------- 1233 New text: (Section 10.1) 1234 --------- 1236 G) Receive 1238 Format: RECEIVE(association id, buffer address, buffer size 1239 [,stream id]) 1240 -> byte count [,transport address] [,stream id] [,stream sequence 1241 number] [,partial flag] [,delivery number] [,payload protocol-id] 1243 ... 1245 o stream sequence number - the Stream Sequence Number assigned by 1246 the sending SCTP peer. 1248 o partial flag - if this returned flag is set to 1, then this 1249 primitive contains a partial delivery of the whole message. When 1250 this flag is set, the stream id and stream sequence number must 1251 accompany this primitive. When this flag is set to 0, it indicates 1252 that no more deliveries will be received for this stream sequence 1253 number. 1255 --------- 1256 Old text: (Section 10.1) 1257 --------- 1259 N) Receive Unsent Message 1261 Format: RECEIVE_UNSENT(data retrieval id, buffer address, buffer 1262 size [,stream id] [, stream sequence number] [,partial 1263 flag] [,payload protocol-id]) 1265 ... 1267 o Stream Sequence Number - this value is returned indicating the 1268 Stream Sequence Number that was associated with the message. 1270 o partial flag - if this returned flag is set to 1, then this 1271 message is a partial delivery of the whole message. When this 1272 flag is set, the stream id and Stream Sequence Number MUST 1273 accompany this receive. When this flag is set to 0, it indicates 1274 that no more deliveries will be received for this Stream Sequence 1275 Number. 1277 --------- 1278 New text: (Section 10.1) 1279 --------- 1281 N) Receive Unsent Message 1283 Format: RECEIVE_UNSENT(data retrieval id, buffer address, buffer 1284 size [,stream id] [, stream sequence number] [,partial 1285 flag] [,payload protocol-id]) 1287 ... 1289 o stream sequence number - this value is returned indicating the 1290 Stream Sequence Number that was associated with the message. 1292 o partial flag - if this returned flag is set to 1, then this 1293 message is a partial delivery of the whole message. When this 1294 flag is set, the stream id and stream sequence number must 1295 accompany this primitive. When this flag is set to 0, it indicates 1296 that no more deliveries will be received for this stream sequence 1297 number. 1299 --------- 1300 Old text: (Section 10.1) 1301 --------- 1303 O) Receive Unacknowledged Message 1305 Format: RECEIVE_UNACKED(data retrieval id, buffer address, buffer 1306 size [,stream id] [,stream sequence number] [,partial 1307 flag] [,payload protocol-id]) 1309 ... 1311 o Stream Sequence Number - this value is returned indicating the 1312 Stream Sequence Number that was associated with the message. 1314 o partial flag - if this returned flag is set to 1, then this 1315 message is a partial delivery of the whole message. When this 1316 flag is set, the stream id and Stream Sequence Number MUST 1317 accompany this receive. When this flag is set to 0, it indicates 1318 that no more deliveries will be received for this Stream Sequence 1319 Number. 1321 --------- 1322 New text: (Section 10.1) 1323 --------- 1325 O) Receive Unacknowledged Message 1326 Format: RECEIVE_UNACKED(data retrieval id, buffer address, buffer 1327 size [,stream id] [,stream sequence number] [,partial 1328 flag] [,payload protocol-id]) 1330 ... 1332 o stream sequence number - this value is returned indicating the 1333 Stream Sequence Number that was associated with the message. 1335 o partial flag - if this returned flag is set to 1, then this 1336 message is a partial delivery of the whole message. When this 1337 flag is set, the stream id and stream sequence number must 1338 accompany this primitive. When this flag is set to 0, it indicates 1339 that no more deliveries will be received for this stream sequence 1340 number. 1342 3.21.3. Solution Description 1344 The normative language is removed from Section 10. In addition, the 1345 consistency of the text has been improved. 1347 3.22. Increase of partial_bytes_acked in Congestion Avoidance 1349 3.22.1. Description of the Problem 1351 Two issues have been discovered with the partial_bytes_acked handling 1352 described in Section 7.2.2 of [RFC4960]: 1354 o If the Cumulative TSN Ack Point is not advanced but the SACK chunk 1355 acknowledges new TSNs in the Gap Ack Blocks, these newly 1356 acknowledged TSNs are not considered for partial_bytes_acked 1357 although these TSNs were successfully received by the peer. 1358 o Duplicate TSNs are not considered in partial_bytes_acked although 1359 they confirm that the DATA chunks were successfully received by 1360 the peer. 1362 3.22.2. Text Changes to the Document 1363 --------- 1364 Old text: (Section 7.2.2) 1365 --------- 1367 o Whenever cwnd is greater than ssthresh, upon each SACK arrival 1368 that advances the Cumulative TSN Ack Point, increase 1369 partial_bytes_acked by the total number of bytes of all new chunks 1370 acknowledged in that SACK including chunks acknowledged by the new 1371 Cumulative TSN Ack and by Gap Ack Blocks. 1373 --------- 1374 New text: (Section 7.2.2) 1375 --------- 1377 o Whenever cwnd is greater than ssthresh, upon each SACK arrival, 1378 increase partial_bytes_acked by the total number of bytes of all 1379 new chunks acknowledged in that SACK including chunks acknowledged 1380 by the new Cumulative TSN Ack, by Gap Ack Blocks and by the number 1381 of bytes of duplicated chunks reported in Duplicate TSNs. 1383 3.22.3. Solution Description 1385 Now partial_bytes_acked is increased by TSNs reported as duplicated 1386 as well as TSNs newly acknowledged in Gap Ack Blocks even if the 1387 Cumulative TSN Ack Point is not advanced. 1389 3.23. Inconsistency in Notifications Handling 1391 3.23.1. Description of the Problem 1393 [RFC4960] uses inconsistent normative and non-normative language when 1394 describing rules for sending notifications to the upper layer. E.g. 1395 Section 8.2 of [RFC4960] says that when a destination address becomes 1396 inactive due to an unacknowledged DATA chunk or HEARTBEAT chunk, SCTP 1397 SHOULD send a notification to the upper layer while Section 8.3 of 1398 [RFC4960] says that when a destination address becomes inactive due 1399 to an unacknowledged HEARTBEAT chunk, SCTP may send a notification to 1400 the upper layer. 1402 This makes the text inconsistent. 1404 3.23.2. Text Changes to the Document 1406 The following change is based on the change described in Section 3.6. 1408 --------- 1409 Old text: (Section 8.1) 1410 --------- 1412 An endpoint shall keep a counter on the total number of consecutive 1413 retransmissions to its peer (this includes data retransmissions 1414 to all the destination transport addresses of the peer if it is 1415 multi-homed), including the number of unacknowledged HEARTBEAT 1416 chunks observed on the path which currently is used for data 1417 transfer. Unacknowledged HEARTBEAT chunks observed on paths 1418 different from the path currently used for data transfer shall 1419 not increment the association error counter, as this could lead 1420 to association closure even if the path which currently is used for 1421 data transfer is available (but idle). If the value of this 1422 counter exceeds the limit indicated in the protocol parameter 1423 'Association.Max.Retrans', the endpoint shall consider the peer 1424 endpoint unreachable and shall stop transmitting any more data to it 1425 (and thus the association enters the CLOSED state). In addition, the 1426 endpoint MAY report the failure to the upper layer and optionally 1427 report back all outstanding user data remaining in its outbound 1428 queue. The association is automatically closed when the peer 1429 endpoint becomes unreachable. 1431 --------- 1432 New text: (Section 8.1) 1433 --------- 1435 An endpoint SHOULD keep a counter on the total number of consecutive 1436 retransmissions to its peer (this includes data retransmissions 1437 to all the destination transport addresses of the peer if it is 1438 multi-homed), including the number of unacknowledged HEARTBEAT 1439 chunks observed on the path which currently is used for data 1440 transfer. Unacknowledged HEARTBEAT chunks observed on paths 1441 different from the path currently used for data transfer SHOULD 1442 NOT increment the association error counter, as this could lead 1443 to association closure even if the path which currently is used for 1444 data transfer is available (but idle). If the value of this 1445 counter exceeds the limit indicated in the protocol parameter 1446 'Association.Max.Retrans', the endpoint SHOULD consider the peer 1447 endpoint unreachable and SHALL stop transmitting any more data to it 1448 (and thus the association enters the CLOSED state). In addition, the 1449 endpoint SHOULD report the failure to the upper layer and optionally 1450 report back all outstanding user data remaining in its outbound 1451 queue. The association is automatically closed when the peer 1452 endpoint becomes unreachable. 1454 The following changes are based on [RFC4960]. 1456 --------- 1457 Old text: (Section 8.2) 1458 --------- 1460 When an outstanding TSN is acknowledged or a HEARTBEAT sent to that 1461 address is acknowledged with a HEARTBEAT ACK, the endpoint shall 1462 clear the error counter of the destination transport address to which 1463 the DATA chunk was last sent (or HEARTBEAT was sent). When the peer 1464 endpoint is multi-homed and the last chunk sent to it was a 1465 retransmission to an alternate address, there exists an ambiguity as 1466 to whether or not the acknowledgement should be credited to the 1467 address of the last chunk sent. However, this ambiguity does not 1468 seem to bear any significant consequence to SCTP behavior. If this 1469 ambiguity is undesirable, the transmitter may choose not to clear the 1470 error counter if the last chunk sent was a retransmission. 1472 --------- 1473 New text: (Section 8.2) 1474 --------- 1476 When an outstanding TSN is acknowledged or a HEARTBEAT sent to that 1477 address is acknowledged with a HEARTBEAT ACK, the endpoint SHOULD 1478 clear the error counter of the destination transport address to which 1479 the DATA chunk was last sent (or HEARTBEAT was sent), and SHOULD 1480 also report to the upper layer when an inactive destination address 1481 is marked as active. When the peer endpoint is multi-homed and the 1482 last chunk sent to it was a retransmission to an alternate address, 1483 there exists an ambiguity as to whether or not the acknowledgement 1484 could be credited to the address of the last chunk sent. However, 1485 this ambiguity does not seem to bear any significant consequence to 1486 SCTP behavior. If this ambiguity is undesirable, the transmitter MAY 1487 choose not to clear the error counter if the last chunk sent was a 1488 retransmission. 1490 --------- 1491 Old text: (Section 8.3) 1492 --------- 1494 When the value of this counter reaches the protocol parameter 1495 'Path.Max.Retrans', the endpoint should mark the corresponding 1496 destination address as inactive if it is not so marked, and may also 1497 optionally report to the upper layer the change of reachability of 1498 this destination address. After this, the endpoint should continue 1499 HEARTBEAT on this destination address but should stop increasing the 1500 counter. 1502 --------- 1503 New text: (Section 8.3) 1504 --------- 1506 When the value of this counter exceeds the protocol parameter 1507 'Path.Max.Retrans', the endpoint SHOULD mark the corresponding 1508 destination address as inactive if it is not so marked, and SHOULD 1509 also report to the upper layer the change of reachability of this 1510 destination address. After this, the endpoint SHOULD continue 1511 HEARTBEAT on this destination address but SHOULD stop increasing the 1512 counter. 1514 --------- 1515 Old text: (Section 8.3) 1516 --------- 1518 Upon the receipt of the HEARTBEAT ACK, the sender of the HEARTBEAT 1519 should clear the error counter of the destination transport address 1520 to which the HEARTBEAT was sent, and mark the destination transport 1521 address as active if it is not so marked. The endpoint may 1522 optionally report to the upper layer when an inactive destination 1523 address is marked as active due to the reception of the latest 1524 HEARTBEAT ACK. The receiver of the HEARTBEAT ACK must also clear the 1525 association overall error count as well (as defined in Section 8.1). 1527 --------- 1528 New text: (Section 8.3) 1529 --------- 1531 Upon the receipt of the HEARTBEAT ACK, the sender of the HEARTBEAT 1532 SHOULD clear the error counter of the destination transport address 1533 to which the HEARTBEAT was sent, and mark the destination transport 1534 address as active if it is not so marked. The endpoint SHOULD 1535 report to the upper layer when an inactive destination address 1536 is marked as active due to the reception of the latest 1537 HEARTBEAT ACK. The receiver of the HEARTBEAT ACK SHOULD also clear 1538 the association overall error counter (as defined in Section 8.1). 1540 --------- 1541 Old text: (Section 9.2) 1542 --------- 1544 An endpoint should limit the number of retransmissions of the 1545 SHUTDOWN chunk to the protocol parameter 'Association.Max.Retrans'. 1546 If this threshold is exceeded, the endpoint should destroy the TCB 1547 and MUST report the peer endpoint unreachable to the upper layer (and 1548 thus the association enters the CLOSED state). 1550 --------- 1551 New text: (Section 9.2) 1552 --------- 1554 An endpoint SHOULD limit the number of retransmissions of the 1555 SHUTDOWN chunk to the protocol parameter 'Association.Max.Retrans'. 1556 If this threshold is exceeded, the endpoint SHOULD destroy the TCB 1557 and SHOULD report the peer endpoint unreachable to the upper layer 1558 (and thus the association enters the CLOSED state). 1560 --------- 1561 Old text: (Section 9.2) 1562 --------- 1564 The sender of the SHUTDOWN ACK should limit the number of 1565 retransmissions of the SHUTDOWN ACK chunk to the protocol parameter 1566 'Association.Max.Retrans'. If this threshold is exceeded, the 1567 endpoint should destroy the TCB and may report the peer endpoint 1568 unreachable to the upper layer (and thus the association enters the 1569 CLOSED state). 1571 --------- 1572 New text: (Section 9.2) 1573 --------- 1575 The sender of the SHUTDOWN ACK SHOULD limit the number of 1576 retransmissions of the SHUTDOWN ACK chunk to the protocol parameter 1577 'Association.Max.Retrans'. If this threshold is exceeded, the 1578 endpoint SHOULD destroy the TCB and SHOULD report the peer endpoint 1579 unreachable to the upper layer (and thus the association enters the 1580 CLOSED state). 1582 3.23.3. Solution Description 1584 The inconsistencies are removed by using consistently SHOULD. 1586 3.24. SACK.Delay Not Listed as a Protocol Parameter 1588 3.24.1. Description of the Problem 1590 SCTP as specified in [RFC4960] supports delaying SACKs. The timer 1591 value for this is a parameter and Section 6.2 of [RFC4960] specifies 1592 a default and maximum value for it. However, defining a name for 1593 this parameter and listing it in the table of protocol parameters in 1594 Section 15 of [RFC4960] is missing. 1596 This issue was reported as an Errata for [RFC4960] with Errata ID 1597 4656. 1599 3.24.2. Text Changes to the Document 1601 --------- 1602 Old text: (Section 6.2) 1603 --------- 1605 An implementation MUST NOT allow the maximum delay to be configured 1606 to be more than 500 ms. In other words, an implementation MAY lower 1607 this value below 500 ms but MUST NOT raise it above 500 ms. 1609 --------- 1610 New text: (Section 6.2) 1611 --------- 1613 An implementation MUST NOT allow the maximum delay (protocol 1614 parameter 'SACK.Delay') to be configured to be more than 500 ms. 1615 In other words, an implementation MAY lower the value of 1616 SACK.Delay below 500 ms but MUST NOT raise it above 500 ms. 1618 --------- 1619 Old text: (Section 15) 1620 --------- 1622 The following protocol parameters are RECOMMENDED: 1624 RTO.Initial - 3 seconds 1625 RTO.Min - 1 second 1626 RTO.Max - 60 seconds 1627 Max.Burst - 4 1628 RTO.Alpha - 1/8 1629 RTO.Beta - 1/4 1630 Valid.Cookie.Life - 60 seconds 1631 Association.Max.Retrans - 10 attempts 1632 Path.Max.Retrans - 5 attempts (per destination address) 1633 Max.Init.Retransmits - 8 attempts 1634 HB.interval - 30 seconds 1635 HB.Max.Burst - 1 1637 --------- 1638 New text: (Section 15) 1639 --------- 1641 The following protocol parameters are RECOMMENDED: 1643 RTO.Initial - 3 seconds 1644 RTO.Min - 1 second 1645 RTO.Max - 60 seconds 1646 Max.Burst - 4 1647 RTO.Alpha - 1/8 1648 RTO.Beta - 1/4 1649 Valid.Cookie.Life - 60 seconds 1650 Association.Max.Retrans - 10 attempts 1651 Path.Max.Retrans - 5 attempts (per destination address) 1652 Max.Init.Retransmits - 8 attempts 1653 HB.interval - 30 seconds 1654 HB.Max.Burst - 1 1655 SACK.Delay - 200 milliseconds 1657 3.24.3. Solution Description 1659 The parameter was given a name and added to the list of protocol 1660 parameters. 1662 3.25. Processing of Chunks in an Incoming SCTP Packet 1664 3.25.1. Description of the Problem 1666 There are a few places in [RFC4960] where the receiver of a packet 1667 must discard it while processing the chunks of the packet. It is 1668 unclear whether the receiver has to rollback state changes already 1669 performed while processing the packet or not. 1671 The intention of [RFC4960] is to process an incoming packet chunk by 1672 chunk and not to perform any prescreening of chunks in the received 1673 packet. Thus, by discarding one chunk the receiver also causes 1674 discarding of all further chunks. 1676 3.25.2. Text Changes to the Document 1678 --------- 1679 Old text: (Section 3.2) 1680 --------- 1682 00 - Stop processing this SCTP packet and discard it, do not 1683 process any further chunks within it. 1685 01 - Stop processing this SCTP packet and discard it, do not 1686 process any further chunks within it, and report the 1687 unrecognized chunk in an 'Unrecognized Chunk Type'. 1689 --------- 1690 New text: (Section 3.2) 1691 --------- 1693 00 - Stop processing this SCTP packet, discard the unrecognized 1694 chunk and all further chunks. 1696 01 - Stop processing this SCTP packet, discard the unrecognized 1697 chunk and all further chunks, and report the unrecognized 1698 chunk in an 'Unrecognized Chunk Type'. 1700 --------- 1701 Old text: (Section 11.3) 1702 --------- 1704 It is helpful for some firewalls if they can inspect just the first 1705 fragment of a fragmented SCTP packet and unambiguously determine 1706 whether it corresponds to an INIT chunk (for further information, 1707 please refer to [RFC1858]). Accordingly, we stress the requirements, 1708 stated in Section 3.1, that (1) an INIT chunk MUST NOT be bundled 1709 with any other chunk in a packet, and (2) a packet containing an INIT 1710 chunk MUST have a zero Verification Tag. Furthermore, we require 1711 that the receiver of an INIT chunk MUST enforce these rules by 1712 silently discarding an arriving packet with an INIT chunk that is 1713 bundled with other chunks or has a non-zero verification tag and 1714 contains an INIT-chunk. 1716 --------- 1717 New text: (Section 11.3) 1718 --------- 1720 It is helpful for some firewalls if they can inspect just the first 1721 fragment of a fragmented SCTP packet and unambiguously determine 1722 whether it corresponds to an INIT chunk (for further information, 1723 please refer to [RFC1858]). Accordingly, we stress the requirements, 1724 stated in Section 3.1, that (1) an INIT chunk MUST NOT be bundled 1725 with any other chunk in a packet, and (2) a packet containing an INIT 1726 chunk MUST have a zero Verification Tag. 1727 The receiver of an INIT chunk MUST silently discard the INIT chunk and 1728 all further chunks if the INIT chunk is bundled with other chunks or 1729 the packet has a non-zero verification tag. 1731 3.25.3. Solution Description 1733 The new text makes it clear that chunks can be processed from the 1734 beginning to the end and no rollback or pre-screening is required. 1736 3.26. CWND Increase in Congestion Avoidance Phase 1738 3.26.1. Description of the Problem 1740 [RFC4960] in Section 7.2.2 prescribes to increase cwnd by 1*MTU per 1741 RTT if the sender has cwnd or more bytes of data outstanding to the 1742 corresponding address in the Congestion Avoidance phase. However, 1743 this is described without normative language. Moreover, 1744 Section 7.2.2 includes an algorithm how an implementation can achieve 1745 this but this algorithm is underspecified and actually allows 1746 increasing cwnd by more than 1*MTU per RTT. 1748 3.26.2. Text Changes to the Document 1750 --------- 1751 Old text: (Section 7.2.2) 1752 --------- 1754 When cwnd is greater than ssthresh, cwnd should be incremented by 1755 1*MTU per RTT if the sender has cwnd or more bytes of data 1756 outstanding for the corresponding transport address. 1758 --------- 1759 New text: (Section 7.2.2) 1760 --------- 1762 When cwnd is greater than ssthresh, cwnd SHOULD be incremented by 1763 1*MTU per RTT if the sender has cwnd or more bytes of data 1764 outstanding for the corresponding transport address. The basic 1765 guidelines for incrementing cwnd during congestion avoidance are: 1767 o SCTP MAY increment cwnd by 1*MTU. 1769 o SCTP SHOULD increment cwnd by one 1*MTU once per RTT when 1770 the sender has cwnd or more bytes of data outstanding for 1771 the corresponding transport address. 1773 o SCTP MUST NOT increment cwnd by more than 1*MTU per RTT. 1775 --------- 1776 Old text: (Section 7.2.2) 1777 --------- 1779 o Whenever cwnd is greater than ssthresh, upon each SACK arrival 1780 that advances the Cumulative TSN Ack Point, increase 1781 partial_bytes_acked by the total number of bytes of all new chunks 1782 acknowledged in that SACK including chunks acknowledged by the new 1783 Cumulative TSN Ack and by Gap Ack Blocks. 1785 o When partial_bytes_acked is equal to or greater than cwnd and 1786 before the arrival of the SACK the sender had cwnd or more bytes 1787 of data outstanding (i.e., before arrival of the SACK, flightsize 1788 was greater than or equal to cwnd), increase cwnd by MTU, and 1789 reset partial_bytes_acked to (partial_bytes_acked - cwnd). 1791 --------- 1792 New text: (Section 7.2.2) 1793 --------- 1795 o Whenever cwnd is greater than ssthresh, upon each SACK arrival, 1796 increase partial_bytes_acked by the total number of bytes of all 1797 new chunks acknowledged in that SACK including chunks acknowledged 1798 by the new Cumulative TSN Ack, by Gap Ack Blocks and by the number 1799 of bytes of duplicated chunks reported in Duplicate TSNs. 1801 o When partial_bytes_acked is greater than cwnd and before the 1802 arrival of the SACK the sender had less than cwnd bytes of data 1803 outstanding (i.e., before arrival of the SACK, flightsize was less 1804 than cwnd), reset partial_bytes_acked to cwnd. 1806 o When partial_bytes_acked is equal to or greater than cwnd and 1807 before the arrival of the SACK the sender had cwnd or more bytes 1808 of data outstanding (i.e., before arrival of the SACK, flightsize 1809 was greater than or equal to cwnd), partial_bytes_acked is reset 1810 to (partial_bytes_acked - cwnd). Next, cwnd is increased by 1*MTU. 1812 3.26.3. Solution Description 1814 The basic guidelines for incrementing cwnd during the congestion 1815 avoidance phase are added into Section 7.2.2. The guidelines include 1816 the normative language and are aligned with [RFC5681]. 1818 The algorithm from Section 7.2.2 is improved to not allow increasing 1819 cwnd by more than 1*MTU per RTT. 1821 3.27. Refresh of cwnd and ssthresh after Idle Period 1823 3.27.1. Description of the Problem 1825 [RFC4960] prescribes to adjust cwnd per RTO if the endpoint does not 1826 transmit data on a given transport address. In addition to that, it 1827 prescribes to set cwnd to the initial value after a sufficiently long 1828 idle period. The latter is excessive. Moreover, it is unclear what 1829 is a sufficiently long idle period. 1831 [RFC4960] doesn't specify the handling of ssthresh in the idle case. 1832 If ssthresh is reduced due to a packet loss, ssthresh is never 1833 recovered. So traffic can end up in Congestion Avoidance all the 1834 time, resulting in a low sending rate and bad performance. The 1835 problem is even more serious for SCTP because in a multi-homed SCTP 1836 association traffic that switches back to the previously failed 1837 primary path will also lead to the situation where traffic ends up in 1838 Congestion Avoidance. 1840 3.27.2. Text Changes to the Document 1842 --------- 1843 Old text: (Section 7.2.1) 1844 --------- 1846 o The initial cwnd before DATA transmission or after a sufficiently 1847 long idle period MUST be set to min(4*MTU, max (2*MTU, 4380 1848 bytes)). 1850 --------- 1851 New text: (Section 7.2.1) 1852 --------- 1854 o The initial cwnd before DATA transmission MUST be set to 1855 min(4*MTU, max (2*MTU, 4380 bytes)). 1857 --------- 1858 Old text: (Section 7.2.1) 1859 --------- 1861 o When the endpoint does not transmit data on a given transport 1862 address, the cwnd of the transport address should be adjusted to 1863 max(cwnd/2, 4*MTU) per RTO. 1865 --------- 1866 New text: (Section 7.2.1) 1867 --------- 1868 o While the endpoint does not transmit data on a given transport 1869 address, the cwnd of the transport address SHOULD be adjusted to 1870 max(cwnd/2, 4*MTU) once per RTO. Before the first cwnd adjustment, 1871 the ssthresh of the transport address SHOULD be set to the cwnd. 1873 3.27.3. Solution Description 1875 A rule about cwnd adjustment after a sufficiently long idle period is 1876 removed. 1878 The text is updated to describe the ssthresh handling. When the idle 1879 period is detected, the cwnd value is stored to the ssthresh value. 1881 3.28. Window Updates After Receiver Window Opens Up 1883 3.28.1. Description of the Problem 1885 The sending of SACK chunks for window updates is only indirectly 1886 referenced in [RFC4960], Section 6.2, where it is stated that an SCTP 1887 receiver must not generate more than one SACK for every incoming 1888 packet, other than to update the offered window. 1890 However, the sending of window updates when the receiver window opens 1891 up is necessary to avoid performance problems. 1893 3.28.2. Text Changes to the Document 1895 --------- 1896 Old text: (Section 6.2) 1897 --------- 1899 An SCTP receiver MUST NOT generate more than one SACK for every 1900 incoming packet, other than to update the offered window as the 1901 receiving application consumes new data. 1903 --------- 1904 New text: (Section 6.2) 1905 --------- 1907 An SCTP receiver MUST NOT generate more than one SACK for every 1908 incoming packet, other than to update the offered window as the 1909 receiving application consumes new data. When the window opens 1910 up, an SCTP receiver SHOULD send additional SACK chunks to update 1911 the window even if no new data is received. 1912 The receiver MUST avoid sending a large number of window updates, 1913 in particular large bursts of them. 1914 One way to achieve this is to send a window update only if the 1915 window can be increased by at least a quarter of the receive 1916 buffer size. 1918 3.28.3. Solution Description 1920 The new text makes clear that additional SACK chunks for window 1921 updates should be sent as long as excessive bursts are avoided. 1923 3.29. Path of DATA and Reply Chunks 1925 3.29.1. Description of the Problem 1927 Section 6.4 of [RFC4960] describes the transmission policy for multi- 1928 homed SCTP endpoints. However, there are the following issues with 1929 it: 1931 o It states that a SACK should be sent to the source address of an 1932 incoming DATA. However, it is known that other SACK policies 1933 (e.g. sending SACKs always to the primary path) may be more 1934 beneficial in some situations. 1936 o Initially it states that an endpoint should always transmit DATA 1937 chunks to the primary path. Then it states that the rule for 1938 transmittal of reply chunks should also be followed if the 1939 endpoint is bundling DATA chunks together with the reply chunk 1940 which contradicts with the first statement to always transmit DATA 1941 chunks to the primary path. Some implementations were having 1942 problems with it and sent DATA chunks bundled with reply chunks to 1943 a different destination address than the primary path that caused 1944 many gaps. 1946 3.29.2. Text Changes to the Document 1948 --------- 1949 Old text: (Section 6.4) 1950 --------- 1952 An endpoint SHOULD transmit reply chunks (e.g., SACK, HEARTBEAT ACK, 1953 etc.) to the same destination transport address from which it 1954 received the DATA or control chunk to which it is replying. This 1955 rule should also be followed if the endpoint is bundling DATA chunks 1956 together with the reply chunk. 1958 However, when acknowledging multiple DATA chunks received in packets 1959 from different source addresses in a single SACK, the SACK chunk may 1960 be transmitted to one of the destination transport addresses from 1961 which the DATA or control chunks being acknowledged were received. 1963 --------- 1964 New text: (Section 6.4) 1965 --------- 1967 An endpoint SHOULD transmit reply chunks (e.g., INIT ACK, COOKIE ACK, 1968 HEARTBEAT ACK, etc.) in response to control chunks to the same 1969 destination transport address from which it received the control 1970 chunk to which it is replying. 1972 The selection of the destination transport address for packets 1973 containing SACK chunks is implementation dependent. However, an endpoint 1974 SHOULD NOT vary the destination transport address of a SACK when it 1975 receives DATA chunks coming from the same source address. 1977 When acknowledging multiple DATA chunks received in packets 1978 from different source addresses in a single SACK, the SACK chunk MAY 1979 be transmitted to one of the destination transport addresses from 1980 which the DATA or control chunks being acknowledged were received. 1982 3.29.3. Solution Description 1984 The SACK transmission policy is left implementation dependent but it 1985 is specified to not vary the destination address of a packet 1986 containing a SACK chunk unless there are reasons for it as it may 1987 negatively impact RTT measurement. 1989 A confusing statement that prescribes to follow the rule for 1990 transmittal of reply chunks when the endpoint is bundling DATA chunks 1991 together with the reply chunk is removed. 1993 3.30. Outstanding Data, Flightsize and Data In Flight Key Terms 1995 3.30.1. Description of the Problem 1997 [RFC4960] uses outstanding data, flightsize and data in flight key 1998 terms in formulas and statements but their definitions are not 1999 provided in Section 1.3. Furthermore, outstanding data does not 2000 include DATA chunks which are classified as lost but which have not 2001 been retransmitted yet and there is a paragraph in Section 6.1 of 2002 [RFC4960] where this statement is broken. 2004 3.30.2. Text Changes to the Document 2006 --------- 2007 Old text: (Section 1.3) 2008 --------- 2010 o Congestion window (cwnd): An SCTP variable that limits the data, 2011 in number of bytes, a sender can send to a particular destination 2012 transport address before receiving an acknowledgement. 2014 ... 2016 o Outstanding TSN (at an SCTP endpoint): A TSN (and the associated 2017 DATA chunk) that has been sent by the endpoint but for which it 2018 has not yet received an acknowledgement. 2020 --------- 2021 New text: (Section 1.3) 2022 --------- 2024 o Outstanding TSN (at an SCTP endpoint): A TSN (and the associated 2025 DATA chunk) that has been sent by the endpoint but for which it 2026 has not yet received an acknowledgement. 2028 o Outstanding data (or Data outstanding or Data in flight): The 2029 total amount of the DATA chunks associated with outstanding TSNs. 2031 A retransmitted DATA chunk is counted once in outstanding data. 2032 A DATA chunk which is classified as lost but which has not been 2033 retransmitted yet is not in outstanding data. 2035 o Flightsize: The amount of bytes of outstanding data to a 2036 particular destination transport address at any given time. 2038 o Congestion window (cwnd): An SCTP variable that limits outstanding 2039 data, in number of bytes, a sender can send to a particular 2040 destination transport address before receiving an acknowledgement. 2042 --------- 2043 Old text: (Section 6.1) 2044 --------- 2046 C) When the time comes for the sender to transmit, before sending new 2047 DATA chunks, the sender MUST first transmit any outstanding DATA 2048 chunks that are marked for retransmission (limited by the current 2049 cwnd). 2051 --------- 2052 New text: (Section 6.1) 2053 --------- 2055 C) When the time comes for the sender to transmit, before sending new 2056 DATA chunks, the sender MUST first transmit any DATA chunks that 2057 are marked for retransmission (limited by the current cwnd). 2059 3.30.3. Solution Description 2061 Now Section 1.3, Key Terms, includes explanations of outstanding 2062 data, data in flight and flightsize key terms. Section 6.1 is 2063 corrected to properly use the outstanding data term. 2065 3.31. CWND Degradation due to Max.Burst 2067 3.31.1. Description of the Problem 2069 Some implementations were experiencing a degradation of cwnd because 2070 of the Max.Burst limit. This was due to misinterpretation of the 2071 suggestion in [RFC4960], Section 6.1, on how to use the Max.Burst 2072 parameter when calculating the number of packets to transmit. 2074 3.31.2. Text Changes to the Document 2075 --------- 2076 Old text: (Section 6.1) 2077 --------- 2079 D) When the time comes for the sender to transmit new DATA chunks, 2080 the protocol parameter Max.Burst SHOULD be used to limit the 2081 number of packets sent. The limit MAY be applied by adjusting 2082 cwnd as follows: 2084 if((flightsize + Max.Burst*MTU) < cwnd) cwnd = flightsize + 2085 Max.Burst*MTU 2087 Or it MAY be applied by strictly limiting the number of packets 2088 emitted by the output routine. 2090 --------- 2091 New text: (Section 6.1) 2092 --------- 2094 D) When the time comes for the sender to transmit new DATA chunks, 2095 the protocol parameter Max.Burst SHOULD be used to limit the 2096 number of packets sent. The limit MAY be applied by adjusting 2097 cwnd temporarily as follows: 2099 if ((flightsize + Max.Burst*MTU) < cwnd) 2100 cwnd = flightsize + Max.Burst*MTU 2102 Or it MAY be applied by strictly limiting the number of packets 2103 emitted by the output routine. When calculating the number of 2104 packets to transmit and particularly using the formula above, 2105 cwnd SHOULD NOT be changed permanently. 2107 3.31.3. Solution Description 2109 The new text clarifies that cwnd should not be changed when applying 2110 the Max.Burst limit. This mitigates packet bursts related to the 2111 reception of SACK chunks, but not bursts related to an application 2112 sending a burst of user messages. 2114 3.32. Reduction of RTO.Initial 2116 3.32.1. Description of the Problem 2118 [RFC4960] uses 3 seconds as the default value for RTO.Initial in 2119 accordance with Section 4.3.2.1 of [RFC1122]. [RFC6298] updates 2120 [RFC1122] and lowers the initial value of the retransmission timer 2121 from 3 seconds to 1 second. 2123 3.32.2. Text Changes to the Document 2125 --------- 2126 Old text: (Section 15) 2127 --------- 2129 The following protocol parameters are RECOMMENDED: 2131 RTO.Initial - 3 seconds 2132 RTO.Min - 1 second 2133 RTO.Max - 60 seconds 2134 Max.Burst - 4 2135 RTO.Alpha - 1/8 2136 RTO.Beta - 1/4 2137 Valid.Cookie.Life - 60 seconds 2138 Association.Max.Retrans - 10 attempts 2139 Path.Max.Retrans - 5 attempts (per destination address) 2140 Max.Init.Retransmits - 8 attempts 2141 HB.interval - 30 seconds 2142 HB.Max.Burst - 1 2143 SACK.Delay - 200 milliseconds 2145 --------- 2146 New text: (Section 15) 2147 --------- 2149 The following protocol parameters are RECOMMENDED: 2151 RTO.Initial - 1 second 2152 RTO.Min - 1 second 2153 RTO.Max - 60 seconds 2154 Max.Burst - 4 2155 RTO.Alpha - 1/8 2156 RTO.Beta - 1/4 2157 Valid.Cookie.Life - 60 seconds 2158 Association.Max.Retrans - 10 attempts 2159 Path.Max.Retrans - 5 attempts (per destination address) 2160 Max.Init.Retransmits - 8 attempts 2161 HB.interval - 30 seconds 2162 HB.Max.Burst - 1 2163 SACK.Delay - 200 milliseconds 2165 3.32.3. Solution Description 2167 The value RTO.Initial has been lowered to 1 second to be in tune with 2168 [RFC6298]. 2170 3.33. Ordering of Bundled SACK and ERROR Chunks 2172 3.33.1. Description of the Problem 2174 When an SCTP endpoint receives a DATA chunk with an invalid stream 2175 identifier it shall acknowledge it by sending a SACK chunk and 2176 indicate that the stream identifier was invalid by sending an ERROR 2177 chunk. These two chunks may be bundled. However, [RFC4960] requires 2178 in case of bundling that the ERROR chunk follows the SACK chunk. 2179 This restriction of the ordering is not necessary and might only 2180 limit interoperability. 2182 3.33.2. Text Changes to the Document 2184 --------- 2185 Old text: (Section 6.5) 2186 --------- 2188 Every DATA chunk MUST carry a valid stream identifier. If an 2189 endpoint receives a DATA chunk with an invalid stream identifier, it 2190 shall acknowledge the reception of the DATA chunk following the 2191 normal procedure, immediately send an ERROR chunk with cause set to 2192 "Invalid Stream Identifier" (see Section 3.3.10), and discard the 2193 DATA chunk. The endpoint may bundle the ERROR chunk in the same 2194 packet as the SACK as long as the ERROR follows the SACK. 2196 --------- 2197 New text: (Section 6.5) 2198 --------- 2200 Every DATA chunk MUST carry a valid stream identifier. If an 2201 endpoint receives a DATA chunk with an invalid stream identifier, it 2202 SHOULD acknowledge the reception of the DATA chunk following the 2203 normal procedure, immediately send an ERROR chunk with cause set to 2204 "Invalid Stream Identifier" (see Section 3.3.10), and discard the 2205 DATA chunk. The endpoint MAY bundle the ERROR chunk and the SACK Chunk 2206 in the same packet. 2208 3.33.3. Solution Description 2210 The unnecessary restriction regarding the ordering of the SACK and 2211 ERROR chunk has been removed. 2213 3.34. Undefined Parameter Returned by RECEIVE Primitive 2214 3.34.1. Description of the Problem 2216 [RFC4960] provides a description of an abstract API. In the 2217 definition of the RECEIVE primitive an optional parameter with name 2218 "delivery number" is mentioned. However, no definition of this 2219 parameter is given in [RFC4960] and the parameter is unnecessary. 2221 3.34.2. Text Changes to the Document 2223 --------- 2224 Old text: (Section 10.1) 2225 --------- 2227 G) Receive 2229 Format: RECEIVE(association id, buffer address, buffer size 2230 [,stream id]) 2231 -> byte count [,transport address] [,stream id] [,stream sequence 2232 number] [,partial flag] [,delivery number] [,payload protocol-id] 2234 --------- 2235 New text: (Section 10.1) 2236 --------- 2238 G) Receive 2240 Format: RECEIVE(association id, buffer address, buffer size 2241 [,stream id]) 2242 -> byte count [,transport address] [,stream id] [,stream sequence 2243 number] [,partial flag] [,payload protocol-id] 2245 3.34.3. Solution Description 2247 The undefined parameter has been removed. 2249 3.35. DSCP Changes 2251 3.35.1. Description of the Problem 2253 The upper layer can change the Differentiated Services Code Point 2254 (DSCP) used for packets being sent. A change of the DSCP can result 2255 in packets hitting different queues on the path and, therefore, the 2256 congestion control should be initialized when the DSCP is changed by 2257 the upper layer. This is not described in [RFC4960]. 2259 3.35.2. Text Changes to the Document 2261 --------- 2262 New text: (Section 7.2.5) 2263 --------- 2264 7.2.5. Change of Differentiated Services Code Points 2266 SCTP implementations MAY allow an application to configure the 2267 Differentiated Services Code Point (DSCP) used for sending packets. 2268 If a DSCP change might result in outgoing packets being queued in 2269 different queues, the congestion control parameters for all affected 2270 destination addresses MUST be reset to their initial values. 2272 --------- 2273 Old text: (Section 10.1) 2274 --------- 2276 M) Set Protocol Parameters 2278 Format: SETPROTOCOLPARAMETERS(association id, 2279 [,destination transport address,] 2280 protocol parameter list) 2281 -> result 2283 This primitive allows the local SCTP to customize the protocol 2284 parameters. 2286 Mandatory attributes: 2288 o association id - local handle to the SCTP association. 2290 o protocol parameter list - the specific names and values of the 2291 protocol parameters (e.g., Association.Max.Retrans; see Section 2292 15) that the SCTP user wishes to customize. 2294 --------- 2295 New text: (Section 10.1) 2296 --------- 2298 M) Set Protocol Parameters 2300 Format: SETPROTOCOLPARAMETERS(association id, 2301 [,destination transport address,] 2302 protocol parameter list) 2303 -> result 2305 This primitive allows the local SCTP to customize the protocol 2306 parameters. 2308 Mandatory attributes: 2310 o association id - local handle to the SCTP association. 2312 o protocol parameter list - the specific names and values of the 2313 protocol parameters (e.g., Association.Max.Retrans; see Section 2314 15, or other parameters like the DSCP) that the SCTP user wishes 2315 to customize. 2317 3.35.3. Solution Description 2319 Text describing the required action on DSCP changes has been added. 2321 3.36. Inconsistent Handling of ICMPv4 and ICMPv6 Messages 2323 3.36.1. Description of the Problem 2325 Appendix C of [RFC4960] describes the handling of ICMPv4 and ICMPv6 2326 messages. The handling of ICMP messages indicating that the port 2327 number is unreachable described in the enumeration is not consistent 2328 with the description given in [RFC4960] after the enumeration. 2329 Furthermore, the text explicitly describes the handling of ICMPv6 2330 packets indicating reachability problems, but does not do the same 2331 for the corresponding ICMPv4 packets. 2333 3.36.2. Text Changes to the Document 2334 --------- 2335 Old text: (Appendix C) 2336 --------- 2338 ICMP3) An implementation MAY ignore any ICMPv4 messages where the 2339 code does not indicate "Protocol Unreachable" or 2340 "Fragmentation Needed". 2342 --------- 2343 New text: (Appendix C) 2344 --------- 2346 ICMP3) An implementation SHOULD ignore any ICMP messages where the 2347 code indicates "Port Unreachable". 2349 --------- 2350 Old text: (Appendix C) 2351 --------- 2353 ICMP9) If the ICMPv6 code is "Destination Unreachable", the 2354 implementation MAY mark the destination into the unreachable 2355 state or alternatively increment the path error counter. 2357 --------- 2358 New text: (Appendix C) 2359 --------- 2361 ICMP9) If the ICMP type is "Destination Unreachable", the 2362 implementation MAY mark the destination into the unreachable 2363 state or alternatively increment the path error counter. 2365 3.36.3. Solution Description 2367 The text has been changed to describe the intended handling of ICMP 2368 messages indicating that the port number is unreachable by replacing 2369 the third rule. Furthermore, remove the limitation to ICMPv6 in the 2370 ninth rule. 2372 3.37. Handling of Soft Errors 2374 3.37.1. Description of the Problem 2376 [RFC1122] defines the handling of soft errors and hard errors for 2377 TCP. Appendix C of [RFC4960] only deals with hard errors. 2379 3.37.2. Text Changes to the Document 2381 --------- 2382 Old text: (Appendix C) 2383 --------- 2385 ICMP9) If the ICMP type is "Destination Unreachable", the 2386 implementation MAY mark the destination into the unreachable 2387 state or alternatively increment the path error counter. 2389 --------- 2390 New text: (Appendix C) 2391 --------- 2393 ICMP9) If the ICMP type is "Destination Unreachable", the 2394 implementation MAY mark the destination into the unreachable 2395 state or alternatively increment the path error counter. 2396 SCTP MAY provide information to the upper layer indicating 2397 the reception of ICMP messages when reporting a network status 2398 change. 2400 3.37.3. Solution Description 2402 Text has been added allowing SCTP to notify the application in case 2403 of soft errors. 2405 3.38. Honoring CWND 2407 3.38.1. Description of the Problem 2409 When using the slow start algorithm, SCTP increases the congestion 2410 window only when it is being fully utilized. Since SCTP uses DATA 2411 chunks and does not use the congestion window to fragment user 2412 messages, this requires that some overbooking of the congestion 2413 window is allowed. 2415 3.38.2. Text Changes to the Document 2416 --------- 2417 Old text: (Section 6.1) 2418 --------- 2420 B) At any given time, the sender MUST NOT transmit new data to a 2421 given transport address if it has cwnd or more bytes of data 2422 outstanding to that transport address. 2424 --------- 2425 New text: (Section 6.1) 2426 --------- 2428 B) At any given time, the sender MUST NOT transmit new data to a 2429 given transport address if it has cwnd + (PMTU - 1) or more bytes 2430 of data outstanding to that transport address. If data is 2431 available the sender SHOULD exceed cwnd by up to (PMTU-1) bytes on 2432 a new data transmission if the flightsize does not currently reach 2433 cwnd. The breach of cwnd MUST constitute one packet only. 2435 --------- 2436 Old text: (Section 7.2.1) 2437 --------- 2439 o Whenever cwnd is greater than zero, the endpoint is allowed to 2440 have cwnd bytes of data outstanding on that transport address. 2442 --------- 2443 New text: (Section 7.2.1) 2444 --------- 2445 o Whenever cwnd is greater than zero, the endpoint is allowed to 2446 have cwnd bytes of data outstanding on that transport address. 2447 A limited overbooking as described in B) of Section 6.1 SHOULD 2448 be supported. 2450 3.38.3. Solution Description 2452 Text was added to clarify how the cwnd limit should be handled. 2454 3.39. Zero Window Probing 2456 3.39.1. Description of the Problem 2458 The text describing zero window probing was not clearly handling the 2459 case where the window was not zero, but too small for the next DATA 2460 chunk to be transmitted. Even in this case, zero window probing has 2461 to be performed to avoid deadlocks. 2463 3.39.2. Text Changes to the Document 2465 --------- 2466 Old text: (Section 6.1) 2467 --------- 2469 A) At any given time, the data sender MUST NOT transmit new data to 2470 any destination transport address if its peer's rwnd indicates 2471 that the peer has no buffer space (i.e., rwnd is 0; see Section 2472 6.2.1). However, regardless of the value of rwnd (including if it 2473 is 0), the data sender can always have one DATA chunk in flight to 2474 the receiver if allowed by cwnd (see rule B, below). This rule 2475 allows the sender to probe for a change in rwnd that the sender 2476 missed due to the SACK's having been lost in transit from the data 2477 receiver to the data sender. 2479 When the receiver's advertised window is zero, this probe is 2480 called a zero window probe. Note that a zero window probe SHOULD 2481 only be sent when all outstanding DATA chunks have been 2482 cumulatively acknowledged and no DATA chunks are in flight. Zero 2483 window probing MUST be supported. 2485 --------- 2486 New text: (Section 6.1) 2487 --------- 2489 A) At any given time, the data sender MUST NOT transmit new data to 2490 any destination transport address if its peer's rwnd indicates 2491 that the peer has no buffer space (i.e., rwnd is smaller than the 2492 size of the next DATA chunk; see Section 6.2.1). 2493 However, regardless of the value of rwnd (including if it is 0), 2494 the data sender can always have one DATA chunk in flight to 2495 the receiver if allowed by cwnd (see rule B, below). This rule 2496 allows the sender to probe for a change in rwnd that the sender 2497 missed due to the SACK's having been lost in transit from the data 2498 receiver to the data sender. 2500 When the receiver has no buffer space, this probe is 2501 called a zero window probe. Note that a zero window probe SHOULD 2502 only be sent when all outstanding DATA chunks have been 2503 cumulatively acknowledged and no DATA chunks are in flight. Zero 2504 window probing MUST be supported. 2506 3.39.3. Solution Description 2508 The terminology is used in a cleaner way. 2510 3.40. Updating References Regarding ECN 2512 3.40.1. Description of the Problem 2514 [RFC4960] refers for ECN only to [RFC3168], which will be updated by 2515 [RFC8311]. This needs to be reflected when referring to ECN. 2517 3.40.2. Text Changes to the Document 2519 --------- 2520 Old text: (Appendix A) 2521 --------- 2523 ECN [RFC3168] describes a proposed extension to IP that details a 2524 method to become aware of congestion outside of datagram loss. 2526 --------- 2527 New text: (Appendix A) 2528 --------- 2530 ECN as specified in [RFC3168] updated by [RFC8311] describes an 2531 extension to IP that details a method to become aware of congestion 2532 outside of datagram loss. 2534 --------- 2535 Old text: (Appendix A) 2536 --------- 2538 In general, [RFC3168] should be followed with the following 2539 exceptions. 2541 --------- 2542 New text: (Appendix A) 2543 --------- 2545 In general, [RFC3168] updated by [RFC8311] SHOULD be followed with the 2546 following exceptions. 2548 --------- 2549 Old text: (Appendix A) 2550 --------- 2552 [RFC3168] details negotiation of ECN during the SYN and SYN-ACK 2553 stages of a TCP connection. 2555 --------- 2556 New text: (Appendix A) 2557 --------- 2559 [RFC3168] updated by [RFC8311] details negotiation of ECN during the 2560 SYN and SYN-ACK stages of a TCP connection. 2562 --------- 2563 Old text: (Appendix A) 2564 --------- 2566 [RFC3168] details a specific bit for a receiver to send back in its 2567 TCP acknowledgements to notify the sender of the Congestion 2568 Experienced (CE) bit having arrived from the network. 2570 --------- 2571 New text: (Appendix A) 2572 --------- 2574 [RFC3168] updated by [RFC8311] details a specific bit for a receiver 2575 to send back in its TCP acknowledgements to notify the sender of the 2576 Congestion Experienced (CE) bit having arrived from the network. 2578 --------- 2579 Old text: (Appendix A) 2580 --------- 2582 [RFC3168] details a specific bit for a sender to send in the header 2583 of its next outbound TCP segment to indicate to its peer that it has 2584 reduced its congestion window. 2585 --------- 2586 New text: (Appendix A) 2587 --------- 2589 [RFC3168] updated by [RFC8311] details a specific bit for a sender 2590 to send in the header of its next outbound TCP segment to indicate to 2591 its peer that it has reduced its congestion window. 2593 3.40.3. Solution Description 2595 References to [RFC8311] have been added. While there, some 2596 wordsmithing has been performed. 2598 3.41. Host Name Address Parameter Deprecated 2600 3.41.1. Description of the Problem 2602 [RFC4960] defines three types of address parameters to be used with 2603 INIT and INIT ACK chunks: 2605 1. IPv4 Address parameters. 2606 2. IPv6 Address parameters. 2608 3. Host Name Address parameters. 2610 The first two are supported by the SCTP kernel implementations of 2611 FreeBSD, Linux and Solaris, but the third one is not. In addition, 2612 the first two where successfully tested in all nine interoperability 2613 tests for SCTP, but the third one has never been successfully tested. 2614 Therefore, the Host Name Address parameter should be deprecated. 2616 3.41.2. Text Changes to the Document 2618 --------- 2619 Old text: (Section 3.3.2) 2620 --------- 2622 Note 3: An INIT chunk MUST NOT contain more than one Host Name 2623 Address parameter. Moreover, the sender of the INIT MUST NOT combine 2624 any other address types with the Host Name Address in the INIT. The 2625 receiver of INIT MUST ignore any other address types if the Host Name 2626 Address parameter is present in the received INIT chunk. 2628 --------- 2629 New text: (Section 3.3.2) 2630 --------- 2632 Note 3: An INIT chunk MUST NOT contain the Host Name Address 2633 parameter. The receiver of an INIT chunk containing a Host Name 2634 Address parameter MUST send an ABORT and MAY include an Error Cause 2635 indicating an Unresolvable Address. 2637 --------- 2638 Old text: (Section 3.3.2.1) 2639 --------- 2641 The sender of INIT uses this parameter to pass its Host Name (in 2642 place of its IP addresses) to its peer. The peer is responsible for 2643 resolving the name. Using this parameter might make it more likely 2644 for the association to work across a NAT box. 2646 --------- 2647 New text: (Section 3.3.2.1) 2648 --------- 2650 The sender of an INIT chunk MUST NOT include this parameter. The 2651 usage of the Host Name Address parameter is deprecated. 2653 --------- 2654 Old text: (Section 3.3.2.1) 2655 --------- 2656 Address Type: 16 bits (unsigned integer) 2658 This is filled with the type value of the corresponding address 2659 TLV (e.g., IPv4 = 5, IPv6 = 6, Host name = 11). 2661 --------- 2662 New text: (Section 3.3.2.1) 2663 --------- 2664 Address Type: 16 bits (unsigned integer) 2666 This is filled with the type value of the corresponding address 2667 TLV (e.g., IPv4 = 5, IPv6 = 6). The value indicating the Host 2668 Name Address parameter (Host name = 11) MUST NOT be used. 2670 --------- 2671 Old text: (Section 3.3.3) 2672 --------- 2674 Note 3: The INIT ACK chunks MUST NOT contain more than one Host Name 2675 Address parameter. Moreover, the sender of the INIT ACK MUST NOT 2676 combine any other address types with the Host Name Address in the 2677 INIT ACK. The receiver of the INIT ACK MUST ignore any other address 2678 types if the Host Name Address parameter is present. 2680 --------- 2681 New text: (Section 3.3.3) 2682 --------- 2684 Note 3: An INIT ACK chunk MUST NOT contain the Host Name Address 2685 parameter. The receiver of INIT ACK chunks containing a Host Name 2686 Address parameter MUST send an ABORT and MAY include an Error Cause 2687 indicating an Unresolvable Address. 2689 --------- 2690 Old text: (Section 5.1.2) 2691 --------- 2693 B) If there is a Host Name parameter present in the received INIT or 2694 INIT ACK chunk, the endpoint shall resolve that host name to a 2695 list of IP address(es) and derive the transport address(es) of 2696 this peer by combining the resolved IP address(es) with the SCTP 2697 source port. 2699 The endpoint MUST ignore any other IP Address parameters if they 2700 are also present in the received INIT or INIT ACK chunk. 2702 The time at which the receiver of an INIT resolves the host name 2703 has potential security implications to SCTP. If the receiver of 2704 an INIT resolves the host name upon the reception of the chunk, 2705 and the mechanism the receiver uses to resolve the host name 2706 involves potential long delay (e.g., DNS query), the receiver may 2707 open itself up to resource attacks for the period of time while it 2708 is waiting for the name resolution results before it can build the 2709 State Cookie and release local resources. 2711 Therefore, in cases where the name translation involves potential 2712 long delay, the receiver of the INIT MUST postpone the name 2713 resolution till the reception of the COOKIE ECHO chunk from the 2714 peer. In such a case, the receiver of the INIT SHOULD build the 2715 State Cookie using the received Host Name (instead of destination 2716 transport addresses) and send the INIT ACK to the source IP 2717 address from which the INIT was received. 2719 The receiver of an INIT ACK shall always immediately attempt to 2720 resolve the name upon the reception of the chunk. 2722 The receiver of the INIT or INIT ACK MUST NOT send user data 2723 (piggy-backed or stand-alone) to its peer until the host name is 2724 successfully resolved. 2726 If the name resolution is not successful, the endpoint MUST 2727 immediately send an ABORT with "Unresolvable Address" error cause 2728 to its peer. The ABORT shall be sent to the source IP address 2729 from which the last peer packet was received. 2731 --------- 2732 New text: (Section 5.1.2) 2733 --------- 2735 B) If there is a Host Name parameter present in the received INIT or 2736 INIT ACK chunk, the endpoint MUST immediately send an ABORT and 2737 MAY include an Error Cause indicating an Unresolvable Address to 2738 its peer. The ABORT SHALL be sent to the source IP address 2739 from which the last peer packet was received. 2741 --------- 2742 Old text: (Section 11.2.4.1) 2743 --------- 2745 The use of the host name feature in the INIT chunk could be used to 2746 flood a target DNS server. A large backlog of DNS queries, resolving 2747 the host name received in the INIT chunk to IP addresses, could be 2748 accomplished by sending INITs to multiple hosts in a given domain. 2749 In addition, an attacker could use the host name feature in an 2750 indirect attack on a third party by sending large numbers of INITs to 2751 random hosts containing the host name of the target. In addition to 2752 the strain on DNS resources, this could also result in large numbers 2753 of INIT ACKs being sent to the target. One method to protect against 2754 this type of attack is to verify that the IP addresses received from 2755 DNS include the source IP address of the original INIT. If the list 2756 of IP addresses received from DNS does not include the source IP 2757 address of the INIT, the endpoint MAY silently discard the INIT. 2758 This last option will not protect against the attack against the DNS. 2760 --------- 2761 New text: (Section 11.2.4.1) 2762 --------- 2764 The support of the Host Name Address parameter has been removed from 2765 the protocol. Endpoints receiving INIT or INIT ACK chunks containing 2766 the Host Name Address parameter MUST send an ABORT chunk in response 2767 and MAY include an Error Cause indicating an Unresolvable Address. 2769 3.41.3. Solution Description 2771 The usage of the Host Name Address parameter has been deprecated. 2773 3.42. Conflicting Text Regarding the Supported Address Types Parameter 2775 3.42.1. Description of the Problem 2777 When receiving an SCTP packet containing an INIT chunk sent from an 2778 address for which the corresponding address type is not listed in the 2779 Supported Address Types, there is conflicting text in Section 5.1.2 2780 of [RFC4960]. It is stated that the association MUST be aborted and 2781 also that the association SHOULD be established and there SHOULD NOT 2782 be any error indication. 2784 3.42.2. Text Changes to the Document 2785 --------- 2786 Old text: (Section 5.1.2) 2787 --------- 2789 The sender of INIT may include a 'Supported Address Types' parameter 2790 in the INIT to indicate what types of address are acceptable. When 2791 this parameter is present, the receiver of INIT (initiate) MUST 2792 either use one of the address types indicated in the Supported 2793 Address Types parameter when responding to the INIT, or abort the 2794 association with an "Unresolvable Address" error cause if it is 2795 unwilling or incapable of using any of the address types indicated by 2796 its peer. 2798 --------- 2799 New text: (Section 5.1.2) 2800 --------- 2802 The sender of INIT chunks MAY include a 'Supported Address Types' 2803 parameter in the INIT to indicate what types of addresses are 2804 acceptable. 2806 3.42.3. Solution Description 2808 The conflicting text has been removed. 2810 3.43. Integration of RFC 6096 2812 3.43.1. Description of the Problem 2814 [RFC6096] updates [RFC4960] by adding a Chunk Flags Registry. This 2815 should be integrated into the base specification. 2817 3.43.2. Text Changes to the Document 2819 --------- 2820 Old text: (Section 14.1) 2821 --------- 2823 14.1. IETF-Defined Chunk Extension 2825 The assignment of new chunk parameter type codes is done through an 2826 IETF Consensus action, as defined in [RFC2434]. Documentation of the 2827 chunk parameter MUST contain the following information: 2829 a) A long and short name for the new chunk type. 2831 b) A detailed description of the structure of the chunk, which MUST 2832 conform to the basic structure defined in Section 3.2. 2834 c) A detailed definition and description of the intended use of each 2835 field within the chunk, including the chunk flags if any. 2837 d) A detailed procedural description of the use of the new chunk type 2838 within the operation of the protocol. 2840 The last chunk type (255) is reserved for future extension if 2841 necessary. 2843 --------- 2844 New text: (Section 14.1) 2845 --------- 2847 14.1. IETF-Defined Chunk Extension 2849 The assignment of new chunk type codes is done through an IETF Review 2850 action, as defined in [RFC8126]. Documentation of a new chunk MUST 2851 contain the following information: 2853 a) A long and short name for the new chunk type; 2855 b) A detailed description of the structure of the chunk, which MUST 2856 conform to the basic structure defined in Section 3.2 of 2857 [RFC4960]; 2859 c) A detailed definition and description of the intended use of each 2860 field within the chunk, including the chunk flags if any. 2861 Defined chunk flags will be used as initial entries in the chunk 2862 flags table for the new chunk type; 2864 d) A detailed procedural description of the use of the new chunk 2865 type within the operation of the protocol. 2867 The last chunk type (255) is reserved for future extension if 2868 necessary. 2870 For each new chunk type, IANA creates a registration table for the 2871 chunk flags of that type. The procedure for registering particular 2872 chunk flags is described in the following Section 14.2. 2874 --------- 2875 New text: (Section 14.2) 2876 --------- 2878 14.2. New IETF Chunk Flags Registration 2879 The assignment of new chunk flags is done through an RFC required 2880 action, as defined in [RFC8126]. Documentation of the chunk flags 2881 MUST contain the following information: 2883 a) A name for the new chunk flag; 2885 b) A detailed procedural description of the use of the new chunk 2886 flag within the operation of the protocol. It MUST be considered 2887 that implementations not supporting the flag will send '0' on 2888 transmit and just ignore it on receipt. 2890 IANA selects a chunk flags value. This MUST be one of 0x01, 0x02, 2891 0x04, 0x08, 0x10, 0x20, 0x40, or 0x80, which MUST be unique within 2892 the chunk flag values for the specific chunk type. 2894 Please note that Sections 14.2, 14.3, 14.4, and 14.5 need to be 2895 renumbered. 2897 3.43.3. Solution Description 2899 [RFC6096] was integrated and the reference updated to [RFC8126]. 2901 3.44. Integration of RFC 6335 2903 3.44.1. Description of the Problem 2905 [RFC6335] updates [RFC4960] by updating Procedures for the Port 2906 Numbers Registry. This should be integrated into the base 2907 specification. While there, update the reference to the RFC giving 2908 guidelines for writing IANA sections to [RFC8126]. 2910 3.44.2. Text Changes to the Document 2912 --------- 2913 Old text: (Section 14.5) 2914 --------- 2916 SCTP services may use contact port numbers to provide service to 2917 unknown callers, as in TCP and UDP. IANA is therefore requested to 2918 open the existing Port Numbers registry for SCTP using the following 2919 rules, which we intend to mesh well with existing Port Numbers 2920 registration procedures. An IESG-appointed Expert Reviewer supports 2921 IANA in evaluating SCTP port allocation requests, according to the 2922 procedure defined in [RFC2434]. 2924 Port numbers are divided into three ranges. The Well Known Ports are 2925 those from 0 through 1023, the Registered Ports are those from 1024 2926 through 49151, and the Dynamic and/or Private Ports are those from 2927 49152 through 65535. Well Known and Registered Ports are intended 2928 for use by server applications that desire a default contact point on 2929 a system. On most systems, Well Known Ports can only be used by 2930 system (or root) processes or by programs executed by privileged 2931 users, while Registered Ports can be used by ordinary user processes 2932 or programs executed by ordinary users. Dynamic and/or Private Ports 2933 are intended for temporary use, including client-side ports, out-of- 2934 band negotiated ports, and application testing prior to registration 2935 of a dedicated port; they MUST NOT be registered. 2937 The Port Numbers registry should accept registrations for SCTP ports 2938 in the Well Known Ports and Registered Ports ranges. Well Known and 2939 Registered Ports SHOULD NOT be used without registration. Although 2940 in some cases -- such as porting an application from TCP to SCTP -- 2941 it may seem natural to use an SCTP port before registration 2942 completes, we emphasize that IANA will not guarantee registration of 2943 particular Well Known and Registered Ports. Registrations should be 2944 requested as early as possible. 2946 Each port registration SHALL include the following information: 2948 o A short port name, consisting entirely of letters (A-Z and a-z), 2949 digits (0-9), and punctuation characters from "-_+./*" (not 2950 including the quotes). 2952 o The port number that is requested for registration. 2954 o A short English phrase describing the port's purpose. 2956 o Name and contact information for the person or entity performing 2957 the registration, and possibly a reference to a document defining 2958 the port's use. Registrations coming from IETF working groups 2959 need only name the working group, but indicating a contact person 2960 is recommended. 2962 Registrants are encouraged to follow these guidelines when submitting 2963 a registration. 2965 o A port name SHOULD NOT be registered for more than one SCTP port 2966 number. 2968 o A port name registered for TCP MAY be registered for SCTP as well. 2969 Any such registration SHOULD use the same port number as the 2970 existing TCP registration. 2972 o Concrete intent to use a port SHOULD precede port registration. 2973 For example, existing TCP ports SHOULD NOT be registered in 2974 advance of any intent to use those ports for SCTP. 2976 --------- 2977 New text: (Section 14.5) 2978 --------- 2980 SCTP services can use contact port numbers to provide service to 2981 unknown callers, as in TCP and UDP. IANA is therefore requested to 2982 open the existing Port Numbers registry for SCTP using the following 2983 rules, which we intend to mesh well with existing Port Numbers 2984 registration procedures. An IESG-appointed Expert Reviewer supports 2985 IANA in evaluating SCTP port allocation requests, according to the 2986 procedure defined in [RFC8126]. The details of this process are 2987 defined in [RFC6335]. 2989 3.44.3. Solution Description 2991 [RFC6335] was integrated and the reference was updated to [RFC8126]. 2993 3.45. Integration of RFC 7053 2995 3.45.1. Description of the Problem 2997 [RFC7053] updates [RFC4960] by adding the I bit to the DATA chunk. 2998 This should be integrated into the base specification. 3000 3.45.2. Text Changes to the Document 3002 --------- 3003 Old text: (Section 3.3.1) 3004 --------- 3006 The following format MUST be used for the DATA chunk: 3008 0 1 2 3 3009 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 3010 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3011 | Type = 0 | Reserved|U|B|E| Length | 3012 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3013 | TSN | 3014 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3015 | Stream Identifier S | Stream Sequence Number n | 3016 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3017 | Payload Protocol Identifier | 3018 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3019 \ \ 3020 / User Data (seq n of Stream S) / 3021 \ \ 3022 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3024 Reserved: 5 bits 3026 Should be set to all '0's and ignored by the receiver. 3028 --------- 3029 New text: (Section 3.3.1) 3030 --------- 3032 0 1 2 3 3033 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 3034 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3035 | Type = 0 | Res |I|U|B|E| Length | 3036 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3037 | TSN | 3038 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3039 | Stream Identifier S | Stream Sequence Number n | 3040 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3041 | Payload Protocol Identifier | 3042 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3043 \ \ 3044 / User Data (seq n of Stream S) / 3045 \ \ 3046 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3048 Res: 4 bits 3050 SHOULD be set to all '0's and ignored by the receiver. 3052 I bit: 1 bit 3054 The (I)mmediate Bit MAY be set by the sender, whenever the sender of 3055 a DATA chunk can benefit from the corresponding SACK chunk being sent 3056 back without delay. See [RFC7053] for a discussion about 3058 --------- 3059 New text: (Append to Section 6.1) 3060 --------- 3062 Whenever the sender of a DATA chunk can benefit from the 3063 corresponding SACK chunk being sent back without delay, the sender 3064 MAY set the I bit in the DATA chunk header. Please note that why the 3065 sender has set the I bit is irrelevant to the receiver. 3067 Reasons for setting the I bit include, but are not limited to (see 3068 Section 4 of [RFC7053] for the benefits): 3070 o The application requests to set the I bit of the last DATA chunk 3071 of a user message when providing the user message to the SCTP 3072 implementation (see Section 7). 3074 o The sender is in the SHUTDOWN-PENDING state. 3076 o The sending of a DATA chunk fills the congestion or receiver 3077 window. 3079 --------- 3080 Old text: (Section 6.2) 3081 --------- 3083 Note: The SHUTDOWN chunk does not contain Gap Ack Block fields. 3084 Therefore, the endpoint should use a SACK instead of the SHUTDOWN 3085 chunk to acknowledge DATA chunks received out of order. 3087 --------- 3088 New text: (Section 6.2) 3089 --------- 3091 Note: The SHUTDOWN chunk does not contain Gap Ack Block fields. 3092 Therefore, the endpoint SHOULD use a SACK instead of the SHUTDOWN 3093 chunk to acknowledge DATA chunks received out of order. 3095 Upon receipt of an SCTP packet containing a DATA chunk with the I bit 3096 set, the receiver SHOULD NOT delay the sending of the corresponding 3097 SACK chunk, i.e., the receiver SHOULD immediately respond with the 3098 corresponding SACK chunk. 3100 --------- 3101 Old text: (Section 10.1) 3102 --------- 3104 E) Send 3106 Format: SEND(association id, buffer address, byte count [,context] 3107 [,stream id] [,life time] [,destination transport address] 3108 [,unordered flag] [,no-bundle flag] [,payload protocol-id] ) 3109 -> result 3111 --------- 3112 New text: (Section 10.1) 3113 --------- 3115 E) Send 3117 Format: SEND(association id, buffer address, byte count [,context] 3118 [,stream id] [,life time] [,destination transport address] 3120 [,unordered flag] [,no-bundle flag] [,payload protocol-id] 3121 [,sack immediately] ) 3122 -> result 3124 --------- 3125 New text: (Append optional parameter in Subsection E of Section 10.1) 3126 --------- 3128 o sack immediately - set the I bit on the last DATA chunk used for 3129 sending buffer. 3131 Please note that the change in Section 6.2 is only about adding a 3132 paragraph. 3134 3.45.3. Solution Description 3136 [RFC7053] was integrated. 3138 3.46. CRC32c Code Improvements 3140 3.46.1. Description of the Problem 3142 The code given for the CRC32c computations uses types like long which 3143 may have different length on different operating systems or 3144 processors. Therefore, the code is changed to use specific types 3145 like uint32_t. 3147 While there, fix also some syntax errors and a comment. 3149 3.46.2. Text Changes to the Document 3151 --------- 3152 Old text: (Appendix B) 3153 --------- 3154 /*************************************************************/ 3155 /* Note Definition for Ross Williams table generator would */ 3156 /* be: TB_WIDTH=4, TB_POLLY=0x1EDC6F41, TB_REVER=TRUE */ 3157 /* For Mr. Williams direct calculation code use the settings */ 3158 /* cm_width=32, cm_poly=0x1EDC6F41, cm_init=0xFFFFFFFF, */ 3159 /* cm_refin=TRUE, cm_refot=TRUE, cm_xorort=0x00000000 */ 3160 /*************************************************************/ 3162 /* Example of the crc table file */ 3163 #ifndef __crc32cr_table_h__ 3164 #define __crc32cr_table_h__ 3166 #define CRC32C_POLY 0x1EDC6F41 3167 #define CRC32C(c,d) (c=(c>>8)^crc_c[(c^(d))&0xFF]) 3169 unsigned long crc_c[256] = 3170 { 3171 0x00000000L, 0xF26B8303L, 0xE13B70F7L, 0x1350F3F4L, 3172 0xC79A971FL, 0x35F1141CL, 0x26A1E7E8L, 0xD4CA64EBL, 3173 0x8AD958CFL, 0x78B2DBCCL, 0x6BE22838L, 0x9989AB3BL, 3174 0x4D43CFD0L, 0xBF284CD3L, 0xAC78BF27L, 0x5E133C24L, 3175 0x105EC76FL, 0xE235446CL, 0xF165B798L, 0x030E349BL, 3176 0xD7C45070L, 0x25AFD373L, 0x36FF2087L, 0xC494A384L, 3177 0x9A879FA0L, 0x68EC1CA3L, 0x7BBCEF57L, 0x89D76C54L, 3178 0x5D1D08BFL, 0xAF768BBCL, 0xBC267848L, 0x4E4DFB4BL, 3179 0x20BD8EDEL, 0xD2D60DDDL, 0xC186FE29L, 0x33ED7D2AL, 3180 0xE72719C1L, 0x154C9AC2L, 0x061C6936L, 0xF477EA35L, 3181 0xAA64D611L, 0x580F5512L, 0x4B5FA6E6L, 0xB93425E5L, 3182 0x6DFE410EL, 0x9F95C20DL, 0x8CC531F9L, 0x7EAEB2FAL, 3183 0x30E349B1L, 0xC288CAB2L, 0xD1D83946L, 0x23B3BA45L, 3185 0xF779DEAEL, 0x05125DADL, 0x1642AE59L, 0xE4292D5AL, 3186 0xBA3A117EL, 0x4851927DL, 0x5B016189L, 0xA96AE28AL, 3187 0x7DA08661L, 0x8FCB0562L, 0x9C9BF696L, 0x6EF07595L, 3188 0x417B1DBCL, 0xB3109EBFL, 0xA0406D4BL, 0x522BEE48L, 3189 0x86E18AA3L, 0x748A09A0L, 0x67DAFA54L, 0x95B17957L, 3190 0xCBA24573L, 0x39C9C670L, 0x2A993584L, 0xD8F2B687L, 3191 0x0C38D26CL, 0xFE53516FL, 0xED03A29BL, 0x1F682198L, 3192 0x5125DAD3L, 0xA34E59D0L, 0xB01EAA24L, 0x42752927L, 3193 0x96BF4DCCL, 0x64D4CECFL, 0x77843D3BL, 0x85EFBE38L, 3194 0xDBFC821CL, 0x2997011FL, 0x3AC7F2EBL, 0xC8AC71E8L, 3195 0x1C661503L, 0xEE0D9600L, 0xFD5D65F4L, 0x0F36E6F7L, 3196 0x61C69362L, 0x93AD1061L, 0x80FDE395L, 0x72966096L, 3197 0xA65C047DL, 0x5437877EL, 0x4767748AL, 0xB50CF789L, 3198 0xEB1FCBADL, 0x197448AEL, 0x0A24BB5AL, 0xF84F3859L, 3199 0x2C855CB2L, 0xDEEEDFB1L, 0xCDBE2C45L, 0x3FD5AF46L, 3200 0x7198540DL, 0x83F3D70EL, 0x90A324FAL, 0x62C8A7F9L, 3201 0xB602C312L, 0x44694011L, 0x5739B3E5L, 0xA55230E6L, 3202 0xFB410CC2L, 0x092A8FC1L, 0x1A7A7C35L, 0xE811FF36L, 3203 0x3CDB9BDDL, 0xCEB018DEL, 0xDDE0EB2AL, 0x2F8B6829L, 3204 0x82F63B78L, 0x709DB87BL, 0x63CD4B8FL, 0x91A6C88CL, 3205 0x456CAC67L, 0xB7072F64L, 0xA457DC90L, 0x563C5F93L, 3206 0x082F63B7L, 0xFA44E0B4L, 0xE9141340L, 0x1B7F9043L, 3207 0xCFB5F4A8L, 0x3DDE77ABL, 0x2E8E845FL, 0xDCE5075CL, 3208 0x92A8FC17L, 0x60C37F14L, 0x73938CE0L, 0x81F80FE3L, 3209 0x55326B08L, 0xA759E80BL, 0xB4091BFFL, 0x466298FCL, 3210 0x1871A4D8L, 0xEA1A27DBL, 0xF94AD42FL, 0x0B21572CL, 3211 0xDFEB33C7L, 0x2D80B0C4L, 0x3ED04330L, 0xCCBBC033L, 3212 0xA24BB5A6L, 0x502036A5L, 0x4370C551L, 0xB11B4652L, 3213 0x65D122B9L, 0x97BAA1BAL, 0x84EA524EL, 0x7681D14DL, 3214 0x2892ED69L, 0xDAF96E6AL, 0xC9A99D9EL, 0x3BC21E9DL, 3215 0xEF087A76L, 0x1D63F975L, 0x0E330A81L, 0xFC588982L, 3216 0xB21572C9L, 0x407EF1CAL, 0x532E023EL, 0xA145813DL, 3217 0x758FE5D6L, 0x87E466D5L, 0x94B49521L, 0x66DF1622L, 3218 0x38CC2A06L, 0xCAA7A905L, 0xD9F75AF1L, 0x2B9CD9F2L, 3219 0xFF56BD19L, 0x0D3D3E1AL, 0x1E6DCDEEL, 0xEC064EEDL, 3220 0xC38D26C4L, 0x31E6A5C7L, 0x22B65633L, 0xD0DDD530L, 3221 0x0417B1DBL, 0xF67C32D8L, 0xE52CC12CL, 0x1747422FL, 3222 0x49547E0BL, 0xBB3FFD08L, 0xA86F0EFCL, 0x5A048DFFL, 3223 0x8ECEE914L, 0x7CA56A17L, 0x6FF599E3L, 0x9D9E1AE0L, 3224 0xD3D3E1ABL, 0x21B862A8L, 0x32E8915CL, 0xC083125FL, 3225 0x144976B4L, 0xE622F5B7L, 0xF5720643L, 0x07198540L, 3226 0x590AB964L, 0xAB613A67L, 0xB831C993L, 0x4A5A4A90L, 3227 0x9E902E7BL, 0x6CFBAD78L, 0x7FAB5E8CL, 0x8DC0DD8FL, 3228 0xE330A81AL, 0x115B2B19L, 0x020BD8EDL, 0xF0605BEEL, 3229 0x24AA3F05L, 0xD6C1BC06L, 0xC5914FF2L, 0x37FACCF1L, 3230 0x69E9F0D5L, 0x9B8273D6L, 0x88D28022L, 0x7AB90321L, 3231 0xAE7367CAL, 0x5C18E4C9L, 0x4F48173DL, 0xBD23943EL, 3232 0xF36E6F75L, 0x0105EC76L, 0x12551F82L, 0xE03E9C81L, 3234 0x34F4F86AL, 0xC69F7B69L, 0xD5CF889DL, 0x27A40B9EL, 3235 0x79B737BAL, 0x8BDCB4B9L, 0x988C474DL, 0x6AE7C44EL, 3236 0xBE2DA0A5L, 0x4C4623A6L, 0x5F16D052L, 0xAD7D5351L, 3237 }; 3239 #endif 3241 --------- 3242 New text: (Appendix B) 3243 --------- 3245 3246 /*************************************************************/ 3247 /* Note Definition for Ross Williams table generator would */ 3248 /* be: TB_WIDTH=4, TB_POLLY=0x1EDC6F41, TB_REVER=TRUE */ 3249 /* For Mr. Williams direct calculation code use the settings */ 3250 /* cm_width=32, cm_poly=0x1EDC6F41, cm_init=0xFFFFFFFF, */ 3251 /* cm_refin=TRUE, cm_refot=TRUE, cm_xorort=0x00000000 */ 3252 /*************************************************************/ 3254 /* Example of the crc table file */ 3255 #ifndef __crc32cr_h__ 3256 #define __crc32cr_h__ 3258 #define CRC32C_POLY 0x1EDC6F41UL 3259 #define CRC32C(c,d) (c=(c>>8)^crc_c[(c^(d))&0xFF]) 3261 uint32_t crc_c[256] = 3262 { 3263 0x00000000UL, 0xF26B8303UL, 0xE13B70F7UL, 0x1350F3F4UL, 3264 0xC79A971FUL, 0x35F1141CUL, 0x26A1E7E8UL, 0xD4CA64EBUL, 3265 0x8AD958CFUL, 0x78B2DBCCUL, 0x6BE22838UL, 0x9989AB3BUL, 3266 0x4D43CFD0UL, 0xBF284CD3UL, 0xAC78BF27UL, 0x5E133C24UL, 3267 0x105EC76FUL, 0xE235446CUL, 0xF165B798UL, 0x030E349BUL, 3268 0xD7C45070UL, 0x25AFD373UL, 0x36FF2087UL, 0xC494A384UL, 3269 0x9A879FA0UL, 0x68EC1CA3UL, 0x7BBCEF57UL, 0x89D76C54UL, 3270 0x5D1D08BFUL, 0xAF768BBCUL, 0xBC267848UL, 0x4E4DFB4BUL, 3271 0x20BD8EDEUL, 0xD2D60DDDUL, 0xC186FE29UL, 0x33ED7D2AUL, 3272 0xE72719C1UL, 0x154C9AC2UL, 0x061C6936UL, 0xF477EA35UL, 3273 0xAA64D611UL, 0x580F5512UL, 0x4B5FA6E6UL, 0xB93425E5UL, 3274 0x6DFE410EUL, 0x9F95C20DUL, 0x8CC531F9UL, 0x7EAEB2FAUL, 3275 0x30E349B1UL, 0xC288CAB2UL, 0xD1D83946UL, 0x23B3BA45UL, 3276 0xF779DEAEUL, 0x05125DADUL, 0x1642AE59UL, 0xE4292D5AUL, 3277 0xBA3A117EUL, 0x4851927DUL, 0x5B016189UL, 0xA96AE28AUL, 3278 0x7DA08661UL, 0x8FCB0562UL, 0x9C9BF696UL, 0x6EF07595UL, 3279 0x417B1DBCUL, 0xB3109EBFUL, 0xA0406D4BUL, 0x522BEE48UL, 3280 0x86E18AA3UL, 0x748A09A0UL, 0x67DAFA54UL, 0x95B17957UL, 3281 0xCBA24573UL, 0x39C9C670UL, 0x2A993584UL, 0xD8F2B687UL, 3282 0x0C38D26CUL, 0xFE53516FUL, 0xED03A29BUL, 0x1F682198UL, 3283 0x5125DAD3UL, 0xA34E59D0UL, 0xB01EAA24UL, 0x42752927UL, 3284 0x96BF4DCCUL, 0x64D4CECFUL, 0x77843D3BUL, 0x85EFBE38UL, 3285 0xDBFC821CUL, 0x2997011FUL, 0x3AC7F2EBUL, 0xC8AC71E8UL, 3286 0x1C661503UL, 0xEE0D9600UL, 0xFD5D65F4UL, 0x0F36E6F7UL, 3287 0x61C69362UL, 0x93AD1061UL, 0x80FDE395UL, 0x72966096UL, 3288 0xA65C047DUL, 0x5437877EUL, 0x4767748AUL, 0xB50CF789UL, 3289 0xEB1FCBADUL, 0x197448AEUL, 0x0A24BB5AUL, 0xF84F3859UL, 3290 0x2C855CB2UL, 0xDEEEDFB1UL, 0xCDBE2C45UL, 0x3FD5AF46UL, 3291 0x7198540DUL, 0x83F3D70EUL, 0x90A324FAUL, 0x62C8A7F9UL, 3292 0xB602C312UL, 0x44694011UL, 0x5739B3E5UL, 0xA55230E6UL, 3293 0xFB410CC2UL, 0x092A8FC1UL, 0x1A7A7C35UL, 0xE811FF36UL, 3294 0x3CDB9BDDUL, 0xCEB018DEUL, 0xDDE0EB2AUL, 0x2F8B6829UL, 3295 0x82F63B78UL, 0x709DB87BUL, 0x63CD4B8FUL, 0x91A6C88CUL, 3296 0x456CAC67UL, 0xB7072F64UL, 0xA457DC90UL, 0x563C5F93UL, 3297 0x082F63B7UL, 0xFA44E0B4UL, 0xE9141340UL, 0x1B7F9043UL, 3298 0xCFB5F4A8UL, 0x3DDE77ABUL, 0x2E8E845FUL, 0xDCE5075CUL, 3299 0x92A8FC17UL, 0x60C37F14UL, 0x73938CE0UL, 0x81F80FE3UL, 3300 0x55326B08UL, 0xA759E80BUL, 0xB4091BFFUL, 0x466298FCUL, 3301 0x1871A4D8UL, 0xEA1A27DBUL, 0xF94AD42FUL, 0x0B21572CUL, 3302 0xDFEB33C7UL, 0x2D80B0C4UL, 0x3ED04330UL, 0xCCBBC033UL, 3303 0xA24BB5A6UL, 0x502036A5UL, 0x4370C551UL, 0xB11B4652UL, 3304 0x65D122B9UL, 0x97BAA1BAUL, 0x84EA524EUL, 0x7681D14DUL, 3305 0x2892ED69UL, 0xDAF96E6AUL, 0xC9A99D9EUL, 0x3BC21E9DUL, 3306 0xEF087A76UL, 0x1D63F975UL, 0x0E330A81UL, 0xFC588982UL, 3307 0xB21572C9UL, 0x407EF1CAUL, 0x532E023EUL, 0xA145813DUL, 3308 0x758FE5D6UL, 0x87E466D5UL, 0x94B49521UL, 0x66DF1622UL, 3309 0x38CC2A06UL, 0xCAA7A905UL, 0xD9F75AF1UL, 0x2B9CD9F2UL, 3310 0xFF56BD19UL, 0x0D3D3E1AUL, 0x1E6DCDEEUL, 0xEC064EEDUL, 3311 0xC38D26C4UL, 0x31E6A5C7UL, 0x22B65633UL, 0xD0DDD530UL, 3312 0x0417B1DBUL, 0xF67C32D8UL, 0xE52CC12CUL, 0x1747422FUL, 3313 0x49547E0BUL, 0xBB3FFD08UL, 0xA86F0EFCUL, 0x5A048DFFUL, 3314 0x8ECEE914UL, 0x7CA56A17UL, 0x6FF599E3UL, 0x9D9E1AE0UL, 3315 0xD3D3E1ABUL, 0x21B862A8UL, 0x32E8915CUL, 0xC083125FUL, 3316 0x144976B4UL, 0xE622F5B7UL, 0xF5720643UL, 0x07198540UL, 3317 0x590AB964UL, 0xAB613A67UL, 0xB831C993UL, 0x4A5A4A90UL, 3318 0x9E902E7BUL, 0x6CFBAD78UL, 0x7FAB5E8CUL, 0x8DC0DD8FUL, 3319 0xE330A81AUL, 0x115B2B19UL, 0x020BD8EDUL, 0xF0605BEEUL, 3320 0x24AA3F05UL, 0xD6C1BC06UL, 0xC5914FF2UL, 0x37FACCF1UL, 3321 0x69E9F0D5UL, 0x9B8273D6UL, 0x88D28022UL, 0x7AB90321UL, 3322 0xAE7367CAUL, 0x5C18E4C9UL, 0x4F48173DUL, 0xBD23943EUL, 3323 0xF36E6F75UL, 0x0105EC76UL, 0x12551F82UL, 0xE03E9C81UL, 3324 0x34F4F86AUL, 0xC69F7B69UL, 0xD5CF889DUL, 0x27A40B9EUL, 3325 0x79B737BAUL, 0x8BDCB4B9UL, 0x988C474DUL, 0x6AE7C44EUL, 3326 0xBE2DA0A5UL, 0x4C4623A6UL, 0x5F16D052UL, 0xAD7D5351UL, 3327 }; 3329 #endif 3331 --------- 3332 Old text: (Appendix B) 3333 --------- 3335 /* Example of table build routine */ 3337 #include 3338 #include 3340 #define OUTPUT_FILE "crc32cr.h" 3341 #define CRC32C_POLY 0x1EDC6F41L 3342 FILE *tf; 3343 unsigned long 3344 reflect_32 (unsigned long b) 3345 { 3346 int i; 3347 unsigned long rw = 0L; 3349 for (i = 0; i < 32; i++){ 3350 if (b & 1) 3351 rw |= 1 << (31 - i); 3352 b >>= 1; 3353 } 3354 return (rw); 3355 } 3357 unsigned long 3358 build_crc_table (int index) 3359 { 3360 int i; 3361 unsigned long rb; 3363 rb = reflect_32 (index); 3365 for (i = 0; i < 8; i++){ 3366 if (rb & 0x80000000L) 3367 rb = (rb << 1) ^ CRC32C_POLY; 3368 else 3369 rb <<= 1; 3370 } 3371 return (reflect_32 (rb)); 3372 } 3374 main () 3375 { 3376 int i; 3378 printf ("\nGenerating CRC-32c table file <%s>\n", 3379 OUTPUT_FILE); 3380 if ((tf = fopen (OUTPUT_FILE, "w")) == NULL){ 3381 printf ("Unable to open %s\n", OUTPUT_FILE); 3382 exit (1); 3383 } 3384 fprintf (tf, "#ifndef __crc32cr_table_h__\n"); 3385 fprintf (tf, "#define __crc32cr_table_h__\n\n"); 3386 fprintf (tf, "#define CRC32C_POLY 0x%08lX\n", 3387 CRC32C_POLY); 3388 fprintf (tf, 3389 "#define CRC32C(c,d) (c=(c>>8)^crc_c[(c^(d))&0xFF])\n"); 3390 fprintf (tf, "\nunsigned long crc_c[256] =\n{\n"); 3391 for (i = 0; i < 256; i++){ 3392 fprintf (tf, "0x%08lXL, ", build_crc_table (i)); 3393 if ((i & 3) == 3) 3394 fprintf (tf, "\n"); 3395 } 3396 fprintf (tf, "};\n\n#endif\n"); 3398 if (fclose (tf) != 0) 3399 printf ("Unable to close <%s>." OUTPUT_FILE); 3400 else 3401 printf ("\nThe CRC-32c table has been written to <%s>.\n", 3402 OUTPUT_FILE); 3403 } 3405 --------- 3406 New text: (Appendix B) 3407 --------- 3409 /* Example of table build routine */ 3411 #include 3412 #include 3414 #define OUTPUT_FILE "crc32cr.h" 3415 #define CRC32C_POLY 0x1EDC6F41UL 3417 static FILE *tf; 3419 static uint32_t 3420 reflect_32(uint32_t b) 3421 { 3422 int i; 3423 uint32_t rw = 0UL; 3425 for (i = 0; i < 32; i++) { 3426 if (b & 1) 3427 rw |= 1 << (31 - i); 3428 b >>= 1; 3429 } 3430 return (rw); 3431 } 3433 static uint32_t 3434 build_crc_table(int index) 3435 { 3436 int i; 3437 uint32_t rb; 3439 rb = reflect_32(index); 3441 for (i = 0; i < 8; i++) { 3442 if (rb & 0x80000000UL) 3443 rb = (rb << 1) ^ (uint32_t)CRC32C_POLY; 3444 else 3445 rb <<= 1; 3446 } 3447 return (reflect_32(rb)); 3448 } 3450 int 3451 main (void) 3452 { 3453 int i; 3454 printf("\nGenerating CRC-32c table file <%s>\n", 3455 OUTPUT_FILE); 3456 if ((tf = fopen(OUTPUT_FILE, "w")) == NULL) { 3457 printf ("Unable to open %s\n", OUTPUT_FILE); 3458 exit (1); 3459 } 3460 fprintf(tf, "#ifndef __crc32cr_h__\n"); 3461 fprintf(tf, "#define __crc32cr_h__\n\n"); 3462 fprintf(tf, "#define CRC32C_POLY 0x%08XUL\n", 3463 (uint32_t)CRC32C_POLY); 3464 fprintf(tf, 3465 "#define CRC32C(c,d) (c=(c>>8)^crc_c[(c^(d))&0xFF])\n"); 3466 fprintf(tf, "\nuint32_t crc_c[256] =\n{\n"); 3467 for (i = 0; i < 256; i++) { 3468 fprintf(tf, "0x%08XUL,", build_crc_table (i)); 3469 if ((i & 3) == 3) 3470 fprintf(tf, "\n"); 3471 else 3472 fprintf(tf, " "); 3473 } 3474 fprintf(tf, "};\n\n#endif\n"); 3476 if (fclose (tf) != 0) 3477 printf("Unable to close <%s>.", OUTPUT_FILE); 3478 else 3479 printf("\nThe CRC-32c table has been written to <%s>.\n", 3480 OUTPUT_FILE); 3481 } 3483 --------- 3484 Old text: (Appendix B) 3485 --------- 3487 /* Example of crc insertion */ 3489 #include "crc32cr.h" 3491 unsigned long 3492 generate_crc32c(unsigned char *buffer, unsigned int length) 3493 { 3494 unsigned int i; 3495 unsigned long crc32 = ~0L; 3496 unsigned long result; 3497 unsigned char byte0,byte1,byte2,byte3; 3499 for (i = 0; i < length; i++){ 3500 CRC32C(crc32, buffer[i]); 3501 } 3502 result = ~crc32; 3504 /* result now holds the negated polynomial remainder; 3505 * since the table and algorithm is "reflected" [williams95]. 3506 * That is, result has the same value as if we mapped the message 3507 * to a polynomial, computed the host-bit-order polynomial 3508 * remainder, performed final negation, then did an end-for-end 3509 * bit-reversal. 3510 * Note that a 32-bit bit-reversal is identical to four inplace 3511 * 8-bit reversals followed by an end-for-end byteswap. 3512 * In other words, the bytes of each bit are in the right order, 3513 * but the bytes have been byteswapped. So we now do an explicit 3514 * byteswap. On a little-endian machine, this byteswap and 3515 * the final ntohl cancel out and could be elided. 3516 */ 3518 byte0 = result & 0xff; 3519 byte1 = (result>>8) & 0xff; 3520 byte2 = (result>>16) & 0xff; 3521 byte3 = (result>>24) & 0xff; 3522 crc32 = ((byte0 << 24) | 3523 (byte1 << 16) | 3524 (byte2 << 8) | 3525 byte3); 3526 return ( crc32 ); 3527 } 3529 int 3530 insert_crc32(unsigned char *buffer, unsigned int length) 3531 { 3532 SCTP_message *message; 3533 unsigned long crc32; 3534 message = (SCTP_message *) buffer; 3535 message->common_header.checksum = 0L; 3536 crc32 = generate_crc32c(buffer,length); 3537 /* and insert it into the message */ 3538 message->common_header.checksum = htonl(crc32); 3539 return 1; 3540 } 3542 int 3543 validate_crc32(unsigned char *buffer, unsigned int length) 3544 { 3545 SCTP_message *message; 3546 unsigned int i; 3547 unsigned long original_crc32; 3548 unsigned long crc32 = ~0L; 3549 /* save and zero checksum */ 3550 message = (SCTP_message *) buffer; 3551 original_crc32 = ntohl(message->common_header.checksum); 3552 message->common_header.checksum = 0L; 3553 crc32 = generate_crc32c(buffer,length); 3554 return ((original_crc32 == crc32)? 1 : -1); 3555 } 3557 --------- 3558 New text: (Appendix B) 3559 --------- 3561 /* Example of crc insertion */ 3563 #include "crc32cr.h" 3565 uint32_t 3566 generate_crc32c(unsigned char *buffer, unsigned int length) 3567 { 3568 unsigned int i; 3569 uint32_t crc32 = 0xffffffffUL; 3570 uint32_t result; 3571 uint8_t byte0, byte1, byte2, byte3; 3573 for (i = 0; i < length; i++) { 3574 CRC32C(crc32, buffer[i]); 3575 } 3577 result = ~crc32; 3579 /* result now holds the negated polynomial remainder; 3580 * since the table and algorithm is "reflected" [williams95]. 3581 * That is, result has the same value as if we mapped the message 3582 * to a polynomial, computed the host-bit-order polynomial 3583 * remainder, performed final negation, then did an end-for-end 3584 * bit-reversal. 3585 * Note that a 32-bit bit-reversal is identical to four inplace 3586 * 8-bit reversals followed by an end-for-end byteswap. 3587 * In other words, the bits of each byte are in the right order, 3588 * but the bytes have been byteswapped. So we now do an explicit 3589 * byteswap. On a little-endian machine, this byteswap and 3590 * the final ntohl cancel out and could be elided. 3591 */ 3593 byte0 = result & 0xff; 3594 byte1 = (result>>8) & 0xff; 3595 byte2 = (result>>16) & 0xff; 3596 byte3 = (result>>24) & 0xff; 3597 crc32 = ((byte0 << 24) | 3598 (byte1 << 16) | 3599 (byte2 << 8) | 3600 byte3); 3601 return (crc32); 3602 } 3604 int 3605 insert_crc32(unsigned char *buffer, unsigned int length) 3606 { 3607 SCTP_message *message; 3608 uint32_t crc32; 3609 message = (SCTP_message *) buffer; 3610 message->common_header.checksum = 0UL; 3611 crc32 = generate_crc32c(buffer,length); 3612 /* and insert it into the message */ 3613 message->common_header.checksum = htonl(crc32); 3614 return 1; 3615 } 3617 int 3618 validate_crc32(unsigned char *buffer, unsigned int length) 3619 { 3620 SCTP_message *message; 3621 unsigned int i; 3622 uint32_t original_crc32; 3623 uint32_t crc32; 3625 /* save and zero checksum */ 3626 message = (SCTP_message *)buffer; 3627 original_crc32 = ntohl(message->common_header.checksum); 3628 message->common_header.checksum = 0L; 3629 crc32 = generate_crc32c(buffer, length); 3630 return ((original_crc32 == crc32)? 1 : -1); 3631 } 3632 3634 3.46.3. Solution Description 3636 The code was changed to use platform independent types. 3638 3.47. Clarification of Gap Ack Blocks in SACK Chunks 3639 3.47.1. Description of the Problem 3641 The Gap Ack Blocks in the SACK chunk are intended to be isolated. 3642 However, this is not mentioned with normative text. 3644 This issue was reported as part of an Errata for [RFC4960] with 3645 Errata ID 5202. 3647 3.47.2. Text Changes to the Document 3649 --------- 3650 Old text: (Section 3.3.4) 3651 --------- 3653 The SACK also contains zero or more Gap Ack Blocks. Each Gap Ack 3654 Block acknowledges a subsequence of TSNs received following a break 3655 in the sequence of received TSNs. By definition, all TSNs 3656 acknowledged by Gap Ack Blocks are greater than the value of the 3657 Cumulative TSN Ack. 3659 --------- 3660 New text: (Section 3.3.4) 3661 --------- 3663 The SACK also contains zero or more Gap Ack Blocks. Each Gap Ack 3664 Block acknowledges a subsequence of TSNs received following a break 3665 in the sequence of received TSNs. The Gap Ack Blocks SHOULD be isolated. 3666 This means that the TSN just before each Gap Ack Block and the TSN just 3667 after each Gap Ack Block has not been received. By definition, all TSNs 3668 acknowledged by Gap Ack Blocks are greater than the value of the 3669 Cumulative TSN Ack. 3671 --------- 3672 Old text: (Section 3.3.4) 3673 --------- 3675 Gap Ack Blocks: 3677 These fields contain the Gap Ack Blocks. They are repeated for 3678 each Gap Ack Block up to the number of Gap Ack Blocks defined in 3679 the Number of Gap Ack Blocks field. All DATA chunks with TSNs 3680 greater than or equal to (Cumulative TSN Ack + Gap Ack Block 3681 Start) and less than or equal to (Cumulative TSN Ack + Gap Ack 3682 Block End) of each Gap Ack Block are assumed to have been received 3683 correctly. 3685 --------- 3686 New text: (Section 3.3.4) 3687 --------- 3689 Gap Ack Blocks: 3691 These fields contain the Gap Ack Blocks. They are repeated for 3692 each Gap Ack Block up to the number of Gap Ack Blocks defined in 3693 the Number of Gap Ack Blocks field. All DATA chunks with TSNs 3694 greater than or equal to (Cumulative TSN Ack + Gap Ack Block 3695 Start) and less than or equal to (Cumulative TSN Ack + Gap Ack 3696 Block End) of each Gap Ack Block are assumed to have been received 3697 correctly. Gap Ack Blocks SHOULD be isolated. That means that 3698 the DATA chunks with TSN equal to (Cumulative TSN Ack + Gap Ack 3699 Block Start - 1) and (Cumulative TSN Ack + Gap Ack Block End + 1) 3700 have not been received. 3702 3.47.3. Solution Description 3704 Normative text describing the intended usage of Gap Ack Blocks has 3705 been added. 3707 3.48. Handling of SSN Wrap Arounds 3709 3.48.1. Description of the Problem 3711 The Stream Sequence Number (SSN) is used for preserving the ordering 3712 of user messages within each SCTP stream. The SSN is limited to 16 3713 bits. Therefore, multiple wrap arounds of the SSN might happen 3714 within the current send window. To allow the receiver to deliver 3715 ordered user messages in the correct sequence, the sender should 3716 limit the number of user messages per stream. 3718 3.48.2. Text Changes to the Document 3720 --------- 3721 Old text: (Section 6.1) 3722 --------- 3724 Note: The data sender SHOULD NOT use a TSN that is more than 2**31 - 3725 1 above the beginning TSN of the current send window. 3727 --------- 3728 New text: (Section 6.1) 3729 --------- 3731 Note: The data sender SHOULD NOT use a TSN that is more than 2**31 - 3732 1 above the beginning TSN of the current send window. 3733 Note: For each stream, the data sender SHOULD NOT have more than 2**16-1 3734 ordered user messages in the current send window. 3736 3.48.3. Solution Description 3738 The data sender is required to limit the number of ordered user 3739 messages within the current send window. 3741 3.49. Update RFC 2119 Boilerplate 3743 3.49.1. Description of the Problem 3745 The text to be used to refer to the [RFC2119] terms has been updated 3746 by [RFC8174]. 3748 3.49.2. Text Changes to the Document 3750 --------- 3751 Old text: (Section 2) 3752 --------- 3754 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 3755 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 3756 document are to be interpreted as described in RFC 2119 [RFC2119]. 3758 --------- 3759 New text: (Section 2) 3760 --------- 3762 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 3763 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 3764 "OPTIONAL" in this document are to be interpreted as described in 3765 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 3766 capitals, as shown here. 3768 3.49.3. Solution Description 3770 The text has been updated to the one specified in [RFC8174]. 3772 3.50. Missed Text Removal 3774 3.50.1. Description of the Problem 3776 When integrating the changes to Section 7.2.4 of [RFC2960] as 3777 described in Section 2.8.2 of [RFC4460] some text was not removed and 3778 is therefore still in [RFC4960]. 3780 3.50.2. Text Changes to the Document 3782 --------- 3783 Old text: (Section 7.2.4) 3784 --------- 3786 A straightforward implementation of the above keeps a counter for 3787 each TSN hole reported by a SACK. The counter increments for each 3788 consecutive SACK reporting the TSN hole. After reaching 3 and 3789 starting the Fast-Retransmit procedure, the counter resets to 0. 3790 Because cwnd in SCTP indirectly bounds the number of outstanding 3791 TSN's, the effect of TCP Fast Recovery is achieved automatically with 3792 no adjustment to the congestion control window size. 3794 --------- 3795 New text: (Section 7.2.4) 3796 --------- 3798 3.50.3. Solution Description 3800 The text has finally been removed. 3802 4. IANA Considerations 3804 Section 3.44 of this document updates the port number registry for 3805 SCTP to be consistent with [RFC6335]. IANA is requested to review 3806 Section 3.44. 3808 IANA is only requested to check if it is OK to make the proposed text 3809 change in an upcoming standards track document that updates[RFC4960]. 3810 IANA is not asked to perform any other action and this document does 3811 not request IANA to make a change to any registry. 3813 5. Security Considerations 3815 This document does not add any security considerations to those given 3816 in [RFC4960]. 3818 6. Acknowledgments 3820 The authors wish to thank Pontus Andersson, Eric W. Biederman, 3821 Cedric Bonnet, Spencer Dawkins, Gorry Fairhurst, Benjamin Kaduk, 3822 Mirja Kuehlewind, Peter Lei, Gyula Marosi, Lionel Morand, Jeff 3823 Morriss, Karen E. E. Nielsen, Tom Petch, Kacheong Poon, Julien 3824 Pourtet, Irene Ruengeler, Michael Welzl, and Qiaobing Xie for their 3825 invaluable comments. 3827 7. References 3829 7.1. Normative References 3831 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3832 Requirement Levels", BCP 14, RFC 2119, 3833 DOI 10.17487/RFC2119, March 1997, 3834 . 3836 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 3837 RFC 4960, DOI 10.17487/RFC4960, September 2007, 3838 . 3840 7.2. Informative References 3842 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 3843 Communication Layers", STD 3, RFC 1122, 3844 DOI 10.17487/RFC1122, October 1989, 3845 . 3847 [RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security 3848 Considerations for IP Fragment Filtering", RFC 1858, 3849 DOI 10.17487/RFC1858, October 1995, 3850 . 3852 [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., 3853 Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., 3854 Zhang, L., and V. Paxson, "Stream Control Transmission 3855 Protocol", RFC 2960, DOI 10.17487/RFC2960, October 2000, 3856 . 3858 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 3859 of Explicit Congestion Notification (ECN) to IP", 3860 RFC 3168, DOI 10.17487/RFC3168, September 2001, 3861 . 3863 [RFC4460] Stewart, R., Arias-Rodriguez, I., Poon, K., Caro, A., and 3864 M. Tuexen, "Stream Control Transmission Protocol (SCTP) 3865 Specification Errata and Issues", RFC 4460, 3866 DOI 10.17487/RFC4460, April 2006, 3867 . 3869 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 3870 Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, 3871 . 3873 [RFC6096] Tuexen, M. and R. Stewart, "Stream Control Transmission 3874 Protocol (SCTP) Chunk Flags Registration", RFC 6096, 3875 DOI 10.17487/RFC6096, January 2011, 3876 . 3878 [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, 3879 "Computing TCP's Retransmission Timer", RFC 6298, 3880 DOI 10.17487/RFC6298, June 2011, 3881 . 3883 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 3884 Cheshire, "Internet Assigned Numbers Authority (IANA) 3885 Procedures for the Management of the Service Name and 3886 Transport Protocol Port Number Registry", BCP 165, 3887 RFC 6335, DOI 10.17487/RFC6335, August 2011, 3888 . 3890 [RFC7053] Tuexen, M., Ruengeler, I., and R. Stewart, "SACK- 3891 IMMEDIATELY Extension for the Stream Control Transmission 3892 Protocol", RFC 7053, DOI 10.17487/RFC7053, November 2013, 3893 . 3895 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 3896 Writing an IANA Considerations Section in RFCs", BCP 26, 3897 RFC 8126, DOI 10.17487/RFC8126, June 2017, 3898 . 3900 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 3901 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 3902 May 2017, . 3904 [RFC8311] Black, D., "Relaxing Restrictions on Explicit Congestion 3905 Notification (ECN) Experimentation", RFC 8311, 3906 DOI 10.17487/RFC8311, January 2018, 3907 . 3909 Authors' Addresses 3911 Randall R. Stewart 3912 Netflix, Inc. 3913 Chapin, SC 29036 3914 United States 3916 Email: randall@lakerest.net 3917 Michael Tuexen 3918 Muenster University of Applied Sciences 3919 Stegerwaldstrasse 39 3920 48565 Steinfurt 3921 Germany 3923 Email: tuexen@fh-muenster.de 3925 Maksim Proshin 3926 Ericsson 3927 Kistavaegen 25 3928 Stockholm 164 80 3929 Sweden 3931 Email: mproshin@tieto.mera.ru