idnits 2.17.1 draft-ietf-tsvwg-rfc4960-errata-05.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 5 instances of too long lines in the document, the longest one being 6 characters in excess of 72. == 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 3114 has weird spacing: '...ed long crc_c...' == Line 3325 has weird spacing: '...ed long crc_c...' -- The document date (March 5, 2018) is 2237 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 2876, but not defined ** Obsolete undefined reference: RFC 2434 (Obsoleted by RFC 5226) == Missing Reference: 'RFC0813' is mentioned on line 417, but not defined ** Obsolete undefined reference: RFC 813 (Obsoleted by RFC 7805) == Missing Reference: 'RFC1858' is mentioned on line 1688, but not defined -- Looks like a reference, but probably isn't: '256' on line 3402 ** 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 5226 (Obsoleted by RFC 8126) -- 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: 4 errors (**), 0 flaws (~~), 7 warnings (==), 8 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: September 6, 2018 Muenster Univ. of Appl. Sciences 6 M. Proshin 7 Ericsson 8 March 5, 2018 10 RFC 4960 Errata and Issues 11 draft-ietf-tsvwg-rfc4960-errata-05.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 September 6, 2018. 42 Copyright Notice 44 Copyright (c) 2018 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Corrections to RFC 4960 . . . . . . . . . . . . . . . . . . . 4 62 3.1. Path Error Counter Threshold Handling . . . . . . . . . . 4 63 3.2. Upper Layer Protocol Shutdown Request Handling . . . . . 5 64 3.3. Registration of New Chunk Types . . . . . . . . . . . . . 6 65 3.4. Variable Parameters for INIT Chunks . . . . . . . . . . . 7 66 3.5. CRC32c Sample Code on 64-bit Platforms . . . . . . . . . 8 67 3.6. Endpoint Failure Detection . . . . . . . . . . . . . . . 9 68 3.7. Data Transmission Rules . . . . . . . . . . . . . . . . . 10 69 3.8. T1-Cookie Timer . . . . . . . . . . . . . . . . . . . . . 11 70 3.9. Miscellaneous Typos . . . . . . . . . . . . . . . . . . . 12 71 3.10. CRC32c Sample Code . . . . . . . . . . . . . . . . . . . 19 72 3.11. partial_bytes_acked after T3-rtx Expiration . . . . . . . 20 73 3.12. Order of Adjustments of partial_bytes_acked and cwnd . . 20 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 . . . . . . . . . . . . . . 83 111 3.49. Update RFC 2119 Boilerplate . . . . . . . . . . . . . . . 84 112 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 85 113 5. Security Considerations . . . . . . . . . . . . . . . . . . . 85 114 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 85 115 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 85 116 7.1. Normative References . . . . . . . . . . . . . . . . . . 85 117 7.2. Informative References . . . . . . . . . . . . . . . . . 86 118 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 87 120 1. Introduction 122 This document contains a compilation of all defects found up until 123 the publication of this document for [RFC4960] specifying the Stream 124 Control Transmission Protocol (SCTP). These defects may be of an 125 editorial or technical nature. This document may be thought of as a 126 companion document to be used in the implementation of SCTP to 127 clarify errors in the original SCTP document. 129 This document provides a history of the changes that will be compiled 130 into a BIS document for [RFC4960]. It is structured similar to 131 [RFC4460]. 133 Each error will be detailed within this document in the form of: 135 o The problem description, 136 o The text quoted from [RFC4960], 137 o The replacement text that should be placed into an upcoming BIS 138 document, 139 o A description of the solution. 141 Note that when reading this document one must use care to assure that 142 a field or item is not updated further on within the document. Each 143 section should be applied in sequence to the original [RFC4960] 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. 148 2. Conventions 150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 152 "OPTIONAL" in this document are to be interpreted as described in 153 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 154 capitals, as shown here. 156 3. Corrections to RFC 4960 158 3.1. Path Error Counter Threshold Handling 160 3.1.1. Description of the Problem 162 The handling of the 'Path.Max.Retrans' parameter is described in 163 Section 8.2 and Section 8.3 of [RFC4960] in an Inconsistent way. 164 Whereas Section 8.2 describes that a path is marked inactive when the 165 path error counter exceeds the threshold, Section 8.3 says the path 166 is marked inactive when the path error counter reaches the threshold. 168 This issue was reported as an Errata for [RFC4960] with Errata ID 169 1440. 171 3.1.2. Text Changes to the Document 172 --------- 173 Old text: (Section 8.3) 174 --------- 176 When the value of this counter reaches the protocol parameter 177 'Path.Max.Retrans', the endpoint should mark the corresponding 178 destination address as inactive if it is not so marked, and may also 179 optionally report to the upper layer the change of reachability of 180 this destination address. After this, the endpoint should continue 181 HEARTBEAT on this destination address but should stop increasing the 182 counter. 184 --------- 185 New text: (Section 8.3) 186 --------- 188 When the value of this counter exceeds the protocol parameter 189 'Path.Max.Retrans', the endpoint SHOULD mark the corresponding 190 destination address as inactive if it is not so marked, and MAY also 191 optionally report to the upper layer the change of reachability of 192 this destination address. After this, the endpoint SHOULD continue 193 HEARTBEAT on this destination address but SHOULD stop increasing the 194 counter. 196 3.1.3. Solution Description 198 The intended state change should happen when the threshold is 199 exceeded. 201 3.2. Upper Layer Protocol Shutdown Request Handling 203 3.2.1. Description of the Problem 205 Section 9.2 of [RFC4960] describes the handling of received SHUTDOWN 206 chunks in the SHUTDOWN-RECEIVED state instead of the handling of 207 shutdown requests from its upper layer in this state. 209 This issue was reported as an Errata for [RFC4960] with Errata ID 210 1574. 212 3.2.2. Text Changes to the Document 213 --------- 214 Old text: (Section 9.2) 215 --------- 217 Once an endpoint has reached the SHUTDOWN-RECEIVED state, it MUST NOT 218 send a SHUTDOWN in response to a ULP request, and should discard 219 subsequent SHUTDOWN chunks. 221 --------- 222 New text: (Section 9.2) 223 --------- 225 Once an endpoint has reached the SHUTDOWN-RECEIVED state, it MUST 226 ignore ULP shutdown requests, but MUST continue responding 227 to SHUTDOWN chunks from its peer. 229 3.2.3. Solution Description 231 The text never intended the SCTP endpoint to ignore SHUTDOWN chunks 232 from its peer. If it did, the endpoints could never gracefully 233 terminate associations in some cases. 235 3.3. Registration of New Chunk Types 237 3.3.1. Description of the Problem 239 Section 14.1 of [RFC4960] should deal with new chunk types, however, 240 the text refers to parameter types. 242 This issue was reported as an Errata for [RFC4960] with Errata ID 243 2592. 245 3.3.2. Text Changes to the Document 246 --------- 247 Old text: (Section 14.1) 248 --------- 250 The assignment of new chunk parameter type codes is done through an 251 IETF Consensus action, as defined in [RFC2434]. Documentation of the 252 chunk parameter MUST contain the following information: 254 --------- 255 New text: (Section 14.1) 256 --------- 258 The assignment of new chunk type codes is done through an 259 IETF Consensus action, as defined in [RFC5226]. Documentation of the 260 chunk type MUST contain the following information: 262 3.3.3. Solution Description 264 Refer to chunk types as intended. 266 3.4. Variable Parameters for INIT Chunks 268 3.4.1. Description of the Problem 270 Newlines in wrong places break the layout of the table of variable 271 parameters for the INIT chunk in Section 3.3.2 of [RFC4960]. 273 This issue was reported as an Errata for [RFC4960] with Errata ID 274 3291 and Errata ID 3804. 276 3.4.2. Text Changes to the Document 277 --------- 278 Old text: (Section 3.3.2) 279 --------- 281 Variable Parameters Status Type Value 282 ------------------------------------------------------------- 283 IPv4 Address (Note 1) Optional 5 IPv6 Address 284 (Note 1) Optional 6 Cookie Preservative 285 Optional 9 Reserved for ECN Capable (Note 2) Optional 286 32768 (0x8000) Host Name Address (Note 3) Optional 287 11 Supported Address Types (Note 4) Optional 12 289 --------- 290 New text: (Section 3.3.2) 291 --------- 293 Variable Parameters Status Type Value 294 ------------------------------------------------------------- 295 IPv4 Address (Note 1) Optional 5 296 IPv6 Address (Note 1) Optional 6 297 Cookie Preservative Optional 9 298 Reserved for ECN Capable (Note 2) Optional 32768 (0x8000) 299 Host Name Address (Note 3) Optional 11 300 Supported Address Types (Note 4) Optional 12 302 3.4.3. Solution Description 304 Fix the formatting of the table. 306 3.5. CRC32c Sample Code on 64-bit Platforms 308 3.5.1. Description of the Problem 310 The sample code for computing the CRC32c provided in [RFC4960] 311 assumes that a variable of type unsigned long uses 32 bits. This is 312 not true on some 64-bit platforms (for example the ones using LP64). 314 This issue was reported as an Errata for [RFC4960] with Errata ID 315 3423. 317 3.5.2. Text Changes to the Document 318 --------- 319 Old text: (Appendix C) 320 --------- 322 unsigned long 323 generate_crc32c(unsigned char *buffer, unsigned int length) 324 { 325 unsigned int i; 326 unsigned long crc32 = ~0L; 328 --------- 329 New 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 = 0xffffffffL; 338 3.5.3. Solution Description 340 Use 0xffffffffL instead of ~0L which gives the same value on 341 platforms using 32 bits or 64 bits for variables of type unsigned 342 long. 344 3.6. Endpoint Failure Detection 346 3.6.1. Description of the Problem 348 The handling of the association error counter defined in Section 8.1 349 of [RFC4960] can result in an association failure even if the path 350 used for data transmission is available, but idle. 352 This issue was reported as an Errata for [RFC4960] with Errata ID 353 3788. 355 3.6.2. Text Changes to the Document 356 --------- 357 Old text: (Section 8.1) 358 --------- 360 An endpoint shall keep a counter on the total number of consecutive 361 retransmissions to its peer (this includes retransmissions to all the 362 destination transport addresses of the peer if it is multi-homed), 363 including unacknowledged HEARTBEAT chunks. 365 --------- 366 New text: (Section 8.1) 367 --------- 369 An endpoint SHOULD keep a counter on the total number of consecutive 370 retransmissions to its peer (this includes data retransmissions 371 to all the destination transport addresses of the peer if it is 372 multi-homed), including the number of unacknowledged HEARTBEAT 373 chunks observed on the path which is currently used for data 374 transfer. Unacknowledged HEARTBEAT chunks observed on paths 375 different from the path currently used for data transfer SHOULD 376 NOT increment the association error counter, as this could lead 377 to association closure even if the path which is currently used for 378 data transfer is available (but idle). 380 3.6.3. Solution Description 382 A more refined handling for the association error counter is defined. 384 3.7. Data Transmission Rules 386 3.7.1. Description of the Problem 388 When integrating the changes to Section 6.1 A) of [RFC2960] as 389 described in Section 2.15.2 of [RFC4460] some text was duplicated and 390 became the final paragraph of Section 6.1 A) of [RFC4960]. 392 This issue was reported as an Errata for [RFC4960] with Errata ID 393 4071. 395 3.7.2. Text Changes to the Document 396 --------- 397 Old text: (Section 6.1 A)) 398 --------- 400 The sender MUST also have an algorithm for sending new DATA chunks 401 to avoid silly window syndrome (SWS) as described in [RFC0813]. 402 The algorithm can be similar to the one described in Section 403 4.2.3.4 of [RFC1122]. 405 However, regardless of the value of rwnd (including if it is 0), 406 the data sender can always have one DATA chunk in flight to the 407 receiver if allowed by cwnd (see rule B below). This rule allows 408 the sender to probe for a change in rwnd that the sender missed 409 due to the SACK having been lost in transit from the data receiver 410 to the data sender. 412 --------- 413 New text: (Section 6.1 A)) 414 --------- 416 The sender MUST also have an algorithm for sending new DATA chunks 417 to avoid silly window syndrome (SWS) as described in [RFC0813]. 418 The algorithm can be similar to the one described in Section 419 4.2.3.4 of [RFC1122]. 421 3.7.3. Solution Description 423 Last paragraph of Section 6.1 A) removed as intended in 424 Section 2.15.2 of [RFC4460]. 426 3.8. T1-Cookie Timer 428 3.8.1. Description of the Problem 430 Figure 4 of [RFC4960] illustrates the SCTP association setup. 431 However, it incorrectly shows that the T1-init timer is used in the 432 COOKIE-ECHOED state whereas the T1-cookie timer should have been used 433 instead. 435 This issue was reported as an Errata for [RFC4960] with Errata ID 436 4400. 438 3.8.2. Text Changes to the Document 439 --------- 440 Old text: (Section 5.1.6, Figure 4) 441 --------- 443 COOKIE ECHO [Cookie_Z] ------\ 444 (Start T1-init timer) \ 445 (Enter COOKIE-ECHOED state) \---> (build TCB enter ESTABLISHED 446 state) 447 /---- COOKIE-ACK 448 / 449 (Cancel T1-init timer, <-----/ 450 Enter ESTABLISHED state) 452 --------- 453 New text: (Section 5.1.6, Figure 4) 454 --------- 456 COOKIE ECHO [Cookie_Z] ------\ 457 (Start T1-cookie timer) \ 458 (Enter COOKIE-ECHOED state) \---> (build TCB enter ESTABLISHED 459 state) 460 /---- COOKIE-ACK 461 / 462 (Cancel T1-cookie timer, <---/ 463 Enter ESTABLISHED state) 465 3.8.3. Solution Description 467 Change the figure such that the T1-cookie timer is used instead of 468 the T1-init timer. 470 3.9. Miscellaneous Typos 472 3.9.1. Description of the Problem 474 While processing [RFC4960] some typos were not caught. 476 3.9.2. Text Changes to the Document 477 --------- 478 Old text: (Section 1.6) 479 --------- 481 Transmission Sequence Numbers wrap around when they reach 2**32 - 1. 482 That is, the next TSN a DATA chunk MUST use after transmitting TSN = 483 2*32 - 1 is TSN = 0. 485 --------- 486 New text: (Section 1.6) 487 --------- 489 Transmission Sequence Numbers wrap around when they reach 2**32 - 1. 490 That is, the next TSN a DATA chunk MUST use after transmitting TSN = 491 2**32 - 1 is TSN = 0. 493 --------- 494 Old text: (Section 3.3.10.9) 495 --------- 497 No User Data: This error cause is returned to the originator of a 499 DATA chunk if a received DATA chunk has no user data. 501 --------- 502 New text: (Section 3.3.10.9) 503 --------- 505 No User Data: This error cause is returned to the originator of a 506 DATA chunk if a received DATA chunk has no user data. 508 --------- 509 Old text: (Section 6.7, Figure 9) 510 --------- 512 Endpoint A Endpoint Z {App 513 sends 3 messages; strm 0} DATA [TSN=6,Strm=0,Seq=2] ---------- 514 -----> (ack delayed) (Start T3-rtx timer) 516 DATA [TSN=7,Strm=0,Seq=3] --------> X (lost) 518 DATA [TSN=8,Strm=0,Seq=4] ---------------> (gap detected, 519 immediately send ack) 520 /----- SACK [TSN Ack=6,Block=1, 521 / Start=2,End=2] 522 <-----/ (remove 6 from out-queue, 523 and mark 7 as "1" missing report) 525 --------- 526 New text: (Section 6.7, Figure 9) 527 --------- 529 Endpoint A Endpoint Z 530 {App sends 3 messages; strm 0} 531 DATA [TSN=6,Strm=0,Seq=2] ---------------> (ack delayed) 532 (Start T3-rtx timer) 534 DATA [TSN=7,Strm=0,Seq=3] --------> X (lost) 536 DATA [TSN=8,Strm=0,Seq=4] ---------------> (gap detected, 537 immediately send ack) 538 /----- SACK [TSN Ack=6,Block=1, 539 / Start=2,End=2] 540 <-----/ 541 (remove 6 from out-queue, 542 and mark 7 as "1" missing report) 544 --------- 545 Old text: (Section 6.10) 546 --------- 548 An endpoint bundles chunks by simply including multiple chunks in one 549 outbound SCTP packet. The total size of the resultant IP datagram, 551 including the SCTP packet and IP headers, MUST be less that or equal 552 to the current Path MTU. 554 --------- 555 New text: (Section 6.10) 556 --------- 558 An endpoint bundles chunks by simply including multiple chunks in one 559 outbound SCTP packet. The total size of the resultant IP datagram, 560 including the SCTP packet and IP headers, MUST be less than or equal 561 to the current PMTU. 563 --------- 564 Old text: (Section 10.1) 565 --------- 567 o Receive Unacknowledged Message 569 Format: RECEIVE_UNACKED(data retrieval id, buffer address, buffer 570 size, [,stream id] [, stream sequence number] [,partial 571 flag] [,payload protocol-id]) 573 --------- 574 New text: (Section 10.1) 575 --------- 577 O) Receive Unacknowledged Message 579 Format: RECEIVE_UNACKED(data retrieval id, buffer address, buffer 580 size [,stream id] [,stream sequence number] [,partial 581 flag] [,payload protocol-id]) 583 --------- 584 Old text: (Section 10.1) 585 --------- 587 M) Set Protocol Parameters 589 Format: SETPROTOCOLPARAMETERS(association id, 590 [,destination transport address,] 591 protocol parameter list) 593 --------- 594 New text: (Section 10.1) 595 --------- 597 M) Set Protocol Parameters 599 Format: SETPROTOCOLPARAMETERS(association id, 600 [destination transport address,] 601 protocol parameter list) 603 --------- 604 Old text: (Appendix C) 605 --------- 607 ICMP2) An implementation MAY ignore all ICMPv6 messages where the 608 type field is not "Destination Unreachable", "Parameter 609 Problem",, or "Packet Too Big". 611 --------- 612 New text: (Appendix C) 613 --------- 615 ICMP2) An implementation MAY ignore all ICMPv6 messages where the 616 type field is not "Destination Unreachable", "Parameter 617 Problem", or "Packet Too Big". 619 --------- 620 Old text: (Appendix C) 621 --------- 623 ICMP7) If the ICMP message is either a v6 "Packet Too Big" or a v4 624 "Fragmentation Needed", an implementation MAY process this 625 information as defined for PATH MTU discovery. 627 --------- 628 New text: (Appendix C) 629 --------- 631 ICMP7) If the ICMP message is either a v6 "Packet Too Big" or a v4 632 "Fragmentation Needed", an implementation MAY process this 633 information as defined for PMTU discovery. 635 --------- 636 Old text: (Section 5.4) 637 --------- 639 2) For the receiver of the COOKIE ECHO, the only CONFIRMED address 640 is the one to which the INIT-ACK was sent. 642 --------- 643 New text: (Section 5.4) 644 --------- 646 2) For the receiver of the COOKIE ECHO, the only CONFIRMED address 647 is the one to which the INIT ACK was sent. 649 --------- 650 Old text: (Section 5.1.6, Figure 4) 651 --------- 653 COOKIE ECHO [Cookie_Z] ------\ 654 (Start T1-init timer) \ 655 (Enter COOKIE-ECHOED state) \---> (build TCB enter ESTABLISHED 656 state) 657 /---- COOKIE-ACK 658 / 659 (Cancel T1-init timer, <-----/ 660 Enter ESTABLISHED state) 662 --------- 663 New text: (Section 5.1.6, Figure 4) 664 --------- 666 COOKIE ECHO [Cookie_Z] ------\ 667 (Start T1-cookie timer) \ 668 (Enter COOKIE-ECHOED state) \---> (build TCB enter ESTABLISHED 669 state) 670 /---- COOKIE ACK 671 / 672 (Cancel T1-cookie timer, <---/ 673 Enter ESTABLISHED state) 675 --------- 676 Old text: (Section 5.2.5) 677 --------- 679 5.2.5. Handle Duplicate COOKIE-ACK. 681 --------- 682 New text: (Section 5.2.5) 683 --------- 685 5.2.5. Handle Duplicate COOKIE ACK. 687 --------- 688 Old text: (Section 8.3) 689 --------- 691 By default, an SCTP endpoint SHOULD monitor the reachability of the 692 idle destination transport address(es) of its peer by sending a 693 HEARTBEAT chunk periodically to the destination transport 694 address(es). HEARTBEAT sending MAY begin upon reaching the 695 ESTABLISHED state and is discontinued after sending either SHUTDOWN 696 or SHUTDOWN-ACK. A receiver of a HEARTBEAT MUST respond to a 697 HEARTBEAT with a HEARTBEAT-ACK after entering the COOKIE-ECHOED state 698 (INIT sender) or the ESTABLISHED state (INIT receiver), up until 699 reaching the SHUTDOWN-SENT state (SHUTDOWN sender) or the SHUTDOWN- 700 ACK-SENT state (SHUTDOWN receiver). 702 --------- 703 New text: (Section 8.3) 704 --------- 705 By default, an SCTP endpoint SHOULD monitor the reachability of the 706 idle destination transport address(es) of its peer by sending a 707 HEARTBEAT chunk periodically to the destination transport 708 address(es). HEARTBEAT sending MAY begin upon reaching the 709 ESTABLISHED state and is discontinued after sending either SHUTDOWN 710 or SHUTDOWN ACK. A receiver of a HEARTBEAT MUST respond to a 711 HEARTBEAT with a HEARTBEAT ACK after entering the COOKIE-ECHOED state 712 (INIT sender) or the ESTABLISHED state (INIT receiver), up until 713 reaching the SHUTDOWN-SENT state (SHUTDOWN sender) or the SHUTDOWN- 714 ACK-SENT state (SHUTDOWN receiver). 716 3.9.3. Solution Description 718 Typos fixed. 720 3.10. CRC32c Sample Code 722 3.10.1. Description of the Problem 724 The CRC32c computation is described in Appendix B of [RFC4960]. 725 However, the corresponding sample code and its explanation appears at 726 the end of Appendix C, which deals with ICMP handling. 728 3.10.2. Text Changes to the Document 730 Move the sample code related to CRC32c computation and its 731 explanation from the end of Appendix C to the end of Appendix B. 733 3.10.3. Solution Description 735 Text moved to the appropriate location. 737 3.11. partial_bytes_acked after T3-rtx Expiration 739 3.11.1. Description of the Problem 741 Section 7.2.3 of [RFC4960] explicitly states that partial_bytes_acked 742 should be reset to 0 after packet loss detection from SACK but the 743 same is missed for T3-rtx timer expiration. 745 3.11.2. Text Changes to the Document 747 --------- 748 Old text: (Section 7.2.3) 749 --------- 751 When the T3-rtx timer expires on an address, SCTP should perform slow 752 start by: 754 ssthresh = max(cwnd/2, 4*MTU) 755 cwnd = 1*MTU 757 --------- 758 New text: (Section 7.2.3) 759 --------- 761 When the T3-rtx timer expires on an address, SCTP SHOULD perform slow 762 start by: 764 ssthresh = max(cwnd/2, 4*MTU) 765 cwnd = 1*MTU 766 partial_bytes_acked = 0 768 3.11.3. Solution Description 770 Specify that partial_bytes_acked should be reset to 0 after T3-rtx 771 timer expiration. 773 3.12. Order of Adjustments of partial_bytes_acked and cwnd 775 3.12.1. Description of the Problem 777 Section 7.2.2 of [RFC4960] is unclear about the order of adjustments 778 applied to partial_bytes_acked and cwnd in the congestion avoidance 779 phase. 781 3.12.2. Text Changes to the Document 783 --------- 784 Old text: (Section 7.2.2) 785 --------- 787 o When partial_bytes_acked is equal to or greater than cwnd and 788 before the arrival of the SACK the sender had cwnd or more bytes 789 of data outstanding (i.e., before arrival of the SACK, flightsize 790 was greater than or equal to cwnd), increase cwnd by MTU, and 791 reset partial_bytes_acked to (partial_bytes_acked - cwnd). 793 --------- 794 New text: (Section 7.2.2) 795 --------- 797 o When partial_bytes_acked is equal to or greater than cwnd and 798 before the arrival of the SACK the sender had cwnd or more bytes 799 of data outstanding (i.e., before arrival of the SACK, flightsize 800 was greater than or equal to cwnd), partial_bytes_acked is reset 801 to (partial_bytes_acked - cwnd). Next, cwnd is increased by 1*MTU. 803 3.12.3. Solution Description 805 The new text defines the exact order of adjustments of 806 partial_bytes_acked and cwnd in the congestion avoidance phase. 808 3.13. HEARTBEAT ACK and the association error counter 810 3.13.1. Description of the Problem 812 Section 8.1 and Section 8.3 of [RFC4960] prescribe that the receiver 813 of a HEARTBEAT ACK must reset the association overall error counter. 814 In some circumstances, e.g. when a router discards DATA chunks but 815 not HEARTBEAT chunks due to the larger size of the DATA chunk, it 816 might be better to not clear the association error counter on 817 reception of the HEARTBEAT ACK and reset it only on reception of the 818 SACK to avoid stalling the association. 820 3.13.2. Text Changes to the Document 821 --------- 822 Old text: (Section 8.1) 823 --------- 825 The counter shall be reset each time a DATA chunk sent to that peer 826 endpoint is acknowledged (by the reception of a SACK) or a HEARTBEAT 827 ACK is received from the peer endpoint. 829 --------- 830 New text: (Section 8.1) 831 --------- 833 The counter SHOULD be reset each time a DATA chunk sent to that peer 834 endpoint is acknowledged (by the reception of a SACK). When a 835 HEARTBEAT ACK is received from the peer endpoint, the counter SHOULD 836 also be reset. The receiver of the HEARTBEAT ACK MAY choose not to 837 clear the counter if there is outstanding data on the association. 838 This allows for handling the possible difference in reachability 839 based on DATA chunks and HEARTBEAT chunks. 841 --------- 842 Old text: (Section 8.3) 843 --------- 845 Upon the receipt of the HEARTBEAT ACK, the sender of the HEARTBEAT 846 should clear the error counter of the destination transport address 847 to which the HEARTBEAT was sent, and mark the destination transport 848 address as active if it is not so marked. The endpoint may 849 optionally report to the upper layer when an inactive destination 850 address is marked as active due to the reception of the latest 851 HEARTBEAT ACK. The receiver of the HEARTBEAT ACK must also clear the 852 association overall error count as well (as defined in Section 8.1). 854 --------- 855 New text: (Section 8.3) 856 --------- 858 Upon the receipt of the HEARTBEAT ACK, the sender of the HEARTBEAT 859 SHOULD clear the error counter of the destination transport address 860 to which the HEARTBEAT was sent, and mark the destination transport 861 address as active if it is not so marked. The endpoint MAY 862 optionally report to the upper layer when an inactive destination 863 address is marked as active due to the reception of the latest 864 HEARTBEAT ACK. The receiver of the HEARTBEAT ACK SHOULD also clear 865 the association overall error counter (as defined in Section 8.1). 867 3.13.3. Solution Description 869 The new text provides a possibility to not reset the association 870 overall error counter when a HEARTBEAT ACK is received if there are 871 valid reasons for it. 873 3.14. Path for Fast Retransmission 875 3.14.1. Description of the Problem 877 [RFC4960] clearly describes where to retransmit data that is timed 878 out when the peer is multi-homed but the same is not stated for fast 879 retransmissions. 881 3.14.2. Text Changes to the Document 883 --------- 884 Old text: (Section 6.4) 885 --------- 887 Furthermore, when its peer is multi-homed, an endpoint SHOULD try to 888 retransmit a chunk that timed out to an active destination transport 889 address that is different from the last destination address to which 890 the DATA chunk was sent. 892 --------- 893 New text: (Section 6.4) 894 --------- 896 Furthermore, when its peer is multi-homed, an endpoint SHOULD try to 897 retransmit a chunk that timed out to an active destination transport 898 address that is different from the last destination address to which 899 the DATA chunk was sent. 901 When its peer is multi-homed, an endpoint SHOULD send fast 902 retransmissions to the same destination transport address where the 903 original data was sent to. If the primary path has been changed and the 904 original data was sent there before the fast retransmit, the 905 implementation MAY send it to the new primary path. 907 3.14.3. Solution Description 909 The new text clarifies where to send fast retransmissions. 911 3.15. Transmittal in Fast Recovery 913 3.15.1. Description of the Problem 915 The Fast Retransmit on Gap Reports algorithm intends that only the 916 very first packet may be sent regardless of cwnd in the Fast Recovery 917 phase but rule 3) of [RFC4960], Section 7.2.4, misses this 918 clarification. 920 3.15.2. Text Changes to the Document 922 --------- 923 Old text: (Section 7.2.4) 924 --------- 926 3) Determine how many of the earliest (i.e., lowest TSN) DATA chunks 927 marked for retransmission will fit into a single packet, subject 928 to constraint of the path MTU of the destination transport 929 address to which the packet is being sent. Call this value K. 930 Retransmit those K DATA chunks in a single packet. When a Fast 931 Retransmit is being performed, the sender SHOULD ignore the value 932 of cwnd and SHOULD NOT delay retransmission for this single 933 packet. 935 --------- 936 New text: (Section 7.2.4) 937 --------- 939 3) If not in Fast Recovery, determine how many of the earliest 940 (i.e., lowest TSN) DATA chunks marked for retransmission will fit 941 into a single packet, subject to constraint of the PMTU of 942 the destination transport address to which the packet is being 943 sent. Call this value K. Retransmit those K DATA chunks in a 944 single packet. When a Fast Retransmit is being performed, the 945 sender SHOULD ignore the value of cwnd and SHOULD NOT delay 946 retransmission for this single packet. 948 3.15.3. Solution Description 950 The new text explicitly specifies to send only the first packet in 951 the Fast Recovery phase disregarding cwnd limitations. 953 3.16. Initial Value of ssthresh 954 3.16.1. Description of the Problem 956 The initial value of ssthresh should be set arbitrarily high. Using 957 the advertised receiver window of the peer is inappropriate if the 958 peer increases its window after the handshake. Furthermore, use a 959 higher requirements level, since not following the advice may result 960 in performance problems. 962 3.16.2. Text Changes to the Document 964 --------- 965 Old text: (Section 7.2.1) 966 --------- 968 o The initial value of ssthresh MAY be arbitrarily high (for 969 example, implementations MAY use the size of the receiver 970 advertised window). 972 --------- 973 New text: (Section 7.2.1) 974 --------- 976 o The initial value of ssthresh SHOULD be arbitrarily high (e.g., 977 the size of the largest possible advertised window). 979 3.16.3. Solution Description 981 Use the same value as suggested in [RFC5681], Section 3.1, as an 982 appropriate initial value. Furthermore, use the same requirements 983 level. 985 3.17. Automatically Confirmed Addresses 987 3.17.1. Description of the Problem 989 The Path Verification procedure of [RFC4960] prescribes that any 990 address passed to the sender of the INIT by its upper layer is 991 automatically CONFIRMED. This, however, is unclear if only addresses 992 in the request to initiate association establishment are considered 993 or any addresses provided by the upper layer in any requests (e.g. in 994 'Set Primary'). 996 3.17.2. Text Changes to the Document 997 --------- 998 Old text: (Section 5.4) 999 --------- 1001 1) Any address passed to the sender of the INIT by its upper layer 1002 is automatically considered to be CONFIRMED. 1004 --------- 1005 New text: (Section 5.4) 1006 --------- 1008 1) Any addresses passed to the sender of the INIT by its upper 1009 layer in the request to initialize an association are 1010 automatically considered to be CONFIRMED. 1012 3.17.3. Solution Description 1014 The new text clarifies that only addresses provided by the upper 1015 layer in the request to initialize an association are automatically 1016 confirmed. 1018 3.18. Only One Packet after Retransmission Timeout 1020 3.18.1. Description of the Problem 1022 [RFC4960] is not completely clear when it describes data transmission 1023 after T3-rtx timer expiration. Section 7.2.1 does not specify how 1024 many packets are allowed to be sent after T3-rtx timer expiration if 1025 more than one packet fit into cwnd. At the same time, Section 7.2.3 1026 has the text without normative language saying that SCTP should 1027 ensure that no more than one packet will be in flight after T3-rtx 1028 timer expiration until successful acknowledgment. It makes the text 1029 inconsistent. 1031 3.18.2. Text Changes to the Document 1032 --------- 1033 Old text: (Section 7.2.1) 1034 --------- 1036 o The initial cwnd after a retransmission timeout MUST be no more 1037 than 1*MTU. 1039 --------- 1040 New text: (Section 7.2.1) 1041 --------- 1043 o The initial cwnd after a retransmission timeout MUST be no more 1044 than 1*MTU and only one packet is allowed to be in flight 1045 until successful acknowledgement. 1047 3.18.3. Solution Description 1049 The new text clearly specifies that only one packet is allowed to be 1050 sent after T3-rtx timer expiration until successful acknowledgement. 1052 3.19. INIT ACK Path for INIT in COOKIE-WAIT State 1054 3.19.1. Description of the Problem 1056 In case of an INIT received in the COOKIE-WAIT state [RFC4960] 1057 prescribes to send an INIT ACK to the same destination address to 1058 which the original INIT has been sent. This text does not address 1059 the possibility of the upper layer to provide multiple remote IP 1060 addresses while requesting the association establishment. If the 1061 upper layer has provided multiple IP addresses and only a subset of 1062 these addresses are supported by the peer then the destination 1063 address of the original INIT may be absent in the incoming INIT and 1064 sending INIT ACK to that address is useless. 1066 3.19.2. Text Changes to the Document 1067 --------- 1068 Old text: (Section 5.2.1) 1069 --------- 1071 Upon receipt of an INIT in the COOKIE-WAIT state, an endpoint MUST 1072 respond with an INIT ACK using the same parameters it sent in its 1073 original INIT chunk (including its Initiate Tag, unchanged). When 1074 responding, the endpoint MUST send the INIT ACK back to the same 1075 address that the original INIT (sent by this endpoint) was sent. 1077 --------- 1078 New text: (Section 5.2.1) 1079 --------- 1081 Upon receipt of an INIT in the COOKIE-WAIT state, an endpoint MUST 1082 respond with an INIT ACK using the same parameters it sent in its 1083 original INIT chunk (including its Initiate Tag, unchanged). When 1084 responding, the following rules MUST be applied: 1086 1) The INIT ACK MUST only be sent to an address passed by the upper 1087 layer in the request to initialize the association. 1089 2) The INIT ACK MUST only be sent to an address reported in the 1090 incoming INIT. 1092 3) The INIT ACK SHOULD be sent to the source address of the 1093 received INIT. 1095 3.19.3. Solution Description 1097 The new text requires sending INIT ACK to a destination address that 1098 is passed by the upper layer and reported in the incoming INIT. If 1099 the source address of the INIT meets these conditions, sending the 1100 INIT ACK to the source address of the INIT is the preferred behavior. 1102 3.20. Zero Window Probing and Unreachable Primary Path 1104 3.20.1. Description of the Problem 1106 Section 6.1 of [RFC4960] states that when sending zero window probes, 1107 SCTP should neither increment the association counter nor increment 1108 the destination address error counter if it continues to receive new 1109 packets from the peer. However, the reception of new packets from 1110 the peer does not guarantee the peer's reachability and, if the 1111 destination address becomes unreachable during zero window probing, 1112 SCTP cannot get an updated rwnd until it switches the destination 1113 address for probes. 1115 3.20.2. Text Changes to the Document 1117 --------- 1118 Old text: (Section 6.1) 1119 --------- 1121 If the sender continues to receive new packets from the receiver 1122 while doing zero window probing, the unacknowledged window probes 1123 should not increment the error counter for the association or any 1124 destination transport address. This is because the receiver MAY 1125 keep its window closed for an indefinite time. Refer to Section 1126 6.2 on the receiver behavior when it advertises a zero window. 1128 --------- 1129 New text: (Section 6.1) 1130 --------- 1132 If the sender continues to receive SACKs from the peer 1133 while doing zero window probing, the unacknowledged window probes 1134 SHOULD NOT increment the error counter for the association or any 1135 destination transport address. This is because the receiver could 1136 keep its window closed for an indefinite time. Section 6.2 describes 1137 the receiver behavior when it advertises a zero window. 1139 3.20.3. Solution Description 1141 The new text clarifies that if the receiver continues to send SACKs, 1142 the sender of probes should not increment the error counter of the 1143 association and the destination address even if the SACKs do not 1144 acknowledge the probes. 1146 3.21. Normative Language in Section 10 1148 3.21.1. Description of the Problem 1150 Section 10 of [RFC4960] is informative and, therefore, normative 1151 language such as MUST and MAY cannot be used there. However, there 1152 are several places in Section 10 where MUST and MAY are used. 1154 3.21.2. Text Changes to the Document 1156 --------- 1157 Old text: (Section 10.1) 1158 --------- 1160 E) Send 1162 Format: SEND(association id, buffer address, byte count [,context] 1164 [,stream id] [,life time] [,destination transport address] 1165 [,unordered flag] [,no-bundle flag] [,payload protocol-id] ) 1166 -> result 1168 ... 1170 o no-bundle flag - instructs SCTP not to bundle this user data with 1171 other outbound DATA chunks. SCTP MAY still bundle even when this 1172 flag is present, when faced with network congestion. 1174 --------- 1175 New text: (Section 10.1) 1176 --------- 1178 E) Send 1180 Format: SEND(association id, buffer address, byte count [,context] 1181 [,stream id] [,life time] [,destination transport address] 1182 [,unordered flag] [,no-bundle flag] [,payload protocol-id] ) 1183 -> result 1185 ... 1187 o no-bundle flag - instructs SCTP not to bundle this user data with 1188 other outbound DATA chunks. SCTP may still bundle even when this 1189 flag is present, when faced with network congestion. 1191 --------- 1192 Old text: (Section 10.1) 1193 --------- 1195 G) Receive 1197 Format: RECEIVE(association id, buffer address, buffer size 1198 [,stream id]) 1199 -> byte count [,transport address] [,stream id] [,stream sequence 1200 number] [,partial flag] [,delivery number] [,payload protocol-id] 1202 ... 1204 o partial flag - if this returned flag is set to 1, then this 1205 Receive contains a partial delivery of the whole message. When 1206 this flag is set, the stream id and Stream Sequence Number MUST 1207 accompany this receive. When this flag is set to 0, it indicates 1208 that no more deliveries will be received for this Stream Sequence 1209 Number. 1211 --------- 1212 New text: (Section 10.1) 1213 --------- 1215 G) Receive 1217 Format: RECEIVE(association id, buffer address, buffer size 1218 [,stream id]) 1219 -> byte count [,transport address] [,stream id] [,stream sequence 1220 number] [,partial flag] [,delivery number] [,payload protocol-id] 1222 ... 1224 o partial flag - if this returned flag is set to 1, then this 1225 Receive contains a partial delivery of the whole message. When 1226 this flag is set, the stream id and Stream Sequence Number must 1227 accompany this receive. When this flag is set to 0, it indicates 1228 that no more deliveries will be received for this Stream Sequence 1229 Number. 1231 --------- 1232 Old text: (Section 10.1) 1233 --------- 1235 N) Receive Unsent Message 1237 Format: RECEIVE_UNSENT(data retrieval id, buffer address, buffer 1238 size [,stream id] [, stream sequence number] [,partial 1239 flag] [,payload protocol-id]) 1241 ... 1243 o partial flag - if this returned flag is set to 1, then this 1244 message is a partial delivery of the whole message. When this 1245 flag is set, the stream id and Stream Sequence Number MUST 1246 accompany this receive. When this flag is set to 0, it indicates 1247 that no more deliveries will be received for this Stream Sequence 1248 Number. 1250 --------- 1251 New text: (Section 10.1) 1252 --------- 1254 N) Receive Unsent Message 1256 Format: RECEIVE_UNSENT(data retrieval id, buffer address, buffer 1257 size [,stream id] [, stream sequence number] [,partial 1258 flag] [,payload protocol-id]) 1260 ... 1262 o partial flag - if this returned flag is set to 1, then this 1263 message is a partial delivery of the whole message. When this 1264 flag is set, the stream id and Stream Sequence Number must 1265 accompany this receive. When this flag is set to 0, it indicates 1266 that no more deliveries will be received for this Stream Sequence 1267 Number. 1269 --------- 1270 Old text: (Section 10.1) 1271 --------- 1273 O) Receive Unacknowledged Message 1275 Format: RECEIVE_UNACKED(data retrieval id, buffer address, buffer 1276 size [,stream id] [,stream sequence number] [,partial 1277 flag] [,payload protocol-id]) 1279 ... 1281 o partial flag - if this returned flag is set to 1, then this 1282 message is a partial delivery of the whole message. When this 1283 flag is set, the stream id and Stream Sequence Number MUST 1284 accompany this receive. When this flag is set to 0, it indicates 1285 that no more deliveries will be received for this Stream Sequence 1286 Number. 1288 --------- 1289 New text: (Section 10.1) 1290 --------- 1292 O) Receive Unacknowledged Message 1294 Format: RECEIVE_UNACKED(data retrieval id, buffer address, buffer 1295 size [,stream id] [,stream sequence number] [,partial 1296 flag] [,payload protocol-id]) 1298 ... 1300 o partial flag - if this returned flag is set to 1, then this 1301 message is a partial delivery of the whole message. When this 1302 flag is set, the stream id and Stream Sequence Number must 1303 accompany this receive. When this flag is set to 0, it indicates 1304 that no more deliveries will be received for this Stream Sequence 1305 Number. 1307 3.21.3. Solution Description 1309 The normative language is removed from Section 10. 1311 3.22. Increase of partial_bytes_acked in Congestion Avoidance 1313 3.22.1. Description of the Problem 1315 Two issues have been discovered with the partial_bytes_acked handling 1316 described in Section 7.2.2 of [RFC4960]: 1318 o If the Cumulative TSN Ack Point is not advanced but the SACK chunk 1319 acknowledges new TSNs in the Gap Ack Blocks, these newly 1320 acknowledged TSNs are not considered for partial_bytes_acked 1321 although these TSNs were successfully received by the peer. 1322 o Duplicate TSNs are not considered in partial_bytes_acked although 1323 they confirm that the DATA chunks were successfully received by 1324 the peer. 1326 3.22.2. Text Changes to the Document 1328 --------- 1329 Old text: (Section 7.2.2) 1330 --------- 1332 o Whenever cwnd is greater than ssthresh, upon each SACK arrival 1333 that advances the Cumulative TSN Ack Point, increase 1334 partial_bytes_acked by the total number of bytes of all new chunks 1335 acknowledged in that SACK including chunks acknowledged by the new 1336 Cumulative TSN Ack and by Gap Ack Blocks. 1338 --------- 1339 New text: (Section 7.2.2) 1340 --------- 1342 o Whenever cwnd is greater than ssthresh, upon each SACK arrival, 1343 increase partial_bytes_acked by the total number of bytes of all 1344 new chunks acknowledged in that SACK including chunks acknowledged 1345 by the new Cumulative TSN Ack, by Gap Ack Blocks and by the number 1346 of bytes of duplicated chunks reported in Duplicate TSNs. 1348 3.22.3. Solution Description 1350 Now partial_bytes_acked is increased by TSNs reported as duplicated 1351 as well as TSNs newly acknowledged in Gap Ack Blocks even if the 1352 Cumulative TSN Ack Point is not advanced. 1354 3.23. Inconsistency in Notifications Handling 1356 3.23.1. Description of the Problem 1358 [RFC4960] uses inconsistent normative and non-normative language when 1359 describing rules for sending notifications to the upper layer. E.g. 1360 Section 8.2 of [RFC4960] says that when a destination address becomes 1361 inactive due to an unacknowledged DATA chunk or HEARTBEAT chunk, SCTP 1362 SHOULD send a notification to the upper layer while Section 8.3 of 1363 [RFC4960] says that when a destination address becomes inactive due 1364 to an unacknowledged HEARTBEAT chunk, SCTP may send a notification to 1365 the upper layer. 1367 This makes the text inconsistent. 1369 3.23.2. Text Changes to the Document 1371 The following change is based on the change described in Section 3.6. 1373 --------- 1374 Old text: (Section 8.1) 1375 --------- 1377 An endpoint shall keep a counter on the total number of consecutive 1378 retransmissions to its peer (this includes data retransmissions 1379 to all the destination transport addresses of the peer if it is 1380 multi-homed), including the number of unacknowledged HEARTBEAT 1381 chunks observed on the path which currently is used for data 1382 transfer. Unacknowledged HEARTBEAT chunks observed on paths 1383 different from the path currently used for data transfer shall 1384 not increment the association error counter, as this could lead 1385 to association closure even if the path which currently is used for 1386 data transfer is available (but idle). If the value of this 1387 counter exceeds the limit indicated in the protocol parameter 1388 'Association.Max.Retrans', the endpoint shall consider the peer 1389 endpoint unreachable and shall stop transmitting any more data to it 1390 (and thus the association enters the CLOSED state). In addition, the 1391 endpoint MAY report the failure to the upper layer and optionally 1392 report back all outstanding user data remaining in its outbound 1393 queue. The association is automatically closed when the peer 1394 endpoint becomes unreachable. 1396 --------- 1397 New text: (Section 8.1) 1398 --------- 1400 An endpoint SHOULD keep a counter on the total number of consecutive 1401 retransmissions to its peer (this includes data retransmissions 1402 to all the destination transport addresses of the peer if it is 1403 multi-homed), including the number of unacknowledged HEARTBEAT 1404 chunks observed on the path which currently is used for data 1405 transfer. Unacknowledged HEARTBEAT chunks observed on paths 1406 different from the path currently used for data transfer SHOULD 1407 NOT increment the association error counter, as this could lead 1408 to association closure even if the path which currently is used for 1409 data transfer is available (but idle). If the value of this 1410 counter exceeds the limit indicated in the protocol parameter 1411 'Association.Max.Retrans', the endpoint SHOULD consider the peer 1412 endpoint unreachable and SHALL stop transmitting any more data to it 1413 (and thus the association enters the CLOSED state). In addition, the 1414 endpoint SHOULD report the failure to the upper layer and optionally 1415 report back all outstanding user data remaining in its outbound 1416 queue. The association is automatically closed when the peer 1417 endpoint becomes unreachable. 1419 The following changes are based on [RFC4960]. 1421 --------- 1422 Old text: (Section 8.2) 1423 --------- 1425 When an outstanding TSN is acknowledged or a HEARTBEAT sent to that 1426 address is acknowledged with a HEARTBEAT ACK, the endpoint shall 1427 clear the error counter of the destination transport address to which 1428 the DATA chunk was last sent (or HEARTBEAT was sent). When the peer 1429 endpoint is multi-homed and the last chunk sent to it was a 1430 retransmission to an alternate address, there exists an ambiguity as 1431 to whether or not the acknowledgement should be credited to the 1432 address of the last chunk sent. However, this ambiguity does not 1433 seem to bear any significant consequence to SCTP behavior. If this 1434 ambiguity is undesirable, the transmitter may choose not to clear the 1435 error counter if the last chunk sent was a retransmission. 1437 --------- 1438 New text: (Section 8.2) 1439 --------- 1441 When an outstanding TSN is acknowledged or a HEARTBEAT sent to that 1442 address is acknowledged with a HEARTBEAT ACK, the endpoint SHOULD 1443 clear the error counter of the destination transport address to which 1444 the DATA chunk was last sent (or HEARTBEAT was sent), and SHOULD 1445 also report to the upper layer when an inactive destination address 1446 is marked as active. When the peer endpoint is multi-homed and the 1447 last chunk sent to it was a retransmission to an alternate address, 1448 there exists an ambiguity as to whether or not the acknowledgement 1449 could be credited to the address of the last chunk sent. However, 1450 this ambiguity does not seem to bear any significant consequence to 1451 SCTP behavior. If this ambiguity is undesirable, the transmitter MAY 1452 choose not to clear the error counter if the last chunk sent was a 1453 retransmission. 1455 --------- 1456 Old text: (Section 8.3) 1457 --------- 1459 When the value of this counter reaches the protocol parameter 1460 'Path.Max.Retrans', the endpoint should mark the corresponding 1461 destination address as inactive if it is not so marked, and may also 1462 optionally report to the upper layer the change of reachability of 1463 this destination address. After this, the endpoint should continue 1464 HEARTBEAT on this destination address but should stop increasing the 1465 counter. 1467 --------- 1468 New text: (Section 8.3) 1469 --------- 1471 When the value of this counter exceeds the protocol parameter 1472 'Path.Max.Retrans', the endpoint SHOULD mark the corresponding 1473 destination address as inactive if it is not so marked, and SHOULD 1474 also report to the upper layer the change of reachability of this 1475 destination address. After this, the endpoint SHOULD continue 1476 HEARTBEAT on this destination address but SHOULD stop increasing the 1477 counter. 1479 --------- 1480 Old text: (Section 8.3) 1481 --------- 1483 Upon the receipt of the HEARTBEAT ACK, the sender of the HEARTBEAT 1484 should clear the error counter of the destination transport address 1485 to which the HEARTBEAT was sent, and mark the destination transport 1486 address as active if it is not so marked. The endpoint may 1487 optionally report to the upper layer when an inactive destination 1488 address is marked as active due to the reception of the latest 1489 HEARTBEAT ACK. The receiver of the HEARTBEAT ACK must also clear the 1490 association overall error count as well (as defined in Section 8.1). 1492 --------- 1493 New text: (Section 8.3) 1494 --------- 1496 Upon the receipt of the HEARTBEAT ACK, the sender of the HEARTBEAT 1497 SHOULD clear the error counter of the destination transport address 1498 to which the HEARTBEAT was sent, and mark the destination transport 1499 address as active if it is not so marked. The endpoint SHOULD 1500 report to the upper layer when an inactive destination address 1501 is marked as active due to the reception of the latest 1502 HEARTBEAT ACK. The receiver of the HEARTBEAT ACK SHOULD also clear 1503 the association overall error counter (as defined in Section 8.1). 1505 --------- 1506 Old text: (Section 9.2) 1507 --------- 1509 An endpoint should limit the number of retransmissions of the 1510 SHUTDOWN chunk to the protocol parameter 'Association.Max.Retrans'. 1511 If this threshold is exceeded, the endpoint should destroy the TCB 1512 and MUST report the peer endpoint unreachable to the upper layer (and 1513 thus the association enters the CLOSED state). 1515 --------- 1516 New text: (Section 9.2) 1517 --------- 1519 An endpoint SHOULD limit the number of retransmissions of the 1520 SHUTDOWN chunk to the protocol parameter 'Association.Max.Retrans'. 1521 If this threshold is exceeded, the endpoint SHOULD destroy the TCB 1522 and SHOULD report the peer endpoint unreachable to the upper layer 1523 (and thus the association enters the CLOSED state). 1525 --------- 1526 Old text: (Section 9.2) 1527 --------- 1529 The sender of the SHUTDOWN ACK should limit the number of 1530 retransmissions of the SHUTDOWN ACK chunk to the protocol parameter 1531 'Association.Max.Retrans'. If this threshold is exceeded, the 1532 endpoint should destroy the TCB and may report the peer endpoint 1533 unreachable to the upper layer (and thus the association enters the 1534 CLOSED state). 1536 --------- 1537 New text: (Section 9.2) 1538 --------- 1540 The sender of the SHUTDOWN ACK SHOULD limit the number of 1541 retransmissions of the SHUTDOWN ACK chunk to the protocol parameter 1542 'Association.Max.Retrans'. If this threshold is exceeded, the 1543 endpoint SHOULD destroy the TCB and SHOULD report the peer endpoint 1544 unreachable to the upper layer (and thus the association enters the 1545 CLOSED state). 1547 3.23.3. Solution Description 1549 The inconsistencies are removed by using consistently SHOULD. 1551 3.24. SACK.Delay Not Listed as a Protocol Parameter 1553 3.24.1. Description of the Problem 1555 SCTP as specified in [RFC4960] supports delaying SACKs. The timer 1556 value for this is a parameter and Section 6.2 of [RFC4960] specifies 1557 a default and maximum value for it. However, defining a name for 1558 this parameter and listing it in the table of protocol parameters in 1559 Section 15 of [RFC4960] is missing. 1561 This issue was reported as an Errata for [RFC4960] with Errata ID 1562 4656. 1564 3.24.2. Text Changes to the Document 1566 --------- 1567 Old text: (Section 6.2) 1568 --------- 1570 An implementation MUST NOT allow the maximum delay to be configured 1571 to be more than 500 ms. In other words, an implementation MAY lower 1572 this value below 500 ms but MUST NOT raise it above 500 ms. 1574 --------- 1575 New text: (Section 6.2) 1576 --------- 1578 An implementation MUST NOT allow the maximum delay (protocol 1579 parameter 'SACK.Delay') to be configured to be more than 500 ms. 1580 In other words, an implementation MAY lower the value of 1581 SACK.Delay below 500 ms but MUST NOT raise it above 500 ms. 1583 --------- 1584 Old text: (Section 15) 1585 --------- 1587 The following protocol parameters are RECOMMENDED: 1589 RTO.Initial - 3 seconds 1590 RTO.Min - 1 second 1591 RTO.Max - 60 seconds 1592 Max.Burst - 4 1593 RTO.Alpha - 1/8 1594 RTO.Beta - 1/4 1595 Valid.Cookie.Life - 60 seconds 1596 Association.Max.Retrans - 10 attempts 1597 Path.Max.Retrans - 5 attempts (per destination address) 1598 Max.Init.Retransmits - 8 attempts 1599 HB.interval - 30 seconds 1600 HB.Max.Burst - 1 1602 --------- 1603 New text: (Section 15) 1604 --------- 1606 The following protocol parameters are RECOMMENDED: 1608 RTO.Initial - 3 seconds 1609 RTO.Min - 1 second 1610 RTO.Max - 60 seconds 1611 Max.Burst - 4 1612 RTO.Alpha - 1/8 1613 RTO.Beta - 1/4 1614 Valid.Cookie.Life - 60 seconds 1615 Association.Max.Retrans - 10 attempts 1616 Path.Max.Retrans - 5 attempts (per destination address) 1617 Max.Init.Retransmits - 8 attempts 1618 HB.interval - 30 seconds 1619 HB.Max.Burst - 1 1620 SACK.Delay - 200 milliseconds 1622 3.24.3. Solution Description 1624 The parameter was given a name and added to the list of protocol 1625 parameters. 1627 3.25. Processing of Chunks in an Incoming SCTP Packet 1629 3.25.1. Description of the Problem 1631 There are a few places in [RFC4960] where the receiver of a packet 1632 must discard it while processing the chunks of the packet. It is 1633 unclear whether the receiver has to rollback state changes already 1634 performed while processing the packet or not. 1636 The intention of [RFC4960] is to process an incoming packet chunk by 1637 chunk and not to perform any prescreening of chunks in the received 1638 packet. Thus, by discarding one chunk the receiver also causes 1639 discarding of all further chunks. 1641 3.25.2. Text Changes to the Document 1643 --------- 1644 Old text: (Section 3.2) 1645 --------- 1647 00 - Stop processing this SCTP packet and discard it, do not 1648 process any further chunks within it. 1650 01 - Stop processing this SCTP packet and discard it, do not 1651 process any further chunks within it, and report the 1652 unrecognized chunk in an 'Unrecognized Chunk Type'. 1654 --------- 1655 New text: (Section 3.2) 1656 --------- 1658 00 - Stop processing this SCTP packet, discard the unrecognized 1659 chunk and all further chunks. 1661 01 - Stop processing this SCTP packet, discard the unrecognized 1662 chunk and all further chunks, and report the unrecognized 1663 chunk in an 'Unrecognized Chunk Type'. 1665 --------- 1666 Old text: (Section 11.3) 1667 --------- 1669 It is helpful for some firewalls if they can inspect just the first 1670 fragment of a fragmented SCTP packet and unambiguously determine 1671 whether it corresponds to an INIT chunk (for further information, 1672 please refer to [RFC1858]). Accordingly, we stress the requirements, 1673 stated in Section 3.1, that (1) an INIT chunk MUST NOT be bundled 1674 with any other chunk in a packet, and (2) a packet containing an INIT 1675 chunk MUST have a zero Verification Tag. Furthermore, we require 1676 that the receiver of an INIT chunk MUST enforce these rules by 1677 silently discarding an arriving packet with an INIT chunk that is 1678 bundled with other chunks or has a non-zero verification tag and 1679 contains an INIT-chunk. 1681 --------- 1682 New text: (Section 11.3) 1683 --------- 1685 It is helpful for some firewalls if they can inspect just the first 1686 fragment of a fragmented SCTP packet and unambiguously determine 1687 whether it corresponds to an INIT chunk (for further information, 1688 please refer to [RFC1858]). Accordingly, we stress the requirements, 1689 stated in Section 3.1, that (1) an INIT chunk MUST NOT be bundled 1690 with any other chunk in a packet, and (2) a packet containing an INIT 1691 chunk MUST have a zero Verification Tag. 1692 The receiver of an INIT chunk MUST silently discard the INIT chunk and all 1693 further chunks if the INIT chunk is bundled with other chunks or the packet 1694 has a non-zero verification tag. 1696 3.25.3. Solution Description 1698 The new text makes it clear that chunks can be processed from the 1699 beginning to the end and no rollback or pre-screening is required. 1701 3.26. CWND Increase in Congestion Avoidance Phase 1703 3.26.1. Description of the Problem 1705 [RFC4960] in Section 7.2.2 prescribes to increase cwnd by 1*MTU per 1706 RTT if the sender has cwnd or more bytes of data outstanding to the 1707 corresponding address in the Congestion Avoidance phase. However, 1708 this is described without normative language. Moreover, 1709 Section 7.2.2 includes an algorithm how an implementation can achieve 1710 this but this algorithm is underspecified and actually allows 1711 increasing cwnd by more than 1*MTU per RTT. 1713 3.26.2. Text Changes to the Document 1715 --------- 1716 Old text: (Section 7.2.2) 1717 --------- 1719 When cwnd is greater than ssthresh, cwnd should be incremented by 1720 1*MTU per RTT if the sender has cwnd or more bytes of data 1721 outstanding for the corresponding transport address. 1723 --------- 1724 New text: (Section 7.2.2) 1725 --------- 1727 When cwnd is greater than ssthresh, cwnd SHOULD be incremented by 1728 1*MTU per RTT if the sender has cwnd or more bytes of data 1729 outstanding for the corresponding transport address. The basic 1730 guidelines for incrementing cwnd during congestion avoidance are: 1732 o SCTP MAY increment cwnd by 1*MTU. 1734 o SCTP SHOULD increment cwnd by one 1*MTU once per RTT when 1735 the sender has cwnd or more bytes of data outstanding for 1736 the corresponding transport address. 1738 o SCTP MUST NOT increment cwnd by more than 1*MTU per RTT. 1740 --------- 1741 Old text: (Section 7.2.2) 1742 --------- 1744 o Whenever cwnd is greater than ssthresh, upon each SACK arrival 1745 that advances the Cumulative TSN Ack Point, increase 1746 partial_bytes_acked by the total number of bytes of all new chunks 1747 acknowledged in that SACK including chunks acknowledged by the new 1748 Cumulative TSN Ack and by Gap Ack Blocks. 1750 o When partial_bytes_acked is equal to or greater than cwnd and 1751 before the arrival of the SACK the sender had cwnd or more bytes 1752 of data outstanding (i.e., before arrival of the SACK, flightsize 1753 was greater than or equal to cwnd), increase cwnd by MTU, and 1754 reset partial_bytes_acked to (partial_bytes_acked - cwnd). 1756 --------- 1757 New text: (Section 7.2.2) 1758 --------- 1760 o Whenever cwnd is greater than ssthresh, upon each SACK arrival, 1761 increase partial_bytes_acked by the total number of bytes of all 1762 new chunks acknowledged in that SACK including chunks acknowledged 1763 by the new Cumulative TSN Ack, by Gap Ack Blocks and by the number 1764 of bytes of duplicated chunks reported in Duplicate TSNs. 1766 o When partial_bytes_acked is greater than cwnd and before the 1767 arrival of the SACK the sender had less than cwnd bytes of data outstanding 1768 (i.e., before arrival of the SACK, flightsize was less 1769 than cwnd), reset partial_bytes_acked to cwnd. 1771 o When partial_bytes_acked is equal to or greater than cwnd and 1772 before the arrival of the SACK the sender had cwnd or more bytes 1773 of data outstanding (i.e., before arrival of the SACK, flightsize 1774 was greater than or equal to cwnd), partial_bytes_acked is reset 1775 to (partial_bytes_acked - cwnd). Next, cwnd is increased by 1*MTU. 1777 3.26.3. Solution Description 1779 The basic guidelines for incrementing cwnd during the congestion 1780 avoidance phase are added into Section 7.2.2. The guidelines include 1781 the normative language and are aligned with [RFC5681]. 1783 The algorithm from Section 7.2.2 is improved to not allow increasing 1784 cwnd by more than 1*MTU per RTT. 1786 3.27. Refresh of cwnd and ssthresh after Idle Period 1788 3.27.1. Description of the Problem 1790 [RFC4960] prescribes to adjust cwnd per RTO if the endpoint does not 1791 transmit data on a given transport address. In addition to that, it 1792 prescribes to set cwnd to the initial value after a sufficiently long 1793 idle period. The latter is excessive. Moreover, it is unclear what 1794 is a sufficiently long idle period. 1796 [RFC4960] doesn't specify the handling of ssthresh in the idle case. 1797 If ssthresh is reduced due to a packet loss, ssthresh is never 1798 recovered. So traffic can end up in Congestion Avoidance all the 1799 time, resulting in a low sending rate and bad performance. The 1800 problem is even more serious for SCTP because in a multi-homed SCTP 1801 association traffic that switches back to the previously failed 1802 primary path will also lead to the situation where traffic ends up in 1803 Congestion Avoidance. 1805 3.27.2. Text Changes to the Document 1807 --------- 1808 Old text: (Section 7.2.1) 1809 --------- 1811 o The initial cwnd before DATA transmission or after a sufficiently 1812 long idle period MUST be set to min(4*MTU, max (2*MTU, 4380 1813 bytes)). 1815 --------- 1816 New text: (Section 7.2.1) 1817 --------- 1819 o The initial cwnd before DATA transmission MUST be set to 1820 min(4*MTU, max (2*MTU, 4380 bytes)). 1822 --------- 1823 Old text: (Section 7.2.1) 1824 --------- 1826 o When the endpoint does not transmit data on a given transport 1827 address, the cwnd of the transport address should be adjusted to 1828 max(cwnd/2, 4*MTU) per RTO. 1830 --------- 1831 New text: (Section 7.2.1) 1832 --------- 1833 o When the endpoint does not transmit data on a given transport 1834 address, the cwnd of the transport address SHOULD be adjusted to 1835 max(cwnd/2, 4*MTU) per RTO. At the first cwnd adjustment, the 1836 ssthresh of the transport address SHOULD be adjusted to the cwnd. 1838 3.27.3. Solution Description 1840 A rule about cwnd adjustment after a sufficiently long idle period is 1841 removed. 1843 The text is updated to refresh ssthresh after the idle period. When 1844 the idle period is detected, the cwnd value is stored to the ssthresh 1845 value. 1847 3.28. Window Updates After Receiver Window Opens Up 1848 3.28.1. Description of the Problem 1850 The sending of SACK chunks for window updates is only indirectly 1851 referenced in [RFC4960], Section 6.2, where it is stated that an SCTP 1852 receiver must not generate more than one SACK for every incoming 1853 packet, other than to update the offered window. 1855 However, the sending of window updates when the receiver window opens 1856 up is necessary to avoid performance problems. 1858 3.28.2. Text Changes to the Document 1860 --------- 1861 Old text: (Section 6.2) 1862 --------- 1864 An SCTP receiver MUST NOT generate more than one SACK for every 1865 incoming packet, other than to update the offered window as the 1866 receiving application consumes new data. 1868 --------- 1869 New text: (Section 6.2) 1870 --------- 1872 An SCTP receiver MUST NOT generate more than one SACK for every 1873 incoming packet, other than to update the offered window as the 1874 receiving application consumes new data. When the window opens 1875 up, an SCTP receiver SHOULD send additional SACK chunks to update 1876 the window even if no new data is received. The receiver MUST avoid 1877 sending large bursts of window updates. 1879 3.28.3. Solution Description 1881 The new text makes clear that additional SACK chunks for window 1882 updates should be sent as long as excessive bursts are avoided. 1884 3.29. Path of DATA and Reply Chunks 1886 3.29.1. Description of the Problem 1888 Section 6.4 of [RFC4960] describes the transmission policy for multi- 1889 homed SCTP endpoints. However, there are the following issues with 1890 it: 1892 o It states that a SACK should be sent to the source address of an 1893 incoming DATA. However, it is known that other SACK policies 1894 (e.g. sending SACKs always to the primary path) may be more 1895 beneficial in some situations. 1896 o Initially it states that an endpoint should always transmit DATA 1897 chunks to the primary path. Then it states that the rule for 1898 transmittal of reply chunks should also be followed if the 1899 endpoint is bundling DATA chunks together with the reply chunk 1900 which contradicts with the first statement to always transmit DATA 1901 chunks to the primary path. Some implementations were having 1902 problems with it and sent DATA chunks bundled with reply chunks to 1903 a different destination address than the primary path that caused 1904 many gaps. 1906 3.29.2. Text Changes to the Document 1908 --------- 1909 Old text: (Section 6.4) 1910 --------- 1912 An endpoint SHOULD transmit reply chunks (e.g., SACK, HEARTBEAT ACK, 1913 etc.) to the same destination transport address from which it 1914 received the DATA or control chunk to which it is replying. This 1915 rule should also be followed if the endpoint is bundling DATA chunks 1916 together with the reply chunk. 1918 However, when acknowledging multiple DATA chunks received in packets 1919 from different source addresses in a single SACK, the SACK chunk may 1920 be transmitted to one of the destination transport addresses from 1921 which the DATA or control chunks being acknowledged were received. 1923 --------- 1924 New text: (Section 6.4) 1925 --------- 1927 An endpoint SHOULD transmit reply chunks (e.g., INIT ACK, COOKIE ACK, 1928 HEARTBEAT ACK, etc.) in response to control chunks to the same 1929 destination transport address from which it received the control 1930 chunk to which it is replying. 1932 The selection of the destination transport address for packets 1933 containing SACK chunks is implementation dependent. However, an endpoint 1934 SHOULD NOT vary the destination transport address of a SACK when it 1935 receives DATA chunks coming from the same source address. 1937 When acknowledging multiple DATA chunks received in packets 1938 from different source addresses in a single SACK, the SACK chunk MAY 1939 be transmitted to one of the destination transport addresses from 1940 which the DATA or control chunks being acknowledged were received. 1942 3.29.3. Solution Description 1944 The SACK transmission policy is left implementation dependent but it 1945 is specified to not vary the destination address of a packet 1946 containing a SACK chunk unless there are reasons for it as it may 1947 negatively impact RTT measurement. 1949 A confusing statement that prescribes to follow the rule for 1950 transmittal of reply chunks when the endpoint is bundling DATA chunks 1951 together with the reply chunk is removed. 1953 3.30. Outstanding Data, Flightsize and Data In Flight Key Terms 1955 3.30.1. Description of the Problem 1957 [RFC4960] uses outstanding data, flightsize and data in flight key 1958 terms in formulas and statements but their definitions are not 1959 provided in Section 1.3. Furthermore, outstanding data does not 1960 include DATA chunks which are classified as lost but which have not 1961 been retransmitted yet and there is a paragraph in Section 6.1 of 1962 [RFC4960] where this statement is broken. 1964 3.30.2. Text Changes to the Document 1966 --------- 1967 Old text: (Section 1.3) 1968 --------- 1970 o Congestion window (cwnd): An SCTP variable that limits the data, 1971 in number of bytes, a sender can send to a particular destination 1972 transport address before receiving an acknowledgement. 1974 ... 1976 o Outstanding TSN (at an SCTP endpoint): A TSN (and the associated 1977 DATA chunk) that has been sent by the endpoint but for which it 1978 has not yet received an acknowledgement. 1980 --------- 1981 New text: (Section 1.3) 1982 --------- 1984 o Outstanding TSN (at an SCTP endpoint): A TSN (and the associated 1985 DATA chunk) that has been sent by the endpoint but for which it 1986 has not yet received an acknowledgement. 1988 o Outstanding data (or Data outstanding or Data in flight): The 1989 total amount of the DATA chunks associated with outstanding TSNs. 1991 A retransmitted DATA chunk is counted once in outstanding data. 1992 A DATA chunk which is classified as lost but which has not been 1993 retransmitted yet is not in outstanding data. 1995 o Flightsize: The amount of bytes of outstanding data to a 1996 particular destination transport address at any given time. 1998 o Congestion window (cwnd): An SCTP variable that limits outstanding 1999 data, in number of bytes, a sender can send to a particular 2000 destination transport address before receiving an acknowledgement. 2002 --------- 2003 Old text: (Section 6.1) 2004 --------- 2006 C) When the time comes for the sender to transmit, before sending new 2007 DATA chunks, the sender MUST first transmit any outstanding DATA 2008 chunks that are marked for retransmission (limited by the current 2009 cwnd). 2011 --------- 2012 New text: (Section 6.1) 2013 --------- 2015 C) When the time comes for the sender to transmit, before sending new 2016 DATA chunks, the sender MUST first transmit any DATA chunks that 2017 are marked for retransmission (limited by the current cwnd). 2019 3.30.3. Solution Description 2021 Now Section 1.3, Key Terms, includes explanations of outstanding 2022 data, data in flight and flightsize key terms. Section 6.1 is 2023 corrected to properly use the outstanding data term. 2025 3.31. CWND Degradation due to Max.Burst 2027 3.31.1. Description of the Problem 2029 Some implementations were experiencing a degradation of cwnd because 2030 of the Max.Burst limit. This was due to misinterpretation of the 2031 suggestion in [RFC4960], Section 6.1, on how to use the Max.Burst 2032 parameter when calculating the number of packets to transmit. 2034 3.31.2. Text Changes to the Document 2035 --------- 2036 Old text: (Section 6.1) 2037 --------- 2039 D) When the time comes for the sender to transmit new DATA chunks, 2040 the protocol parameter Max.Burst SHOULD be used to limit the 2041 number of packets sent. The limit MAY be applied by adjusting 2042 cwnd as follows: 2044 if((flightsize + Max.Burst*MTU) < cwnd) cwnd = flightsize + 2045 Max.Burst*MTU 2047 Or it MAY be applied by strictly limiting the number of packets 2048 emitted by the output routine. 2050 --------- 2051 New text: (Section 6.1) 2052 --------- 2054 D) When the time comes for the sender to transmit new DATA chunks, 2055 the protocol parameter Max.Burst SHOULD be used to limit the 2056 number of packets sent. The limit MAY be applied by adjusting 2057 cwnd temporarily as follows: 2059 if ((flightsize + Max.Burst*MTU) < cwnd) 2060 cwnd = flightsize + Max.Burst*MTU 2062 Or it MAY be applied by strictly limiting the number of packets 2063 emitted by the output routine. When calculating the number of 2064 packets to transmit and particularly using the formula above, 2065 cwnd SHOULD NOT be changed permanently. 2067 3.31.3. Solution Description 2069 The new text clarifies that cwnd should not be changed when applying 2070 the Max.Burst limit. This mitigates packet bursts related to the 2071 reception of SACK chunks, but not bursts related to an application 2072 sending a burst of user messages. 2074 3.32. Reduction of RTO.Initial 2076 3.32.1. Description of the Problem 2078 [RFC4960] uses 3 seconds as the default value for RTO.Initial in 2079 accordance with Section 4.3.2.1 of [RFC1122]. [RFC6298] updates 2080 [RFC1122] and lowers the initial value of the retransmission timer 2081 from 3 seconds to 1 second. 2083 3.32.2. Text Changes to the Document 2085 --------- 2086 Old text: (Section 15) 2087 --------- 2089 The following protocol parameters are RECOMMENDED: 2091 RTO.Initial - 3 seconds 2092 RTO.Min - 1 second 2093 RTO.Max - 60 seconds 2094 Max.Burst - 4 2095 RTO.Alpha - 1/8 2096 RTO.Beta - 1/4 2097 Valid.Cookie.Life - 60 seconds 2098 Association.Max.Retrans - 10 attempts 2099 Path.Max.Retrans - 5 attempts (per destination address) 2100 Max.Init.Retransmits - 8 attempts 2101 HB.interval - 30 seconds 2102 HB.Max.Burst - 1 2103 SACK.Delay - 200 milliseconds 2105 --------- 2106 New text: (Section 15) 2107 --------- 2109 The following protocol parameters are RECOMMENDED: 2111 RTO.Initial - 1 second 2112 RTO.Min - 1 second 2113 RTO.Max - 60 seconds 2114 Max.Burst - 4 2115 RTO.Alpha - 1/8 2116 RTO.Beta - 1/4 2117 Valid.Cookie.Life - 60 seconds 2118 Association.Max.Retrans - 10 attempts 2119 Path.Max.Retrans - 5 attempts (per destination address) 2120 Max.Init.Retransmits - 8 attempts 2121 HB.interval - 30 seconds 2122 HB.Max.Burst - 1 2123 SACK.Delay - 200 milliseconds 2125 3.32.3. Solution Description 2127 The value RTO.Initial has been lowered to 1 second to be in tune with 2128 [RFC6298]. 2130 3.33. Ordering of Bundled SACK and ERROR Chunks 2132 3.33.1. Description of the Problem 2134 When an SCTP endpoint receives a DATA chunk with an invalid stream 2135 identifier it shall acknowledge it by sending a SACK chunk and 2136 indicate that the stream identifier was invalid by sending an ERROR 2137 chunk. These two chunks may be bundled. However, [RFC4960] requires 2138 in case of bundling that the ERROR chunk follows the SACK chunk. 2139 This restriction of the ordering is not necessary and might only 2140 limit interoperability. 2142 3.33.2. Text Changes to the Document 2144 --------- 2145 Old text: (Section 6.5) 2146 --------- 2148 Every DATA chunk MUST carry a valid stream identifier. If an 2149 endpoint receives a DATA chunk with an invalid stream identifier, it 2150 shall acknowledge the reception of the DATA chunk following the 2151 normal procedure, immediately send an ERROR chunk with cause set to 2152 "Invalid Stream Identifier" (see Section 3.3.10), and discard the 2153 DATA chunk. The endpoint may bundle the ERROR chunk in the same 2154 packet as the SACK as long as the ERROR follows the SACK. 2156 --------- 2157 New text: (Section 6.5) 2158 --------- 2160 Every DATA chunk MUST carry a valid stream identifier. If an 2161 endpoint receives a DATA chunk with an invalid stream identifier, it 2162 SHOULD acknowledge the reception of the DATA chunk following the 2163 normal procedure, immediately send an ERROR chunk with cause set to 2164 "Invalid Stream Identifier" (see Section 3.3.10), and discard the 2165 DATA chunk. The endpoint MAY bundle the ERROR chunk and the SACK Chunk 2166 in the same packet. 2168 3.33.3. Solution Description 2170 The unnecessary restriction regarding the ordering of the SACK and 2171 ERROR chunk has been removed. 2173 3.34. Undefined Parameter Returned by RECEIVE Primitive 2174 3.34.1. Description of the Problem 2176 [RFC4960] provides a description of an abstract API. In the 2177 definition of the RECEIVE primitive an optional parameter with name 2178 "delivery number" is mentioned. However, no definition of this 2179 parameter is given in [RFC4960] and the parameter is unnecessary. 2181 3.34.2. Text Changes to the Document 2183 --------- 2184 Old text: (Section 10.1) 2185 --------- 2187 G) Receive 2189 Format: RECEIVE(association id, buffer address, buffer size 2190 [,stream id]) 2191 -> byte count [,transport address] [,stream id] [,stream sequence 2192 number] [,partial flag] [,delivery number] [,payload protocol-id] 2194 --------- 2195 New text: (Section 10.1) 2196 --------- 2198 G) Receive 2200 Format: RECEIVE(association id, buffer address, buffer size 2201 [,stream id]) 2202 -> byte count [,transport address] [,stream id] [,stream sequence 2203 number] [,partial flag] [,payload protocol-id] 2205 3.34.3. Solution Description 2207 The undefined parameter has been removed. 2209 3.35. DSCP Changes 2211 3.35.1. Description of the Problem 2213 The upper layer can change the Differentiated Services Code Point 2214 (DSCP) used for packets being sent. A change of the DSCP can result 2215 in packets hitting different queues on the path and, therefore, the 2216 congestion control should be initialized when the DSCP is changed by 2217 the upper layer. This is not described in [RFC4960]. 2219 3.35.2. Text Changes to the Document 2221 --------- 2222 New text: (Section 7.2.5) 2223 --------- 2225 SCTP implementations MAY allow an application to configure the 2226 Differentiated Services Code Point (DSCP) used for sending packets. 2227 If a DSCP change might result in outgoing packets being queued in 2228 different queues, the congestion control parameters for all affected 2229 destination addresses MUST be reset to their initial values. 2231 --------- 2232 Old text: (Section 10.1) 2233 --------- 2235 M) Set Protocol Parameters 2237 Format: SETPROTOCOLPARAMETERS(association id, 2238 [,destination transport address,] 2239 protocol parameter list) 2240 -> result 2242 This primitive allows the local SCTP to customize the protocol 2243 parameters. 2245 Mandatory attributes: 2247 o association id - local handle to the SCTP association. 2249 o protocol parameter list - the specific names and values of the 2250 protocol parameters (e.g., Association.Max.Retrans; see Section 2251 15) that the SCTP user wishes to customize. 2253 --------- 2254 Old text: (Section 10.1) 2255 --------- 2257 M) Set Protocol Parameters 2259 Format: SETPROTOCOLPARAMETERS(association id, 2260 [,destination transport address,] 2261 protocol parameter list) 2262 -> result 2264 This primitive allows the local SCTP to customize the protocol 2265 parameters. 2267 Mandatory attributes: 2269 o association id - local handle to the SCTP association. 2271 o protocol parameter list - the specific names and values of the 2272 protocol parameters (e.g., Association.Max.Retrans; see Section 2273 15, or other parameters like the DSCP) that the SCTP user wishes 2274 to customize. 2276 3.35.3. Solution Description 2278 Text describing the required action on DSCP changes has been added. 2280 3.36. Inconsistent Handling of ICMPv4 and ICMPv6 Messages 2282 3.36.1. Description of the Problem 2284 Appendix C of [RFC4960] describes the handling of ICMPv4 and ICMPv6 2285 messages. The text explicitly describes the handling of ICMPv6 2286 packets indicating reachability problems, but does not do the same 2287 for the corresponding ICMPv4 packets. 2289 3.36.2. Text Changes to the Document 2290 --------- 2291 Old text: (Appendix C) 2292 --------- 2294 ICMP3) An implementation MAY ignore any ICMPv4 messages where the 2295 code does not indicate "Protocol Unreachable" or 2296 "Fragmentation Needed". 2298 --------- 2299 New text: 2300 --------- 2302 ICMP3) An implementation SHOULD ignore any ICMPv4 messages where the 2303 code indicates "Port Unreachable". 2305 --------- 2306 Old text: (Appendix C) 2307 --------- 2309 ICMP9) If the ICMPv6 code is "Destination Unreachable", the 2310 implementation MAY mark the destination into the unreachable 2311 state or alternatively increment the path error counter. 2313 --------- 2314 New text: 2315 --------- 2317 ICMP9) If the ICMP type is "Destination Unreachable", the 2318 implementation MAY mark the destination into the unreachable 2319 state or alternatively increment the path error counter. 2321 3.36.3. Solution Description 2323 The text has been changed to not limit the processing of ICMPv4 2324 packets with type "Destination Unreachable" by rewording the third 2325 rule. Furthermore, remove the limitation to ICMPv6 in the ninth 2326 rule. 2328 3.37. Handling of Soft Errors 2330 3.37.1. Description of the Problem 2332 [RFC1122] defines the handling of soft errors and hard errors for 2333 TCP. Appendix C of [RFC4960] only deals with hard errors. 2335 3.37.2. Text Changes to the Document 2337 --------- 2338 Old text: (Appendix C) 2339 --------- 2341 ICMP8) If the ICMP type is "Destination Unreachable", the 2342 implementation MAY mark the destination into the unreachable 2343 state or alternatively increment the path error counter. 2345 --------- 2346 New text: (Appendix C) 2347 --------- 2349 ICMP8) If the ICMP type is "Destination Unreachable", the 2350 implementation MAY mark the destination into the unreachable 2351 state or alternatively increment the path error counter. 2352 SCTP MAY provide information to the upper layer indicating 2353 the reception of ICMP messages when reporting a network status 2354 change. 2356 3.37.3. Solution Description 2358 Text has been added allowing SCTP to notify the application in case 2359 of soft errors. 2361 3.38. Honoring CWND 2363 3.38.1. Description of the Problem 2365 When using the slow start algorithm, SCTP increases the congestion 2366 window only when it is being fully utilized. Since SCTP uses DATA 2367 chunks and does not use the congestion window to fragment user 2368 messages, this requires that some overbooking of the congestion 2369 window is allowed. 2371 3.38.2. Text Changes to the Document 2372 --------- 2373 Old text: (Section 6.1) 2374 --------- 2376 B) At any given time, the sender MUST NOT transmit new data to a 2377 given transport address if it has cwnd or more bytes of data 2378 outstanding to that transport address. 2380 --------- 2381 New text: (Section 6.1) 2382 --------- 2384 B) At any given time, the sender MUST NOT transmit new data to a 2385 given transport address if it has cwnd + (PMTU - 1) or more bytes 2386 of data outstanding to that transport address. If data is 2387 available the sender SHOULD exceed cwnd by up to (PMTU-1) bytes on 2388 a new data transmission if the flightsize does not currently reach 2389 cwnd. The breach of cwnd MUST constitute one packet only. 2391 --------- 2392 Old text: (Section 7.2.1) 2393 --------- 2395 o Whenever cwnd is greater than zero, the endpoint is allowed to 2396 have cwnd bytes of data outstanding on that transport address. 2398 --------- 2399 New text: (Section 7.2.1) 2400 --------- 2401 o Whenever cwnd is greater than zero, the endpoint is allowed to 2402 have cwnd bytes of data outstanding on that transport address. 2403 A limited overbooking as described in B) of Section 6.1 SHOULD 2404 be supported. 2406 3.38.3. Solution Description 2408 Text was added to clarify how the cwnd limit should be handled. 2410 3.39. Zero Window Probing 2412 3.39.1. Description of the Problem 2414 The text describing zero window probing was not clearly handling the 2415 case where the window was not zero, but too small for the next DATA 2416 chunk to be transmitted. Even in this case, zero window probing has 2417 to be performed to avoid deadlocks. 2419 3.39.2. Text Changes to the Document 2421 --------- 2422 Old text: (Section 6.1) 2423 --------- 2425 A) At any given time, the data sender MUST NOT transmit new data to 2426 any destination transport address if its peer's rwnd indicates 2427 that the peer has no buffer space (i.e., rwnd is 0; see Section 2428 6.2.1). However, regardless of the value of rwnd (including if it 2429 is 0), the data sender can always have one DATA chunk in flight to 2430 the receiver if allowed by cwnd (see rule B, below). This rule 2431 allows the sender to probe for a change in rwnd that the sender 2432 missed due to the SACK's having been lost in transit from the data 2433 receiver to the data sender. 2435 When the receiver's advertised window is zero, this probe is 2436 called a zero window probe. Note that a zero window probe SHOULD 2437 only be sent when all outstanding DATA chunks have been 2438 cumulatively acknowledged and no DATA chunks are in flight. Zero 2439 window probing MUST be supported. 2441 --------- 2442 New text: (Section 6.1) 2443 --------- 2445 A) At any given time, the data sender MUST NOT transmit new data to 2446 any destination transport address if its peer's rwnd indicates 2447 that the peer has no buffer space (i.e., rwnd is smaller than the 2448 size of the next DATA chunk; see Section 6.2.1). 2449 However, regardless of the value of rwnd (including if it is 0), 2450 the data sender can always have one DATA chunk in flight to 2451 the receiver if allowed by cwnd (see rule B, below). This rule 2452 allows the sender to probe for a change in rwnd that the sender 2453 missed due to the SACK's having been lost in transit from the data 2454 receiver to the data sender. 2456 When the receiver has no buffer space, this probe is 2457 called a zero window probe. Note that a zero window probe SHOULD 2458 only be sent when all outstanding DATA chunks have been 2459 cumulatively acknowledged and no DATA chunks are in flight. Zero 2460 window probing MUST be supported. 2462 3.39.3. Solution Description 2464 The terminology is used in a cleaner way. 2466 3.40. Updating References Regarding ECN 2468 3.40.1. Description of the Problem 2470 [RFC4960] refers for ECN only to [RFC3168], which will be updated by 2471 [RFC8311]. This needs to be reflected when referring to ECN. 2473 3.40.2. Text Changes to the Document 2475 --------- 2476 Old text: (Appendix A) 2477 --------- 2479 ECN [RFC3168] describes a proposed extension to IP that details a 2480 method to become aware of congestion outside of datagram loss. 2482 --------- 2483 New text: (Appendix A) 2484 --------- 2486 ECN as specified in [RFC3168] updated by [RFC8311] describes a proposed 2487 extension to IP that details a method to become aware of congestion 2488 outside of datagram loss. 2490 --------- 2491 Old text: (Appendix A) 2492 --------- 2494 In general, [RFC3168] should be followed with the following 2495 exceptions. 2497 --------- 2498 New text: (Appendix A) 2499 --------- 2501 In general, [RFC3168] updated by [RFC8311] SHOULD be followed with the 2502 following exceptions. 2504 --------- 2505 Old text: (Appendix A) 2506 --------- 2508 [RFC3168] details negotiation of ECN during the SYN and SYN-ACK 2509 stages of a TCP connection. 2511 --------- 2512 New text: (Appendix A) 2513 --------- 2515 [RFC3168] updated by [RFC8311] details negotiation of ECN during the 2516 SYN and SYN-ACK stages of a TCP connection. 2518 --------- 2519 Old text: (Appendix A) 2520 --------- 2522 [RFC3168] details a specific bit for a receiver to send back in its 2523 TCP acknowledgements to notify the sender of the Congestion 2524 Experienced (CE) bit having arrived from the network. 2526 --------- 2527 New text: (Appendix A) 2528 --------- 2530 [RFC3168] updated by [RFC8311] details a specific bit for a receiver 2531 to send back in its TCP acknowledgements to notify the sender of the 2532 Congestion Experienced (CE) bit having arrived from the network. 2534 --------- 2535 Old text: (Appendix A) 2536 --------- 2538 [RFC3168] details a specific bit for a sender to send in the header 2539 of its next outbound TCP segment to indicate to its peer that it has 2540 reduced its congestion window. 2541 --------- 2542 New text: (Appendix A) 2543 --------- 2545 [RFC3168] updated by [RFC8311] details a specific bit for a sender 2546 to send in the header of its next outbound TCP segment to indicate to 2547 its peer that it has reduced its congestion window. 2549 3.40.3. Solution Description 2551 References to [RFC8311] have been added. 2553 3.41. Host Name Address Parameter Deprecated 2555 3.41.1. Description of the Problem 2557 [RFC4960] defines three types of address parameters to be used with 2558 INIT and INIT ACK chunks: 2560 1. IPv4 Address parameters. 2561 2. IPv6 Address parameters. 2562 3. Host Name Address parameters. 2564 The first two are supported by the SCTP kernel implementations of 2565 FreeBSD, Linux and Solaris, but the third one is not. In addition, 2566 the first two where successfully tested in all nine interoperability 2567 tests for SCTP, but the third one has never been successfully tested. 2568 Therefore, the Host Name Address parameter should be deprecated. 2570 3.41.2. Text Changes to the Document 2572 --------- 2573 Old text: (Section 3.3.2) 2574 --------- 2576 Note 3: An INIT chunk MUST NOT contain more than one Host Name 2577 Address parameter. Moreover, the sender of the INIT MUST NOT combine 2578 any other address types with the Host Name Address in the INIT. The 2579 receiver of INIT MUST ignore any other address types if the Host Name 2580 Address parameter is present in the received INIT chunk. 2582 --------- 2583 New text: (Section 3.3.2) 2584 --------- 2586 Note 3: An INIT chunk MUST NOT contain the Host Name Address 2587 parameter. The receiver of an INIT chunk containing a Host Name 2588 Address parameter MUST send an ABORT and MAY include an Error Cause 2589 indicating an Unresolvable Address. 2591 --------- 2592 Old text: (Section 3.3.2.1) 2593 --------- 2595 The sender of INIT uses this parameter to pass its Host Name (in 2596 place of its IP addresses) to its peer. The peer is responsible for 2597 resolving the name. Using this parameter might make it more likely 2598 for the association to work across a NAT box. 2600 --------- 2601 New text: (Section 3.3.2.1) 2602 --------- 2604 The sender of an INIT chunk MUST NOT include this parameter. The 2605 usage of the Host Name Address parameter is deprecated. 2607 --------- 2608 Old text: (Section 3.3.2.1) 2609 --------- 2611 Address Type: 16 bits (unsigned integer) 2612 This is filled with the type value of the corresponding address 2613 TLV (e.g., IPv4 = 5, IPv6 = 6, Host name = 11). 2615 --------- 2616 New text: (Section 3.3.2.1) 2617 --------- 2618 Address Type: 16 bits (unsigned integer) 2620 This is filled with the type value of the corresponding address 2621 TLV (e.g., IPv4 = 5, IPv6 = 6). The value indicating the Host 2622 Name Address parameter (Host name = 11) MUST NOT be used. 2624 --------- 2625 Old text: (Section 3.3.3) 2626 --------- 2628 Note 3: The INIT ACK chunks MUST NOT contain more than one Host Name 2629 Address parameter. Moreover, the sender of the INIT ACK MUST NOT 2630 combine any other address types with the Host Name Address in the 2631 INIT ACK. The receiver of the INIT ACK MUST ignore any other address 2632 types if the Host Name Address parameter is present. 2634 --------- 2635 New text: (Section 3.3.3) 2636 --------- 2638 Note 3: An INIT ACK chunk MUST NOT contain the Host Name Address 2639 parameter. The receiver of INIT ACK chunks containing a Host Name 2640 Address parameter MUST send an ABORT and MAY include an Error Cause 2641 indicating an Unresolvable Address. 2643 --------- 2644 Old text: (Section 5.1.2) 2645 --------- 2647 B) If there is a Host Name parameter present in the received INIT or 2648 INIT ACK chunk, the endpoint shall resolve that host name to a 2649 list of IP address(es) and derive the transport address(es) of 2650 this peer by combining the resolved IP address(es) with the SCTP 2651 source port. 2653 The endpoint MUST ignore any other IP Address parameters if they 2654 are also present in the received INIT or INIT ACK chunk. 2656 The time at which the receiver of an INIT resolves the host name 2657 has potential security implications to SCTP. If the receiver of 2658 an INIT resolves the host name upon the reception of the chunk, 2659 and the mechanism the receiver uses to resolve the host name 2660 involves potential long delay (e.g., DNS query), the receiver may 2661 open itself up to resource attacks for the period of time while it 2662 is waiting for the name resolution results before it can build the 2663 State Cookie and release local resources. 2665 Therefore, in cases where the name translation involves potential 2666 long delay, the receiver of the INIT MUST postpone the name 2667 resolution till the reception of the COOKIE ECHO chunk from the 2668 peer. In such a case, the receiver of the INIT SHOULD build the 2669 State Cookie using the received Host Name (instead of destination 2670 transport addresses) and send the INIT ACK to the source IP 2671 address from which the INIT was received. 2673 The receiver of an INIT ACK shall always immediately attempt to 2674 resolve the name upon the reception of the chunk. 2676 The receiver of the INIT or INIT ACK MUST NOT send user data 2677 (piggy-backed or stand-alone) to its peer until the host name is 2678 successfully resolved. 2680 If the name resolution is not successful, the endpoint MUST 2681 immediately send an ABORT with "Unresolvable Address" error cause 2682 to its peer. The ABORT shall be sent to the source IP address 2683 from which the last peer packet was received. 2685 --------- 2686 New text: (Section 5.1.2) 2687 --------- 2689 B) If there is a Host Name parameter present in the received INIT or 2690 INIT ACK chunk, the endpoint MUST immediately send an ABORT and 2691 MAY include an Error Cause indicating an Unresolvable Address to 2692 its peer. The ABORT SHALL be sent to the source IP address 2693 from which the last peer packet was received. 2695 --------- 2696 Old text: (Section 11.2.4.1) 2697 --------- 2699 The use of the host name feature in the INIT chunk could be used to 2700 flood a target DNS server. A large backlog of DNS queries, resolving 2701 the host name received in the INIT chunk to IP addresses, could be 2702 accomplished by sending INITs to multiple hosts in a given domain. 2703 In addition, an attacker could use the host name feature in an 2704 indirect attack on a third party by sending large numbers of INITs to 2705 random hosts containing the host name of the target. In addition to 2706 the strain on DNS resources, this could also result in large numbers 2707 of INIT ACKs being sent to the target. One method to protect against 2708 this type of attack is to verify that the IP addresses received from 2709 DNS include the source IP address of the original INIT. If the list 2710 of IP addresses received from DNS does not include the source IP 2711 address of the INIT, the endpoint MAY silently discard the INIT. 2712 This last option will not protect against the attack against the DNS. 2714 --------- 2715 New text: (Section 11.2.4.1) 2716 --------- 2718 The support of the Host Name Address parameter has been removed from 2719 the protocol. Endpoints receiving INIT or INIT ACK chunks containing 2720 the Host Name Address parameter MUST send an ABORT chunk in response 2721 and MAY include an Error Cause indicating an Unresolvable Address. 2723 3.41.3. Solution Description 2725 The usage of the Host Name Address parameter has been deprecated. 2727 3.42. Conflicting Text Regarding the Supported Address Types Parameter 2729 3.42.1. Description of the Problem 2731 When receiving an SCTP packet containing an INIT chunk sent from an 2732 address for which the corresponding address type is not listed in the 2733 Supported Address Types, there is conflicting text in Section 5.1.2 2734 of [RFC4960]. It is stated that the association MUST be aborted and 2735 also that the association SHOULD be established and there SHOULD NOT 2736 be any error indication. 2738 3.42.2. Text Changes to the Document 2739 --------- 2740 Old text: (Section 5.1.2) 2741 --------- 2743 The sender of INIT may include a 'Supported Address Types' parameter 2744 in the INIT to indicate what types of address are acceptable. When 2745 this parameter is present, the receiver of INIT (initiate) MUST 2746 either use one of the address types indicated in the Supported 2747 Address Types parameter when responding to the INIT, or abort the 2748 association with an "Unresolvable Address" error cause if it is 2749 unwilling or incapable of using any of the address types indicated by 2750 its peer. 2752 --------- 2753 New text: (Section 5.1.2) 2754 --------- 2756 The sender of INIT chunks MAY include a 'Supported Address Types' parameter 2757 in the INIT to indicate what types of addresses are acceptable. 2759 3.42.3. Solution Description 2761 The conflicting text has been removed. 2763 3.43. Integration of RFC 6096 2765 3.43.1. Description of the Problem 2767 [RFC6096] updates [RFC4960] by adding a Chunk Flags Registry. This 2768 should be integrated into the base specification. 2770 3.43.2. Text Changes to the Document 2772 --------- 2773 Old text: (Section 14.1) 2774 --------- 2776 14.1. IETF-Defined Chunk Extension 2778 The assignment of new chunk parameter type codes is done through an 2779 IETF Consensus action, as defined in [RFC2434]. Documentation of the 2780 chunk parameter MUST contain the following information: 2782 a) A long and short name for the new chunk type. 2784 b) A detailed description of the structure of the chunk, which MUST 2785 conform to the basic structure defined in Section 3.2. 2787 c) A detailed definition and description of the intended use of each 2788 field within the chunk, including the chunk flags if any. 2790 d) A detailed procedural description of the use of the new chunk type 2791 within the operation of the protocol. 2793 The last chunk type (255) is reserved for future extension if 2794 necessary. 2796 --------- 2797 New text: (Section 14.1) 2798 --------- 2800 14.1. IETF-Defined Chunk Extension 2802 The assignment of new chunk type codes is done through an IETF Review 2803 action, as defined in [RFC5226]. Documentation of a new chunk MUST 2804 contain the following information: 2806 a) A long and short name for the new chunk type; 2808 b) A detailed description of the structure of the chunk, which MUST 2809 conform to the basic structure defined in Section 3.2 of 2810 [RFC4960]; 2812 c) A detailed definition and description of the intended use of each 2813 field within the chunk, including the chunk flags if any. 2814 Defined chunk flags will be used as initial entries in the chunk 2815 flags table for the new chunk type; 2817 d) A detailed procedural description of the use of the new chunk 2818 type within the operation of the protocol. 2820 The last chunk type (255) is reserved for future extension if 2821 necessary. 2823 For each new chunk type, IANA creates a registration table for the 2824 chunk flags of that type. The procedure for registering particular 2825 chunk flags is described in the following Section 14.2. 2827 --------- 2828 New text: (Section 14.2) 2829 --------- 2831 14.2. New IETF Chunk Flags Registration 2833 The assignment of new chunk flags is done through an RFC required 2834 action, as defined in [RFC5226]. Documentation of the chunk flags 2835 MUST contain the following information: 2837 a) A name for the new chunk flag; 2839 b) A detailed procedural description of the use of the new chunk 2840 flag within the operation of the protocol. It MUST be considered 2841 that implementations not supporting the flag will send '0' on 2842 transmit and just ignore it on receipt. 2844 IANA selects a chunk flags value. This MUST be one of 0x01, 0x02, 2845 0x04, 0x08, 0x10, 0x20, 0x40, or 0x80, which MUST be unique within 2846 the chunk flag values for the specific chunk type. 2848 Please note that Sections 14.2, 14.3, 14.4, and 14.5 need to be 2849 renumbered. 2851 3.43.3. Solution Description 2853 [RFC6096] was integrated. 2855 3.44. Integration of RFC 6335 2857 3.44.1. Description of the Problem 2859 [RFC6335] updates [RFC4960] by updating Procedures for the Port 2860 Numbers Registry. This should be integrated into the base 2861 specification. While there, update the reference to the RFC giving 2862 guidelines for writing IANA sections to [RFC8126]. 2864 3.44.2. Text Changes to the Document 2866 --------- 2867 Old text: (Section 14.5) 2868 --------- 2870 SCTP services may use contact port numbers to provide service to 2871 unknown callers, as in TCP and UDP. IANA is therefore requested to 2872 open the existing Port Numbers registry for SCTP using the following 2873 rules, which we intend to mesh well with existing Port Numbers 2874 registration procedures. An IESG-appointed Expert Reviewer supports 2875 IANA in evaluating SCTP port allocation requests, according to the 2876 procedure defined in [RFC2434]. 2878 Port numbers are divided into three ranges. The Well Known Ports are 2879 those from 0 through 1023, the Registered Ports are those from 1024 2880 through 49151, and the Dynamic and/or Private Ports are those from 2881 49152 through 65535. Well Known and Registered Ports are intended 2882 for use by server applications that desire a default contact point on 2883 a system. On most systems, Well Known Ports can only be used by 2884 system (or root) processes or by programs executed by privileged 2885 users, while Registered Ports can be used by ordinary user processes 2886 or programs executed by ordinary users. Dynamic and/or Private Ports 2887 are intended for temporary use, including client-side ports, out-of- 2888 band negotiated ports, and application testing prior to registration 2889 of a dedicated port; they MUST NOT be registered. 2891 The Port Numbers registry should accept registrations for SCTP ports 2892 in the Well Known Ports and Registered Ports ranges. Well Known and 2893 Registered Ports SHOULD NOT be used without registration. Although 2894 in some cases -- such as porting an application from TCP to SCTP -- 2895 it may seem natural to use an SCTP port before registration 2896 completes, we emphasize that IANA will not guarantee registration of 2897 particular Well Known and Registered Ports. Registrations should be 2898 requested as early as possible. 2900 Each port registration SHALL include the following information: 2902 o A short port name, consisting entirely of letters (A-Z and a-z), 2903 digits (0-9), and punctuation characters from "-_+./*" (not 2904 including the quotes). 2906 o The port number that is requested for registration. 2908 o A short English phrase describing the port's purpose. 2910 o Name and contact information for the person or entity performing 2911 the registration, and possibly a reference to a document defining 2912 the port's use. Registrations coming from IETF working groups 2913 need only name the working group, but indicating a contact person 2914 is recommended. 2916 Registrants are encouraged to follow these guidelines when submitting 2917 a registration. 2919 o A port name SHOULD NOT be registered for more than one SCTP port 2920 number. 2922 o A port name registered for TCP MAY be registered for SCTP as well. 2923 Any such registration SHOULD use the same port number as the 2924 existing TCP registration. 2926 o Concrete intent to use a port SHOULD precede port registration. 2927 For example, existing TCP ports SHOULD NOT be registered in 2928 advance of any intent to use those ports for SCTP. 2930 --------- 2931 New text: (Section 14.5) 2932 --------- 2934 SCTP services can use contact port numbers to provide service to 2935 unknown callers, as in TCP and UDP. IANA is therefore requested to 2936 open the existing Port Numbers registry for SCTP using the following 2937 rules, which we intend to mesh well with existing Port Numbers 2938 registration procedures. An IESG-appointed Expert Reviewer supports 2939 IANA in evaluating SCTP port allocation requests, according to the 2940 procedure defined in [RFC8126]. The details of this process are 2941 defined in [RFC6335]. 2943 3.44.3. Solution Description 2945 [RFC6335] was integrated and the reference was updated to [RFC8126]. 2947 3.45. Integration of RFC 7053 2949 3.45.1. Description of the Problem 2951 [RFC7053] updates [RFC4960] by adding the I bit to the DATA chunk. 2952 This should be integrated into the base specification. 2954 3.45.2. Text Changes to the Document 2956 --------- 2957 Old text: (Section 3.3.1) 2958 --------- 2960 The following format MUST be used for the DATA chunk: 2962 0 1 2 3 2963 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 2964 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2965 | Type = 0 | Reserved|U|B|E| Length | 2966 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2967 | TSN | 2968 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2969 | Stream Identifier S | Stream Sequence Number n | 2970 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2971 | Payload Protocol Identifier | 2972 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2973 \ \ 2974 / User Data (seq n of Stream S) / 2975 \ \ 2976 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2978 Reserved: 5 bits 2979 Should be set to all '0's and ignored by the receiver. 2981 --------- 2982 New text: (Section 3.3.1) 2983 --------- 2985 0 1 2 3 2986 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 2987 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2988 | Type = 0 | Res |I|U|B|E| Length | 2989 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2990 | TSN | 2991 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2992 | Stream Identifier S | Stream Sequence Number n | 2993 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2994 | Payload Protocol Identifier | 2995 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2996 \ \ 2997 / User Data (seq n of Stream S) / 2998 \ \ 2999 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3001 Res: 4 bits 3003 SHOULD be set to all '0's and ignored by the receiver. 3005 I bit: 1 bit 3007 The (I)mmediate Bit MAY be set by the sender, whenever the sender of 3008 a DATA chunk can benefit from the corresponding SACK chunk being sent 3009 back without delay. See [RFC7053] for a discussion about 3011 --------- 3012 New text: (Append to Section 6.1) 3013 --------- 3015 Whenever the sender of a DATA chunk can benefit from the 3016 corresponding SACK chunk being sent back without delay, the sender 3017 MAY set the I bit in the DATA chunk header. Please note that why the 3018 sender has set the I bit is irrelevant to the receiver. 3020 Reasons for setting the I bit include, but are not limited to (see 3021 Section 4 of [RFC7053] for the benefits): 3023 o The application requests to set the I bit of the last DATA chunk 3024 of a user message when providing the user message to the SCTP 3025 implementation (see Section 7). 3027 o The sender is in the SHUTDOWN-PENDING state. 3029 o The sending of a DATA chunk fills the congestion or receiver 3030 window. 3032 --------- 3033 Old text: (Section 6.2) 3034 --------- 3036 Note: The SHUTDOWN chunk does not contain Gap Ack Block fields. 3037 Therefore, the endpoint should use a SACK instead of the SHUTDOWN 3038 chunk to acknowledge DATA chunks received out of order. 3040 --------- 3041 New text: (Section 6.2) 3042 --------- 3044 Note: The SHUTDOWN chunk does not contain Gap Ack Block fields. 3045 Therefore, the endpoint SHOULD use a SACK instead of the SHUTDOWN 3046 chunk to acknowledge DATA chunks received out of order. 3048 Upon receipt of an SCTP packet containing a DATA chunk with the I bit 3049 set, the receiver SHOULD NOT delay the sending of the corresponding 3050 SACK chunk, i.e., the receiver SHOULD immediately respond with the 3051 corresponding SACK chunk. 3053 --------- 3054 Old text: (Section 10.1) 3055 --------- 3057 E) Send 3059 Format: SEND(association id, buffer address, byte count [,context] 3060 [,stream id] [,life time] [,destination transport address] 3061 [,unordered flag] [,no-bundle flag] [,payload protocol-id] ) 3062 -> result 3064 --------- 3065 New text: (Section 10.1) 3066 --------- 3068 E) Send 3070 Format: SEND(association id, buffer address, byte count [,context] 3071 [,stream id] [,life time] [,destination transport address] 3072 [,unordered flag] [,no-bundle flag] [,payload protocol-id] 3073 [,sack immediately] ) 3075 -> result 3077 --------- 3078 New text: (Append optional parameter in Subsection E of Section 10.1) 3079 --------- 3081 o sack immediately - set the I bit on the last DATA chunk used for 3082 sending buffer. 3084 Please note that the change in Section 6.2 is only about adding a 3085 paragraph. 3087 3.45.3. Solution Description 3089 [RFC7053] was integrated. 3091 3.46. CRC32c Code Improvements 3093 3.46.1. Description of the Problem 3095 The code given for the CRC32c computations uses types like long which 3096 may have different length on different operating systems or 3097 processors. Therefore, the code is changed to use specific types 3098 like uint32_t. 3100 While there, fix also some syntax errors. 3102 3.46.2. Text Changes to the Document 3104 --------- 3105 Old text: (Appendix B) 3106 --------- 3107 /* Example of the crc table file */ 3108 #ifndef __crc32cr_table_h__ 3109 #define __crc32cr_table_h__ 3111 #define CRC32C_POLY 0x1EDC6F41 3112 #define CRC32C(c,d) (c=(c>>8)^crc_c[(c^(d))&0xFF]) 3114 unsigned long crc_c[256] = 3115 { 3116 0x00000000L, 0xF26B8303L, 0xE13B70F7L, 0x1350F3F4L, 3117 0xC79A971FL, 0x35F1141CL, 0x26A1E7E8L, 0xD4CA64EBL, 3118 0x8AD958CFL, 0x78B2DBCCL, 0x6BE22838L, 0x9989AB3BL, 3119 0x4D43CFD0L, 0xBF284CD3L, 0xAC78BF27L, 0x5E133C24L, 3120 0x105EC76FL, 0xE235446CL, 0xF165B798L, 0x030E349BL, 3121 0xD7C45070L, 0x25AFD373L, 0x36FF2087L, 0xC494A384L, 3122 0x9A879FA0L, 0x68EC1CA3L, 0x7BBCEF57L, 0x89D76C54L, 3123 0x5D1D08BFL, 0xAF768BBCL, 0xBC267848L, 0x4E4DFB4BL, 3124 0x20BD8EDEL, 0xD2D60DDDL, 0xC186FE29L, 0x33ED7D2AL, 3125 0xE72719C1L, 0x154C9AC2L, 0x061C6936L, 0xF477EA35L, 3126 0xAA64D611L, 0x580F5512L, 0x4B5FA6E6L, 0xB93425E5L, 3127 0x6DFE410EL, 0x9F95C20DL, 0x8CC531F9L, 0x7EAEB2FAL, 3128 0x30E349B1L, 0xC288CAB2L, 0xD1D83946L, 0x23B3BA45L, 3130 0xF779DEAEL, 0x05125DADL, 0x1642AE59L, 0xE4292D5AL, 3131 0xBA3A117EL, 0x4851927DL, 0x5B016189L, 0xA96AE28AL, 3132 0x7DA08661L, 0x8FCB0562L, 0x9C9BF696L, 0x6EF07595L, 3133 0x417B1DBCL, 0xB3109EBFL, 0xA0406D4BL, 0x522BEE48L, 3134 0x86E18AA3L, 0x748A09A0L, 0x67DAFA54L, 0x95B17957L, 3135 0xCBA24573L, 0x39C9C670L, 0x2A993584L, 0xD8F2B687L, 3136 0x0C38D26CL, 0xFE53516FL, 0xED03A29BL, 0x1F682198L, 3137 0x5125DAD3L, 0xA34E59D0L, 0xB01EAA24L, 0x42752927L, 3138 0x96BF4DCCL, 0x64D4CECFL, 0x77843D3BL, 0x85EFBE38L, 3139 0xDBFC821CL, 0x2997011FL, 0x3AC7F2EBL, 0xC8AC71E8L, 3140 0x1C661503L, 0xEE0D9600L, 0xFD5D65F4L, 0x0F36E6F7L, 3141 0x61C69362L, 0x93AD1061L, 0x80FDE395L, 0x72966096L, 3142 0xA65C047DL, 0x5437877EL, 0x4767748AL, 0xB50CF789L, 3143 0xEB1FCBADL, 0x197448AEL, 0x0A24BB5AL, 0xF84F3859L, 3144 0x2C855CB2L, 0xDEEEDFB1L, 0xCDBE2C45L, 0x3FD5AF46L, 3145 0x7198540DL, 0x83F3D70EL, 0x90A324FAL, 0x62C8A7F9L, 3146 0xB602C312L, 0x44694011L, 0x5739B3E5L, 0xA55230E6L, 3147 0xFB410CC2L, 0x092A8FC1L, 0x1A7A7C35L, 0xE811FF36L, 3148 0x3CDB9BDDL, 0xCEB018DEL, 0xDDE0EB2AL, 0x2F8B6829L, 3149 0x82F63B78L, 0x709DB87BL, 0x63CD4B8FL, 0x91A6C88CL, 3150 0x456CAC67L, 0xB7072F64L, 0xA457DC90L, 0x563C5F93L, 3151 0x082F63B7L, 0xFA44E0B4L, 0xE9141340L, 0x1B7F9043L, 3152 0xCFB5F4A8L, 0x3DDE77ABL, 0x2E8E845FL, 0xDCE5075CL, 3153 0x92A8FC17L, 0x60C37F14L, 0x73938CE0L, 0x81F80FE3L, 3154 0x55326B08L, 0xA759E80BL, 0xB4091BFFL, 0x466298FCL, 3155 0x1871A4D8L, 0xEA1A27DBL, 0xF94AD42FL, 0x0B21572CL, 3156 0xDFEB33C7L, 0x2D80B0C4L, 0x3ED04330L, 0xCCBBC033L, 3157 0xA24BB5A6L, 0x502036A5L, 0x4370C551L, 0xB11B4652L, 3158 0x65D122B9L, 0x97BAA1BAL, 0x84EA524EL, 0x7681D14DL, 3159 0x2892ED69L, 0xDAF96E6AL, 0xC9A99D9EL, 0x3BC21E9DL, 3160 0xEF087A76L, 0x1D63F975L, 0x0E330A81L, 0xFC588982L, 3161 0xB21572C9L, 0x407EF1CAL, 0x532E023EL, 0xA145813DL, 3162 0x758FE5D6L, 0x87E466D5L, 0x94B49521L, 0x66DF1622L, 3163 0x38CC2A06L, 0xCAA7A905L, 0xD9F75AF1L, 0x2B9CD9F2L, 3164 0xFF56BD19L, 0x0D3D3E1AL, 0x1E6DCDEEL, 0xEC064EEDL, 3165 0xC38D26C4L, 0x31E6A5C7L, 0x22B65633L, 0xD0DDD530L, 3166 0x0417B1DBL, 0xF67C32D8L, 0xE52CC12CL, 0x1747422FL, 3167 0x49547E0BL, 0xBB3FFD08L, 0xA86F0EFCL, 0x5A048DFFL, 3168 0x8ECEE914L, 0x7CA56A17L, 0x6FF599E3L, 0x9D9E1AE0L, 3169 0xD3D3E1ABL, 0x21B862A8L, 0x32E8915CL, 0xC083125FL, 3170 0x144976B4L, 0xE622F5B7L, 0xF5720643L, 0x07198540L, 3171 0x590AB964L, 0xAB613A67L, 0xB831C993L, 0x4A5A4A90L, 3172 0x9E902E7BL, 0x6CFBAD78L, 0x7FAB5E8CL, 0x8DC0DD8FL, 3173 0xE330A81AL, 0x115B2B19L, 0x020BD8EDL, 0xF0605BEEL, 3174 0x24AA3F05L, 0xD6C1BC06L, 0xC5914FF2L, 0x37FACCF1L, 3175 0x69E9F0D5L, 0x9B8273D6L, 0x88D28022L, 0x7AB90321L, 3176 0xAE7367CAL, 0x5C18E4C9L, 0x4F48173DL, 0xBD23943EL, 3177 0xF36E6F75L, 0x0105EC76L, 0x12551F82L, 0xE03E9C81L, 3179 0x34F4F86AL, 0xC69F7B69L, 0xD5CF889DL, 0x27A40B9EL, 3180 0x79B737BAL, 0x8BDCB4B9L, 0x988C474DL, 0x6AE7C44EL, 3181 0xBE2DA0A5L, 0x4C4623A6L, 0x5F16D052L, 0xAD7D5351L, 3182 }; 3184 #endif 3186 --------- 3187 New text: (Appendix B) 3188 --------- 3190 /* Example of the crc table file */ 3191 #ifndef __crc32cr_h__ 3192 #define __crc32cr_h__ 3194 #define CRC32C_POLY 0x1EDC6F41UL 3195 #define CRC32C(c,d) (c=(c>>8)^crc_c[(c^(d))&0xFF]) 3197 uint32_t crc_c[256] = 3198 { 3199 0x00000000UL, 0xF26B8303UL, 0xE13B70F7UL, 0x1350F3F4UL, 3200 0xC79A971FUL, 0x35F1141CUL, 0x26A1E7E8UL, 0xD4CA64EBUL, 3201 0x8AD958CFUL, 0x78B2DBCCUL, 0x6BE22838UL, 0x9989AB3BUL, 3202 0x4D43CFD0UL, 0xBF284CD3UL, 0xAC78BF27UL, 0x5E133C24UL, 3203 0x105EC76FUL, 0xE235446CUL, 0xF165B798UL, 0x030E349BUL, 3204 0xD7C45070UL, 0x25AFD373UL, 0x36FF2087UL, 0xC494A384UL, 3205 0x9A879FA0UL, 0x68EC1CA3UL, 0x7BBCEF57UL, 0x89D76C54UL, 3206 0x5D1D08BFUL, 0xAF768BBCUL, 0xBC267848UL, 0x4E4DFB4BUL, 3207 0x20BD8EDEUL, 0xD2D60DDDUL, 0xC186FE29UL, 0x33ED7D2AUL, 3208 0xE72719C1UL, 0x154C9AC2UL, 0x061C6936UL, 0xF477EA35UL, 3209 0xAA64D611UL, 0x580F5512UL, 0x4B5FA6E6UL, 0xB93425E5UL, 3210 0x6DFE410EUL, 0x9F95C20DUL, 0x8CC531F9UL, 0x7EAEB2FAUL, 3211 0x30E349B1UL, 0xC288CAB2UL, 0xD1D83946UL, 0x23B3BA45UL, 3212 0xF779DEAEUL, 0x05125DADUL, 0x1642AE59UL, 0xE4292D5AUL, 3213 0xBA3A117EUL, 0x4851927DUL, 0x5B016189UL, 0xA96AE28AUL, 3214 0x7DA08661UL, 0x8FCB0562UL, 0x9C9BF696UL, 0x6EF07595UL, 3215 0x417B1DBCUL, 0xB3109EBFUL, 0xA0406D4BUL, 0x522BEE48UL, 3216 0x86E18AA3UL, 0x748A09A0UL, 0x67DAFA54UL, 0x95B17957UL, 3217 0xCBA24573UL, 0x39C9C670UL, 0x2A993584UL, 0xD8F2B687UL, 3218 0x0C38D26CUL, 0xFE53516FUL, 0xED03A29BUL, 0x1F682198UL, 3219 0x5125DAD3UL, 0xA34E59D0UL, 0xB01EAA24UL, 0x42752927UL, 3220 0x96BF4DCCUL, 0x64D4CECFUL, 0x77843D3BUL, 0x85EFBE38UL, 3221 0xDBFC821CUL, 0x2997011FUL, 0x3AC7F2EBUL, 0xC8AC71E8UL, 3222 0x1C661503UL, 0xEE0D9600UL, 0xFD5D65F4UL, 0x0F36E6F7UL, 3223 0x61C69362UL, 0x93AD1061UL, 0x80FDE395UL, 0x72966096UL, 3224 0xA65C047DUL, 0x5437877EUL, 0x4767748AUL, 0xB50CF789UL, 3225 0xEB1FCBADUL, 0x197448AEUL, 0x0A24BB5AUL, 0xF84F3859UL, 3226 0x2C855CB2UL, 0xDEEEDFB1UL, 0xCDBE2C45UL, 0x3FD5AF46UL, 3227 0x7198540DUL, 0x83F3D70EUL, 0x90A324FAUL, 0x62C8A7F9UL, 3228 0xB602C312UL, 0x44694011UL, 0x5739B3E5UL, 0xA55230E6UL, 3229 0xFB410CC2UL, 0x092A8FC1UL, 0x1A7A7C35UL, 0xE811FF36UL, 3230 0x3CDB9BDDUL, 0xCEB018DEUL, 0xDDE0EB2AUL, 0x2F8B6829UL, 3231 0x82F63B78UL, 0x709DB87BUL, 0x63CD4B8FUL, 0x91A6C88CUL, 3232 0x456CAC67UL, 0xB7072F64UL, 0xA457DC90UL, 0x563C5F93UL, 3233 0x082F63B7UL, 0xFA44E0B4UL, 0xE9141340UL, 0x1B7F9043UL, 3234 0xCFB5F4A8UL, 0x3DDE77ABUL, 0x2E8E845FUL, 0xDCE5075CUL, 3235 0x92A8FC17UL, 0x60C37F14UL, 0x73938CE0UL, 0x81F80FE3UL, 3236 0x55326B08UL, 0xA759E80BUL, 0xB4091BFFUL, 0x466298FCUL, 3237 0x1871A4D8UL, 0xEA1A27DBUL, 0xF94AD42FUL, 0x0B21572CUL, 3238 0xDFEB33C7UL, 0x2D80B0C4UL, 0x3ED04330UL, 0xCCBBC033UL, 3239 0xA24BB5A6UL, 0x502036A5UL, 0x4370C551UL, 0xB11B4652UL, 3240 0x65D122B9UL, 0x97BAA1BAUL, 0x84EA524EUL, 0x7681D14DUL, 3241 0x2892ED69UL, 0xDAF96E6AUL, 0xC9A99D9EUL, 0x3BC21E9DUL, 3242 0xEF087A76UL, 0x1D63F975UL, 0x0E330A81UL, 0xFC588982UL, 3243 0xB21572C9UL, 0x407EF1CAUL, 0x532E023EUL, 0xA145813DUL, 3244 0x758FE5D6UL, 0x87E466D5UL, 0x94B49521UL, 0x66DF1622UL, 3245 0x38CC2A06UL, 0xCAA7A905UL, 0xD9F75AF1UL, 0x2B9CD9F2UL, 3246 0xFF56BD19UL, 0x0D3D3E1AUL, 0x1E6DCDEEUL, 0xEC064EEDUL, 3247 0xC38D26C4UL, 0x31E6A5C7UL, 0x22B65633UL, 0xD0DDD530UL, 3248 0x0417B1DBUL, 0xF67C32D8UL, 0xE52CC12CUL, 0x1747422FUL, 3249 0x49547E0BUL, 0xBB3FFD08UL, 0xA86F0EFCUL, 0x5A048DFFUL, 3250 0x8ECEE914UL, 0x7CA56A17UL, 0x6FF599E3UL, 0x9D9E1AE0UL, 3251 0xD3D3E1ABUL, 0x21B862A8UL, 0x32E8915CUL, 0xC083125FUL, 3252 0x144976B4UL, 0xE622F5B7UL, 0xF5720643UL, 0x07198540UL, 3253 0x590AB964UL, 0xAB613A67UL, 0xB831C993UL, 0x4A5A4A90UL, 3254 0x9E902E7BUL, 0x6CFBAD78UL, 0x7FAB5E8CUL, 0x8DC0DD8FUL, 3255 0xE330A81AUL, 0x115B2B19UL, 0x020BD8EDUL, 0xF0605BEEUL, 3256 0x24AA3F05UL, 0xD6C1BC06UL, 0xC5914FF2UL, 0x37FACCF1UL, 3257 0x69E9F0D5UL, 0x9B8273D6UL, 0x88D28022UL, 0x7AB90321UL, 3258 0xAE7367CAUL, 0x5C18E4C9UL, 0x4F48173DUL, 0xBD23943EUL, 3259 0xF36E6F75UL, 0x0105EC76UL, 0x12551F82UL, 0xE03E9C81UL, 3260 0x34F4F86AUL, 0xC69F7B69UL, 0xD5CF889DUL, 0x27A40B9EUL, 3261 0x79B737BAUL, 0x8BDCB4B9UL, 0x988C474DUL, 0x6AE7C44EUL, 3262 0xBE2DA0A5UL, 0x4C4623A6UL, 0x5F16D052UL, 0xAD7D5351UL, 3263 }; 3265 #endif 3266 --------- 3267 Old text: (Appendix B) 3268 --------- 3270 /* Example of table build routine */ 3272 #include 3273 #include 3275 #define OUTPUT_FILE "crc32cr.h" 3276 #define CRC32C_POLY 0x1EDC6F41L 3277 FILE *tf; 3278 unsigned long 3279 reflect_32 (unsigned long b) 3280 { 3281 int i; 3282 unsigned long rw = 0L; 3284 for (i = 0; i < 32; i++){ 3285 if (b & 1) 3286 rw |= 1 << (31 - i); 3287 b >>= 1; 3288 } 3289 return (rw); 3290 } 3292 unsigned long 3293 build_crc_table (int index) 3294 { 3295 int i; 3296 unsigned long rb; 3298 rb = reflect_32 (index); 3300 for (i = 0; i < 8; i++){ 3301 if (rb & 0x80000000L) 3302 rb = (rb << 1) ^ CRC32C_POLY; 3303 else 3304 rb <<= 1; 3305 } 3306 return (reflect_32 (rb)); 3307 } 3309 main () 3310 { 3311 int i; 3313 printf ("\nGenerating CRC-32c table file <%s>\n", 3314 OUTPUT_FILE); 3315 if ((tf = fopen (OUTPUT_FILE, "w")) == NULL){ 3316 printf ("Unable to open %s\n", OUTPUT_FILE); 3317 exit (1); 3318 } 3319 fprintf (tf, "#ifndef __crc32cr_table_h__\n"); 3320 fprintf (tf, "#define __crc32cr_table_h__\n\n"); 3321 fprintf (tf, "#define CRC32C_POLY 0x%08lX\n", 3322 CRC32C_POLY); 3323 fprintf (tf, 3324 "#define CRC32C(c,d) (c=(c>>8)^crc_c[(c^(d))&0xFF])\n"); 3325 fprintf (tf, "\nunsigned long crc_c[256] =\n{\n"); 3326 for (i = 0; i < 256; i++){ 3327 fprintf (tf, "0x%08lXL, ", build_crc_table (i)); 3328 if ((i & 3) == 3) 3329 fprintf (tf, "\n"); 3330 } 3331 fprintf (tf, "};\n\n#endif\n"); 3333 if (fclose (tf) != 0) 3334 printf ("Unable to close <%s>." OUTPUT_FILE); 3335 else 3336 printf ("\nThe CRC-32c table has been written to <%s>.\n", 3337 OUTPUT_FILE); 3338 } 3340 --------- 3341 New text: (Appendix B) 3342 --------- 3344 /* Example of table build routine */ 3346 #include 3347 #include 3349 #define OUTPUT_FILE "crc32cr.h" 3350 #define CRC32C_POLY 0x1EDC6F41UL 3352 static FILE *tf; 3354 static uint32_t 3355 reflect_32(uint32_t b) 3356 { 3357 int i; 3358 uint32_t rw = 0UL; 3360 for (i = 0; i < 32; i++) { 3361 if (b & 1) 3362 rw |= 1 << (31 - i); 3363 b >>= 1; 3364 } 3365 return (rw); 3366 } 3368 static uint32_t 3369 build_crc_table(int index) 3370 { 3371 int i; 3372 uint32_t rb; 3374 rb = reflect_32(index); 3376 for (i = 0; i < 8; i++) { 3377 if (rb & 0x80000000UL) 3378 rb = (rb << 1) ^ (uint32_t)CRC32C_POLY; 3379 else 3380 rb <<= 1; 3381 } 3382 return (reflect_32(rb)); 3383 } 3385 int 3386 main (void) 3387 { 3388 int i; 3390 printf("\nGenerating CRC-32c table file <%s>\n", 3391 OUTPUT_FILE); 3392 if ((tf = fopen(OUTPUT_FILE, "w")) == NULL) { 3393 printf ("Unable to open %s\n", OUTPUT_FILE); 3394 exit (1); 3395 } 3396 fprintf(tf, "#ifndef __crc32cr_h__\n"); 3397 fprintf(tf, "#define __crc32cr_h__\n\n"); 3398 fprintf(tf, "#define CRC32C_POLY 0x%08XUL\n", 3399 (uint32_t)CRC32C_POLY); 3400 fprintf(tf, 3401 "#define CRC32C(c,d) (c=(c>>8)^crc_c[(c^(d))&0xFF])\n"); 3402 fprintf(tf, "\nuint32_t crc_c[256] =\n{\n"); 3403 for (i = 0; i < 256; i++) { 3404 fprintf(tf, "0x%08XUL,", build_crc_table (i)); 3405 if ((i & 3) == 3) 3406 fprintf(tf, "\n"); 3407 else 3408 fprintf(tf, " "); 3409 } 3410 fprintf(tf, "};\n\n#endif\n"); 3412 if (fclose (tf) != 0) 3413 printf("Unable to close <%s>.", OUTPUT_FILE); 3414 else 3415 printf("\nThe CRC-32c table has been written to <%s>.\n", 3416 OUTPUT_FILE); 3417 } 3419 --------- 3420 Old text: (Appendix B) 3421 --------- 3423 /* Example of crc insertion */ 3425 #include "crc32cr.h" 3427 unsigned long 3428 generate_crc32c(unsigned char *buffer, unsigned int length) 3429 { 3430 unsigned int i; 3431 unsigned long crc32 = ~0L; 3432 unsigned long result; 3433 unsigned char byte0,byte1,byte2,byte3; 3435 for (i = 0; i < length; i++){ 3436 CRC32C(crc32, buffer[i]); 3437 } 3439 result = ~crc32; 3441 /* result now holds the negated polynomial remainder; 3442 * since the table and algorithm is "reflected" [williams95]. 3443 * That is, result has the same value as if we mapped the message 3444 * to a polynomial, computed the host-bit-order polynomial 3445 * remainder, performed final negation, then did an end-for-end 3446 * bit-reversal. 3447 * Note that a 32-bit bit-reversal is identical to four inplace 3448 * 8-bit reversals followed by an end-for-end byteswap. 3449 * In other words, the bytes of each bit are in the right order, 3450 * but the bytes have been byteswapped. So we now do an explicit 3451 * byteswap. On a little-endian machine, this byteswap and 3452 * the final ntohl cancel out and could be elided. 3453 */ 3455 byte0 = result & 0xff; 3456 byte1 = (result>>8) & 0xff; 3457 byte2 = (result>>16) & 0xff; 3458 byte3 = (result>>24) & 0xff; 3459 crc32 = ((byte0 << 24) | 3460 (byte1 << 16) | 3461 (byte2 << 8) | 3462 byte3); 3463 return ( crc32 ); 3464 } 3466 int 3467 insert_crc32(unsigned char *buffer, unsigned int length) 3468 { 3469 SCTP_message *message; 3470 unsigned long crc32; 3471 message = (SCTP_message *) buffer; 3472 message->common_header.checksum = 0L; 3473 crc32 = generate_crc32c(buffer,length); 3474 /* and insert it into the message */ 3475 message->common_header.checksum = htonl(crc32); 3476 return 1; 3477 } 3479 int 3480 validate_crc32(unsigned char *buffer, unsigned int length) 3481 { 3482 SCTP_message *message; 3483 unsigned int i; 3484 unsigned long original_crc32; 3485 unsigned long crc32 = ~0L; 3487 /* save and zero checksum */ 3488 message = (SCTP_message *) buffer; 3489 original_crc32 = ntohl(message->common_header.checksum); 3490 message->common_header.checksum = 0L; 3491 crc32 = generate_crc32c(buffer,length); 3492 return ((original_crc32 == crc32)? 1 : -1); 3493 } 3495 --------- 3496 New text: (Appendix B) 3497 --------- 3499 /* Example of crc insertion */ 3501 #include "crc32cr.h" 3503 uint32_t 3504 generate_crc32c(unsigned char *buffer, unsigned int length) 3505 { 3506 unsigned int i; 3507 uint32_t crc32 = 0xffffffffUL; 3508 uint32_t result; 3509 uint8_t byte0, byte1, byte2, byte3; 3511 for (i = 0; i < length; i++) { 3512 CRC32C(crc32, buffer[i]); 3513 } 3515 result = ~crc32; 3517 /* result now holds the negated polynomial remainder; 3518 * since the table and algorithm is "reflected" [williams95]. 3519 * That is, result has the same value as if we mapped the message 3520 * to a polynomial, computed the host-bit-order polynomial 3521 * remainder, performed final negation, then did an end-for-end 3522 * bit-reversal. 3523 * Note that a 32-bit bit-reversal is identical to four inplace 3524 * 8-bit reversals followed by an end-for-end byteswap. 3525 * In other words, the bytes of each bit are in the right order, 3526 * but the bytes have been byteswapped. So we now do an explicit 3527 * byteswap. On a little-endian machine, this byteswap and 3528 * the final ntohl cancel out and could be elided. 3529 */ 3531 byte0 = result & 0xff; 3532 byte1 = (result>>8) & 0xff; 3533 byte2 = (result>>16) & 0xff; 3534 byte3 = (result>>24) & 0xff; 3535 crc32 = ((byte0 << 24) | 3536 (byte1 << 16) | 3537 (byte2 << 8) | 3538 byte3); 3539 return (crc32); 3540 } 3542 int 3543 insert_crc32(unsigned char *buffer, unsigned int length) 3544 { 3545 SCTP_message *message; 3546 uint32_t crc32; 3547 message = (SCTP_message *) buffer; 3548 message->common_header.checksum = 0UL; 3549 crc32 = generate_crc32c(buffer,length); 3550 /* and insert it into the message */ 3551 message->common_header.checksum = htonl(crc32); 3552 return 1; 3553 } 3554 int 3555 validate_crc32(unsigned char *buffer, unsigned int length) 3556 { 3557 SCTP_message *message; 3558 unsigned int i; 3559 uint32_t original_crc32; 3560 uint32_t crc32; 3562 /* save and zero checksum */ 3563 message = (SCTP_message *)buffer; 3564 original_crc32 = ntohl(message->common_header.checksum); 3565 message->common_header.checksum = 0L; 3566 crc32 = generate_crc32c(buffer, length); 3567 return ((original_crc32 == crc32)? 1 : -1); 3568 } 3570 3.46.3. Solution Description 3572 The code was changed to use platform independent types. 3574 3.47. Clarification of Gap Ack Blocks in SACK Chunks 3576 3.47.1. Description of the Problem 3578 The Gap Ack Blocks in the SACK chunk are intended to be isolated. 3579 However, this is not mentioned with normative text. 3581 3.47.2. Text Changes to the Document 3583 --------- 3584 Old text: (Section 3.3.4) 3585 --------- 3587 The SACK also contains zero or more Gap Ack Blocks. Each Gap Ack 3588 Block acknowledges a subsequence of TSNs received following a break 3589 in the sequence of received TSNs. By definition, all TSNs 3590 acknowledged by Gap Ack Blocks are greater than the value of the 3591 Cumulative TSN Ack. 3593 --------- 3594 New text: (Section 3.3.4) 3595 --------- 3597 The SACK also contains zero or more Gap Ack Blocks. Each Gap Ack 3598 Block acknowledges a subsequence of TSNs received following a break 3599 in the sequence of received TSNs. The Gap Ack Blocks SHOULD be isolated. 3600 This means that the TSN just before each Gap Ack Block and the TSN just after 3601 each Gap Ack Block has not been received. By definition, all TSNs 3602 acknowledged by Gap Ack Blocks are greater than the value of the 3603 Cumulative TSN Ack. 3605 --------- 3606 Old text: (Section 3.3.4) 3607 --------- 3609 Gap Ack Blocks: 3611 These fields contain the Gap Ack Blocks. They are repeated for 3612 each Gap Ack Block up to the number of Gap Ack Blocks defined in 3613 the Number of Gap Ack Blocks field. All DATA chunks with TSNs 3614 greater than or equal to (Cumulative TSN Ack + Gap Ack Block 3615 Start) and less than or equal to (Cumulative TSN Ack + Gap Ack 3616 Block End) of each Gap Ack Block are assumed to have been received 3617 correctly. 3619 --------- 3620 New text: (Section 3.3.4) 3621 --------- 3623 Gap Ack Blocks: 3625 These fields contain the Gap Ack Blocks. They are repeated for 3626 each Gap Ack Block up to the number of Gap Ack Blocks defined in 3627 the Number of Gap Ack Blocks field. All DATA chunks with TSNs 3628 greater than or equal to (Cumulative TSN Ack + Gap Ack Block 3629 Start) and less than or equal to (Cumulative TSN Ack + Gap Ack 3630 Block End) of each Gap Ack Block are assumed to have been received 3631 correctly. Gap Ack Blocks SHOULD be isolated. That means that 3632 the DATA chunks with TSN equal to (Cumulative TSN Ack + Gap Ack 3633 Block Start - 1) and (Cumulative TSN Ack + Gap Ack Block End + 1) 3634 have not been received. 3636 3.47.3. Solution Description 3638 Normative text describing the intended usage of Gap Ack Blocks has 3639 been added. 3641 3.48. Handling of SSN Wrap Arounds 3643 3.48.1. Description of the Problem 3645 The Stream Sequence Number (SSN) is used for preserving the ordering 3646 of user messages within each SCTP stream. The SSN is limited to 16 3647 bits. Therefore, multiple wrap arounds of the SSN might happen 3648 within the current send window. To allow the receiver to deliver 3649 ordered user messages in the correct sequence, the sender should 3650 limit the number of user messages per stream. 3652 3.48.2. Text Changes to the Document 3654 --------- 3655 Old text: (Section 6.1) 3656 --------- 3658 Note: The data sender SHOULD NOT use a TSN that is more than 2**31 - 3659 1 above the beginning TSN of the current send window. 3661 --------- 3662 New text: (Section 6.1) 3663 --------- 3665 Note: The data sender SHOULD NOT use a TSN that is more than 2**31 - 3666 1 above the beginning TSN of the current send window. 3667 Note: For each stream, the data sender SHOULD NOT have more than 2**16-1 3668 ordered user messages in the current send window. 3670 3.48.3. Solution Description 3672 The data sender is required to limit the number of ordered user 3673 messages within the current send window. 3675 3.49. Update RFC 2119 Boilerplate 3677 3.49.1. Description of the Problem 3679 The text to be used to refer to the [RFC2119] terms has been updated 3680 by [RFC8174]. 3682 3.49.2. Text Changes to the Document 3683 --------- 3684 Old text: (Section 2) 3685 --------- 3687 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 3688 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 3689 document are to be interpreted as described in RFC 2119 [RFC2119]. 3691 --------- 3692 New text: (Section 2) 3693 --------- 3695 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 3696 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 3697 "OPTIONAL" in this document are to be interpreted as described in 3698 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 3699 capitals, as shown here. 3701 3.49.3. Solution Description 3703 The text has been updated to the one specified in [RFC8174]. 3705 4. IANA Considerations 3707 Section 3.44 of this document updates the port number registry for 3708 SCTP to be consistent with [RFC6335]. IANA is requested to review 3709 Section 3.44. 3711 5. Security Considerations 3713 This document does not add any security considerations to those given 3714 in [RFC4960]. 3716 6. Acknowledgments 3718 The authors wish to thank Pontus Andersson, Eric W. Biederman, 3719 Cedric Bonnet, Gorry Fairhurst, Peter Lei, Lionel Morand, Jeff 3720 Morriss, Karen E. E. Nielsen, Tom Petch, Kacheong Poon, Julien 3721 Pourtet, Irene Ruengeler, Michael Welzl, and Qiaobing Xie for their 3722 invaluable comments. 3724 7. References 3726 7.1. Normative References 3728 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3729 Requirement Levels", BCP 14, RFC 2119, 3730 DOI 10.17487/RFC2119, March 1997, 3731 . 3733 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 3734 RFC 4960, DOI 10.17487/RFC4960, September 2007, 3735 . 3737 7.2. Informative References 3739 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 3740 Communication Layers", STD 3, RFC 1122, 3741 DOI 10.17487/RFC1122, October 1989, 3742 . 3744 [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., 3745 Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., 3746 Zhang, L., and V. Paxson, "Stream Control Transmission 3747 Protocol", RFC 2960, DOI 10.17487/RFC2960, October 2000, 3748 . 3750 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 3751 of Explicit Congestion Notification (ECN) to IP", 3752 RFC 3168, DOI 10.17487/RFC3168, September 2001, 3753 . 3755 [RFC4460] Stewart, R., Arias-Rodriguez, I., Poon, K., Caro, A., and 3756 M. Tuexen, "Stream Control Transmission Protocol (SCTP) 3757 Specification Errata and Issues", RFC 4460, 3758 DOI 10.17487/RFC4460, April 2006, 3759 . 3761 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 3762 IANA Considerations Section in RFCs", RFC 5226, 3763 DOI 10.17487/RFC5226, May 2008, 3764 . 3766 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 3767 Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, 3768 . 3770 [RFC6096] Tuexen, M. and R. Stewart, "Stream Control Transmission 3771 Protocol (SCTP) Chunk Flags Registration", RFC 6096, 3772 DOI 10.17487/RFC6096, January 2011, 3773 . 3775 [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, 3776 "Computing TCP's Retransmission Timer", RFC 6298, 3777 DOI 10.17487/RFC6298, June 2011, 3778 . 3780 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 3781 Cheshire, "Internet Assigned Numbers Authority (IANA) 3782 Procedures for the Management of the Service Name and 3783 Transport Protocol Port Number Registry", BCP 165, 3784 RFC 6335, DOI 10.17487/RFC6335, August 2011, 3785 . 3787 [RFC7053] Tuexen, M., Ruengeler, I., and R. Stewart, "SACK- 3788 IMMEDIATELY Extension for the Stream Control Transmission 3789 Protocol", RFC 7053, DOI 10.17487/RFC7053, November 2013, 3790 . 3792 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 3793 Writing an IANA Considerations Section in RFCs", BCP 26, 3794 RFC 8126, DOI 10.17487/RFC8126, June 2017, 3795 . 3797 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 3798 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 3799 May 2017, . 3801 [RFC8311] Black, D., "Relaxing Restrictions on Explicit Congestion 3802 Notification (ECN) Experimentation", RFC 8311, 3803 DOI 10.17487/RFC8311, January 2018, 3804 . 3806 Authors' Addresses 3808 Randall R. Stewart 3809 Netflix, Inc. 3810 Chapin, SC 29036 3811 United States 3813 Email: randall@lakerest.net 3815 Michael Tuexen 3816 Muenster University of Applied Sciences 3817 Stegerwaldstrasse 39 3818 48565 Steinfurt 3819 Germany 3821 Email: tuexen@fh-muenster.de 3822 Maksim Proshin 3823 Ericsson 3824 Kistavaegen 25 3825 Stockholm 164 80 3826 Sweden 3828 Email: mproshin@tieto.mera.ru