idnits 2.17.1 draft-ietf-tsvwg-rfc4960-errata-04.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 is 1 instance of too long lines in the document, the longest one being 5 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 3100 has weird spacing: '...ed long crc_c...' == Line 3311 has weird spacing: '...ed long crc_c...' -- The document date (November 13, 2017) is 2356 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 2862, 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 1667, but not defined -- Looks like a reference, but probably isn't: '256' on line 3388 ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) == Outdated reference: A later version (-08) exists of draft-ietf-tsvwg-ecn-experimentation-07 -- 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 (~~), 8 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: May 17, 2018 Muenster Univ. of Appl. Sciences 6 M. Proshin 7 Ericsson 8 November 13, 2017 10 RFC 4960 Errata and Issues 11 draft-ietf-tsvwg-rfc4960-errata-04.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 based 19 way. The issues are listed in the order they were brought up. 20 Because some text is changed several times the last delta in the text 21 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 May 17, 2018. 42 Copyright Notice 44 Copyright (c) 2017 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 . . . . . . . . . . . . . . . . . . . 18 72 3.11. partial_bytes_acked after T3-rtx Expiration . . . . . . . 19 73 3.12. Order of Adjustments of partial_bytes_acked and cwnd . . 19 74 3.13. HEARTBEAT ACK and the association error counter . . . . . 20 75 3.14. Path for Fast Retransmission . . . . . . . . . . . . . . 22 76 3.15. Transmittal in Fast Recovery . . . . . . . . . . . . . . 23 77 3.16. Initial Value of ssthresh . . . . . . . . . . . . . . . . 23 78 3.17. Automatically Confirmed Addresses . . . . . . . . . . . . 24 79 3.18. Only One Packet after Retransmission Timeout . . . . . . 25 80 3.19. INIT ACK Path for INIT in COOKIE-WAIT State . . . . . . . 26 81 3.20. Zero Window Probing and Unreachable Primary Path . . . . 27 82 3.21. Normative Language in Section 10 . . . . . . . . . . . . 28 83 3.22. Increase of partial_bytes_acked in Congestion Avoidance . 32 84 3.23. Inconsistency in Notifications Handling . . . . . . . . . 33 85 3.24. SACK.Delay Not Listed as a Protocol Parameter . . . . . . 37 86 3.25. Processing of Chunks in an Incoming SCTP Packet . . . . . 39 87 3.26. CWND Increase in Congestion Avoidance Phase . . . . . . . 40 88 3.27. Refresh of cwnd and ssthresh after Idle Period . . . . . 42 89 3.28. Window Updates After Receiver Window Opens Up . . . . . . 43 90 3.29. Path of DATA and Reply Chunks . . . . . . . . . . . . . . 44 91 3.30. Outstanding Data, Flightsize and Data In Flight Key Terms 46 92 3.31. CWND Degradation due to Max.Burst . . . . . . . . . . . . 47 93 3.32. Reduction of RTO.Initial . . . . . . . . . . . . . . . . 48 94 3.33. Ordering of Bundled SACK and ERROR Chunks . . . . . . . . 50 95 3.34. Undefined Parameter Returned by RECEIVE Primitive . . . . 50 96 3.35. DSCP Changes . . . . . . . . . . . . . . . . . . . . . . 51 97 3.36. Inconsistent Handling of ICMPv4 and ICMPv6 Messages . . . 53 98 3.37. Handling of Soft Errors . . . . . . . . . . . . . . . . . 54 99 3.38. Honoring CWND . . . . . . . . . . . . . . . . . . . . . . 55 100 3.39. Zero Window Probing . . . . . . . . . . . . . . . . . . . 56 101 3.40. Updating References Regarding ECN . . . . . . . . . . . . 58 102 3.41. Host Name Address Parameter Deprecated . . . . . . . . . 60 103 3.42. Conflicting Text Regarding the Supported Address Types 104 Parameter . . . . . . . . . . . . . . . . . . . . . . . . 63 105 3.43. Integration of RFC 6096 . . . . . . . . . . . . . . . . . 64 106 3.44. Integration of RFC 6335 . . . . . . . . . . . . . . . . . 66 107 3.45. Integration of RFC 7053 . . . . . . . . . . . . . . . . . 68 108 3.46. CRC32c Code Improvements . . . . . . . . . . . . . . . . 71 109 3.47. Clarification of Gap Ack Blocks in SACK Chunks . . . . . 81 110 3.48. Handling of SSN Wrap Arounds . . . . . . . . . . . . . . 82 111 3.49. Update RFC 2119 Boilerplate . . . . . . . . . . . . . . . 83 112 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 84 113 5. Security Considerations . . . . . . . . . . . . . . . . . . . 84 114 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 84 115 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 84 116 7.1. Normative References . . . . . . . . . . . . . . . . . . 84 117 7.2. Informative References . . . . . . . . . . . . . . . . . 85 118 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 86 120 1. Introduction 122 This document contains a compilation of all defects found up until 123 the publishing 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 NOT 226 send a SHUTDOWN in response to a ULP request, and should discard 227 subsequent ULP shutdown requests. 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 [RFC2434]. 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 shall 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 currently is used for data 374 transfer. Unacknowledged HEARTBEAT chunks observed on paths 375 different from the path currently used for data transfer shall 376 not increment the association error counter, as this could lead 377 to association closure even if the path which currently is 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 catched. 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 / Strt=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 Path MTU. 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: (Appendix C) 585 --------- 587 ICMP2) An implementation MAY ignore all ICMPv6 messages where the 588 type field is not "Destination Unreachable", "Parameter 589 Problem",, or "Packet Too Big". 591 --------- 592 New text: (Appendix C) 593 --------- 595 ICMP2) An implementation MAY ignore all ICMPv6 messages where the 596 type field is not "Destination Unreachable", "Parameter 597 Problem", or "Packet Too Big". 599 --------- 600 Old text: (Appendix C) 601 --------- 603 ICMP7) If the ICMP message is either a v6 "Packet Too Big" or a v4 604 "Fragmentation Needed", an implementation MAY process this 605 information as defined for PATH MTU discovery. 607 --------- 608 New text: (Appendix C) 609 --------- 611 ICMP7) If the ICMP message is either a v6 "Packet Too Big" or a v4 612 "Fragmentation Needed", an implementation MAY process this 613 information as defined for path MTU discovery. 615 --------- 616 Old text: (Section 5.4) 617 --------- 619 2) For the receiver of the COOKIE ECHO, the only CONFIRMED address 620 is the one to which the INIT-ACK was sent. 622 --------- 623 New text: (Section 5.4) 624 --------- 626 2) For the receiver of the COOKIE ECHO, the only CONFIRMED address 627 is the one to which the INIT ACK was sent. 629 --------- 630 Old text: (Section 5.1.6, Figure 4) 631 --------- 633 COOKIE ECHO [Cookie_Z] ------\ 634 (Start T1-init timer) \ 635 (Enter COOKIE-ECHOED state) \---> (build TCB enter ESTABLISHED 636 state) 637 /---- COOKIE-ACK 638 / 639 (Cancel T1-init timer, <-----/ 640 Enter ESTABLISHED state) 642 --------- 643 New text: (Section 5.1.6, Figure 4) 644 --------- 646 COOKIE ECHO [Cookie_Z] ------\ 647 (Start T1-cookie timer) \ 648 (Enter COOKIE-ECHOED state) \---> (build TCB enter ESTABLISHED 649 state) 650 /---- COOKIE ACK 651 / 652 (Cancel T1-cookie timer, <---/ 653 Enter ESTABLISHED state) 655 --------- 656 Old text: (Section 5.2.5) 657 --------- 659 5.2.5. Handle Duplicate COOKIE-ACK. 661 --------- 662 New text: (Section 5.2.5) 663 --------- 665 5.2.5. Handle Duplicate COOKIE ACK. 667 --------- 668 Old text: (Section 8.3) 669 --------- 671 By default, an SCTP endpoint SHOULD monitor the reachability of the 672 idle destination transport address(es) of its peer by sending a 673 HEARTBEAT chunk periodically to the destination transport 674 address(es). HEARTBEAT sending MAY begin upon reaching the 675 ESTABLISHED state and is discontinued after sending either SHUTDOWN 676 or SHUTDOWN-ACK. A receiver of a HEARTBEAT MUST respond to a 677 HEARTBEAT with a HEARTBEAT-ACK after entering the COOKIE-ECHOED state 678 (INIT sender) or the ESTABLISHED state (INIT receiver), up until 679 reaching the SHUTDOWN-SENT state (SHUTDOWN sender) or the SHUTDOWN- 680 ACK-SENT state (SHUTDOWN receiver). 682 --------- 683 New text: (Section 8.3) 684 --------- 685 By default, an SCTP endpoint SHOULD monitor the reachability of the 686 idle destination transport address(es) of its peer by sending a 687 HEARTBEAT chunk periodically to the destination transport 688 address(es). HEARTBEAT sending MAY begin upon reaching the 689 ESTABLISHED state and is discontinued after sending either SHUTDOWN 690 or SHUTDOWN ACK. A receiver of a HEARTBEAT MUST respond to a 691 HEARTBEAT with a HEARTBEAT ACK after entering the COOKIE-ECHOED state 692 (INIT sender) or the ESTABLISHED state (INIT receiver), up until 693 reaching the SHUTDOWN-SENT state (SHUTDOWN sender) or the SHUTDOWN- 694 ACK-SENT state (SHUTDOWN receiver). 696 3.9.3. Solution Description 698 Typos fixed. 700 3.10. CRC32c Sample Code 702 3.10.1. Description of the Problem 704 The CRC32c computation is described in Appendix B of [RFC4960]. 705 However, the corresponding sample code and its explanation appears at 706 the end of Appendix C, which deals with ICMP handling. 708 3.10.2. Text Changes to the Document 710 Move the sample code related to CRC32c computation and its 711 explanation from the end of Appendix C to the end of Appendix B. 713 3.10.3. Solution Description 715 Text moved to the appropriate location. 717 3.11. partial_bytes_acked after T3-rtx Expiration 719 3.11.1. Description of the Problem 721 Section 7.2.3 of [RFC4960] explicitly states that partial_bytes_acked 722 should be reset to 0 after packet loss detecting from SACK but the 723 same is missed for T3-rtx timer expiration. 725 3.11.2. Text Changes to the Document 727 --------- 728 Old text: (Section 7.2.3) 729 --------- 731 When the T3-rtx timer expires on an address, SCTP should perform slow 732 start by: 734 ssthresh = max(cwnd/2, 4*MTU) 735 cwnd = 1*MTU 737 --------- 738 New text: (Section 7.2.3) 739 --------- 741 When the T3-rtx timer expires on an address, SCTP should perform slow 742 start by: 744 ssthresh = max(cwnd/2, 4*MTU) 745 cwnd = 1*MTU 746 partial_bytes_acked = 0 748 3.11.3. Solution Description 750 Specify that partial_bytes_acked should be reset to 0 after T3-rtx 751 timer expiration. 753 3.12. Order of Adjustments of partial_bytes_acked and cwnd 755 3.12.1. Description of the Problem 757 Section 7.2.2 of [RFC4960] is unclear about the order of adjustments 758 applied to partial_bytes_acked and cwnd in the congestion avoidance 759 phase. 761 3.12.2. Text Changes to the Document 763 --------- 764 Old text: (Section 7.2.2) 765 --------- 767 o When partial_bytes_acked is equal to or greater than cwnd and 768 before the arrival of the SACK the sender had cwnd or more bytes 769 of data outstanding (i.e., before arrival of the SACK, flightsize 770 was greater than or equal to cwnd), increase cwnd by MTU, and 771 reset partial_bytes_acked to (partial_bytes_acked - cwnd). 773 --------- 774 New text: (Section 7.2.2) 775 --------- 777 o When partial_bytes_acked is equal to or greater than cwnd and 778 before the arrival of the SACK the sender had cwnd or more bytes 779 of data outstanding (i.e., before arrival of the SACK, flightsize 780 was greater than or equal to cwnd), partial_bytes_acked is reset 781 to (partial_bytes_acked - cwnd). Next, cwnd is increased by MTU. 783 3.12.3. Solution Description 785 The new text defines the exact order of adjustments of 786 partial_bytes_acked and cwnd in the congestion avoidance phase. 788 3.13. HEARTBEAT ACK and the association error counter 790 3.13.1. Description of the Problem 792 Section 8.1 and Section 8.3 of [RFC4960] prescribe that the receiver 793 of a HEARTBEAT ACK must reset the association overall error counter. 794 In some circumstances, e.g. when a router discards DATA chunks but 795 not HEARTBEAT chunks due to the larger size of the DATA chunk, it 796 might be better to not clear the association error counter on 797 reception of the HEARTBEAT ACK and reset it only on reception of the 798 SACK to avoid stalling the association. 800 3.13.2. Text Changes to the Document 801 --------- 802 Old text: (Section 8.1) 803 --------- 805 The counter shall be reset each time a DATA chunk sent to that peer 806 endpoint is acknowledged (by the reception of a SACK) or a HEARTBEAT 807 ACK is received from the peer endpoint. 809 --------- 810 New text: (Section 8.1) 811 --------- 813 The counter shall be reset each time a DATA chunk sent to that peer 814 endpoint is acknowledged (by the reception of a SACK). When a 815 HEARTBEAT ACK is received from the peer endpoint, the counter should 816 also be reset. The receiver of the HEARTBEAT ACK may choose not to 817 clear the counter if there is outstanding data on the association. 818 This allows for handling the possible difference in reachability 819 based on DATA chunks and HEARTBEAT chunks. 821 --------- 822 Old text: (Section 8.3) 823 --------- 825 Upon the receipt of the HEARTBEAT ACK, the sender of the HEARTBEAT 826 should clear the error counter of the destination transport address 827 to which the HEARTBEAT was sent, and mark the destination transport 828 address as active if it is not so marked. The endpoint may 829 optionally report to the upper layer when an inactive destination 830 address is marked as active due to the reception of the latest 831 HEARTBEAT ACK. The receiver of the HEARTBEAT ACK must also clear the 832 association overall error count as well (as defined in Section 8.1). 834 --------- 835 New text: (Section 8.3) 836 --------- 838 Upon the receipt of the HEARTBEAT ACK, the sender of the HEARTBEAT 839 should clear the error counter of the destination transport address 840 to which the HEARTBEAT was sent, and mark the destination transport 841 address as active if it is not so marked. The endpoint may 842 optionally report to the upper layer when an inactive destination 843 address is marked as active due to the reception of the latest 844 HEARTBEAT ACK. The receiver of the HEARTBEAT ACK should also clear 845 the association overall error counter (as defined in Section 8.1). 847 3.13.3. Solution Description 849 The new text provides a possibility to not reset the association 850 overall error counter when a HEARTBEAT ACK is received if there are 851 valid reasons for it. 853 3.14. Path for Fast Retransmission 855 3.14.1. Description of the Problem 857 [RFC4960] clearly describes where to retransmit data that is timed 858 out when the peer is multi-homed but the same is not stated for fast 859 retransmissions. 861 3.14.2. Text Changes to the Document 863 --------- 864 Old text: (Section 6.4) 865 --------- 867 Furthermore, when its peer is multi-homed, an endpoint SHOULD try to 868 retransmit a chunk that timed out to an active destination transport 869 address that is different from the last destination address to which 870 the DATA chunk was sent. 872 --------- 873 New text: (Section 6.4) 874 --------- 876 Furthermore, when its peer is multi-homed, an endpoint SHOULD try to 877 retransmit a chunk that timed out to an active destination transport 878 address that is different from the last destination address to which 879 the DATA chunk was sent. 881 When its peer is multi-homed, an endpoint SHOULD send fast 882 retransmissions to the same destination transport address where 883 original data was sent to. If the primary path has been changed and 884 original data was sent there before the fast retransmit, the 885 implementation MAY send it to the new primary path. 887 3.14.3. Solution Description 889 The new text clarifies where to send fast retransmissions. 891 3.15. Transmittal in Fast Recovery 893 3.15.1. Description of the Problem 895 The Fast Retransmit on Gap Reports algorithm intends that only the 896 very first packet may be sent regardless of cwnd in the Fast Recovery 897 phase but rule 3) of [RFC4960], Section 7.2.4, misses this 898 clarification. 900 3.15.2. Text Changes to the Document 902 --------- 903 Old text: (Section 7.2.4) 904 --------- 906 3) Determine how many of the earliest (i.e., lowest TSN) DATA chunks 907 marked for retransmission will fit into a single packet, subject 908 to constraint of the path MTU of the destination transport 909 address to which the packet is being sent. Call this value K. 910 Retransmit those K DATA chunks in a single packet. When a Fast 911 Retransmit is being performed, the sender SHOULD ignore the value 912 of cwnd and SHOULD NOT delay retransmission for this single 913 packet. 915 --------- 916 New text: (Section 7.2.4) 917 --------- 919 3) If not in Fast Recovery, determine how many of the earliest 920 (i.e., lowest TSN) DATA chunks marked for retransmission will fit 921 into a single packet, subject to constraint of the path MTU of 922 the destination transport address to which the packet is being 923 sent. Call this value K. Retransmit those K DATA chunks in a 924 single packet. When a Fast Retransmit is being performed, the 925 sender SHOULD ignore the value of cwnd and SHOULD NOT delay 926 retransmission for this single packet. 928 3.15.3. Solution Description 930 The new text explicitly specifies to send only the first packet in 931 the Fast Recovery phase disregarding cwnd limitations. 933 3.16. Initial Value of ssthresh 934 3.16.1. Description of the Problem 936 The initial value of ssthresh should be set arbitrarily high. Using 937 the advertised receiver window of the peer is inappropriate if the 938 peer increases its window after the handshake. Furthermore, use a 939 higher requirements level, since not following the advice may result 940 in performance problems. 942 3.16.2. Text Changes to the Document 944 --------- 945 Old text: (Section 7.2.1) 946 --------- 948 o The initial value of ssthresh MAY be arbitrarily high (for 949 example, implementations MAY use the size of the receiver 950 advertised window). 952 --------- 953 New text: (Section 7.2.1) 954 --------- 956 o The initial value of ssthresh SHOULD be arbitrarily high (e.g., 957 to the size of the largest possible advertised window). 959 3.16.3. Solution Description 961 Use the same value as suggested in [RFC5681], Section 3.1, as an 962 appropriate initial value. Furthermore use the same requirements 963 level. 965 3.17. Automatically Confirmed Addresses 967 3.17.1. Description of the Problem 969 The Path Verification procedure of [RFC4960] prescribes that any 970 address passed to the sender of the INIT by its upper layer is 971 automatically CONFIRMED. This however is unclear if only addresses 972 in the request to initiate association establishment are considered 973 or any addresses provided by the upper layer in any requests (e.g. in 974 'Set Primary'). 976 3.17.2. Text Changes to the Document 977 --------- 978 Old text: (Section 5.4) 979 --------- 981 1) Any address passed to the sender of the INIT by its upper layer 982 is automatically considered to be CONFIRMED. 984 --------- 985 New text: (Section 5.4) 986 --------- 988 1) Any addresses passed to the sender of the INIT by its upper 989 layer in the request to initialize an association is 990 automatically considered to be CONFIRMED. 992 3.17.3. Solution Description 994 The new text clarifies that only addresses provided by the upper 995 layer in the request to initialize an association are automatically 996 confirmed. 998 3.18. Only One Packet after Retransmission Timeout 1000 3.18.1. Description of the Problem 1002 [RFC4960] is not completely clear when it describes data transmission 1003 after T3-rtx timer expiration. Section 7.2.1 does not specify how 1004 many packets are allowed to be sent after T3-rtx timer expiration if 1005 more than one packet fit into cwnd. At the same time, Section 7.2.3 1006 has the text without normative language saying that SCTP should 1007 ensure that no more than one packet will be in flight after T3-rtx 1008 timer expiration until successful acknowledgment. It makes the text 1009 inconsistent. 1011 3.18.2. Text Changes to the Document 1012 --------- 1013 Old text: (Section 7.2.1) 1014 --------- 1016 o The initial cwnd after a retransmission timeout MUST be no more 1017 than 1*MTU. 1019 --------- 1020 New text: (Section 7.2.1) 1021 --------- 1023 o The initial cwnd after a retransmission timeout MUST be no more 1024 than 1*MTU and only one packet is allowed to be in flight 1025 until successful acknowledgement. 1027 3.18.3. Solution Description 1029 The new text clearly specifies that only one packet is allowed to be 1030 sent after T3-rtx timer expiration until successful acknowledgement. 1032 3.19. INIT ACK Path for INIT in COOKIE-WAIT State 1034 3.19.1. Description of the Problem 1036 In case of an INIT received in the COOKIE-WAIT state [RFC4960] 1037 prescribes to send an INIT ACK to the same destination address to 1038 which the original INIT has been sent. This text does not address 1039 the possibility of the upper layer to provide multiple remote IP 1040 addresses while requesting the association establishment. If the 1041 upper layer has provided multiple IP addresses and only a subset of 1042 these addresses are supported by the peer then the destination 1043 address of the original INIT may be absent in the incoming INIT and 1044 sending INIT ACK to that address is useless. 1046 3.19.2. Text Changes to the Document 1047 --------- 1048 Old text: (Section 5.2.1) 1049 --------- 1051 Upon receipt of an INIT in the COOKIE-WAIT state, an endpoint MUST 1052 respond with an INIT ACK using the same parameters it sent in its 1053 original INIT chunk (including its Initiate Tag, unchanged). When 1054 responding, the endpoint MUST send the INIT ACK back to the same 1055 address that the original INIT (sent by this endpoint) was sent. 1057 --------- 1058 New text: (Section 5.2.1) 1059 --------- 1061 Upon receipt of an INIT in the COOKIE-WAIT state, an endpoint MUST 1062 respond with an INIT ACK using the same parameters it sent in its 1063 original INIT chunk (including its Initiate Tag, unchanged). When 1064 responding, the following rules MUST be applied: 1066 1) The INIT ACK MUST only be sent to an address passed by the upper 1067 layer in the request to initialize the association. 1069 2) The INIT ACK MUST only be sent to an address reported in the 1070 incoming INIT. 1072 3) The INIT ACK SHOULD be sent to the source address of the 1073 received INIT. 1075 3.19.3. Solution Description 1077 The new text requires sending INIT ACK to the destination address 1078 that is passed by the upper layer and reported in the incoming INIT. 1079 If the source address of the INIT fulfills it then sending the INIT 1080 ACK to the source address of the INIT is the preferred behavior. 1082 3.20. Zero Window Probing and Unreachable Primary Path 1084 3.20.1. Description of the Problem 1086 Section 6.1 of [RFC4960] states that when sending zero window probes, 1087 SCTP should neither increment the association counter nor increment 1088 the destination address error counter if it continues to receive new 1089 packets from the peer. But receiving new packets from the peer does 1090 not guarantee peer's accessibility and, if the destination address 1091 becomes unreachable during zero window probing, SCTP cannot get a 1092 changed rwnd until it switches the destination address for probes. 1094 3.20.2. Text Changes to the Document 1096 --------- 1097 Old text: (Section 6.1) 1098 --------- 1100 If the sender continues to receive new packets from the receiver 1101 while doing zero window probing, the unacknowledged window probes 1102 should not increment the error counter for the association or any 1103 destination transport address. This is because the receiver MAY 1104 keep its window closed for an indefinite time. Refer to Section 1105 6.2 on the receiver behavior when it advertises a zero window. 1107 --------- 1108 New text: (Section 6.1) 1109 --------- 1111 If the sender continues to receive SACKs from the peer 1112 while doing zero window probing, the unacknowledged window probes 1113 should not increment the error counter for the association or any 1114 destination transport address. This is because the receiver MAY 1115 keep its window closed for an indefinite time. Refer to Section 1116 6.2 on the receiver behavior when it advertises a zero window. 1118 3.20.3. Solution Description 1120 The new text clarifies that if the receiver continues to send SACKs, 1121 the sender of probes should not increment the error counter of the 1122 association and the destination address even if the SACKs do not 1123 acknowledge the probes. 1125 3.21. Normative Language in Section 10 1127 3.21.1. Description of the Problem 1129 Section 10 of [RFC4960] is informative and normative language such as 1130 MUST and MAY cannot be used there. However, there are several places 1131 in Section 10 where MUST and MAY are used. 1133 3.21.2. Text Changes to the Document 1135 --------- 1136 Old text: (Section 10.1) 1137 --------- 1139 E) Send 1141 Format: SEND(association id, buffer address, byte count [,context] 1143 [,stream id] [,life time] [,destination transport address] 1144 [,unordered flag] [,no-bundle flag] [,payload protocol-id] ) 1145 -> result 1147 ... 1149 o no-bundle flag - instructs SCTP not to bundle this user data with 1150 other outbound DATA chunks. SCTP MAY still bundle even when this 1151 flag is present, when faced with network congestion. 1153 --------- 1154 New text: (Section 10.1) 1155 --------- 1157 E) Send 1159 Format: SEND(association id, buffer address, byte count [,context] 1160 [,stream id] [,life time] [,destination transport address] 1161 [,unordered flag] [,no-bundle flag] [,payload protocol-id] ) 1162 -> result 1164 ... 1166 o no-bundle flag - instructs SCTP not to bundle this user data with 1167 other outbound DATA chunks. SCTP may still bundle even when this 1168 flag is present, when faced with network congestion. 1170 --------- 1171 Old text: (Section 10.1) 1172 --------- 1174 G) Receive 1176 Format: RECEIVE(association id, buffer address, buffer size 1177 [,stream id]) 1178 -> byte count [,transport address] [,stream id] [,stream sequence 1179 number] [,partial flag] [,delivery number] [,payload protocol-id] 1181 ... 1183 o partial flag - if this returned flag is set to 1, then this 1184 Receive contains a partial delivery of the whole message. When 1185 this flag is set, the stream id and Stream Sequence Number MUST 1186 accompany this receive. When this flag is set to 0, it indicates 1187 that no more deliveries will be received for this Stream Sequence 1188 Number. 1190 --------- 1191 New text: (Section 10.1) 1192 --------- 1194 G) Receive 1196 Format: RECEIVE(association id, buffer address, buffer size 1197 [,stream id]) 1198 -> byte count [,transport address] [,stream id] [,stream sequence 1199 number] [,partial flag] [,delivery number] [,payload protocol-id] 1201 ... 1203 o partial flag - if this returned flag is set to 1, then this 1204 Receive contains a partial delivery of the whole message. When 1205 this flag is set, the stream id and Stream Sequence Number must 1206 accompany this receive. When this flag is set to 0, it indicates 1207 that no more deliveries will be received for this Stream Sequence 1208 Number. 1210 --------- 1211 Old text: (Section 10.1) 1212 --------- 1214 N) Receive Unsent Message 1216 Format: RECEIVE_UNSENT(data retrieval id, buffer address, buffer 1217 size [,stream id] [, stream sequence number] [,partial 1218 flag] [,payload protocol-id]) 1220 ... 1222 o partial flag - if this returned flag is set to 1, then this 1223 message is a partial delivery of the whole message. When this 1224 flag is set, the stream id and Stream Sequence Number MUST 1225 accompany this receive. When this flag is set to 0, it indicates 1226 that no more deliveries will be received for this Stream Sequence 1227 Number. 1229 --------- 1230 New text: (Section 10.1) 1231 --------- 1233 N) Receive Unsent Message 1235 Format: RECEIVE_UNSENT(data retrieval id, buffer address, buffer 1236 size [,stream id] [, stream sequence number] [,partial 1237 flag] [,payload protocol-id]) 1239 ... 1241 o partial flag - if this returned flag is set to 1, then this 1242 message is a partial delivery of the whole message. When this 1243 flag is set, the stream id and Stream Sequence Number must 1244 accompany this receive. When this flag is set to 0, it indicates 1245 that no more deliveries will be received for this Stream Sequence 1246 Number. 1248 --------- 1249 Old text: (Section 10.1) 1250 --------- 1252 O) Receive Unacknowledged Message 1254 Format: RECEIVE_UNACKED(data retrieval id, buffer address, buffer 1255 size, [,stream id] [, stream sequence number] [,partial 1256 flag] [,payload protocol-id]) 1258 ... 1260 o partial flag - if this returned flag is set to 1, then this 1261 message is a partial delivery of the whole message. When this 1262 flag is set, the stream id and Stream Sequence Number MUST 1263 accompany this receive. When this flag is set to 0, it indicates 1264 that no more deliveries will be received for this Stream Sequence 1265 Number. 1267 --------- 1268 New text: (Section 10.1) 1269 --------- 1271 O) Receive Unacknowledged Message 1273 Format: RECEIVE_UNACKED(data retrieval id, buffer address, buffer 1274 size, [,stream id] [, stream sequence number] [,partial 1275 flag] [,payload protocol-id]) 1277 ... 1279 o partial flag - if this returned flag is set to 1, then this 1280 message is a partial delivery of the whole message. When this 1281 flag is set, the stream id and Stream Sequence Number must 1282 accompany this receive. When this flag is set to 0, it indicates 1283 that no more deliveries will be received for this Stream Sequence 1284 Number. 1286 3.21.3. Solution Description 1288 The normative language is removed from Section 10. 1290 3.22. Increase of partial_bytes_acked in Congestion Avoidance 1292 3.22.1. Description of the Problem 1294 Two issues have been discovered with the partial_bytes_acked handling 1295 described in Section 7.2.2 of [RFC4960]: 1297 o If the Cumulative TSN Ack Point is not advanced but the SACK chunk 1298 acknowledges new TSNs in the Gap Ack Blocks, these newly 1299 acknowledged TSNs are not considered for partial_bytes_acked 1300 although these TSNs were successfully received by the peer. 1301 o Duplicate TSNs are not considered in partial_bytes_acked although 1302 they confirm that the DATA chunks were successfully received by 1303 the peer. 1305 3.22.2. Text Changes to the Document 1307 --------- 1308 Old text: (Section 7.2.2) 1309 --------- 1311 o Whenever cwnd is greater than ssthresh, upon each SACK arrival 1312 that advances the Cumulative TSN Ack Point, increase 1313 partial_bytes_acked by the total number of bytes of all new chunks 1314 acknowledged in that SACK including chunks acknowledged by the new 1315 Cumulative TSN Ack and by Gap Ack Blocks. 1317 --------- 1318 New text: (Section 7.2.2) 1319 --------- 1321 o Whenever cwnd is greater than ssthresh, upon each SACK arrival, 1322 increase partial_bytes_acked by the total number of bytes of all 1323 new chunks acknowledged in that SACK including chunks acknowledged 1324 by the new Cumulative TSN Ack, by Gap Ack Blocks and by the number 1325 of bytes of duplicated chunks reported in Duplicate TSNs. 1327 3.22.3. Solution Description 1329 Now partial_bytes_acked is increased by TSNs reported as duplicated 1330 as well as TSNs newly acknowledged in Gap Ack Blocks even if the 1331 Cumulative TSN Ack Point is not advanced. 1333 3.23. Inconsistency in Notifications Handling 1335 3.23.1. Description of the Problem 1337 [RFC4960] uses inconsistent normative and non-normative language when 1338 describing rules for sending notifications to the upper layer. E.g. 1339 Section 8.2 of [RFC4960] says that when a destination address becomes 1340 inactive due to an unacknowledged DATA chunk or HEARTBEAT chunk, SCTP 1341 SHOULD send a notification to the upper layer while Section 8.3 of 1342 [RFC4960] says that when a destination address becomes inactive due 1343 to an unacknowledged HEARTBEAT chunk, SCTP may send a notification to 1344 the upper layer. 1346 This makes the text inconsistent. 1348 3.23.2. Text Changes to the Document 1350 The following cahnge is based on the change described in Section 3.6. 1352 --------- 1353 Old text: (Section 8.1) 1354 --------- 1356 An endpoint shall keep a counter on the total number of consecutive 1357 retransmissions to its peer (this includes data retransmissions 1358 to all the destination transport addresses of the peer if it is 1359 multi-homed), including the number of unacknowledged HEARTBEAT 1360 chunks observed on the path which currently is used for data 1361 transfer. Unacknowledged HEARTBEAT chunks observed on paths 1362 different from the path currently used for data transfer shall 1363 not increment the association error counter, as this could lead 1364 to association closure even if the path which currently is used for 1365 data transfer is available (but idle). If the value of this 1366 counter exceeds the limit indicated in the protocol parameter 1367 'Association.Max.Retrans', the endpoint shall consider the peer 1368 endpoint unreachable and shall stop transmitting any more data to it 1369 (and thus the association enters the CLOSED state). In addition, the 1370 endpoint MAY report the failure to the upper layer and optionally 1371 report back all outstanding user data remaining in its outbound 1372 queue. The association is automatically closed when the peer 1373 endpoint becomes unreachable. 1375 --------- 1376 New text: (Section 8.1) 1377 --------- 1379 An endpoint shall keep a counter on the total number of consecutive 1380 retransmissions to its peer (this includes data retransmissions 1381 to all the destination transport addresses of the peer if it is 1382 multi-homed), including the number of unacknowledged HEARTBEAT 1383 chunks observed on the path which currently is used for data 1384 transfer. Unacknowledged HEARTBEAT chunks observed on paths 1385 different from the path currently used for data transfer shall 1386 not increment the association error counter, as this could lead 1387 to association closure even if the path which currently is used for 1388 data transfer is available (but idle). If the value of this 1389 counter exceeds the limit indicated in the protocol parameter 1390 'Association.Max.Retrans', the endpoint shall consider the peer 1391 endpoint unreachable and shall stop transmitting any more data to it 1392 (and thus the association enters the CLOSED state). In addition, the 1393 endpoint SHOULD report the failure to the upper layer and optionally 1394 report back all outstanding user data remaining in its outbound 1395 queue. The association is automatically closed when the peer 1396 endpoint becomes unreachable. 1398 The following changes are based on [RFC4960]. 1400 --------- 1401 Old text: (Section 8.2) 1402 --------- 1404 When an outstanding TSN is acknowledged or a HEARTBEAT sent to that 1405 address is acknowledged with a HEARTBEAT ACK, the endpoint shall 1406 clear the error counter of the destination transport address to which 1407 the DATA chunk was last sent (or HEARTBEAT was sent). When the peer 1408 endpoint is multi-homed and the last chunk sent to it was a 1409 retransmission to an alternate address, there exists an ambiguity as 1410 to whether or not the acknowledgement should be credited to the 1411 address of the last chunk sent. However, this ambiguity does not 1412 seem to bear any significant consequence to SCTP behavior. If this 1413 ambiguity is undesirable, the transmitter may choose not to clear the 1414 error counter if the last chunk sent was a retransmission. 1416 --------- 1417 New text: (Section 8.2) 1418 --------- 1420 When an outstanding TSN is acknowledged or a HEARTBEAT sent to that 1421 address is acknowledged with a HEARTBEAT ACK, the endpoint shall 1422 clear the error counter of the destination transport address to which 1423 the DATA chunk was last sent (or HEARTBEAT was sent), and SHOULD 1424 also report to the upper layer when an inactive destination address 1425 is marked as active. When the peer endpoint is multi-homed and the 1426 last chunk sent to it was a retransmission to an alternate address, 1427 there exists an ambiguity as to whether or not the acknowledgement 1428 should be credited to the address of the last chunk sent. However, 1429 this ambiguity does not seem to bear any significant consequence to 1430 SCTP behavior. If this ambiguity is undesirable, the transmitter may 1431 choose not to clear the error counter if the last chunk sent was a 1432 retransmission. 1434 --------- 1435 Old text: (Section 8.3) 1436 --------- 1438 When the value of this counter reaches the protocol parameter 1439 'Path.Max.Retrans', the endpoint should mark the corresponding 1440 destination address as inactive if it is not so marked, and may also 1441 optionally report to the upper layer the change of reachability of 1442 this destination address. After this, the endpoint should continue 1443 HEARTBEAT on this destination address but should stop increasing the 1444 counter. 1446 --------- 1447 New text: (Section 8.3) 1448 --------- 1450 When the value of this counter exceeds the protocol parameter 1451 'Path.Max.Retrans', the endpoint should mark the corresponding 1452 destination address as inactive if it is not so marked, and SHOULD 1453 also report to the upper layer the change of reachability of this 1454 destination address. After this, the endpoint should continue 1455 HEARTBEAT on this destination address but should stop increasing the 1456 counter. 1458 --------- 1459 Old text: (Section 8.3) 1460 --------- 1462 Upon the receipt of the HEARTBEAT ACK, the sender of the HEARTBEAT 1463 should clear the error counter of the destination transport address 1464 to which the HEARTBEAT was sent, and mark the destination transport 1465 address as active if it is not so marked. The endpoint may 1466 optionally report to the upper layer when an inactive destination 1467 address is marked as active due to the reception of the latest 1468 HEARTBEAT ACK. The receiver of the HEARTBEAT ACK must also clear the 1469 association overall error count as well (as defined in Section 8.1). 1471 --------- 1472 New text: (Section 8.3) 1473 --------- 1475 Upon the receipt of the HEARTBEAT ACK, the sender of the HEARTBEAT 1476 should clear the error counter of the destination transport address 1477 to which the HEARTBEAT was sent, and mark the destination transport 1478 address as active if it is not so marked. The endpoint SHOULD 1479 report to the upper layer when an inactive destination address 1480 is marked as active due to the reception of the latest 1481 HEARTBEAT ACK. The receiver of the HEARTBEAT ACK should also clear 1482 the association overall error counter (as defined in Section 8.1). 1484 --------- 1485 Old text: (Section 9.2) 1486 --------- 1488 An endpoint should limit the number of retransmissions of the 1489 SHUTDOWN chunk to the protocol parameter 'Association.Max.Retrans'. 1490 If this threshold is exceeded, the endpoint should destroy the TCB 1491 and MUST report the peer endpoint unreachable to the upper layer (and 1492 thus the association enters the CLOSED state). 1494 --------- 1495 New text: (Section 9.2) 1496 --------- 1498 An endpoint should limit the number of retransmissions of the 1499 SHUTDOWN chunk to the protocol parameter 'Association.Max.Retrans'. 1500 If this threshold is exceeded, the endpoint should destroy the TCB 1501 and SHOULD report the peer endpoint unreachable to the upper layer 1502 (and thus the association enters the CLOSED state). 1504 --------- 1505 Old text: (Section 9.2) 1506 --------- 1508 The sender of the SHUTDOWN ACK should limit the number of 1509 retransmissions of the SHUTDOWN ACK chunk to the protocol parameter 1510 'Association.Max.Retrans'. If this threshold is exceeded, the 1511 endpoint should destroy the TCB and may report the peer endpoint 1512 unreachable to the upper layer (and thus the association enters the 1513 CLOSED state). 1515 --------- 1516 New text: (Section 9.2) 1517 --------- 1519 The sender of the SHUTDOWN ACK should limit the number of 1520 retransmissions of the SHUTDOWN ACK chunk to the protocol parameter 1521 'Association.Max.Retrans'. If this threshold is exceeded, the 1522 endpoint should destroy the TCB and SHOULD report the peer endpoint 1523 unreachable to the upper layer (and thus the association enters the 1524 CLOSED state). 1526 3.23.3. Solution Description 1528 The inconsistencies are removed by using consistently SHOULD. 1530 3.24. SACK.Delay Not Listed as a Protocol Parameter 1532 3.24.1. Description of the Problem 1534 SCTP as specified in [RFC4960] supports delaying SACKs. The timer 1535 value for this is a parameter and Section 6.2 of [RFC4960] specifies 1536 a default and maximum value for it. However, defining a name for 1537 this parameter and listing it in the table of protocol parameters in 1538 Section 15 of [RFC4960] is missing. 1540 This issue was reported as an Errata for [RFC4960] with Errata ID 1541 4656. 1543 3.24.2. Text Changes to the Document 1545 --------- 1546 Old text: (Section 6.2) 1547 --------- 1549 An implementation MUST NOT allow the maximum delay to be configured 1550 to be more than 500 ms. In other words, an implementation MAY lower 1551 this value below 500 ms but MUST NOT raise it above 500 ms. 1553 --------- 1554 New text: (Section 6.2) 1555 --------- 1557 An implementation MUST NOT allow the maximum delay (protocol 1558 parameter 'SACK.Delay') to be configured to be more than 500 ms. 1559 In other words, an implementation MAY lower the value of 1560 SACK.Delay below 500 ms but MUST NOT raise it above 500 ms. 1562 --------- 1563 Old text: (Section 15) 1564 --------- 1566 The following protocol parameters are RECOMMENDED: 1568 RTO.Initial - 3 seconds 1569 RTO.Min - 1 second 1570 RTO.Max - 60 seconds 1571 Max.Burst - 4 1572 RTO.Alpha - 1/8 1573 RTO.Beta - 1/4 1574 Valid.Cookie.Life - 60 seconds 1575 Association.Max.Retrans - 10 attempts 1576 Path.Max.Retrans - 5 attempts (per destination address) 1577 Max.Init.Retransmits - 8 attempts 1578 HB.interval - 30 seconds 1579 HB.Max.Burst - 1 1581 --------- 1582 New text: (Section 15) 1583 --------- 1585 The following protocol parameters are RECOMMENDED: 1587 RTO.Initial - 3 seconds 1588 RTO.Min - 1 second 1589 RTO.Max - 60 seconds 1590 Max.Burst - 4 1591 RTO.Alpha - 1/8 1592 RTO.Beta - 1/4 1593 Valid.Cookie.Life - 60 seconds 1594 Association.Max.Retrans - 10 attempts 1595 Path.Max.Retrans - 5 attempts (per destination address) 1596 Max.Init.Retransmits - 8 attempts 1597 HB.interval - 30 seconds 1598 HB.Max.Burst - 1 1599 SACK.Delay - 200 milliseconds 1601 3.24.3. Solution Description 1603 The parameter was given a name and added to the list of protocol 1604 parameters. 1606 3.25. Processing of Chunks in an Incoming SCTP Packet 1608 3.25.1. Description of the Problem 1610 There are a few places in [RFC4960] where the receiver of a packet 1611 must discard it while processing the chunks of the packet. It is 1612 unclear whether the receiver has to rollback state changes already 1613 performed while processing the packet or not. 1615 The intention of [RFC4960] is to process an incoming packet chunk by 1616 chunk and do not perform any prescreening of chunks in the received 1617 packet so the receiver must only discard a chunk causing discard and 1618 all further chunks. 1620 3.25.2. Text Changes to the Document 1622 --------- 1623 Old text: (Section 3.2) 1624 --------- 1626 00 - Stop processing this SCTP packet and discard it, do not 1627 process any further chunks within it. 1629 01 - Stop processing this SCTP packet and discard it, do not 1630 process any further chunks within it, and report the 1631 unrecognized chunk in an 'Unrecognized Chunk Type'. 1633 --------- 1634 New text: (Section 3.2) 1635 --------- 1637 00 - Stop processing this SCTP packet, discard the unrecognized 1638 chunk and all further chunks. 1640 01 - Stop processing this SCTP packet, discard the unrecognized 1641 chunk and all further chunks, and report the unrecognized 1642 chunk in an 'Unrecognized Chunk Type'. 1644 --------- 1645 Old text: (Section 11.3) 1646 --------- 1648 It is helpful for some firewalls if they can inspect just the first 1649 fragment of a fragmented SCTP packet and unambiguously determine 1650 whether it corresponds to an INIT chunk (for further information, 1651 please refer to [RFC1858]). Accordingly, we stress the requirements, 1652 stated in Section 3.1, that (1) an INIT chunk MUST NOT be bundled 1653 with any other chunk in a packet, and (2) a packet containing an INIT 1654 chunk MUST have a zero Verification Tag. Furthermore, we require 1655 that the receiver of an INIT chunk MUST enforce these rules by 1656 silently discarding an arriving packet with an INIT chunk that is 1657 bundled with other chunks or has a non-zero verification tag and 1658 contains an INIT-chunk. 1660 --------- 1661 New text: (Section 11.3) 1662 --------- 1664 It is helpful for some firewalls if they can inspect just the first 1665 fragment of a fragmented SCTP packet and unambiguously determine 1666 whether it corresponds to an INIT chunk (for further information, 1667 please refer to [RFC1858]). Accordingly, we stress the requirements, 1668 stated in Section 3.1, that (1) an INIT chunk MUST NOT be bundled 1669 with any other chunk in a packet, and (2) a packet containing an INIT 1670 chunk MUST have a zero Verification Tag. Furthermore, we require 1671 that the receiver of an INIT chunk MUST enforce these rules by 1672 silently discarding the INIT chunk and all further chunks if the INIT 1673 chunk is bundled with other chunks or the packet has a non-zero 1674 verification tag. 1676 3.25.3. Solution Description 1678 The new text makes it clear that chunks can be processed from the 1679 beginning to the end and no rollback or pre-screening is required. 1681 3.26. CWND Increase in Congestion Avoidance Phase 1683 3.26.1. Description of the Problem 1685 [RFC4960] in Section 7.2.2 prescribes to increase cwnd by 1*MTU per 1686 RTT if the sender has cwnd or more bytes of outstanding data to the 1687 corresponding address in the Congestion Avoidance phase. However, 1688 this is described without normative language. Moreover, 1689 Section 7.2.2 includes an algorithm how an implementation can achieve 1690 it but this algorithm is underspecified and actually allows 1691 increasing cwnd by more than 1*MTU per RTT. 1693 3.26.2. Text Changes to the Document 1695 --------- 1696 Old text: (Section 7.2.2) 1697 --------- 1699 When cwnd is greater than ssthresh, cwnd should be incremented by 1700 1*MTU per RTT if the sender has cwnd or more bytes of data 1701 outstanding for the corresponding transport address. 1703 --------- 1704 New text: (Section 7.2.2) 1705 --------- 1707 When cwnd is greater than ssthresh, cwnd should be incremented by 1708 1*MTU per RTT if the sender has cwnd or more bytes of data 1709 outstanding for the corresponding transport address. The basic 1710 guidelines for incrementing cwnd during congestion avoidance are: 1712 o SCTP MAY increment cwnd by 1*MTU. 1714 o SCTP SHOULD increment cwnd by one 1*MTU once per RTT when 1715 the sender has cwnd or more bytes of data outstanding for 1716 the corresponding transport address. 1718 o SCTP MUST NOT increment cwnd by more than 1*MTU per RTT. 1720 --------- 1721 Old text: (Section 7.2.2) 1722 --------- 1724 o Whenever cwnd is greater than ssthresh, upon each SACK arrival 1725 that advances the Cumulative TSN Ack Point, increase 1726 partial_bytes_acked by the total number of bytes of all new chunks 1727 acknowledged in that SACK including chunks acknowledged by the new 1728 Cumulative TSN Ack and by Gap Ack Blocks. 1730 o When partial_bytes_acked is equal to or greater than cwnd and 1731 before the arrival of the SACK the sender had cwnd or more bytes 1732 of data outstanding (i.e., before arrival of the SACK, flightsize 1733 was greater than or equal to cwnd), increase cwnd by MTU, and 1734 reset partial_bytes_acked to (partial_bytes_acked - cwnd). 1736 --------- 1737 New text: (Section 7.2.2) 1738 --------- 1740 o Whenever cwnd is greater than ssthresh, upon each SACK arrival, 1741 increase partial_bytes_acked by the total number of bytes of all 1742 new chunks acknowledged in that SACK including chunks acknowledged 1743 by the new Cumulative TSN Ack, by Gap Ack Blocks and by the number 1744 of bytes of duplicated chunks reported in Duplicate TSNs. 1746 o When partial_bytes_acked is greater than cwnd and before the 1747 arrival of the SACK the sender had less bytes of data outstanding 1748 than cwnd (i.e., before arrival of the SACK, flightsize was less 1749 than cwnd), reset partial_bytes_acked to cwnd. 1751 o When partial_bytes_acked is equal to or greater than cwnd and 1752 before the arrival of the SACK the sender had cwnd or more bytes 1753 of data outstanding (i.e., before arrival of the SACK, flightsize 1754 was greater than or equal to cwnd), partial_bytes_acked is reset 1755 to (partial_bytes_acked - cwnd). Next, cwnd is increased by MTU. 1757 3.26.3. Solution Description 1759 The basic guidelines for incrementing cwnd during congestion 1760 avoidance phase are added into Section 7.2.2. The guidelines include 1761 the normative language and are aligned with [RFC5681]. 1763 The algorithm from Section 7.2.2 is improved to not allow increasing 1764 cwnd by more than 1*MTU per RTT. 1766 3.27. Refresh of cwnd and ssthresh after Idle Period 1768 3.27.1. Description of the Problem 1770 [RFC4960] prescribes to adjust cwnd per RTO if the endpoint does not 1771 transmit data on a given transport address. In addition to that, it 1772 prescribes to set cwnd to the initial value after a sufficiently long 1773 idle period. The latter is excessive. Moreover, it is unclear what 1774 is a sufficiently long idle period. 1776 [RFC4960] doesn't specify the handling of ssthresh in the idle case. 1777 If ssthres is reduced due to a packet loss, ssthresh is never 1778 recovered. So traffic can end up in Congestion Avoidance all the 1779 time, resulting in a low sending rate and bad performance. The 1780 problem is even more serious for SCTP because in a multi-homed SCTP 1781 association traffic switch back to the previously failed primary path 1782 will also lead to the situation where traffic ends up in Congestion 1783 Avoidance. 1785 3.27.2. Text Changes to the Document 1787 --------- 1788 Old text: (Section 7.2.1) 1789 --------- 1791 o The initial cwnd before DATA transmission or after a sufficiently 1792 long idle period MUST be set to min(4*MTU, max (2*MTU, 4380 1793 bytes)). 1795 --------- 1796 New text: (Section 7.2.1) 1797 --------- 1799 o The initial cwnd before DATA transmission MUST be set to 1800 min(4*MTU, max (2*MTU, 4380 bytes)). 1802 --------- 1803 Old text: (Section 7.2.1) 1804 --------- 1806 o When the endpoint does not transmit data on a given transport 1807 address, the cwnd of the transport address should be adjusted to 1808 max(cwnd/2, 4*MTU) per RTO. 1810 --------- 1811 New text: (Section 7.2.1) 1812 --------- 1813 o When the endpoint does not transmit data on a given transport 1814 address, the cwnd of the transport address should be adjusted to 1815 max(cwnd/2, 4*MTU) per RTO. At the first cwnd adjustment, the 1816 ssthresh of the transport address should be adjusted to the cwnd. 1818 3.27.3. Solution Description 1820 A rule about cwnd adjustment after a sufficiently long idle period is 1821 removed. 1823 The text is updated to refresh ssthresh after the idle period. When 1824 the idle period is detected, the cwnd value is stored to the ssthresh 1825 value. 1827 3.28. Window Updates After Receiver Window Opens Up 1828 3.28.1. Description of the Problem 1830 The sending of SACK chunks for window updates is only indirectly 1831 referenced in [RFC4960], Section 6.2, where it is stated that an SCTP 1832 receiver must not generate more than one SACK for every incoming 1833 packet, other than to update the offered window. 1835 However, the sending of window updates when the receiver window opens 1836 up is necessary to avoid performance problems. 1838 3.28.2. Text Changes to the Document 1840 --------- 1841 Old text: (Section 6.2) 1842 --------- 1844 An SCTP receiver MUST NOT generate more than one SACK for every 1845 incoming packet, other than to update the offered window as the 1846 receiving application consumes new data. 1848 --------- 1849 New text: (Section 6.2) 1850 --------- 1852 An SCTP receiver MUST NOT generate more than one SACK for every 1853 incoming packet, other than to update the offered window as the 1854 receiving application consumes new data. When the window opens 1855 up, an SCTP receiver SHOULD send additional SACK chunks to update 1856 the window even if no new data is received. The receiver MUST avoid 1857 sending large burst of window updates. 1859 3.28.3. Solution Description 1861 The new text makes clear that additional SACK chunks for window 1862 updates should be sent as long as excessive bursts are avoided. 1864 3.29. Path of DATA and Reply Chunks 1866 3.29.1. Description of the Problem 1868 Section 6.4 of [RFC4960] describes the transmission policy for multi- 1869 homed SCTP endpoints. However, there are the following issues with 1870 it: 1872 o It states that a SACK should be sent to the source address of an 1873 incoming DATA. However, it is known that other SACK policies 1874 (e.g. sending SACKs always to the primary path) may be more 1875 beneficial in some situations. 1876 o Initially it states that an endpoint should always transmit DATA 1877 chunks to the primary path. Then it states that the rule for 1878 transmittal of reply chunks should also be followed if the 1879 endpoint is bundling DATA chunks together with the reply chunk 1880 which contradicts with the first statement to always transmit DATA 1881 chunks to the primary path. Some implementations were having 1882 problems with it and sent DATA chunks bundled with reply chunks to 1883 a different destination address than the primary path that caused 1884 many gaps. 1886 3.29.2. Text Changes to the Document 1888 --------- 1889 Old text: (Section 6.4) 1890 --------- 1892 An endpoint SHOULD transmit reply chunks (e.g., SACK, HEARTBEAT ACK, 1893 etc.) to the same destination transport address from which it 1894 received the DATA or control chunk to which it is replying. This 1895 rule should also be followed if the endpoint is bundling DATA chunks 1896 together with the reply chunk. 1898 However, when acknowledging multiple DATA chunks received in packets 1899 from different source addresses in a single SACK, the SACK chunk may 1900 be transmitted to one of the destination transport addresses from 1901 which the DATA or control chunks being acknowledged were received. 1903 --------- 1904 New text: (Section 6.4) 1905 --------- 1907 An endpoint SHOULD transmit reply chunks (e.g., INIT ACK, COOKIE ACK, 1908 HEARTBEAT ACK, etc.) in response to control chunks to the same 1909 destination transport address from which it received the control 1910 chunk to which it is replying. 1912 The selection of the destination transport address for packets 1913 containing SACK chunks is implementation dependent. However, an endpoint 1914 SHOULD NOT vary the destination transport address of a SACK when it 1915 receives DATA chunks from the same source address. 1917 When acknowledging multiple DATA chunks received in packets 1918 from different source addresses in a single SACK, the SACK chunk MAY 1919 be transmitted to one of the destination transport addresses from 1920 which the DATA or control chunks being acknowledged were received. 1922 3.29.3. Solution Description 1924 The SACK transmission policy is left implementation dependent but it 1925 is specified to not vary the destination address of a packet 1926 containing a SACK chunk unless there are reasons for it as it may 1927 negatively impact RTT measurement. 1929 A confusing statement that prescribes to follow the rule for 1930 transmittal of reply chunks when the endpoint is bundling DATA chunks 1931 together with the reply chunk is removed. 1933 3.30. Outstanding Data, Flightsize and Data In Flight Key Terms 1935 3.30.1. Description of the Problem 1937 [RFC4960] uses outstanding data, flightsize and data in flight key 1938 terms in formulas and statements but their definitions are not 1939 provided in Section 1.3. Furthermore, outstanding data does not 1940 include DATA chunks which are classified as lost but which has not 1941 been retransmitted yet and there is a paragraph in Section 6.1 of 1942 [RFC4960] where this statement is broken. 1944 3.30.2. Text Changes to the Document 1946 --------- 1947 Old text: (Section 1.3) 1948 --------- 1950 o Congestion window (cwnd): An SCTP variable that limits the data, 1951 in number of bytes, a sender can send to a particular destination 1952 transport address before receiving an acknowledgement. 1954 ... 1956 o Outstanding TSN (at an SCTP endpoint): A TSN (and the associated 1957 DATA chunk) that has been sent by the endpoint but for which it 1958 has not yet received an acknowledgement. 1960 --------- 1961 New text: (Section 1.3) 1962 --------- 1964 o Outstanding TSN (at an SCTP endpoint): A TSN (and the associated 1965 DATA chunk) that has been sent by the endpoint but for which it 1966 has not yet received an acknowledgement. 1968 o Outstanding data (or Data outstanding or Data in flight): The 1969 total amount of the DATA chunks associated with outstanding TSNs. 1971 A retransmitted DATA chunk is counted once in outstanding data. 1972 A DATA chunk which is classified as lost but which has not been 1973 retransmitted yet is not in outstanding data. 1975 o Flightsize: The amount of bytes of outstanding data to a 1976 particular destination transport address at any given time. 1978 o Congestion window (cwnd): An SCTP variable that limits outstanding 1979 data, in number of bytes, a sender can send to a particular 1980 destination transport address before receiving an acknowledgement. 1982 --------- 1983 Old text: (Section 6.1) 1984 --------- 1986 C) When the time comes for the sender to transmit, before sending new 1987 DATA chunks, the sender MUST first transmit any outstanding DATA 1988 chunks that are marked for retransmission (limited by the current 1989 cwnd). 1991 --------- 1992 New text: (Section 6.1) 1993 --------- 1995 C) When the time comes for the sender to transmit, before sending new 1996 DATA chunks, the sender MUST first transmit any DATA chunks that 1997 are marked for retransmission (limited by the current cwnd). 1999 3.30.3. Solution Description 2001 Now Section 1.3, Key Terms, includes explanations of outstanding 2002 data, data in flight and flightsize key terms. Section 6.1 is 2003 corrected to properly use the outstanding data term. 2005 3.31. CWND Degradation due to Max.Burst 2007 3.31.1. Description of the Problem 2009 Some implementations were experiencing a degradation of cwnd because 2010 of the Max.Burst limit. This was due to misinterpretation of the 2011 suggestion in [RFC4960], Section 6.1, on how to use the Max.Burst 2012 parameter when calculating the number of packets to transmit. 2014 3.31.2. Text Changes to the Document 2015 --------- 2016 Old text: (Section 6.1) 2017 --------- 2019 D) When the time comes for the sender to transmit new DATA chunks, 2020 the protocol parameter Max.Burst SHOULD be used to limit the 2021 number of packets sent. The limit MAY be applied by adjusting 2022 cwnd as follows: 2024 if((flightsize + Max.Burst*MTU) < cwnd) cwnd = flightsize + 2025 Max.Burst*MTU 2027 Or it MAY be applied by strictly limiting the number of packets 2028 emitted by the output routine. 2030 --------- 2031 New text: (Section 6.1) 2032 --------- 2034 D) When the time comes for the sender to transmit new DATA chunks, 2035 the protocol parameter Max.Burst SHOULD be used to limit the 2036 number of packets sent. The limit MAY be applied by adjusting 2037 cwnd as follows: 2039 if((flightsize + Max.Burst*MTU) < cwnd) 2040 cwnd = flightsize + Max.Burst*MTU 2042 Or it MAY be applied by strictly limiting the number of packets 2043 emitted by the output routine. When calculating the number of 2044 packets to transmit and particularly using the formula above, 2045 cwnd SHOULD NOT be changed. 2047 3.31.3. Solution Description 2049 The new text clarifies that cwnd should not be changed when appling 2050 the Max.Burst limit. This mitigates packet bursts related to the 2051 reception of SACK chunks, but not bursts related to an application 2052 sending a burst of user messages. 2054 3.32. Reduction of RTO.Initial 2056 3.32.1. Description of the Problem 2058 [RFC4960] uses 3 seconds as the default value for RTO.Initial in 2059 accordance with Section 4.3.2.1 of [RFC1122]. [RFC6298] updates 2060 [RFC1122] and lowers the initial value of the retransmission timer 2061 from 3 seconds to 1 second. 2063 3.32.2. Text Changes to the Document 2065 --------- 2066 Old text: (Section 15) 2067 --------- 2069 The following protocol parameters are RECOMMENDED: 2071 RTO.Initial - 3 seconds 2072 RTO.Min - 1 second 2073 RTO.Max - 60 seconds 2074 Max.Burst - 4 2075 RTO.Alpha - 1/8 2076 RTO.Beta - 1/4 2077 Valid.Cookie.Life - 60 seconds 2078 Association.Max.Retrans - 10 attempts 2079 Path.Max.Retrans - 5 attempts (per destination address) 2080 Max.Init.Retransmits - 8 attempts 2081 HB.interval - 30 seconds 2082 HB.Max.Burst - 1 2083 SACK.Delay - 200 milliseconds 2085 --------- 2086 New text: (Section 15) 2087 --------- 2089 The following protocol parameters are RECOMMENDED: 2091 RTO.Initial - 1 second 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 3.32.3. Solution Description 2107 The value RTO.Initial has been lowered to 1 second to be in tune with 2108 [RFC6298]. 2110 3.33. Ordering of Bundled SACK and ERROR Chunks 2112 3.33.1. Description of the Problem 2114 When an SCTP endpoint receives a DATA chunk with an invalid stream 2115 identifier it shall acknowledge it by sending a SACK chunk and 2116 indicate that the stream identifier was invalid by sending an ERROR 2117 chunk. These two chunks may be bundled. However, [RFC4960] requires 2118 in case of bundling that the ERROR chunk follows the SACK chunk. 2119 This restriction of the ordering is not necessary and might only 2120 limit interoperability. 2122 3.33.2. Text Changes to the Document 2124 --------- 2125 Old text: (Section 6.5) 2126 --------- 2128 Every DATA chunk MUST carry a valid stream identifier. If an 2129 endpoint receives a DATA chunk with an invalid stream identifier, it 2130 shall acknowledge the reception of the DATA chunk following the 2131 normal procedure, immediately send an ERROR chunk with cause set to 2132 "Invalid Stream Identifier" (see Section 3.3.10), and discard the 2133 DATA chunk. The endpoint may bundle the ERROR chunk in the same 2134 packet as the SACK as long as the ERROR follows the SACK. 2136 --------- 2137 New text: (Section 6.5) 2138 --------- 2140 Every DATA chunk MUST carry a valid stream identifier. If an 2141 endpoint receives a DATA chunk with an invalid stream identifier, it 2142 shall acknowledge the reception of the DATA chunk following the 2143 normal procedure, immediately send an ERROR chunk with cause set to 2144 "Invalid Stream Identifier" (see Section 3.3.10), and discard the 2145 DATA chunk. The endpoint may bundle the ERROR chunk and the SACK Chunk 2146 in the same packet. 2148 3.33.3. Solution Description 2150 The unnecessary restriction regarding the ordering of the SACK and 2151 ERROR chunk has been removed. 2153 3.34. Undefined Parameter Returned by RECEIVE Primitive 2154 3.34.1. Description of the Problem 2156 [RFC4960] provides a description of an abstract API. In the 2157 definition of the RECEIVE primitive an optional parameter with name 2158 "delivery number" is mentioned. However, no definition of this 2159 parameter is given in [RFC4960] and the parameter is unnecessary. 2161 3.34.2. Text Changes to the Document 2163 --------- 2164 Old text: (Section 10.1) 2165 --------- 2167 G) Receive 2169 Format: RECEIVE(association id, buffer address, buffer size 2170 [,stream id]) 2171 -> byte count [,transport address] [,stream id] [,stream sequence 2172 number] [,partial flag] [,delivery number] [,payload protocol-id] 2174 --------- 2175 New text: (Section 10.1) 2176 --------- 2178 G) Receive 2180 Format: RECEIVE(association id, buffer address, buffer size 2181 [,stream id]) 2182 -> byte count [,transport address] [,stream id] [,stream sequence 2183 number] [,partial flag] [,payload protocol-id] 2185 3.34.3. Solution Description 2187 The undefined parameter has been removed. 2189 3.35. DSCP Changes 2191 3.35.1. Description of the Problem 2193 The upper layer can change the Differentiated Services Code Point 2194 (DSCP) used for packets being sent. A change of the DSCP can result 2195 in packets hitting different queues on the path and therefore the 2196 congestion control should be initialized when the DSCP is changed by 2197 the upper layer. This is not described in [RFC4960]. 2199 3.35.2. Text Changes to the Document 2201 --------- 2202 New text: (Section 7.2.5) 2203 --------- 2205 SCTP implementations MAY allow an application to configure the 2206 Differentiated Services Code Point (DSCP) used for sending packets. 2207 If a DSCP change might result in outgoing packets being queued in 2208 different queues, the congestion control parameters for all affected 2209 destination addresses MUST be reset to their initial values. 2211 --------- 2212 Old text: (Section 10.1) 2213 --------- 2215 M) Set Protocol Parameters 2217 Format: SETPROTOCOLPARAMETERS(association id, 2218 [,destination transport address,] 2219 protocol parameter list) 2220 -> result 2222 This primitive allows the local SCTP to customize the protocol 2223 parameters. 2225 Mandatory attributes: 2227 o association id - local handle to the SCTP association. 2229 o protocol parameter list - the specific names and values of the 2230 protocol parameters (e.g., Association.Max.Retrans; see Section 2231 15) that the SCTP user wishes to customize. 2233 --------- 2234 Old text: (Section 10.1) 2235 --------- 2237 M) Set Protocol Parameters 2239 Format: SETPROTOCOLPARAMETERS(association id, 2240 [,destination transport address,] 2241 protocol parameter list) 2242 -> result 2244 This primitive allows the local SCTP to customize the protocol 2245 parameters. 2247 Mandatory attributes: 2249 o association id - local handle to the SCTP association. 2251 o protocol parameter list - the specific names and values of the 2252 protocol parameters (e.g., Association.Max.Retrans; see Section 2253 15, or other parameters like the DSCP) that the SCTP user wishes 2254 to customize. 2256 3.35.3. Solution Description 2258 Text describing the required action on DSCP changes has been added. 2260 3.36. Inconsistent Handling of ICMPv4 and ICMPv6 Messages 2262 3.36.1. Description of the Problem 2264 Appendix C of [RFC4960] describes the handling of ICMPv4 and ICMPv6 2265 messages. The text explicitly describes the handling of ICMPv6 2266 packets indicating reachability problems, but does not do the same 2267 for the corresponding ICMPv4 packets. 2269 3.36.2. Text Changes to the Document 2270 --------- 2271 Old text: (Appendix C) 2272 --------- 2274 ICMP3) An implementation MAY ignore any ICMPv4 messages where the 2275 code does not indicate "Protocol Unreachable" or 2276 "Fragmentation Needed". 2278 --------- 2279 New text: 2280 --------- 2282 ICMP3) An implementation SHOULD ignore any ICMPv4 messages where the 2283 code indicates "Port Unreachable". 2285 --------- 2286 Old text: (Appendix C) 2287 --------- 2289 ICMP9) If the ICMPv6 code is "Destination Unreachable", the 2290 implementation MAY mark the destination into the unreachable 2291 state or alternatively increment the path error counter. 2293 --------- 2294 New text: 2295 --------- 2297 ICMP9) If the ICMP type is "Destination Unreachable", the 2298 implementation MAY mark the destination into the unreachable 2299 state or alternatively increment the path error counter. 2301 3.36.3. Solution Description 2303 The text has been changed to not limit the processing of ICMPv4 2304 packets with type "Destination Unreachable" by rewording the third 2305 rule. Furthermore, remove in the ninth rule the limitation to 2306 ICMPv6. 2308 3.37. Handling of Soft Errors 2310 3.37.1. Description of the Problem 2312 [RFC1122] defines the handling of soft errors and hard errors for 2313 TCP. Appendix C of [RFC4960] only deals with hard errors. 2315 3.37.2. Text Changes to the Document 2317 --------- 2318 Old text: (Appendix C) 2319 --------- 2321 ICMP8) If the ICMP type is "Destination Unreachable", the 2322 implementation MAY mark the destination into the unreachable 2323 state or alternatively increment the path error counter. 2325 --------- 2326 New text: (Appendix C) 2327 --------- 2329 ICMP8) If the ICMP type is "Destination Unreachable", the 2330 implementation MAY mark the destination into the unreachable 2331 state or alternatively increment the path error counter. 2332 SCTP MAY provide information to the upper layer indicating 2333 the reception of ICMP messages when reporting a network status 2334 change. 2336 3.37.3. Solution Description 2338 Text has been added allowing the SCTP to notify the application in 2339 case of soft errors. 2341 3.38. Honoring CWND 2343 3.38.1. Description of the Problem 2345 When using the slow start algorithm, SCTP increases the congestion 2346 window only when it is being fully utilized. Since SCTP uses DATA 2347 chunks and does not use the congestion window to fragment user 2348 messages, this requires that some overbooking of the congestion 2349 window is allowed. 2351 3.38.2. Text Changes to the Document 2352 --------- 2353 Old text: (Section 6.1) 2354 --------- 2356 B) At any given time, the sender MUST NOT transmit new data to a 2357 given transport address if it has cwnd or more bytes of data 2358 outstanding to that transport address. 2360 --------- 2361 New text: (Section 6.1) 2362 --------- 2364 B) At any given time, the sender MUST NOT transmit new data to a 2365 given transport address if it has cwnd + (PMTU - 1) or more bytes 2366 of data outstanding to that transport address. If data is 2367 available the sender SHOULD exceed cwnd by up to (PMTU-1) bytes on 2368 a new data transmission if the flightsize does not currently reach 2369 cwnd. The breach of cwnd MUST constitute one packet only. 2371 --------- 2372 Old text: (Section 7.2.1) 2373 --------- 2375 o Whenever cwnd is greater than zero, the endpoint is allowed to 2376 have cwnd bytes of data outstanding on that transport address. 2378 --------- 2379 New text: (Section 7.2.1) 2380 --------- 2381 o Whenever cwnd is greater than zero, the endpoint is allowed to 2382 have cwnd bytes of data outstanding on that transport address. 2383 A limited overbooking as described in B) of Section 6.1 should 2384 be supported. 2386 3.38.3. Solution Description 2388 Text was added that to clarify how the CWND limit should be handled. 2390 3.39. Zero Window Probing 2392 3.39.1. Description of the Problem 2394 The text describing zero window probing was not clearly handling the 2395 case where the window was not zero, but too small for the next DATA 2396 chunk to be transmitted. Even in this case, zero window probing has 2397 to be performed to avoid deadlocks. 2399 3.39.2. Text Changes to the Document 2401 --------- 2402 Old text: (Section 6.1) 2403 --------- 2405 A) At any given time, the data sender MUST NOT transmit new data to 2406 any destination transport address if its peer's rwnd indicates 2407 that the peer has no buffer space (i.e., rwnd is 0; see Section 2408 6.2.1). However, regardless of the value of rwnd (including if it 2409 is 0), the data sender can always have one DATA chunk in flight to 2410 the receiver if allowed by cwnd (see rule B, below). This rule 2411 allows the sender to probe for a change in rwnd that the sender 2412 missed due to the SACK's having been lost in transit from the data 2413 receiver to the data sender. 2415 When the receiver's advertised window is zero, this probe is 2416 called a zero window probe. Note that a zero window probe SHOULD 2417 only be sent when all outstanding DATA chunks have been 2418 cumulatively acknowledged and no DATA chunks are in flight. Zero 2419 window probing MUST be supported. 2421 --------- 2422 New 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 smaller than the 2428 size of the next DATA chunk; see Section 6.2.1). 2429 However, regardless of the value of rwnd (including if it is 0), 2430 the data sender can always have one DATA chunk in flight to 2431 the receiver if allowed by cwnd (see rule B, below). This rule 2432 allows the sender to probe for a change in rwnd that the sender 2433 missed due to the SACK's having been lost in transit from the data 2434 receiver to the data sender. 2436 When the receiver has no buffer space, this probe is 2437 called a zero window probe. Note that a zero window probe SHOULD 2438 only be sent when all outstanding DATA chunks have been 2439 cumulatively acknowledged and no DATA chunks are in flight. Zero 2440 window probing MUST be supported. 2442 3.39.3. Solution Description 2444 The terminology is used in a cleaner way. 2446 3.40. Updating References Regarding ECN 2448 3.40.1. Description of the Problem 2450 [RFC4960] refers for ECN only to [RFC3168], which will be updated by 2451 [I-D.ietf-tsvwg-ecn-experimentation]. This needs to be reflected 2452 when referring to ECN. 2454 3.40.2. Text Changes to the Document 2456 --------- 2457 Old text: (Appendix A) 2458 --------- 2460 ECN [RFC3168] describes a proposed extension to IP that details a 2461 method to become aware of congestion outside of datagram loss. 2463 --------- 2464 New text: (Appendix A) 2465 --------- 2467 ECN as specified in [RFC3168] updated by 2468 [I-D.ietf-tsvwg-ecn-experimentation] describes a proposed extension 2469 to IP that details a method to become aware of congestion outside 2470 of datagram loss. 2472 --------- 2473 Old text: (Appendix A) 2474 --------- 2476 In general, [RFC3168] should be followed with the following 2477 exceptions. 2479 --------- 2480 New text: (Appendix A) 2481 --------- 2483 In general, [RFC3168] updated by [I-D.ietf-tsvwg-ecn-experimentation] 2484 should be followed with the following exceptions. 2486 --------- 2487 Old text: (Appendix A) 2488 --------- 2490 [RFC3168] details negotiation of ECN during the SYN and SYN-ACK 2491 stages of a TCP connection. 2493 --------- 2494 New text: (Appendix A) 2495 --------- 2497 [RFC3168] updated by [I-D.ietf-tsvwg-ecn-experimentation] details 2498 negotiation of ECN during the SYN and SYN-ACK stages of a TCP 2499 connection. 2501 --------- 2502 Old text: (Appendix A) 2503 --------- 2505 [RFC3168] details a specific bit for a receiver to send back in its 2506 TCP acknowledgements to notify the sender of the Congestion 2507 Experienced (CE) bit having arrived from the network. 2509 --------- 2510 New text: (Appendix A) 2511 --------- 2513 [RFC3168] updated by [I-D.ietf-tsvwg-ecn-experimentation] 2514 details a specific bit for a receiver to send back in its 2515 TCP acknowledgements to notify the sender of the Congestion 2516 Experienced (CE) bit having arrived from the network. 2518 --------- 2519 Old text: (Appendix A) 2520 --------- 2522 [RFC3168] details a specific bit for a sender to send in the header 2523 of its next outbound TCP segment to indicate to its peer that it has 2524 reduced its congestion window. 2525 --------- 2526 New text: (Appendix A) 2527 --------- 2529 [RFC3168] updated by [I-D.ietf-tsvwg-ecn-experimentation] 2530 details a specific bit for a sender to send in the header 2531 of its next outbound TCP segment to indicate to its peer that it has 2532 reduced its congestion window. 2534 3.40.3. Solution Description 2536 References to [I-D.ietf-tsvwg-ecn-experimentation] have been added. 2538 3.41. Host Name Address Parameter Deprecated 2540 3.41.1. Description of the Problem 2542 [RFC4960] defines three types of address parameters to be used with 2543 INIT and INIT ACK chunks: 2545 1. IPv4 Address parameters. 2546 2. IPv6 Address parameters. 2547 3. Host Name Address parameters. 2549 The first two are supported by the SCTP kernel implementations of 2550 FreeBSD, Linux and Solaris, but the third one is not. In addition, 2551 the first two where successfully tested in all nine interoperability 2552 tests for SCTP, but the third one has never been successfully tested. 2553 Therefore, the Host Name Address parameter should be deprecated. 2555 3.41.2. Text Changes to the Document 2557 --------- 2558 Old text: (Section 3.3.2) 2559 --------- 2561 Note 3: An INIT chunk MUST NOT contain more than one Host Name 2562 Address parameter. Moreover, the sender of the INIT MUST NOT combine 2563 any other address types with the Host Name Address in the INIT. The 2564 receiver of INIT MUST ignore any other address types if the Host Name 2565 Address parameter is present in the received INIT chunk. 2567 --------- 2568 New text: (Section 3.3.2) 2569 --------- 2571 Note 3: An INIT chunk MUST NOT contain the Host Name Address 2572 parameter. The receiver of an INIT chunk containing an Host Name 2573 Address parameter MUST send an ABORT and MAY include an Error Cause 2574 indicating an Unresolvable Address. 2576 --------- 2577 Old text: (Section 3.3.2.1) 2578 --------- 2580 The sender of INIT uses this parameter to pass its Host Name (in 2581 place of its IP addresses) to its peer. The peer is responsible for 2582 resolving the name. Using this parameter might make it more likely 2583 for the association to work across a NAT box. 2585 --------- 2586 New text: (Section 3.3.2.1) 2587 --------- 2589 The sender of an INIT chunk MUST NOT include this parameter. The 2590 usage of the Host Name Address parameter is deprecated. 2592 --------- 2593 Old text: (Section 3.3.2.1) 2594 --------- 2596 Address Type: 16 bits (unsigned integer) 2598 This is filled with the type value of the corresponding address 2599 TLV (e.g., IPv4 = 5, IPv6 = 6, Host name = 11). 2601 --------- 2602 New text: (Section 3.3.2.1) 2603 --------- 2604 Address Type: 16 bits (unsigned integer) 2606 This is filled with the type value of the corresponding address 2607 TLV (e.g., IPv4 = 5, IPv6 = 6). The value indicating the Host 2608 Name Address parameter (Host name = 11) MUST NOT be used. 2610 --------- 2611 Old text: (Section 3.3.3) 2612 --------- 2614 Note 3: The INIT ACK chunks MUST NOT contain more than one Host Name 2615 Address parameter. Moreover, the sender of the INIT ACK MUST NOT 2616 combine any other address types with the Host Name Address in the 2617 INIT ACK. The receiver of the INIT ACK MUST ignore any other address 2618 types if the Host Name Address parameter is present. 2620 --------- 2621 New text: (Section 3.3.3) 2622 --------- 2624 Note 3: An INIT ACK chunk MUST NOT contain the Host Name Address 2625 parameter. The receiver of INIT ACK chunks containing an Host Name 2626 Address parameter MUST send an ABORT and MAY include an Error Cause 2627 indicating an Unresolvable Address. 2629 --------- 2630 Old text: (Section 5.1.2) 2631 --------- 2633 B) If there is a Host Name parameter present in the received INIT or 2634 INIT ACK chunk, the endpoint shall resolve that host name to a 2635 list of IP address(es) and derive the transport address(es) of 2636 this peer by combining the resolved IP address(es) with the SCTP 2637 source port. 2639 The endpoint MUST ignore any other IP Address parameters if they 2640 are also present in the received INIT or INIT ACK chunk. 2642 The time at which the receiver of an INIT resolves the host name 2643 has potential security implications to SCTP. If the receiver of 2644 an INIT resolves the host name upon the reception of the chunk, 2645 and the mechanism the receiver uses to resolve the host name 2646 involves potential long delay (e.g., DNS query), the receiver may 2647 open itself up to resource attacks for the period of time while it 2648 is waiting for the name resolution results before it can build the 2649 State Cookie and release local resources. 2651 Therefore, in cases where the name translation involves potential 2652 long delay, the receiver of the INIT MUST postpone the name 2653 resolution till the reception of the COOKIE ECHO chunk from the 2654 peer. In such a case, the receiver of the INIT SHOULD build the 2655 State Cookie using the received Host Name (instead of destination 2656 transport addresses) and send the INIT ACK to the source IP 2657 address from which the INIT was received. 2659 The receiver of an INIT ACK shall always immediately attempt to 2660 resolve the name upon the reception of the chunk. 2662 The receiver of the INIT or INIT ACK MUST NOT send user data 2663 (piggy-backed or stand-alone) to its peer until the host name is 2664 successfully resolved. 2666 If the name resolution is not successful, the endpoint MUST 2667 immediately send an ABORT with "Unresolvable Address" error cause 2668 to its peer. The ABORT shall be sent to the source IP address 2669 from which the last peer packet was received. 2671 --------- 2672 New text: (Section 5.1.2) 2673 --------- 2675 B) If there is a Host Name parameter present in the received INIT or 2676 INIT ACK chunk, the endpoint MUST immediately send an ABORT and 2677 MAY include an Error Cause indicating an Unresolvable Address to 2678 its peer. The ABORT shall be sent to the source IP address 2679 from which the last peer packet was received. 2681 --------- 2682 Old text: (Section 11.2.4.1) 2683 --------- 2685 The use of the host name feature in the INIT chunk could be used to 2686 flood a target DNS server. A large backlog of DNS queries, resolving 2687 the host name received in the INIT chunk to IP addresses, could be 2688 accomplished by sending INITs to multiple hosts in a given domain. 2689 In addition, an attacker could use the host name feature in an 2690 indirect attack on a third party by sending large numbers of INITs to 2691 random hosts containing the host name of the target. In addition to 2692 the strain on DNS resources, this could also result in large numbers 2693 of INIT ACKs being sent to the target. One method to protect against 2694 this type of attack is to verify that the IP addresses received from 2695 DNS include the source IP address of the original INIT. If the list 2696 of IP addresses received from DNS does not include the source IP 2697 address of the INIT, the endpoint MAY silently discard the INIT. 2698 This last option will not protect against the attack against the DNS. 2700 --------- 2701 New text: (Section 11.2.4.1) 2702 --------- 2704 The support of the Host Name Address parameter has been removed from 2705 the protocol. Endpoints receiving INIT or INIT ACK chunks containing 2706 the Host Name Address parameter MUST send an ABORT chunk in response 2707 an MAY include an Error Cause indicating an Unresolvable Address. 2709 3.41.3. Solution Description 2711 The usage of the Host Name Address parameter has been deprecated. 2713 3.42. Conflicting Text Regarding the Supported Address Types Parameter 2715 3.42.1. Description of the Problem 2717 When receiving an SCTP packet containing an INIT chunk sent from an 2718 address for which the corresponding address type is not listed in the 2719 Supported Address Types, there is conflicting text in Section 5.1.2 2720 of [RFC4960]. It is stated that the association MUST be aborted and 2721 also that the association SHOULD be established and there SHOULD NOT 2722 be any error indication. 2724 3.42.2. Text Changes to the Document 2725 --------- 2726 Old text: (Section 5.1.2) 2727 --------- 2729 The sender of INIT may include a 'Supported Address Types' parameter 2730 in the INIT to indicate what types of address are acceptable. When 2731 this parameter is present, the receiver of INIT (initiate) MUST 2732 either use one of the address types indicated in the Supported 2733 Address Types parameter when responding to the INIT, or abort the 2734 association with an "Unresolvable Address" error cause if it is 2735 unwilling or incapable of using any of the address types indicated by 2736 its peer. 2738 --------- 2739 New text: (Section 5.1.2) 2740 --------- 2742 The sender of INIT may include a 'Supported Address Types' parameter 2743 in the INIT to indicate what types of address are acceptable. 2745 3.42.3. Solution Description 2747 The conflicting text has been removed. 2749 3.43. Integration of RFC 6096 2751 3.43.1. Description of the Problem 2753 [RFC6096] updates [RFC4960] by adding a Chunk Flags Registry. This 2754 should be integrated into the base specification. 2756 3.43.2. Text Changes to the Document 2758 --------- 2759 Old text: (Section 14.1) 2760 --------- 2762 14.1. IETF-Defined Chunk Extension 2764 The assignment of new chunk parameter type codes is done through an 2765 IETF Consensus action, as defined in [RFC2434]. Documentation of the 2766 chunk parameter MUST contain the following information: 2768 a) A long and short name for the new chunk type. 2770 b) A detailed description of the structure of the chunk, which MUST 2771 conform to the basic structure defined in Section 3.2. 2773 c) A detailed definition and description of intended use of each 2774 field within the chunk, including the chunk flags if any. 2776 d) A detailed procedural description of the use of the new chunk type 2777 within the operation of the protocol. 2779 The last chunk type (255) is reserved for future extension if 2780 necessary. 2782 --------- 2783 New text: (Section 14.1) 2784 --------- 2786 14.1. IETF-Defined Chunk Extension 2788 The assignment of new chunk type codes is done through an IETF Review 2789 action, as defined in [RFC5226]. Documentation of a new chunk MUST 2790 contain the following information: 2792 a) A long and short name for the new chunk type; 2794 b) A detailed description of the structure of the chunk, which MUST 2795 conform to the basic structure defined in Section 3.2 of 2796 [RFC4960]; 2798 c) A detailed definition and description of intended use of each 2799 field within the chunk, including the chunk flags if any. 2800 Defined chunk flags will be used as initial entries in the chunk 2801 flags table for the new chunk type; 2803 d) A detailed procedural description of the use of the new chunk 2804 type within the operation of the protocol. 2806 The last chunk type (255) is reserved for future extension if 2807 necessary. 2809 For each new chunk type, IANA creates a registration table for the 2810 chunk flags of that type. The procedure for registering particular 2811 chunk flags is described in the following Section 14.2. 2813 --------- 2814 New text: (Section 14.2) 2815 --------- 2817 14.2. New IETF Chunk Flags Registration 2819 The assignment of new chunk flags is done through an RFC required 2820 action, as defined in [RFC5226]. Documentation of the chunk flags 2821 MUST contain the following information: 2823 a) A name for the new chunk flag; 2825 b) A detailed procedural description of the use of the new chunk 2826 flag within the operation of the protocol. It MUST be considered 2827 that implementations not supporting the flag will send '0' on 2828 transmit and just ignore it on receipt. 2830 IANA selects a chunk flags value. This must be one of 0x01, 0x02, 2831 0x04, 0x08, 0x10, 0x20, 0x40, or 0x80, which MUST be unique within 2832 the chunk flag values for the specific chunk type. 2834 Please note that Sections 14.2, 14.3, 14.4, and 14.5 need to be 2835 renumbered. 2837 3.43.3. Solution Description 2839 [RFC6096] was integrated. 2841 3.44. Integration of RFC 6335 2843 3.44.1. Description of the Problem 2845 [RFC6335] updates [RFC4960] by updating Procedures for the Port 2846 Numbers Registry. This should be integrated into the base 2847 specification. While there, update the reference to the RFC giving 2848 guidelines for writing IANA sections to [RFC8126]. 2850 3.44.2. Text Changes to the Document 2852 --------- 2853 Old text: (Section 14.5) 2854 --------- 2856 SCTP services may use contact port numbers to provide service to 2857 unknown callers, as in TCP and UDP. IANA is therefore requested to 2858 open the existing Port Numbers registry for SCTP using the following 2859 rules, which we intend to mesh well with existing Port Numbers 2860 registration procedures. An IESG-appointed Expert Reviewer supports 2861 IANA in evaluating SCTP port allocation requests, according to the 2862 procedure defined in [RFC2434]. 2864 Port numbers are divided into three ranges. The Well Known Ports are 2865 those from 0 through 1023, the Registered Ports are those from 1024 2866 through 49151, and the Dynamic and/or Private Ports are those from 2867 49152 through 65535. Well Known and Registered Ports are intended 2868 for use by server applications that desire a default contact point on 2869 a system. On most systems, Well Known Ports can only be used by 2870 system (or root) processes or by programs executed by privileged 2871 users, while Registered Ports can be used by ordinary user processes 2872 or programs executed by ordinary users. Dynamic and/or Private Ports 2873 are intended for temporary use, including client-side ports, out-of- 2874 band negotiated ports, and application testing prior to registration 2875 of a dedicated port; they MUST NOT be registered. 2877 The Port Numbers registry should accept registrations for SCTP ports 2878 in the Well Known Ports and Registered Ports ranges. Well Known and 2879 Registered Ports SHOULD NOT be used without registration. Although 2880 in some cases -- such as porting an application from TCP to SCTP -- 2881 it may seem natural to use an SCTP port before registration 2882 completes, we emphasize that IANA will not guarantee registration of 2883 particular Well Known and Registered Ports. Registrations should be 2884 requested as early as possible. 2886 Each port registration SHALL include the following information: 2888 o A short port name, consisting entirely of letters (A-Z and a-z), 2889 digits (0-9), and punctuation characters from "-_+./*" (not 2890 including the quotes). 2892 o The port number that is requested for registration. 2894 o A short English phrase describing the port's purpose. 2896 o Name and contact information for the person or entity performing 2897 the registration, and possibly a reference to a document defining 2898 the port's use. Registrations coming from IETF working groups 2899 need only name the working group, but indicating a contact person 2900 is recommended. 2902 Registrants are encouraged to follow these guidelines when submitting 2903 a registration. 2905 o A port name SHOULD NOT be registered for more than one SCTP port 2906 number. 2908 o A port name registered for TCP MAY be registered for SCTP as well. 2909 Any such registration SHOULD use the same port number as the 2910 existing TCP registration. 2912 o Concrete intent to use a port SHOULD precede port registration. 2913 For example, existing TCP ports SHOULD NOT be registered in 2914 advance of any intent to use those ports for SCTP. 2916 --------- 2917 New text: (Section 14.5) 2918 --------- 2920 SCTP services may use contact port numbers to provide service to 2921 unknown callers, as in TCP and UDP. IANA is therefore requested to 2922 open the existing Port Numbers registry for SCTP using the following 2923 rules, which we intend to mesh well with existing Port Numbers 2924 registration procedures. An IESG-appointed Expert Reviewer supports 2925 IANA in evaluating SCTP port allocation requests, according to the 2926 procedure defined in [RFC8126]. The details of this process are 2927 defined in [RFC6335]. 2929 3.44.3. Solution Description 2931 [RFC6335] was integrated and the reference was updated to [RFC8126]. 2933 3.45. Integration of RFC 7053 2935 3.45.1. Description of the Problem 2937 [RFC7053] updates [RFC4960] by adding the I bit to the DATA chunk. 2938 This should be integrated into the base specification. 2940 3.45.2. Text Changes to the Document 2942 --------- 2943 Old text: (Section 3.3.1) 2944 --------- 2946 The following format MUST be used for the DATA chunk: 2948 0 1 2 3 2949 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 2950 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2951 | Type = 0 | Reserved|U|B|E| Length | 2952 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2953 | TSN | 2954 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2955 | Stream Identifier S | Stream Sequence Number n | 2956 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2957 | Payload Protocol Identifier | 2958 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2959 \ \ 2960 / User Data (seq n of Stream S) / 2961 \ \ 2962 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2964 Reserved: 5 bits 2965 Should be set to all '0's and ignored by the receiver. 2967 --------- 2968 New text: (Section 3.3.1) 2969 --------- 2971 0 1 2 3 2972 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 2973 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2974 | Type = 0 | Res |I|U|B|E| Length | 2975 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2976 | TSN | 2977 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2978 | Stream Identifier S | Stream Sequence Number n | 2979 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2980 | Payload Protocol Identifier | 2981 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2982 \ \ 2983 / User Data (seq n of Stream S) / 2984 \ \ 2985 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2987 Res: 4 bits 2989 Should be set to all '0's and ignored by the receiver. 2991 I bit: 1 bit 2993 The (I)mmediate Bit MAY be set by the sender, whenever the sender of 2994 a DATA chunk can benefit from the corresponding SACK chunk being sent 2995 back without delay. See [RFC7053] for a discussion about 2997 --------- 2998 New text: (Append to Section 6.1) 2999 --------- 3001 Whenever the sender of a DATA chunk can benefit from the 3002 corresponding SACK chunk being sent back without delay, the sender 3003 MAY set the I bit in the DATA chunk header. Please note that why the 3004 sender has set the I bit is irrelevant to the receiver. 3006 Reasons for setting the I bit include, but are not limited to (see 3007 Section 4 of [RFC7053] for the benefits): 3009 o The application requests to set the I bit of the last DATA chunk 3010 of a user message when providing the user message to the SCTP 3011 implementation (see Section 7). 3013 o The sender is in the SHUTDOWN-PENDING state. 3015 o The sending of a DATA chunk fills the congestion or receiver 3016 window. 3018 --------- 3019 Old text: (Section 6.2) 3020 --------- 3022 Note: The SHUTDOWN chunk does not contain Gap Ack Block fields. 3023 Therefore, the endpoint should use a SACK instead of the SHUTDOWN 3024 chunk to acknowledge DATA chunks received out of order. 3026 --------- 3027 New text: (Section 6.2) 3028 --------- 3030 Note: The SHUTDOWN chunk does not contain Gap Ack Block fields. 3031 Therefore, the endpoint should use a SACK instead of the SHUTDOWN 3032 chunk to acknowledge DATA chunks received out of order. 3034 Upon receipt of an SCTP packet containing a DATA chunk with the I bit 3035 set, the receiver SHOULD NOT delay the sending of the corresponding 3036 SACK chunk, i.e., the receiver SHOULD immediately respond with the 3037 corresponding SACK chunk. 3039 --------- 3040 Old text: (Section 10.1) 3041 --------- 3043 E) Send 3045 Format: SEND(association id, buffer address, byte count [,context] 3046 [,stream id] [,life time] [,destination transport address] 3047 [,unordered flag] [,no-bundle flag] [,payload protocol-id] ) 3048 -> result 3050 --------- 3051 New text: (Section 10.1) 3052 --------- 3054 E) Send 3056 Format: SEND(association id, buffer address, byte count [,context] 3057 [,stream id] [,life time] [,destination transport address] 3058 [,unordered flag] [,no-bundle flag] [,payload protocol-id] 3059 [,sack immediately] ) 3061 -> result 3063 --------- 3064 New text: (Append optional parameter in Subsection E of Section 10.1) 3065 --------- 3067 o sack immediately - set the I bit on the last DATA chunk used for 3068 sending buffer. 3070 Please note that the change in Section 6.2 is only about adding a 3071 paragraph. 3073 3.45.3. Solution Description 3075 [RFC7053] was integrated. 3077 3.46. CRC32c Code Improvements 3079 3.46.1. Description of the Problem 3081 The code given for the CRC32c computations uses types like long which 3082 may have different length on different operating systems or 3083 processors. Therefore the code is changed to use specific types like 3084 uint32_t. 3086 While there, fix also some syntax errors. 3088 3.46.2. Text Changes to the Document 3090 --------- 3091 Old text: (Appendix B) 3092 --------- 3093 /* Example of the crc table file */ 3094 #ifndef __crc32cr_table_h__ 3095 #define __crc32cr_table_h__ 3097 #define CRC32C_POLY 0x1EDC6F41 3098 #define CRC32C(c,d) (c=(c>>8)^crc_c[(c^(d))&0xFF]) 3100 unsigned long crc_c[256] = 3101 { 3102 0x00000000L, 0xF26B8303L, 0xE13B70F7L, 0x1350F3F4L, 3103 0xC79A971FL, 0x35F1141CL, 0x26A1E7E8L, 0xD4CA64EBL, 3104 0x8AD958CFL, 0x78B2DBCCL, 0x6BE22838L, 0x9989AB3BL, 3105 0x4D43CFD0L, 0xBF284CD3L, 0xAC78BF27L, 0x5E133C24L, 3106 0x105EC76FL, 0xE235446CL, 0xF165B798L, 0x030E349BL, 3107 0xD7C45070L, 0x25AFD373L, 0x36FF2087L, 0xC494A384L, 3108 0x9A879FA0L, 0x68EC1CA3L, 0x7BBCEF57L, 0x89D76C54L, 3109 0x5D1D08BFL, 0xAF768BBCL, 0xBC267848L, 0x4E4DFB4BL, 3110 0x20BD8EDEL, 0xD2D60DDDL, 0xC186FE29L, 0x33ED7D2AL, 3111 0xE72719C1L, 0x154C9AC2L, 0x061C6936L, 0xF477EA35L, 3112 0xAA64D611L, 0x580F5512L, 0x4B5FA6E6L, 0xB93425E5L, 3113 0x6DFE410EL, 0x9F95C20DL, 0x8CC531F9L, 0x7EAEB2FAL, 3114 0x30E349B1L, 0xC288CAB2L, 0xD1D83946L, 0x23B3BA45L, 3116 0xF779DEAEL, 0x05125DADL, 0x1642AE59L, 0xE4292D5AL, 3117 0xBA3A117EL, 0x4851927DL, 0x5B016189L, 0xA96AE28AL, 3118 0x7DA08661L, 0x8FCB0562L, 0x9C9BF696L, 0x6EF07595L, 3119 0x417B1DBCL, 0xB3109EBFL, 0xA0406D4BL, 0x522BEE48L, 3120 0x86E18AA3L, 0x748A09A0L, 0x67DAFA54L, 0x95B17957L, 3121 0xCBA24573L, 0x39C9C670L, 0x2A993584L, 0xD8F2B687L, 3122 0x0C38D26CL, 0xFE53516FL, 0xED03A29BL, 0x1F682198L, 3123 0x5125DAD3L, 0xA34E59D0L, 0xB01EAA24L, 0x42752927L, 3124 0x96BF4DCCL, 0x64D4CECFL, 0x77843D3BL, 0x85EFBE38L, 3125 0xDBFC821CL, 0x2997011FL, 0x3AC7F2EBL, 0xC8AC71E8L, 3126 0x1C661503L, 0xEE0D9600L, 0xFD5D65F4L, 0x0F36E6F7L, 3127 0x61C69362L, 0x93AD1061L, 0x80FDE395L, 0x72966096L, 3128 0xA65C047DL, 0x5437877EL, 0x4767748AL, 0xB50CF789L, 3129 0xEB1FCBADL, 0x197448AEL, 0x0A24BB5AL, 0xF84F3859L, 3130 0x2C855CB2L, 0xDEEEDFB1L, 0xCDBE2C45L, 0x3FD5AF46L, 3131 0x7198540DL, 0x83F3D70EL, 0x90A324FAL, 0x62C8A7F9L, 3132 0xB602C312L, 0x44694011L, 0x5739B3E5L, 0xA55230E6L, 3133 0xFB410CC2L, 0x092A8FC1L, 0x1A7A7C35L, 0xE811FF36L, 3134 0x3CDB9BDDL, 0xCEB018DEL, 0xDDE0EB2AL, 0x2F8B6829L, 3135 0x82F63B78L, 0x709DB87BL, 0x63CD4B8FL, 0x91A6C88CL, 3136 0x456CAC67L, 0xB7072F64L, 0xA457DC90L, 0x563C5F93L, 3137 0x082F63B7L, 0xFA44E0B4L, 0xE9141340L, 0x1B7F9043L, 3138 0xCFB5F4A8L, 0x3DDE77ABL, 0x2E8E845FL, 0xDCE5075CL, 3139 0x92A8FC17L, 0x60C37F14L, 0x73938CE0L, 0x81F80FE3L, 3140 0x55326B08L, 0xA759E80BL, 0xB4091BFFL, 0x466298FCL, 3141 0x1871A4D8L, 0xEA1A27DBL, 0xF94AD42FL, 0x0B21572CL, 3142 0xDFEB33C7L, 0x2D80B0C4L, 0x3ED04330L, 0xCCBBC033L, 3143 0xA24BB5A6L, 0x502036A5L, 0x4370C551L, 0xB11B4652L, 3144 0x65D122B9L, 0x97BAA1BAL, 0x84EA524EL, 0x7681D14DL, 3145 0x2892ED69L, 0xDAF96E6AL, 0xC9A99D9EL, 0x3BC21E9DL, 3146 0xEF087A76L, 0x1D63F975L, 0x0E330A81L, 0xFC588982L, 3147 0xB21572C9L, 0x407EF1CAL, 0x532E023EL, 0xA145813DL, 3148 0x758FE5D6L, 0x87E466D5L, 0x94B49521L, 0x66DF1622L, 3149 0x38CC2A06L, 0xCAA7A905L, 0xD9F75AF1L, 0x2B9CD9F2L, 3150 0xFF56BD19L, 0x0D3D3E1AL, 0x1E6DCDEEL, 0xEC064EEDL, 3151 0xC38D26C4L, 0x31E6A5C7L, 0x22B65633L, 0xD0DDD530L, 3152 0x0417B1DBL, 0xF67C32D8L, 0xE52CC12CL, 0x1747422FL, 3153 0x49547E0BL, 0xBB3FFD08L, 0xA86F0EFCL, 0x5A048DFFL, 3154 0x8ECEE914L, 0x7CA56A17L, 0x6FF599E3L, 0x9D9E1AE0L, 3155 0xD3D3E1ABL, 0x21B862A8L, 0x32E8915CL, 0xC083125FL, 3156 0x144976B4L, 0xE622F5B7L, 0xF5720643L, 0x07198540L, 3157 0x590AB964L, 0xAB613A67L, 0xB831C993L, 0x4A5A4A90L, 3158 0x9E902E7BL, 0x6CFBAD78L, 0x7FAB5E8CL, 0x8DC0DD8FL, 3159 0xE330A81AL, 0x115B2B19L, 0x020BD8EDL, 0xF0605BEEL, 3160 0x24AA3F05L, 0xD6C1BC06L, 0xC5914FF2L, 0x37FACCF1L, 3161 0x69E9F0D5L, 0x9B8273D6L, 0x88D28022L, 0x7AB90321L, 3162 0xAE7367CAL, 0x5C18E4C9L, 0x4F48173DL, 0xBD23943EL, 3163 0xF36E6F75L, 0x0105EC76L, 0x12551F82L, 0xE03E9C81L, 3165 0x34F4F86AL, 0xC69F7B69L, 0xD5CF889DL, 0x27A40B9EL, 3166 0x79B737BAL, 0x8BDCB4B9L, 0x988C474DL, 0x6AE7C44EL, 3167 0xBE2DA0A5L, 0x4C4623A6L, 0x5F16D052L, 0xAD7D5351L, 3168 }; 3170 #endif 3172 --------- 3173 New text: (Appendix B) 3174 --------- 3176 /* Example of the crc table file */ 3177 #ifndef __crc32cr_h__ 3178 #define __crc32cr_h__ 3180 #define CRC32C_POLY 0x1EDC6F41UL 3181 #define CRC32C(c,d) (c=(c>>8)^crc_c[(c^(d))&0xFF]) 3183 uint32_t crc_c[256] = 3184 { 3185 0x00000000UL, 0xF26B8303UL, 0xE13B70F7UL, 0x1350F3F4UL, 3186 0xC79A971FUL, 0x35F1141CUL, 0x26A1E7E8UL, 0xD4CA64EBUL, 3187 0x8AD958CFUL, 0x78B2DBCCUL, 0x6BE22838UL, 0x9989AB3BUL, 3188 0x4D43CFD0UL, 0xBF284CD3UL, 0xAC78BF27UL, 0x5E133C24UL, 3189 0x105EC76FUL, 0xE235446CUL, 0xF165B798UL, 0x030E349BUL, 3190 0xD7C45070UL, 0x25AFD373UL, 0x36FF2087UL, 0xC494A384UL, 3191 0x9A879FA0UL, 0x68EC1CA3UL, 0x7BBCEF57UL, 0x89D76C54UL, 3192 0x5D1D08BFUL, 0xAF768BBCUL, 0xBC267848UL, 0x4E4DFB4BUL, 3193 0x20BD8EDEUL, 0xD2D60DDDUL, 0xC186FE29UL, 0x33ED7D2AUL, 3194 0xE72719C1UL, 0x154C9AC2UL, 0x061C6936UL, 0xF477EA35UL, 3195 0xAA64D611UL, 0x580F5512UL, 0x4B5FA6E6UL, 0xB93425E5UL, 3196 0x6DFE410EUL, 0x9F95C20DUL, 0x8CC531F9UL, 0x7EAEB2FAUL, 3197 0x30E349B1UL, 0xC288CAB2UL, 0xD1D83946UL, 0x23B3BA45UL, 3198 0xF779DEAEUL, 0x05125DADUL, 0x1642AE59UL, 0xE4292D5AUL, 3199 0xBA3A117EUL, 0x4851927DUL, 0x5B016189UL, 0xA96AE28AUL, 3200 0x7DA08661UL, 0x8FCB0562UL, 0x9C9BF696UL, 0x6EF07595UL, 3201 0x417B1DBCUL, 0xB3109EBFUL, 0xA0406D4BUL, 0x522BEE48UL, 3202 0x86E18AA3UL, 0x748A09A0UL, 0x67DAFA54UL, 0x95B17957UL, 3203 0xCBA24573UL, 0x39C9C670UL, 0x2A993584UL, 0xD8F2B687UL, 3204 0x0C38D26CUL, 0xFE53516FUL, 0xED03A29BUL, 0x1F682198UL, 3205 0x5125DAD3UL, 0xA34E59D0UL, 0xB01EAA24UL, 0x42752927UL, 3206 0x96BF4DCCUL, 0x64D4CECFUL, 0x77843D3BUL, 0x85EFBE38UL, 3207 0xDBFC821CUL, 0x2997011FUL, 0x3AC7F2EBUL, 0xC8AC71E8UL, 3208 0x1C661503UL, 0xEE0D9600UL, 0xFD5D65F4UL, 0x0F36E6F7UL, 3209 0x61C69362UL, 0x93AD1061UL, 0x80FDE395UL, 0x72966096UL, 3210 0xA65C047DUL, 0x5437877EUL, 0x4767748AUL, 0xB50CF789UL, 3211 0xEB1FCBADUL, 0x197448AEUL, 0x0A24BB5AUL, 0xF84F3859UL, 3212 0x2C855CB2UL, 0xDEEEDFB1UL, 0xCDBE2C45UL, 0x3FD5AF46UL, 3213 0x7198540DUL, 0x83F3D70EUL, 0x90A324FAUL, 0x62C8A7F9UL, 3214 0xB602C312UL, 0x44694011UL, 0x5739B3E5UL, 0xA55230E6UL, 3215 0xFB410CC2UL, 0x092A8FC1UL, 0x1A7A7C35UL, 0xE811FF36UL, 3216 0x3CDB9BDDUL, 0xCEB018DEUL, 0xDDE0EB2AUL, 0x2F8B6829UL, 3217 0x82F63B78UL, 0x709DB87BUL, 0x63CD4B8FUL, 0x91A6C88CUL, 3218 0x456CAC67UL, 0xB7072F64UL, 0xA457DC90UL, 0x563C5F93UL, 3219 0x082F63B7UL, 0xFA44E0B4UL, 0xE9141340UL, 0x1B7F9043UL, 3220 0xCFB5F4A8UL, 0x3DDE77ABUL, 0x2E8E845FUL, 0xDCE5075CUL, 3221 0x92A8FC17UL, 0x60C37F14UL, 0x73938CE0UL, 0x81F80FE3UL, 3222 0x55326B08UL, 0xA759E80BUL, 0xB4091BFFUL, 0x466298FCUL, 3223 0x1871A4D8UL, 0xEA1A27DBUL, 0xF94AD42FUL, 0x0B21572CUL, 3224 0xDFEB33C7UL, 0x2D80B0C4UL, 0x3ED04330UL, 0xCCBBC033UL, 3225 0xA24BB5A6UL, 0x502036A5UL, 0x4370C551UL, 0xB11B4652UL, 3226 0x65D122B9UL, 0x97BAA1BAUL, 0x84EA524EUL, 0x7681D14DUL, 3227 0x2892ED69UL, 0xDAF96E6AUL, 0xC9A99D9EUL, 0x3BC21E9DUL, 3228 0xEF087A76UL, 0x1D63F975UL, 0x0E330A81UL, 0xFC588982UL, 3229 0xB21572C9UL, 0x407EF1CAUL, 0x532E023EUL, 0xA145813DUL, 3230 0x758FE5D6UL, 0x87E466D5UL, 0x94B49521UL, 0x66DF1622UL, 3231 0x38CC2A06UL, 0xCAA7A905UL, 0xD9F75AF1UL, 0x2B9CD9F2UL, 3232 0xFF56BD19UL, 0x0D3D3E1AUL, 0x1E6DCDEEUL, 0xEC064EEDUL, 3233 0xC38D26C4UL, 0x31E6A5C7UL, 0x22B65633UL, 0xD0DDD530UL, 3234 0x0417B1DBUL, 0xF67C32D8UL, 0xE52CC12CUL, 0x1747422FUL, 3235 0x49547E0BUL, 0xBB3FFD08UL, 0xA86F0EFCUL, 0x5A048DFFUL, 3236 0x8ECEE914UL, 0x7CA56A17UL, 0x6FF599E3UL, 0x9D9E1AE0UL, 3237 0xD3D3E1ABUL, 0x21B862A8UL, 0x32E8915CUL, 0xC083125FUL, 3238 0x144976B4UL, 0xE622F5B7UL, 0xF5720643UL, 0x07198540UL, 3239 0x590AB964UL, 0xAB613A67UL, 0xB831C993UL, 0x4A5A4A90UL, 3240 0x9E902E7BUL, 0x6CFBAD78UL, 0x7FAB5E8CUL, 0x8DC0DD8FUL, 3241 0xE330A81AUL, 0x115B2B19UL, 0x020BD8EDUL, 0xF0605BEEUL, 3242 0x24AA3F05UL, 0xD6C1BC06UL, 0xC5914FF2UL, 0x37FACCF1UL, 3243 0x69E9F0D5UL, 0x9B8273D6UL, 0x88D28022UL, 0x7AB90321UL, 3244 0xAE7367CAUL, 0x5C18E4C9UL, 0x4F48173DUL, 0xBD23943EUL, 3245 0xF36E6F75UL, 0x0105EC76UL, 0x12551F82UL, 0xE03E9C81UL, 3246 0x34F4F86AUL, 0xC69F7B69UL, 0xD5CF889DUL, 0x27A40B9EUL, 3247 0x79B737BAUL, 0x8BDCB4B9UL, 0x988C474DUL, 0x6AE7C44EUL, 3248 0xBE2DA0A5UL, 0x4C4623A6UL, 0x5F16D052UL, 0xAD7D5351UL, 3249 }; 3251 #endif 3252 --------- 3253 Old text: (Appendix B) 3254 --------- 3256 /* Example of table build routine */ 3258 #include 3259 #include 3261 #define OUTPUT_FILE "crc32cr.h" 3262 #define CRC32C_POLY 0x1EDC6F41L 3263 FILE *tf; 3264 unsigned long 3265 reflect_32 (unsigned long b) 3266 { 3267 int i; 3268 unsigned long rw = 0L; 3270 for (i = 0; i < 32; i++){ 3271 if (b & 1) 3272 rw |= 1 << (31 - i); 3273 b >>= 1; 3274 } 3275 return (rw); 3276 } 3278 unsigned long 3279 build_crc_table (int index) 3280 { 3281 int i; 3282 unsigned long rb; 3284 rb = reflect_32 (index); 3286 for (i = 0; i < 8; i++){ 3287 if (rb & 0x80000000L) 3288 rb = (rb << 1) ^ CRC32C_POLY; 3289 else 3290 rb <<= 1; 3291 } 3292 return (reflect_32 (rb)); 3293 } 3295 main () 3296 { 3297 int i; 3299 printf ("\nGenerating CRC-32c table file <%s>\n", 3300 OUTPUT_FILE); 3301 if ((tf = fopen (OUTPUT_FILE, "w")) == NULL){ 3302 printf ("Unable to open %s\n", OUTPUT_FILE); 3303 exit (1); 3304 } 3305 fprintf (tf, "#ifndef __crc32cr_table_h__\n"); 3306 fprintf (tf, "#define __crc32cr_table_h__\n\n"); 3307 fprintf (tf, "#define CRC32C_POLY 0x%08lX\n", 3308 CRC32C_POLY); 3309 fprintf (tf, 3310 "#define CRC32C(c,d) (c=(c>>8)^crc_c[(c^(d))&0xFF])\n"); 3311 fprintf (tf, "\nunsigned long crc_c[256] =\n{\n"); 3312 for (i = 0; i < 256; i++){ 3313 fprintf (tf, "0x%08lXL, ", build_crc_table (i)); 3314 if ((i & 3) == 3) 3315 fprintf (tf, "\n"); 3316 } 3317 fprintf (tf, "};\n\n#endif\n"); 3319 if (fclose (tf) != 0) 3320 printf ("Unable to close <%s>." OUTPUT_FILE); 3321 else 3322 printf ("\nThe CRC-32c table has been written to <%s>.\n", 3323 OUTPUT_FILE); 3324 } 3326 --------- 3327 New text: (Appendix B) 3328 --------- 3330 /* Example of table build routine */ 3332 #include 3333 #include 3335 #define OUTPUT_FILE "crc32cr.h" 3336 #define CRC32C_POLY 0x1EDC6F41UL 3338 static FILE *tf; 3340 static uint32_t 3341 reflect_32(uint32_t b) 3342 { 3343 int i; 3344 uint32_t rw = 0UL; 3346 for (i = 0; i < 32; i++) { 3347 if (b & 1) 3348 rw |= 1 << (31 - i); 3349 b >>= 1; 3350 } 3351 return (rw); 3352 } 3354 static uint32_t 3355 build_crc_table(int index) 3356 { 3357 int i; 3358 uint32_t rb; 3360 rb = reflect_32(index); 3362 for (i = 0; i < 8; i++) { 3363 if (rb & 0x80000000UL) 3364 rb = (rb << 1) ^ (uint32_t)CRC32C_POLY; 3365 else 3366 rb <<= 1; 3367 } 3368 return (reflect_32 (rb)); 3369 } 3371 int 3372 main (void) 3373 { 3374 int i; 3376 printf("\nGenerating CRC-32c table file <%s>\n", 3377 OUTPUT_FILE); 3378 if ((tf = fopen (OUTPUT_FILE, "w")) == NULL) { 3379 printf ("Unable to open %s\n", OUTPUT_FILE); 3380 exit (1); 3381 } 3382 fprintf(tf, "#ifndef __crc32cr_h__\n"); 3383 fprintf(tf, "#define __crc32cr_h__\n\n"); 3384 fprintf(tf, "#define CRC32C_POLY 0x%08XUL\n", 3385 (uint32_t)CRC32C_POLY); 3386 fprintf(tf, 3387 "#define CRC32C(c,d) (c=(c>>8)^crc_c[(c^(d))&0xFF])\n"); 3388 fprintf(tf, "\nuint32_t crc_c[256] =\n{\n"); 3389 for (i = 0; i < 256; i++) { 3390 fprintf(tf, "0x%08XUL,", build_crc_table (i)); 3391 if ((i & 3) == 3) 3392 fprintf(tf, "\n"); 3393 else 3394 fprintf(tf, " "); 3395 } 3396 fprintf(tf, "};\n\n#endif\n"); 3398 if (fclose (tf) != 0) 3399 printf("Unable to close <%s>.", OUTPUT_FILE); 3400 else 3401 printf("\nThe CRC-32c table has been written to <%s>.\n", 3402 OUTPUT_FILE); 3403 } 3405 --------- 3406 Old text: (Appendix B) 3407 --------- 3409 /* Example of crc insertion */ 3411 #include "crc32cr.h" 3413 unsigned long 3414 generate_crc32c(unsigned char *buffer, unsigned int length) 3415 { 3416 unsigned int i; 3417 unsigned long crc32 = ~0L; 3418 unsigned long result; 3419 unsigned char byte0,byte1,byte2,byte3; 3421 for (i = 0; i < length; i++){ 3422 CRC32C(crc32, buffer[i]); 3423 } 3425 result = ~crc32; 3427 /* result now holds the negated polynomial remainder; 3428 * since the table and algorithm is "reflected" [williams95]. 3429 * That is, result has the same value as if we mapped the message 3430 * to a polynomial, computed the host-bit-order polynomial 3431 * remainder, performed final negation, then did an end-for-end 3432 * bit-reversal. 3433 * Note that a 32-bit bit-reversal is identical to four inplace 3434 * 8-bit reversals followed by an end-for-end byteswap. 3435 * In other words, the bytes of each bit are in the right order, 3436 * but the bytes have been byteswapped. So we now do an explicit 3437 * byteswap. On a little-endian machine, this byteswap and 3438 * the final ntohl cancel out and could be elided. 3439 */ 3441 byte0 = result & 0xff; 3442 byte1 = (result>>8) & 0xff; 3443 byte2 = (result>>16) & 0xff; 3444 byte3 = (result>>24) & 0xff; 3445 crc32 = ((byte0 << 24) | 3446 (byte1 << 16) | 3447 (byte2 << 8) | 3448 byte3); 3449 return ( crc32 ); 3450 } 3452 int 3453 insert_crc32(unsigned char *buffer, unsigned int length) 3454 { 3455 SCTP_message *message; 3456 unsigned long crc32; 3457 message = (SCTP_message *) buffer; 3458 message->common_header.checksum = 0L; 3459 crc32 = generate_crc32c(buffer,length); 3460 /* and insert it into the message */ 3461 message->common_header.checksum = htonl(crc32); 3462 return 1; 3463 } 3465 int 3466 validate_crc32(unsigned char *buffer, unsigned int length) 3467 { 3468 SCTP_message *message; 3469 unsigned int i; 3470 unsigned long original_crc32; 3471 unsigned long crc32 = ~0L; 3473 /* save and zero checksum */ 3474 message = (SCTP_message *) buffer; 3475 original_crc32 = ntohl(message->common_header.checksum); 3476 message->common_header.checksum = 0L; 3477 crc32 = generate_crc32c(buffer,length); 3478 return ((original_crc32 == crc32)? 1 : -1); 3479 } 3481 --------- 3482 New text: (Appendix B) 3483 --------- 3485 /* Example of crc insertion */ 3487 #include "crc32cr.h" 3489 unsigned long 3490 generate_crc32c(unsigned char *buffer, unsigned int length) 3491 { 3492 unsigned int i; 3493 uint32_t crc32 = 0xffffffffUL; 3494 uint32_t result; 3495 uint8_t byte0, byte1, byte2, byte3; 3497 for (i = 0; i < length; i++) { 3498 CRC32C(crc32, buffer[i]); 3499 } 3501 result = ~crc32; 3503 /* result now holds the negated polynomial remainder; 3504 * since the table and algorithm is "reflected" [williams95]. 3505 * That is, result has the same value as if we mapped the message 3506 * to a polynomial, computed the host-bit-order polynomial 3507 * remainder, performed final negation, then did an end-for-end 3508 * bit-reversal. 3509 * Note that a 32-bit bit-reversal is identical to four inplace 3510 * 8-bit reversals followed by an end-for-end byteswap. 3511 * In other words, the bytes of each bit are in the right order, 3512 * but the bytes have been byteswapped. So we now do an explicit 3513 * byteswap. On a little-endian machine, this byteswap and 3514 * the final ntohl cancel out and could be elided. 3515 */ 3517 byte0 = result & 0xff; 3518 byte1 = (result>>8) & 0xff; 3519 byte2 = (result>>16) & 0xff; 3520 byte3 = (result>>24) & 0xff; 3521 crc32 = ((byte0 << 24) | 3522 (byte1 << 16) | 3523 (byte2 << 8) | 3524 byte3); 3525 return (crc32); 3526 } 3528 int 3529 insert_crc32(unsigned char *buffer, unsigned int length) 3530 { 3531 SCTP_message *message; 3532 uint32_t crc32; 3533 message = (SCTP_message *) buffer; 3534 message->common_header.checksum = 0UL; 3535 crc32 = generate_crc32c(buffer,length); 3536 /* and insert it into the message */ 3537 message->common_header.checksum = htonl(crc32); 3538 return 1; 3539 } 3540 int 3541 validate_crc32(unsigned char *buffer, unsigned int length) 3542 { 3543 SCTP_message *message; 3544 unsigned int i; 3545 uint32_t original_crc32; 3546 uint32_t crc32; 3548 /* save and zero checksum */ 3549 message = (SCTP_message *)buffer; 3550 original_crc32 = ntohl(message->common_header.checksum); 3551 message->common_header.checksum = 0L; 3552 crc32 = generate_crc32c(buffer, length); 3553 return ((original_crc32 == crc32)? 1 : -1); 3554 } 3556 3.46.3. Solution Description 3558 The code was changed to use platform independent types. 3560 3.47. Clarification of Gap Ack Blocks in SACK Chunks 3562 3.47.1. Description of the Problem 3564 The Gap Ack Blocks in the SACK chunk are intended to be isolated. 3565 However, this is not mentioned with normative text. 3567 3.47.2. Text Changes to the Document 3569 --------- 3570 Old text: (Section 3.3.4) 3571 --------- 3573 The SACK also contains zero or more Gap Ack Blocks. Each Gap Ack 3574 Block acknowledges a subsequence of TSNs received following a break 3575 in the sequence of received TSNs. By definition, all TSNs 3576 acknowledged by Gap Ack Blocks are greater than the value of the 3577 Cumulative TSN Ack. 3579 --------- 3580 New text: (Section 3.3.4) 3581 --------- 3583 The SACK also contains zero or more Gap Ack Blocks. Each Gap Ack 3584 Block acknowledges a subsequence of TSNs received following a break 3585 in the sequence of received TSNs. The Gap Ack Blocks SHOULD be isolated. 3586 This means that the TSN just before each Gap Ack Block and the TSN just after 3587 each Gap Ack Block has not been received. By definition, all TSNs 3588 acknowledged by Gap Ack Blocks are greater than the value of the 3589 Cumulative TSN Ack. 3591 --------- 3592 Old text: (Section 3.3.4) 3593 --------- 3595 Gap Ack Blocks: 3597 These fields contain the Gap Ack Blocks. They are repeated for 3598 each Gap Ack Block up to the number of Gap Ack Blocks defined in 3599 the Number of Gap Ack Blocks field. All DATA chunks with TSNs 3600 greater than or equal to (Cumulative TSN Ack + Gap Ack Block 3601 Start) and less than or equal to (Cumulative TSN Ack + Gap Ack 3602 Block End) of each Gap Ack Block are assumed to have been received 3603 correctly. 3605 --------- 3606 New 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. Gap Ack Blocks SHOULD be isolated. That means that 3618 the DATA chunks with TSN equal to (Cumulative TSN Ack + Gap Ack 3619 Block Start - 1) and (Cumulative TSN Ack + Gap Ack Block End + 1) 3620 have not been received. 3622 3.47.3. Solution Description 3624 Normative text describing the intended usage of Gap Ack Blocks has 3625 been added. 3627 3.48. Handling of SSN Wrap Arounds 3629 3.48.1. Description of the Problem 3631 The Stream Sequence Numbers (SSN) is used for perserving the ordering 3632 of user messages within each SCTP stream. The SSN is limited to 16 3633 bits. Therefore, multiple wrap arounds of the SSN might happen 3634 within the current send window. To allow the receiver to deliver 3635 ordered user messages in the correct sequence, the sender should 3636 limit the number of user messages per stream. 3638 3.48.2. Text Changes to the Document 3640 --------- 3641 Old text: (Section 6.1) 3642 --------- 3644 Note: The data sender SHOULD NOT use a TSN that is more than 2**31 - 3645 1 above the beginning TSN of the current send window. 3647 --------- 3648 New text: (Section 6.1) 3649 --------- 3651 Note: The data sender SHOULD NOT use a TSN that is more than 2**31 - 3652 1 above the beginning TSN of the current send window. 3653 Note: For each stream, the data sender SHOULD NOT have more than 2**16-1 3654 ordered user messages in the current send window. 3656 3.48.3. Solution Description 3658 The data sender is required to limit the number of ordered user 3659 messages within the current send window. 3661 3.49. Update RFC 2119 Boilerplate 3663 3.49.1. Description of the Problem 3665 The text to be used to refer to the [RFC2119] terms has been updated 3666 by [RFC8174]. 3668 3.49.2. Text Changes to the Document 3669 --------- 3670 Old text: (Section 2) 3671 --------- 3673 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 3674 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 3675 document are to be interpreted as described in RFC 2119 [RFC2119]. 3677 --------- 3678 New text: (Section 2) 3679 --------- 3681 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 3682 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 3683 "OPTIONAL" in this document are to be interpreted as described in 3684 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 3685 capitals, as shown here. 3687 3.49.3. Solution Description 3689 The text has been updated to the one specified in [RFC8174]. 3691 4. IANA Considerations 3693 This document does not require any actions from IANA. 3695 5. Security Considerations 3697 This document does not add any security considerations to those given 3698 in [RFC4960]. 3700 6. Acknowledgments 3702 The authors wish to thank Pontus Andersson, Eric W. Biederman, 3703 Cedric Bonnet, Lionel Morand, Jeff Morriss, Karen E. E. Nielsen, 3704 Tom Petch, Julien Pourtet, and Michael Welzl for their invaluable 3705 comments. 3707 7. References 3709 7.1. Normative References 3711 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3712 Requirement Levels", BCP 14, RFC 2119, 3713 DOI 10.17487/RFC2119, March 1997, 3714 . 3716 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 3717 RFC 4960, DOI 10.17487/RFC4960, September 2007, 3718 . 3720 7.2. Informative References 3722 [I-D.ietf-tsvwg-ecn-experimentation] 3723 Black, D., "Relaxing Restrictions on Explicit Congestion 3724 Notification (ECN) Experimentation", draft-ietf-tsvwg-ecn- 3725 experimentation-07 (work in progress), October 2017. 3727 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 3728 Communication Layers", STD 3, RFC 1122, 3729 DOI 10.17487/RFC1122, October 1989, 3730 . 3732 [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., 3733 Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., 3734 Zhang, L., and V. Paxson, "Stream Control Transmission 3735 Protocol", RFC 2960, DOI 10.17487/RFC2960, October 2000, 3736 . 3738 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 3739 of Explicit Congestion Notification (ECN) to IP", 3740 RFC 3168, DOI 10.17487/RFC3168, September 2001, 3741 . 3743 [RFC4460] Stewart, R., Arias-Rodriguez, I., Poon, K., Caro, A., and 3744 M. Tuexen, "Stream Control Transmission Protocol (SCTP) 3745 Specification Errata and Issues", RFC 4460, 3746 DOI 10.17487/RFC4460, April 2006, 3747 . 3749 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 3750 IANA Considerations Section in RFCs", RFC 5226, 3751 DOI 10.17487/RFC5226, May 2008, 3752 . 3754 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 3755 Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, 3756 . 3758 [RFC6096] Tuexen, M. and R. Stewart, "Stream Control Transmission 3759 Protocol (SCTP) Chunk Flags Registration", RFC 6096, 3760 DOI 10.17487/RFC6096, January 2011, 3761 . 3763 [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, 3764 "Computing TCP's Retransmission Timer", RFC 6298, 3765 DOI 10.17487/RFC6298, June 2011, 3766 . 3768 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 3769 Cheshire, "Internet Assigned Numbers Authority (IANA) 3770 Procedures for the Management of the Service Name and 3771 Transport Protocol Port Number Registry", BCP 165, 3772 RFC 6335, DOI 10.17487/RFC6335, August 2011, 3773 . 3775 [RFC7053] Tuexen, M., Ruengeler, I., and R. Stewart, "SACK- 3776 IMMEDIATELY Extension for the Stream Control Transmission 3777 Protocol", RFC 7053, DOI 10.17487/RFC7053, November 2013, 3778 . 3780 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 3781 Writing an IANA Considerations Section in RFCs", BCP 26, 3782 RFC 8126, DOI 10.17487/RFC8126, June 2017, 3783 . 3785 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 3786 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 3787 May 2017, . 3789 Authors' Addresses 3791 Randall R. Stewart 3792 Netflix, Inc. 3793 Chapin, SC 29036 3794 United States 3796 Email: randall@lakerest.net 3798 Michael Tuexen 3799 Muenster University of Applied Sciences 3800 Stegerwaldstrasse 39 3801 48565 Steinfurt 3802 Germany 3804 Email: tuexen@fh-muenster.de 3805 Maksim Proshin 3806 Ericsson 3807 Kistavaegen 25 3808 Stockholm 164 80 3809 Sweden 3811 Email: mproshin@tieto.mera.ru